Article archive

Story type: Testy Tips

The Amber Report

A Delivery Manager asked me to replace red with amber before Programme Board because red would distract from the recovery message. I changed the board version to amber, then saved the original red report beside his written request. After the release failed, he said testing had always been comfortable with the risk. Version control is […]

Read article

Name the Owner of Every Release Action

Give every release action one named owner and a deadline. “The team will fix the test data before Thursday” means the tester will discover at 4:45 on Thursday that the team was a fictional employee.

Read article

Turn Nobody Would Do That into a Test

Whenever someone says, “No user would ever do that,” write down the exact action and test it. You are testing the behaviour they are confidently refusing to imagine. Production is full of users who never attended the meeting.

Read article

Use a Fresh User for the Final Check

Repeat critical journeys with a newly created account before release. A six-month-old QA account has usually been made administrator, resurrected twice and exempted from half the rules. It is no longer a user. It is project royalty.

Read article

Put the Decision Beside the Defect

Record who accepted, downgraded or deferred the defect directly on the ticket. “The project accepted the risk” is useless because projects cannot join incident calls and explain themselves.

Read article

Write the Business Answer into the Ticket

When a business rule is agreed during a call, add the answer to the story or defect and tag the person who gave it. Otherwise, by UAT, the rule will have changed and the original meeting will be remembered as a séance attended only by testing.

Read article

Group Defects by Root Cause

Check whether several failures come from one shared component before creating dozens of tickets. Twelve Jira defects for one typo is only efficient when your performance target counts tickets.

Read article