Story type: Testy Tips

Before spending an hour repeating the same test, ask what code, configuration or data has changed. “Try it again” is not a fix description. It is how people operate broken televisions.

Severity describes the impact. Priority describes how urgently the project chooses to act. A serious defect does not become harmless because the release date is emotionally important.

Start important journeys with the lowest-permission user who should be able to complete them. Administrator access is not a representative customer journey unless the customers have recently taken control of IT.

Include the date, time and timezone when reporting intermittent, integration or logging issues. “Just after lunch” is only searchable if the developer also knows what you ate.

A defect should say what happened and what should have happened. “Page broken, please investigate” is not test evidence. It is a cry for help with a Jira number.

Ask who has authority to approve or reject the release before the final meeting. A room full of people nodding cautiously is not governance. It is a group photograph waiting to happen.

Temporarily break the feature and confirm the automated test catches it. A test that always passes is not stable. It is decorative.

Confirm the version, database migration and feature flags are actually present before starting a full retest. There is no professional satisfaction in producing twelve pages of evidence against yesterday’s build.

Check whether duplicate clicks, timeouts and automatic retries create duplicate payments or orders. Users will click once. Then twice. Then fifteen times while loudly blaming the website.

Capture the acceptance criteria before testing begins. Requirements have an extraordinary ability to improve after a defect proves they were wrong.