A testing report has one purpose. It should let the creator understand what happened and act on it. A report that says the app did not work names a problem but gives no way to fix it. A report that says exactly what you did, on which device, with what result and how serious it is lets the creator reproduce the issue, rank it and fix it.
This guide covers the parts of a useful report and ends with a template for CESXY Paid to test tasks.
Steps to reproduce
The most valuable part of a bug report is a precise sequence of steps that reliably causes the problem.
Start from a known point. Give the exact address, whether you were signed in and any earlier state that matters, such as a new account with nothing saved.
Write one action per step, in order. For example: Step one, open the project at the address in the brief. Step two, choose New list. Step three, paste the sample text from the brief. Step four, choose Generate.
Separate expected and actual results. Expected: a grouped shopping list appears within a few seconds. Actual: a loading indicator stays on screen for more than a minute and no list appears.
Say how often it happens. Every time, some of the time or once. Give the count of attempts if you have it. If you could not reproduce it, say so. That is still useful.
Evidence
Evidence lets the creator see what you saw.
Screenshots and recordings. Capture the screen when the problem happens. For a sequence of events, a short recording often says more than several screenshots. Before you share an image, check that it shows no personal information, such as your email address, notifications or other open tabs.
Timings. When speed matters, record how long the page took to load, how long the core action took or how long before an error appeared. Approximate figures are fine if you mark them as approximate.
Device and environment. For each finding, note the device type and model, the operating system and version, the browser and version, screen size or orientation if relevant, and unusual network conditions.
Console errors. If you are comfortable doing so, open the browser's developer console and copy any errors that appear with the problem. This is optional and often helps.
Severity and opinion
Creators have to decide what to fix first. A report that separates defects from preferences makes that easier.
Use a simple scale. Critical means the core action cannot be completed, or data is lost or exposed. Major means the core action works only with difficulty or a workaround. Minor means the project works but something is wrong or inconsistent, such as a misspelt label. Suggestion means it is not a defect but an idea, such as an export option.
Mark opinions as opinions. The button is hard to see in daylight is an observation from use. I dislike the colours is a preference. Both can go in a report when the brief asks for views. Label them differently, and do not file either as a defect.
Keep it professional. Our Community Guidelines apply to every report. Be specific, be fair and criticise the project, not the person. Negative findings are welcome. Abusive language is not.
Report template
Copy the lines below into your report and fill in each one.
Testing report
Task or brief reference:
Tester:
Date and time of testing, with time zone:
Environment
Device:
Operating system and version:
Browser and version:
Signed in: yes or no
Summary
Core action completed: yes, no or partly
Overall summary in two or three sentences:
Findings
Finding one, title:
Severity: critical, major, minor or suggestion
Steps to reproduce, one per line:
Expected result:
Actual result:
Reproducibility, for example five of five attempts:
Evidence, with a screenshot or recording reference:
Repeat the finding block for each further finding.
Answers to the brief's questions, one per question:
Additional observations, marked as opinion:
A last read before you submit
Read the report once as the creator would. Check that every finding can be reproduced from your steps, every finding has a severity, no evidence shows personal information, every question in the brief has an answer and opinions are marked as opinions.
A report that passes this read is one a creator can act on straight away. That is the measure of a useful test.