Quality assistance: how Atlassian does QA

We threw out the traditional QA model (and we're pretty happy with that decision)

Atlassian’s QA team works with development teams to help ship features quickly and safely. Traditional testers help to ship safely by doing the testing, but this can have the side-effect of slowing the team down. When bugs are found in a testing stage, fixing them requires rework of existing code, taking extra time. The team is then put in a position where they have to decide between shipping quickly or safely.

At Atlassian, we optimised the process by empowering and educating developers to test their own features to production quality standards. We evolved this over time by keeping the ratio of testers:developers low – not because of resource constraints, but to force the “whole team” mentality when it comes to quality. As developers learn to build quality into their features from the start, rework is reduced, and the team can achieve both quick and safe delivery. A QA engineer becomes the facilitator for this, instead of the individual performing the tests. We call this model “quality assistance”, reusing the term coined by Cem Kaner in The Ongoing Revolution in Software Testing.

The guiding principles of quality assistance

That's a pretty radical shift from the traditional model. And as such, our goals are more about what we can help development teams achieve than about bug counts and time-to-resolution. 


Development teams should be delivering software that works under all conditions. They should not expect other teams, users of dogfooding instances, or customers to find their bugs. 


Development teams should be able to ship their features to production in as short a time as possible. They should not write code that does not get shipped, and should minimise the need for rework. 


Development teams should be able to write features, test those features, and deliver them to production themselves. They should not rely on QA, or other teams, which may act as bottlenecks.


The high-level process described here has evolved by innovations over time. Each team has its own context, and is expected to make changes to adapt this process, and to validate the results of those changes.

The quality assistance process

I'll describe the QA process that teams at Atlassian use, which your team can implement and adapt. As teams move towards this process, they will generally experiment with additional techniques that aid the team goals of quality, speed (or both) such as...

  • Blitz testing: many people performing a time-constrained test session
  • QA kickoffs: pairing to brainstorm on testing notes before the coding starts
  • Dogfooding: internal use of new features before they are pushed to production (as in "eating your own dog food")

To be sure, there are some assumptions are baked into this process: that teams are agile, they have the goals of quality and speed, and they work on issues in the form of epics, stories, tasks, and bugs. The crucial part is the step done by the developer, which includes coding and testing. After this stage, we do a QA demo to confirm that the testing was done (not to repeat the testing). Once the story or issue is marked as done, it is ready to ship – no additional testing is required or expected.

We believe that the ability to test well is not some magical 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.

Keep reading to learn more about transitioning to a quality assistance model, and honing your skills for it. See you on the next page!

Posted by Mark Hrynczak in QA

6 min read

Tools we use