Development Versus QA: Ending The Battle With Automation

Accepting this conflict fails to grasp the bigger picture: that both teams should be working towards the same goal. Both developers and QA engineers are responsible for ensuring speedy software quality. Sources of conflict can become sources of mutual strength and cohesion.

The roles: Developers vs. QA engineers

Developers are responsible for building software. They’re heavily incentivized to ship code as quickly as possible, as many teams put emphasis on short software development lifecycles to hit KPIs and maintain developer velocity in competitive marketplaces. QA engineers are responsible for testing the software written by developers in order to catch defects and ensure that the software meets project requirements.

As such, it seems like the two roles naturally conflict. When viewed as competing teams, QA engineers have no incentive to work quickly, as their responsibility is to catch as many defects as they can. It’s not always clear whose responsibility it is to fix bugs that are caught by QA, and a lack of policy regarding ownership of bugs can cause further issues. It should fall to the developers to fix bugs, but a slow turnaround from shipping code to getting test feedback can frustrate developers, who need to refamiliarize themselves with code written possibly days ago.

Developer-based testing vs. QA-based testing

Businesses in situations such as these often find themselves stuck in ‘iron triangle’ thinking, whether they realize it or not. It’s not unreasonable to assess the situation and conclude that developers and QA engineers are conflicted between speed, quality, and cost. Developers move quickly to ship software and generate revenue, whereas QA slows developers down but is necessary for catching bugs and ensuring software quality. Resolving this conflict generally comes down to favoring one side over the other.

Some teams argue for developer-based testing. Developers are already much more familiar with the code than QA testers, and they already do a lot of casual testing while writing the code. Some software methodologies, such as test-driven development, even demand the developers write tests for code before they begin writing the code itself. Writing tests at the same time as writing the code can be quite efficient and allows the developer to keep the same headspace while writing both. For code-level testing (such as unit and API testing), it’s hard to argue with this approach.

Other teams argue for wholly QA-based testing. Making developers write tests takes time away from writing code. When deadlines matter, having QA take charge of testing lets developers focus on writing code. Developers being familiar with their code can also be a disadvantage in testing, as they know how everything is supposed to work, and therefore can’t behave like a naive user in tests, especially when they are testing the user interface. Developers may implicitly resist thoroughly testing their own code out of unconscious pride – when admitting the human factor, developers may be reluctant to conduct thorough testing of code they wrote for fear of finding too many errors.

How automated testing can help close the gap

It’s important to realize that ‘iron triangle’ thinking is a mindset. There doesn’t have to be a choice between speed, cost, and quality. Smart, automated testing helps QA develop faster, more accurate tests and reduce test runtimes, which means that developers get feedback much quicker. If developers learn about bugs minutes after generating them, they can avoid context switching and fix those bugs as part of their development process rather than as part of a new sprint.

Automated testing uses tools such as code frameworks or record-and-playback to process pre-defined actions and compare the results to expected outcomes. These tests are easily repeatable and can be extended. One particular benefit of automated testing for web-based software is the ability to test code in multiple browsers and resolutions simultaneously. Tests can be repeated as many times as necessary at no additional expense, which also massively reduces testing runtime compared to manual testing.

This allows QA teams to focus on developing tests without impeding test runtime. Teams may share automated tests so that QA testers simply need to develop and maintain tests while developers can integrate existing tests into their CI/CD pipelines and get feedback on test results much quicker. Well-prioritized, high-speed test automation allows great engineering teams to move fast and maintain high-quality code while doing so, achieving any software company’s holy grail.

QA engineers and developers can work together

Automated testing can help resolve the conflict between teams and improve morale. QA testers no longer have to spend hours of their day conducting repetitive manual testing, and developers don’t have to wait hours or days to receive test results. Instead, both teams can work towards developing cost-efficient, high-quality software at a rapid pace. Developers get to focus on what they are best at, which is writing code. Testers get to focus on what they are best at, which is performing tests. Automated testing helps close the gap and reduces the lag between development and testing, allowing teams to work together instead of against each other. It also helps prevent burnout in QA by automating repetitive tasks and encourages QA to conduct more exploratory testing. QA engineers are still incentivized to find bugs, but it doesn’t come at the expense of developer velocity.