- We want to do Agile development but it keeps not going well
- We want to do good QA with Agile but how do we do that well
- The plans we have which map our sprints to a timeline keep not working
I’ll talk about some possible root causes to the above.
I’ll often ask what your goals are as an organization and how you are applying a QA strategy to ensure those goals. Then I’ll ask how do you know its a good strategy? A good conversation talks about measurement, evaluation, and action plans.
I’ll pose these scenarios when I am interviewing technical people. The general landscape to a good answer is that a good QA strategy can answer the conceptual questions about who, what, and how you are testing your systems. The way that you build a QA strategy, therefore, is to build a conceptual framework for how you think about QA strategy. Any conceptual framework is better than none, and I will offer a framework here.
So, strategy and tactics are different at both the conceptual level and the level of applying them.
Conceptually, a strategy is an emergent accumulation of the answers to the following 5 questions:
- Who are we?
- What are our ultimate goals here? (Note: Goals answer the question why, and are tightly coupled with who you are. From this conversation you get to know your Values.)
- What do we need to do to achieve those goals?
- How will we do it? (This answer together with your Values form your Mission.)
- What [people, procedures, technology, human] resources will we employ in doing it?
A QA strategy traces the big picture of the system under test into functional modules, test data, operational correctness, and interdependencies into priorities. Remember: Strategy shows priorities. A QA strategy:
- combines values and mission
- to produce a workable plan that
- can be used as a measuring stick to
- see how you are doing at any point along the way in order to
- feed expected value decisions that balance [cost, risk, and reward]
Your QA strategy should identify the anatomy of your system under test, the users, user personas perhaps, user roles probably, how users interact with the system, how the system processes input to produce output, timing diagrams, physical architecture decisions, and recommendations on end to end testing as well as module specific testing. A strategy must be a living document, so keep it short, use pictures whenever possible, and avoid acronyms and technical identifiers.
A QA Plan sequences the resources and actions needed to accomplish the Mission. Remember: Plans show sequencing. A QA Plan:
- Is produced by a strategic expected value decisions which
- Contain measurable, workable, deliverable, verifiable goals which are
- Broken down by the roles needed to accomplish them and
- Assigned to responsible people in those roles who can own the goal
Your QA plan should show who is doing what work and when they’ll probably be done. Your plan shows dependencies and provides solutions for them. Your plan is tied to a staffing plan and why you need the people you need, and possible plays around uncertainties.
The art of good QA management is practicing the above, noting your failures and determining what was missing, fixing it, and doing it again. Good luck!