The Industrial Revolution began about 250 years ago and machines started to take over for human labor in factories, fields, and mines. This led to major economic growth, but machines started to replace the average worker, who could not get another job or acquire a new skill, which hurt many people. The similarity of the situation QA testing finds itself in currently is uncanny. QA was a savior during the Internet boom when budgets were virtually unlimited and software was being produced at an exponential rate. However, as the economy bottomed out, budgets deflated, Agile development became more widespread, and automated testing began taking over. Just as some forms of manual labor became obsolete over time due to the Industrial Revolution, manual QA testing finds itself facing the same predicament.
Let's take a step back and examine how things used to work. Waterfall has been the method of choice for many software development teams since the 1950s. This approach allowed for developers to design everything upfront, then focus on their code, pass it on to QA for testing, and get it back with a list of bugs to fix. Over time, systems were upgraded, development methods got better and faster, and we found ourselves producing so much software at such a rate that we needed more testers. More testers were hired and developers got lazier knowing that QA would be there to catch their mistakes.
In February 2001, as the dot-com bubble was bursting, the Agile Manifesto was published and a new way of developer thinking started to emerge. Agile development methodologies breathed new life into the developer world, where adapting to ever-changing situations and rapidly deploying working software became the focus of development teams. Agile is more involved in each working part of a team and the code, with a special focus on developer testing rather than QA testing. As Agile continues to become more widespread and effective, QA is needed less, and that means it has one foot out the door.
More QA, More Problems
Enterprise software development is an expensive and complex endeavor. When using the Waterfall model, it is common to find that the original product goals are not reached at which point, management typically makes one of three choices:
- Add Budget: More money can be thrown at a project. This might make it possible to complete the project on time, taking into account the law of diminishing returns. But this is not a preferred scenario for management.
- Trim Features: Neither developers nor management are keen on giving customers less than they are paying for. This generally is not an option for many companies.
- Lower Quality: Quality is expensive, and thus is often the first thing to be cut back.
What we are left with is a sense of imbalance. Developers create code that lacks the necessary quality, while at the same time, management is cutting down on QA. There is an inherent flaw here. This is where Agile fundamentals can come into play.
It's An Agile Thing
After the dot-com bubble burst and the economy was gradually working its way back, companies knew that they needed to create good software without the huge costs. Fortunately, Agile development is about developers testing their own code. While QA can still test fringe or flow cases, developers recognize the need to take responsibility for their code. One of the pillars of Agile development is delivery of working software. Some Agile methodologies include TDD and unit testing performed by the developers. Unit testing is about developers doing their part to make the whole better with the benefit of continuous, instant feedback that flushes bugs out quickly and cheaply. Without good unit testing coverage, it is very hard to stay Agile because, as a design continuously changes, the unit tests can flag problematic consequences of the rolling changes.
Unit Testing: Possible QA killer
It has been shown that unit testing can properly check 90% of code and, unlike QA Automation tools, unit tests that are built correctly evolve with your codebase. As a platform for testing code (and creating abstract design), unit testing costs less and gets better quality software out the door quicker than competing approaches that rely on QA to find all the defects. And, as mentioned previously, automated unit testing and TDD enable developers to adapt their code to new features and other changes on the fly. When combined with other Agile techniques, these approaches rely on delivering working software every day. The question is what role, if any, QA departments will be left to handle?
At many companies, when working software passes UATs, it is good enough for deployment for internal use. This leaves a rapidly shrinking role for QA departments. Obviously, companies with products for external consumption or with tight safety or regulatory requirements will need extensive support from QA and ancillary testers, but increasingly, those might well be the last redoubts of the formerly universal QA departments. And even their fate will hinge upon how much testing developers take on, which itself is a function of how much developers can automate the testing of their own code.
Eli Lopian is the CEO of Typemock, the Unit Testing Company. A well-known figure in the agile and test-driven-development arenas, Eli has over 17 years of R&D experience at large companies such as AMDOCS (NYSE:DOX) and Digital Equipment Corporation (DEC). Andrew Binstock is the editor in chief of Dr. Dobb's.