ICT Quality Engineers and Test Analysts
Develop procedures and strategies to support, create, maintain and manage technical quality assurance processes, guidelines and systems infrastructure, investigate, analyse and resolve system problems and performance issues, and test the behaviour, functionality and integrity of systems.
Two days before the app goes live
You are a test analyst on a small team, with two days left before a booking app goes live for thousands of customers. It is Wednesday morning. Launch is Friday. You have a list of tests still to run, a new feature added late, and a stack of messages from people who want to hear that everything is fine.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
I've just added a quick change to the payment screen. It's tiny, honestly, and I'm sure it's fine. Can you skip the full regression and just check the main path? We're really short on time.
Agree and check only the main path, because Jamal knows the code best and the deadline is close
The main path works, but the change breaks something on the edge of the screen. It is found by a customer in the first hour of launch. Small changes are where big surprises hide.
Run the payment screen tests and tell the team which others you have skipped
You find a small mistake in the change within an hour, and Jamal fixes it. The team knows the risk it is carrying. Testing is about choosing where to look as well as what to look at.
Insist on the full set of tests, regardless of the time left before the launch
You are thorough, but the full run takes most of a day and blocks other fixes. Doing everything is not always the best use of the time you have.
You've found a bug in the seat selection, but it only happens when you swap seats twice. Surely nobody will do that. We've promised Friday and I'd like to ship. What is the real risk?
Show her how a family would run into it, explain the effect and suggest a quick fix or a warning
Brigid sees the example and agrees to a fix, but you did not quantify how likely it is, so the argument is about feelings. A clear picture of the impact was useful, and so is a sense of how often.
Say it is not your decision, you have reported it and the rest is up to her and the team
The bug ships. Brigid never fully understood what you meant and later says she wishes you had been clearer. Reporting is not the same as helping someone decide.
Show her a short screen recording, say who it would affect, and suggest two options
Brigid watches it twice and picks a quick fix. Because you gave her a choice, she feels in control and not overruled. Good testers help others decide well.
I've been testing the cancel button and everything passes, so I think I'm done. But I don't really know what else to check. Is it okay if I just sign off?
Sit with her for ten minutes and ask what a stressed customer might try that the plan didn't cover
Nina comes up with three new ideas, and one of them finds a small fault. She sees that testing is about imagination as well as ticking boxes.
Tell her to sign off if the test cases pass, because that is what the plan asks
It is correct by the plan, but Nina learns nothing and the plan has gaps. Passing the tests and finding the problems are not always the same.
Take the task from her and finish it yourself, to save time
You get it done faster, but Nina feels she was not trusted. The next time she's stuck, she may not ask.
How it went
The late change was checked, the seat bug was fixed and Nina learned to think like a customer. Testers protect other people's work by asking awkward questions at the right time, and they need to be both careful and kind. Would you rather build things, or try to break them?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The refund that charged twice
A fictional case set in a small software team at a fictional ferry company, building a booking and refund app.
The situation
Alicia was a test analyst at Pelican Bay Ferries, building an app for booking and refunds. Two days before launch, she tried cancelling a booking just as the payment was being finalised, and the app took the money a second time. It happened only once in about thirty attempts, and she could not make it happen again straight away. The product owner said it was a rare fluke and the launch had been announced to customers.
What they did
Alicia did not argue about how rare it was. She recorded exactly what she did, with screen recordings and the times, and ran the test another forty times to find a pattern. She found that it happened when the phone briefly lost signal. She showed the product owner what a customer would see, and explained that a double charge on a family holiday booking would be a bad first week. She proposed a small delay in launch and a fix.
How it turned out
The developers fixed the fault in a day, and Alicia ran the tests again. Launch slipped by three days, and the product owner was grumpy about it. After launch, the app handled refunds without trouble, and the team added a rule that tests must include a weak signal.
What would you do?
- How would you convince someone that a rare bug still matters?
- What would it feel like to be the person who delays something everybody is excited about?
- Do you enjoy trying to break things, and finding out exactly how they break?