Describe expected behaviors, reproduce anomalies and verify corrections.
These sheets describe activities and teaching exercises. They do not constitute job offers, certifying courses or recruitment promises.
All job descriptions
Make defects observable and verify project requirements through scenarios, regression checks and evidence supporting acceptance decisions.
Testing cannot guarantee absence of defects. Project owners decide release readiness using risks, blockers and results, with specialists for specialised checks.
Deliver an acceptance matrix and a reproducible defect with expected outcome, observed result and severity.
This is an editorial description of common activities. Job titles and scope vary across teams; it is not a certification framework.
W3C: organising accessibility responsibilities across a team
Establish functional validation of a form successfully, errors, duplicates and recovery.
Work on a copy or demo environment. Define the data used and the expected result before you begin. Keep your decisions and the difficulties encountered in order to be able to explain the process.
A functional validation plan, reproducible anomalies and retest results.
Another person can reproduce the control and understand why the result is accepted.
For each check, note the context, the action, the expected result and what has been observed. Distinguish a successful verification from a remaining hypothesis. Another person must be able to understand the deliverable without attending all its manufacture.
Préparer les vérifications du siteA long list of controls does not replace an accurate expected result. A closed fault without retest can remain present in the actual course.
Collaboration to explore: Project management.
Specify the sharing of responsibilities: who provides the information, who decides, who checks and maintains the result. A good handover retains the constraints and decisions, not just the final file.
Employment, trades and trainingFictional teaching material: this excerpt illustrates part of a deliverable. It is not a client reference, a complete specification or evidence of professional qualification.
Context: three-resource list, empty filter.
Action: enter a word absent from every title.
Expected: no items and an explicit message.
Observed in the defect example: empty list without explanation.
Recovery check: clearing the filter restores all three items.It may illustrate the fault, but also provide the starting state, input, steps and test context. A screenshot alone does not show whether content is absent, filtered or still loading.
Technical reference : W3C WAI · User Notification · Consulted 15 October 2026. The excerpt above is an original teaching example.
These three fictional entries demonstrate a result, an empty state and a return to the full list. Try “mobile”, then a word absent from the entries. No network request is made.
3 examples available.
For the review: use the keyboard, test an accented word and check the result count after clearing. This local list does not demonstrate server loading or network failure handling. Input is not saved or sent.
Useful quality assurance supports an actionable decision, not merely a list of clicks. Tie each check to a risk, expected result and reproducible observation.
| Skill | Evidence to examine | Failure to spot |
|---|---|---|
| Coverage | Essential paths and relevant failures are identified. | Many tests repeat the happy path and ignore interruptions. |
| Reproduction | Context, data and steps allow repeating the test. | A screenshot alone cannot reproduce the defect. |
| Conclusion | Severity and impact are distinguished from visual preferences. | Automated success is presented as complete proof of accessibility. |
Take a fixed defect and first verify its disappearance in the same context. Then check other occurrences of the affected component: this is a justified regression check rather than repeating every test.
W3C WAI: preliminary accessibility checks.
In-depth exercise: Prepare the functional validation of a form and its confirmation with a smartphone version and a computer version. Separate nominal cases, errors and interrupts. For each defect, keep the context, the exact steps and the observed result. Use only test data. A defect does not become corrected because the code has changed: replay the scenario on the corrected version and note the effects on the nearest routes.
These criteria are a working basis to adapt to the context. For each, note the action taken, the expected result, the observed result and the information remaining to be confirmed.
Transmit cases, evidence and open anomalies with their explained priority. Distinguish an impossibility to verify from a compliant result. A team should know what has been replayed after correction and what remains dependent on an external environment. The balance sheet should not promise a universal absence of defects: it precisely describes the checks carried out and the risks still observed.
Verification focuses on the consequences of a defect. Exploratory checks and reproducible scenarios complement each other but meet different needs.
A successful test in one environment does not guarantee success elsewhere. Identify the data, permissions, browsers and dependencies tested.
Classify findings by their consequences for users. Justify the release decision with blockers, known limitations and checks still required.
It allows you to show an approach and its limits. It is neither a diploma, nor a certification, nor proof of a production experience.
Specify that this is an exercise, your role, constraints, decisions and checks. Use test data and media whose rights are established.
Another person can reproduce the control and understand why the result is accepted. Add the difficulties encountered and what remains to be verified rather than presenting absolute validation.
Record known conditions, observed frequency and available logs. Simplify the scenario without hiding uncertainty and distinguish what remains suspected. Describe intermittent defects by their impact and evidence.