In a traditional "quality assurance" model, the goals of a QA team member are pretty clear: testing the developers' work before it gets released, detecting bugs, communicating findings, and advocating for problems to be fixed. With a "quality assistance" model, there are different goals to focus on:
- Empower developers to confidently test by providing training, tools, and environments.
- Help the team to produce high quality software, efficiently.
- Keep tabs on the team's output, and identify where improvements can be made.
- Foresee and prevent problems before they become problems.
These goals require a particular set of skills, which will need to be practised to be effective. A potential pitfall is when QA engineers spend too much of their time on the actual testing tasks, because (rightly or wrongly) they don't have faith in the developers to do a good job. A high-functioning team is one where every member of the team can be relied upon to do a great job at testing, and the QA engineers are focused on solving the big-picture problems.
Quality assistance skills
You will need to convince everybody on the team to genuinely embrace whole-team responsibility for quality. Testing time must be included in estimates for developer story work, and must actually be done. Do away with the expectation that others will catch mistakes: you are not there to be a safety net or gatekeeper. (Or goalie... choose your favourite metaphor.)
How to practice:
Becoming an influencer can take time – you need to gain the respect of the team before telling them what to do. To earn respect you should make sure that the input you are giving is valuable. Don't give your opinion: it's no more valuable than anyone else's just because you come from QA. Instead, provide the team with facts. Collect metrics, examples, evidence to help the decision makers. Accept that you can be wrong, and trust others to make good decisions based on the input you provide.
Providing testing expertise
Developers are experts at coding, but may not have much experience when it comes to testing. You must be able to give accurate and valuable input for high-quality development of individual features and stories. Developers will be doing the testing (and remember, you need to earn their trust), so you want to avoid asking them to do unnecessary tasks "just in case".
How to practice
A skilled tester is able to quickly identify the risks for a particular story or feature. This comes from an understanding of the implementation of a feature, and often the developer is the best source of that information. You can become more effective by asking the developer to explain the implementation details, and by asking questions about how it would handle various scenarios. Exploratory testing is a valuable technique, which takes practice. A potential problem with the quality assistance model is that by doing less of the testing, the QA engineer actually becomes rusty, and it may be necessary to find ways to counteract this.
Developers can test well, as long as they are taught how. You can train them in specific testing skills, to embrace a QA mindset, and to increase their product knowledge to make them better testers.
How to practice
Think back to how you learned to test, and pass that experience on. Design workshops and practice sessions for your developers. Be willing to give advice, pair with them, and answer questions when they have doubts.
Testing has a bad rep in some quarters. If your testing activities are tedious, repetitive, and low-value, then they're doing it wrong. Developers should learn to see testing as a valuable, challenging, and fun activity – and be open to experimenting with process changes.
How to practice
Why do you find testing fun? Is it the challenge of out-smarting the code, or the person that developed it? Is it the thrill of finding an obscure edge-case, or protecting customers against nasty bugs? Share your motivations with the team. Make sure they don't view testing as mindlessly clicking around a UI, hoping to stumble across bugs. If developers fall into that trap they'll resent the activity as a waste of time, and perform it poorly. (Wouldn't you?)
The team needs to be communicating well, and holding each other to high-quality standards. You make this happen by defining the quality bar, by organising testing sessions, and by ensuring that developers have the right tools, right data, and environments they need to carry out their testing efficiently.
How to practice
Set up blitz testing sessions, where you ask the developers to find problems with a specific feature. Make it fun, make it competitive, work with the developers to get them thinking like an experienced tester would. Get everyone involved in the conversations about whether bugs are worth fixing or not, and the reasoning behind it. Make it clear that you aren't a perfectionist requiring that every trivial issue is a must-fix, and come to a team agreement on which classes of bugs are not even worth raising.
While the developers perform the actual testing, you will be looking out for problems and creating opportunities to improve the team's quality, efficiency, and independence. Become a champion of the changes you think are most important for your team, lead their implementation, and be candid in your assessment of their effect – for better, or for worse.
How to practice
Teams should be holding regular retrospectives, ideally every sprint. If your team doesn't, start. This gives you a forum to raise and discuss the problems a team faces, and is an ideal opportunity to start trialling improvements. Sometimes developers are reluctant to change, so be willing to try changes as experiments, and to drop the change if it doesn't provide the benefits as expected. If the process change does show a measurable improvement, then embedding it as a permanent practice should be an easy sell.
Begin your quality assistance training now
As you've probably guessed, improving your quality assistance skills can't be done in a vacuum. But the good news is that you can start honing these skills right now, regardless of where your team sits on the quality assurance to quality assistance spectrum. I encourage you to embrace one of Atlassian's core values and "be the change you seek" on your team. Happy practising, and good luck!