If you want to be a Kick-Ass developer you care about the quality of your software. The QA shouldn’t be responsible for finding your bugs. At Atlassian QA means Quality Assistance. For each 13 developer there is one employee working in QA. And we think this a great ratio! Sometimes QA departements see themselves as the quality keeper of the company and often they are a bottleneck within the organisation. Features are new Versions are waiting for the approval to be released.
Developers are Tester
..or as we call it at Atlassian DOT -> Developer on Test! We want our developers to test the features they produce to raise the awareness for quality. We want to move fast so we have a passion for quality but are not obsessed with it. So Developer picking tasks from other Developers and test them. This way developers are feeling more responsible for the quality they produce. It helps them focus on quality when they implement the code. There is not a QA that will find the bugs, just the person next desk. The QA is focusing on providing the Tools for screenshots, picture comparison , test automation frameworks, data generation and so on. Some features are still be tested be a QA employee. These are normally the risky features, that require some more attention and test knowledge.
More Test Awesomeness
To make DOTing really rockin we implemented some more things:
Training: Every developer get some training lessons from the QA about how to test and what to look after.
Pairing Sessions: A developer and a Tester are pairing. This is also part of the DOTing education. The developer is doing the actual testing and the QA person is giving tips and tricks how to become more effective. This helps also the QA team to get a better understanding of the developers mindset.
Split Sessions: In split sessions a developer and a QA employee is testing the same feature at the same time but separately. After the split sessions the two come together and discusses what they found. This way the testing becomes a little bit of a competition where everybody wants to find the most issues and the developer can become better by learning from the QA person.
Blitz Test: In Blitz tests our QA is inviting developers from all over the company to participate in a time boxed test session. The more the better. We are normally testing new features of our software. Some people get the task to test something specific like different browsers others just have to try to break it. The best tester (decided by a jury) gets a cool Blitz Test winner shirt.
Test Recipes: After educating so many great tester the QA employees start writing a test recipe for a feature. It tells the developers what the QA recommends to test. These are done in Bonfire test session so the documentation of test is directly connected to the feature in JIRA. At the moment this is the holy grail of our testing strategy. The QA is only involved in giving advices and it scales quite well. We don’t need an army of QA employees.
Bug Hunter: Another thing we’re currently trying is to implement a bug hunter in the team. Each day or second day one person from the team plays the bug hunter. His task for the day is to find bugs in the currently developed features. This raises the awareness for quality even more.
More Awareness for Quality
The goal of the QA team at Atlassian is it not to get more people but to be more efficient. With Developers on Test the QA gets more time to work on strategy and it scales way better than doing all tests themselves. They can work on cool tools like a “Flaky Test Detector” or QA plugins for JIRA. For developers it raises the awareness for quality. Before we started with DOTing 36% of fixed bugs got rejected. No we are down to 7%!
Kick Ass software developer
- are accountable for the quality of the software they produce
- care about good quality but are not obsessed with it. Speed is still the key for Kick-Ass software developement
- love the idea to test the software themselves and don’t have to rely on the time schedule of a QA person
- are willing to learn how to test better and faster with more fun
Sven Peters 
Thanks Sven for the informative post. I like the concept of “Developer picking tasks from other Developers and test them.” as it builds upon peer code reviews which already identifies many issues.
How effective is DIT at finding the complex bugs related to missing, misunderstandings or conflicts within in the requirements? People often talk about the developer mindset of “How do in build this” and the tester mindset of “How do I break it” or “Does this meet the business/customer need”. This tester mindset is quite important for identifying theses issues.
As requirement related defects are the most costly defect to fix, we use ATDD (Acceptance Test Driven Development) in the development of Behave for JIRA (http://hindsighttesting.com). This allows the tester mindset to applied on the requirements and everyone writes test scenarios before coding starts. The core idea is our Acceptance Tests become our requirements document for the developers. We find this maximises the input of the testers and reduces very costly defects.
So what level of testing are we talking about here? In unit-testing i can definitely see coders testing each others code. In integration and system testing it’s never been about testing “my own” stuff since at that point we’re dealing with hundreds or thousands of components that must work together. Insisting that a coder should do that testing just means you loose coding-capacity. How is that efficient?
Hi Alex, thanks for your comment. We’re talking about manual testing here. The stuff that testers do to make sure the end-user has a great experience. We had quality issues by just doing automatic testing. So every front facing feature is going through a manual test. The coders are actually testing the user stories that other coders has implemented. Of course we loose coding capacity but we win accountability. The coders feel much more responsible for their work if it is not another group testing the stuff for it. Have you ever worked with a QA departement? Sometimes they become bottlenecks if you’re in front of an release. Why should we in that phase produce more code and don’t help the testers with testing? Just because we’re specialists in coding? This doesn’t help the product and sounds wrong to me!
Hi Sven and thanks for your reply.
I certainly understand the gains if going from an organization where testers were located in a separate QA department. I never worked for such a company, even when having had hundreds of colleagues. And I can see where you’re coming from.
But put the tester in the team! We can’t be experts on everything. WE do it together. The kick-ass product development. And as a coder, I can only be accontable for that which I have some control over, and that is before high-level integration if not doing something fairly simple.
Great blog. Thanks.
Great Alex to see we’re on the same page here. At Atlassian we have also testers sitting in the teams helping and training the devs how to better test. W ewant to work together as one team that makes a kick-ass product!