Observe
Choose signals that reveal user impact, not dashboard noise.
Practical software testing · Cohort field studio
Find the weak seam before traffic does.
Learn to turn vague risk into observable tests, controlled failures and release evidence. Pudafexori is a guided studio for developers, QA engineers and technical leads who want a repeatable reliability practice.
Stress
Introduce one controlled failure and preserve a clean comparison.
Decide
Turn traces and notes into a release decision with named owners.
01 · Starting grid
Baseline diagnostic
Set your role, system boundary and immediate risk. The diagnostic proposes a first lab, an evidence source and a review owner; it does not grade your experience.
Application developer · critical journey · latency
Instrument one real journey before adding load.
Capture navigation timing, API spans and one user-visible threshold. Your first lab compares a clean pass with a deliberately slowed dependency.
- Evidence
- A paired trace and annotated timing waterfall
- Review owner
- Developer with a QA partner
02 · Observation deck
Four test sectors, one shared evidence habit
Sector 01
Critical journey timing
Measure the steps a user notices, then connect each delay to a trace, request or render boundary.
- Choose one repeatable journey.
- Record clean and stressed passes.
- Define the user-visible threshold first.
03 · Controlled pressure
DELAY MODE
Fault injection, without theatre
Choose one disturbance. The console explains what to hold constant, what to observe and when to stop the exercise.
Slow one dependency, not the whole system.
Introduce a bounded response delay and watch queue depth, retry behaviour and user-visible completion time.
Hold constantTraffic shape
Stop whenError budget crosses 20%
05 · Course map
Six sectors, each producing evidence
The course alternates short briefings, facilitated labs and review sessions. A typical cohort spends four to six hours each week across six weeks.
Build: a service map and three user-facing thresholds. Lab: record a clean journey and challenge the completeness of its telemetry.
Build: a small boundary with known inputs and outputs. Lab: isolate unstable dependencies without hiding real behaviour.
Build: safe stop conditions. Lab: inject delay, capacity loss and dependency failure one variable at a time.
Build: a shared timeline. Lab: connect technical traces to the user experience and the team response.
Build: a reversible recovery action. Lab: test ownership, rollback and communication under time pressure.
Build: a concise release gate. Lab: defend a go, hold or limited-release decision with visible evidence.
06 · Pit review
Four lenses for a useful review
Filter the board to focus the conversation. A selected lens expands into a full-width image-and-evidence panel rather than shrinking into an orphan card.
What changed first?
Place the earliest trustworthy observation beside the user-visible symptom and remove metrics that arrived after the decision point.
What action was available?
Name the safe action, its owner and the information required to take it. Record uncertainty rather than hiding it.
What will the next lap prove?
Convert one unanswered question into a narrower experiment with a clear comparison and stop condition.
07 · Release gate
Choose a decision strength
Move the gate to see how much evidence a decision needs. This exercise teaches proportional confidence; it is not an automated production approval.
LIMITED RELEASE
Protect the boundary while you learn.
Use a smaller audience, named owner and short review window. Keep rollback ready and record the comparison.
08 · Inclusive conditions
Reliability includes access
A fast system can still fail people. The accessibility sector combines keyboard, focus, contrast, zoom and assistive-control checks with the same evidence discipline used for latency and recovery.
Keyboard path Visible state Announced change Zoom resilience
Accommodation requests can be included in the application form. They do not reduce assessment expectations; they change how practice is delivered.
09 · Track desk
Questions before the first lap
Search the rulings or open each answer. If your situation is unusual, use the application form and describe the constraint.
No matching ruling. Clear the search or send the question through the application form.
Developers, QA engineers, SREs and technical leads who can read application behaviour and participate in a staging or sandbox exercise. You do not need prior chaos-engineering experience.
A safe non-production environment, permission to inspect logs or traces, and one small system boundary are enough. The course never requires production credentials.
Assessment uses the clarity of your hypothesis, safety of the exercise, quality of evidence and strength of the next decision. A dramatic failure is not considered a better result.
Bring the monitoring and test tools your team already trusts. Examples use vendor-neutral concepts, and the facilitators help identify the smallest missing signal.
No. Completion records the work you performed in this studio. It is not third-party accreditation and does not guarantee employment, promotion or a specific reliability improvement.
Cohort dates are fixed, but individual labs can be paced around maintenance windows. Contact us early if access, time zone or accommodation needs affect participation.
10 · Application bay
Bring one system and one honest risk.
Tell us what you want to practise. We use the note to recommend a starting sector; submitting the form does not reserve a seat or create a paid engagement.