It’s easy to find people to do Quality Assurance, it’s hard (and wonderful) to find people that do Quality Assurance right.
There are various ways of testing your product and an associated cost for catching problems late in the development cycle; it’s important to have people testing that understand what your product should do and are dedicated to ensuring it’s perfect (if not appearing evil in finding its flaws before your users do).
Over the decades, we’ve observed different approaches to how to involve Quality Assurance staff:
- give them the specifications and let them built their test plans an scripts
- involve them as early as possible in the development cycle of the product as possible so they can find flaws in the product design as well as understand what they’re testing as early as possible
I’m a huge fan of #2 provided there’s enough slack to engage the QA resources early enough; ideally there should be.
Additionally, QA must understand why they’re doing what they’re doing. If they run tests without having the expertise everyone else on the team has in the product, you have a warm seat testing, but not understanding.
There’s also differentiation between manual and automated testing.
Manual testing should build a foundation of test cases that are categorized by feature and run as appropriate; e.g. the feature was implemented or revised, the underlying architecture was refactored. Additionally, the developers ideally get to consult to ensure the QA team avoid unnecessary over testing when they know it would test unchanged functionality.
Automated testing would implement what’s been done manually in an automated manner after each build cycle providing insight into whether the build is improving or regressing.
For all QA disciplines (manual and automated), it’s important to understand key metrics such as:
- what percent of the functionality has test cases written for it
- what percentage of all functionality has their baseline testcases documented
- what percentage of this sprint’s test cases have been run
- percentage passed, failed (blockers, non-blockers), not yest tested
- Percentage of code coverage
Where does QA work?
It’s hard to answer this without smiling. I’ve seen QA at four in the morning with legs propped on two chairs; the good ones will go to battle for the good of the product and get it done.
Seriously, when needed, they’ll walk over to the developer to ensure the issue is understood and avoid misunderstanding especially as the project’s key milestones are fast approaching; there’s no opportunity to waste time. If they’re remote, they’ll virtually walk over using whatever modern technology they have to effectively communicate, share and demonstrate in real time.
You’ll know where they work because they carry the flag that wants to get it done and done right; you may need to tell them to let go of the issues that can wait.