A straightforward tester journey
One short introduction, one focused test and feedback that can be acted upon.
The intended journey seeks to reduce installation effort. Its actual effect on starting and understanding a test remains a benefit to be measured through documented feedback.
Before installing anything, the tester should be able to understand the problem addressed, the expected result and the safeguards.
Android and Desktop access follow different arrangements. The exact build and its capabilities must be confirmed for each identified tester.
Fictitious or anonymised material should be used whenever possible.
- Understand the test before installing.
- Use only the build and instructions supplied for the test.
- Prefer fictitious or anonymised material.
- Report both helpful and blocking experiences.
1. Understand before installing
Start with a short explanation of the problem, intended benefit and limits of the Alpha. The introductory scenario aims to take about five minutes, but actual time varies.
- short orientation
- visible safeguards
- no promise of an outcome
2. Use the supplied test build
Use an Android or Desktop Alpha build only after its access, version, fingerprint, date and distribution authorisation have been confirmed.
- platform-specific instructions
- identified testers
- capabilities checked against the supplied version
3. Test with safe material
Use a fictitious or properly anonymised letter and observe whether the explanation and next steps are understandable. Any analysis may contain errors and requires review.
- no unnecessary personal data
- review the analysis
- check what still needs human verification
4. Share useful feedback
Describe what helped, what caused difficulty and what should be made clearer or more accessible.
- what worked
- what was missing
- what should be simplified
Concrete scenarios
Three intended scenarios for assessing whether the project may be useful.
These scenarios describe test objectives, not proven capability, availability or measured benefit.
A scenario should make it possible to judge clarity, accessibility and caution.
The purpose is to identify improvements, not to demonstrate that the Alpha is complete.
- Clarity of explanations
- Accessibility of the journey
- Usefulness of the proposed next steps
- Visibility of limitations
Understand a letter
Identify important information, dates and possible next actions without presenting the output as an official decision.
- important information
- deadlines
- points to verify
Prepare a child's case file
Bring together school information, needs, documents, appointments and explanations in a clearer structure.
- school context
- document organisation
- human review
Explain an invisible difficulty
Turn pain, fatigue or isolation into careful, understandable facts without inventing a diagnosis.
- lived experience
- factual wording
- explicit uncertainty
Test method
Test without unnecessary risk and without promises.
A short test should examine understanding, outputs and safeguards before feedback is submitted.
Choose a scenario such as a letter, case file, appointment, supporting document or refusal.
Observe whether the explanations are clear, cautious and useful.
Check any available outputs against the capabilities of the supplied build.
Report what helped, what is missing and what should be simplified.
- Choose one scenario.
- Assess comprehension.
- Review the outputs and their limits.
- Provide concise feedback.
Frequently asked questions
Questions about this page
Should real personal documents be used during the test?
Fictitious or anonymised material should be preferred whenever possible.
Do Android and Desktop always provide the same functions?
No. Access, capabilities and qualification depend on the build supplied to the tester.
Does Alpha testing validate a right or an administrative outcome?
No. Testing assesses clarity, accessibility and usefulness; competent professionals and institutions retain their responsibilities and decisions.