Article archive
Dashboards are useful until people start managing the dashboard instead of the risk. A pass rate is not good news by itself. Ninety-nine routine checks can pass while the one failed test proves customers cannot pay. The percentage is technically accurate and…
Not automatically. Different teams working on different risks should not be forced into identical testing just so a governance diagram looks tidy. A data platform, mobile app and internal admin service may need very different approaches. Standardising every test template and ceremony…
There is no universally correct box on the organisation chart. What matters is whether testing has enough independence, authority and access to tell the truth. Reporting into engineering can strengthen technical collaboration and automation. Reporting into delivery can connect testing closely to…
Yes, a bit. No, not nearly as much as some recruitment processes pretend. I say that as someone who has more qualifications than you can count. Qualifications can give people a useful common vocabulary and a structured introduction to testing. ISTQB Foundation,…
Ignore the size of the team for a moment. Ignore the glossy methodology. Ignore the slide showing 14 global delivery centres. Ask what risk the supplier has actually helped you understand or reduce. This is exactly the sort of supplier review where…
Sometimes. Outsourcing can give you specialist capability, independence and flexible capacity. It can also give you a remote team executing a script nobody understands while your internal staff spend half their week explaining the product to them. If you are considering outsourcing,…
Start by refusing to answer the question with headcount, test-case volume or automation percentage. A large QA function may be excellent value if it protects critical revenue, catches expensive failures early, provides strong independent assurance and helps delivery improve. It may be…
Read it and ask whether it changes what anybody actually does. A good test strategy explains the important risks, how the organisation intends to get evidence about them, where responsibilities sit, what environments and data are needed, what gets automated, which specialist…
Enough to support good testing, evidence and decisions. No more. Documentation is useful when it prevents knowledge disappearing, makes important coverage repeatable, records decisions, explains risks or helps another person understand what happened. It becomes waste when the team spends more time…
Then you have test execution, not assurance. It is entirely possible to have a large test team and still reach the launch meeting with nobody willing to answer the only question anybody cares about: what do we know, what do we not…