Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


The Shrinking Role of QA

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.