More often than not, developers who are backed up by one or more quality assurance (QA) testers don't fully test their code. That's because sometimes they don't want to spend the time, or they'd prefer to rely on QA to find defects. Or it's one way to appear productive by completing more stories or tasks. And, occasionally, some developers think that their code is flawless. But even small bugs can lead to big business problems.
The current trend among software development teams is to move away from QA-based testing in favor of developer-based testing. But is that the right choice? You can find strong opinions on both sides.
Which way should your team go? To answer that question, you need to understand what developer- and QA-based testing really mean, and the strengths and weaknesses of each approach. Only then can you decide what will best serve your customers and ensure business success.
The argument for developer-based testing
Many teams require developers to perform unit testing at minimum; some also ask them to produce automated, integrated, code-based tests. But building development tests takes time that developers could spend producing new code, so developers frequently bypass building those in favor of creating new features. It's possible, however, for developers to build a significant amount of test coverage into their code, if it's done consistently across the entire codebase.
Other teams release code into production with barely a unit test or code review. I’ve known a few teams that didn’t even verify that their code still compiled after they’d made changes. If you’re going to rely on developer-based testing, have a detailed, well-managed process in place.
So why would developers bypass testing new code? One reason is that they work within one section of the application code and don’t understand how the entire application works. In other cases, developers have told me that they don’t make mistakes. And I'm not the only one who has heard this.
“I’ve seen a lot of programmer-tested applications fail miserably because the developer thought so highly of their code that testing was deemed unnecessary.”
—James Jeffery on the Hacker Noon blog
Some developers also complain that creating unit tests wastes time and that it is too complicated and too difficult to execute repeatedly, even when the testing process is automated. The bottom line, they say, is that testing slows down the development process and decreases coding productivity.
But then there are the developers who thoroughly test their code. They use coded tests to determine whether a given fix breaks the existing code, the build, or the application's base functionality. Developers who test are often competitive; they don’t want the QA tester or customers to find defects. It’s a matter of pride.
A developer who can execute a test-code set repeatedly can confirm that the code still functions properly after making changes. In the long run, writing tests saves time by decreasing release issues and downtime on production, and by reducing the number of visible customer defects.
Many developers hate testing because they think it’s boring, repetitive, and too complicated. They also don’t understand how all the parts of the application work together. But developer testing is a productive part of your QA program when managed well, and when teams add sufficient time to the release cycle to accomplish both feature development and testing.
The argument for QA-based testing
QA testing is a distinct set of skills that are quite different from those of a successful developer.
“The value of a good tester cannot be underestimated. Generally they are disciplined, like repetition, and refuse to accept that not finding bugs is proof there aren’t any.”
—Nataliya Hordiy, quality assurance analyst at LYONSCG
Testing and reporting bugs to developers requires confidence, self-assurance, and the ability to think creatively all the time. “Good testers become familiar with all the nuances of an entire application system and are efficient at testing. They have a broader knowledge of the application's regression history than any developer,” Hordiy wrote.
QA testers are professionally contentious and can seem irritating to developers, but they do keep coders honest. In some respects, they are an extension of the development manager, or the development process.
Testers perform non-obvious functions that push an application in different directions, often where it was never intended to go. They believe in defects and don’t accept that bugs are fixed unless they have proof. They are unafraid to try and fail. Failing to find a bug the first time around means they need to execute tests with additional creativity.
QA-based testing is important, whether implemented as a support role for development teams or as an independent entity. It’s possible, though, that you only need a small team of testers, or a single tester per team.
QA testers work best within a team of developers because both groups are more productive when they work closely together. Pure code-based testing fails because it lacks the human factor. Humans do interesting things to applications in ways that are often surprising. QA testers enhance the success of coded tests by providing a human eye, and a human element, to help anticipate that.
Testing is repetitive, but it's not boring to testers, since they must use their imaginations to anticipate what the customer might do. And they have experience with a variety of web and mobile applications against which they can compare. It's this ability to shift gears, to learn how an entire application functions or how a suite of applications functions, that makes testers valuable.
Also, the test cases and plans that testers create provide an additional documentation source for training and customer use. Tests contain the information developers need to understand full application functionality and its integration points.
Although it’s popular to move away from having only QA testers, many businesses find that when they do make that move, customer complaints increase. Having a QA tester is necessary.
A balanced approach is best
Many development teams produce and release code continuously, or nearly so. Speed is the name of the game, and speed to market is important for business success. But you need to add time for QA testing to the release schedule. Once you do that, however, who should do the testing?
In most cases, both test engineers and software engineers should. Developers can test their code to eliminate many defects. And QA testers should tackle the defects in customer workflow or in the full spectrum of application functionality that can be missed with developer-based code testing.
What are your thoughts on who should be testing your code? How does your organization do it? I look forward to your thoughts and comments below.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
