We’ve Inherited a Failing Software Testing Programme. Where Do We Start?
Do not start by rewriting the test strategy.
Article archive
Do not start by rewriting the test strategy.
If testing is delaying the programme, measure the delay before fixing the testers.
Headcount is not assurance.
Fix the thing that is causing the most important risk or waste. Not the thing that is easiest to put on a transformation slide.
You turn around a failing software testing function by making it useful again, not by announcing a quality transformation.
Because automated tests only prove the things they actually check. They do not sprinkle correctness over the application like holy water. A suite can be 100% green and still be largely useless if it is checking the wrong risks, asserting too little,…
Do not begin by asking the delivery team whether they are confident. They have been living inside the programme for months and are usually very motivated to reach the date. An independent review should test the release argument itself. Our independent review…
Sometimes yes. Sometimes absolutely not. ‘Performance testing is best practice’ is not a reason to spend money. If twelve people will use an internal tool and the biggest performance risk is somebody making tea while a report loads, you probably do not…
Developers testing their own code is good engineering. It is not automatically a complete test strategy. A developer is usually very good at proving that the thing they built behaves as designed. A tester is useful when you also need somebody to…
Because busy is not a quality metric. A test team can execute thousands of cases, raise hundreds of defects and produce a dashboard that would make a programme office weep with joy while still missing the things customers actually care about. When…