This is the first in a series of blogs on Atlassian QA. We will cover how the QA strategy has been implemented in different teams, the tools and techniques we use, and the personal experiences from members of the team.
True, it’s an assumption – but probably a safe one – that the majority of professional software testers can’t code. This seems to be the cause of perennial hand-wringing by some testers who feel the need to justify their lack of technical skills, and frustrated developers who interact with them. An even safer assumption, however, is that most developers can’t test. Curiously, this doesn’t garner much debate or discussion, despite it being of far greater importance and concern to successful software development.
To be fair, a large number of people claiming to be professional testers can’t test either. Manually executing steps from a test script, especially one written by someone else, rarely comes close to actual testing. Unsurprisingly then, automating the execution of similar test steps doesn’t make developers proficient testers either. So who does know how to test?
Who should test?
Think of the best tester you’ve ever encountered. Most organizations often have one tester who can find significantly more – and significantly nastier – bugs than everyone else, and they do it surprisingly quickly. They’re the people who know how to test. Unfortunately this skill is often assumed to be some sort of magical power to “break software” bestowed on a select few at birth, and therefore alarmingly little attention is placed upon developing this skill in others. But imagine if that wasn’t the case. Imagine if everyone involved in software development, testers and developers alike, were all thinking and testing like the best tester you’ve ever encountered. Such a team would produce exceedingly higher quality software, far more efficiently. So why isn’t this the norm?
Partly it’s due to traditional approaches to software development (such as waterfall), emphasizing requirement traceability and test repeatability over good testing. For these teams, the priority is on how many tests passed or failed rather than on which tests were valuable or not (which partly explains the legion of testers who aren’t very good testers). Furthermore, the traditional notion that testers need to be independent from developers in order to be effective not only creates a “wall” between test and development teams that discourages developers from caring about the quality of their work, it also obscures great testing. This prevents developers from recognizing, understanding and learning it. The testing profession is also to blame for doing a poor job at communicating and promoting such skills.
Agile methodologies avoid the quality “wall” problem by taking a whole team approach to quality. But when developers find themselves responsible for testing, typically they’ll try to solve this the same way they solve most problems: through code, in the form of automated tests. Test automation is crucial, but automation proficiency can be mistaken for good testing skills by developers who have never been exposed to, let alone taught, great testing skills (the Dunning-Kruger effect). The fact that agile’s early adopters were primarily developers, and that agile advocates teams of generalists over specialists, also means that testers have had to expend a lot of effort justifying their place in agile teams over the years (and for many the struggle continues), instead of teaching testing skills to a willing and eager team.
Enter Atlassian QA
At Atlassian we take a different view. Our QA strategy is founded on the idea that:
- The ability to test well is not some magical genetic trait, but a skill that can be taught and learned.
- Developers that master testing not only increase the efficiency and capacity of their teams, but also write higher quality software.
- When testing can be confidently shared with developers, the people who are passionate about quality, such as great testers, can focus on solving the root causes of quality problems in addition to discovering their symptoms.
Consequently, everyone on our development teams is responsible for quality and the role of our QA team is to help people succeed with fulfilling their responsibility. As a result our QA team doesn’t provide quality assurance, but rather quality assistance; helping developers be good testers is an important part of this work. In this blog post series, the Atlassian QA team will explore our approach in detail and explain how we’ve implemented that strategy, the challenges we’ve faced and benefits we’ve achieved as a result.