What type of QA engineer are you? Quality Assurance, or Quality Assistance?
At Atlassian we take a “quality assistance” approach to QA in order to optimise our release process for both quality and speed. Quality assistance, first coined by Cem Kaner, is based on the idea that a QA engineer is a facilitator for high product quality, instead of the individual performing the tests. Quality Assistance helps developers build quality into their features from the start, reducing the work and rework cycles that a traditional quality engineer and development team would go through.
In a quality assurance model, the usual goals of a QA team member are: 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, including providing training, tools, and environments for developers to test, helping streamline and improve software development processes, and preventing issues before they become bugs.
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. These goals require a particular set of skills, which will need to be practised to be effective. Here are 6 main skills to start developing:
1. Influence
A little bit of influence goes a long, long way. To make a quality assistance model work, you’ll need to convince the whole team to take responsibility for quality. Include testing time in estimates for developer story work, and actually get it done. Do away with the expectation that others will catch mistakes: you are not there to be a safety net or gatekeeper.
How to practice:
Becoming an influencer can take time – you have to gain the team’s respect before suggesting changes. Make sure that the input you are giving is valuable (i.e. don’t give your opinion, 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.
Data is a more valuable input than an opinion.
2. Testing expertise
Developers are experts at coding, but may not have much experience at testing. You must be able to give accurate and valuable input for the development of individual features and stories. Since developers will be doing the testing (and remember, earn trust first), 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 feature implementation, 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, and it takes practice. A potential problem with the quality assistance model is that by doing less of the testing, the QA engineer actually becomes rusty, so it may be necessary to find ways to counteract this.
3. Teaching skills
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.
A quality assistance engineer is as much an educator as they are anything else.
4. Inspiration
Testing has a bad rep in some quarters. If your testing activities are tedious, repetitive, and low-value, then you’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 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?)
5. Facilitation
The team needs to be communicating well, and holding each other to high-quality standards. You can 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.
How to win at team testing: make it fun, make it competitive.
6. Identifying problems
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 do this, then start. This gives you a forum to raise and discuss the problems a team 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.
Can’t stop, won’t stop
As you can see, improving your quality assistance skills isn’t 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 assurance-to-assistance spectrum. Check out some of our other resources to take your team testing to the next level.
Read more about Quality Assistance
Did you find this post useful? Share it on your social network of choice so your fellow QA engineers can get these tips, too!