Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles The Day the QA Department Died

The Day the QA Department Died

Leia em Português


The Industrial Revolution began about 250 years ago and machines started to take over for human labor in factories, fields, and mines. It is true that this lead to major economic growth, but machines still replaced the average worker who could not get another job or find a new skill to learn, which hurt many people. The similarity of the situation QA testing finds itself in currently is uncanny. Just look at the explosion of testing companies, like Mercury Interactive, during the 1990s. QA testing and QA departments were the big savior during the big Internet boom in the 1990s - when software was being produced at an exponential rate that needed to work when it was released. This led to a growth in development tooling and increase in employment for QA. However, as the economy bottomed out, budgets deflated, Agile development became more widespread, and software continued to become widespread, automated testing began taking over. Just as manual labor became more obsolete over time due to the Industrial Revolution, manual QA testing finds itself faced with the same predicament. Many QA Engineers are moving from Software Quality Assurance to quality checking positions involving programming and developer testing. The QA team is changing and integrating into a cross-functional team. The walls are coming down.

Let’s take a step back and examine how things used to work. Waterfall has been the method of choice for most software development teams since the 1950s. This methodology allowed for developers to design everything upfront, then focus on their code, pass it on to QA for testing, and get it back with bugs to fix. As the developers are always under pressure, and never on time, developers started to rely more and more on QA to check their code. This led to a vicious circle. More testers were hired so developers relied on them more and tested their code less. It became so exaggerated that developers stopped testing their code at all.

This was ineffective both for testers or developers, delaying time-to-market. The resultant products failed to reach the customer on time.

Meanwhile, in February of 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 spotlight 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 very complex endeavor. For those reasons it is very common to find that the goals of the original plan are not reached, and management needs to decide how to react to this situation. There are really three routes a company can choose from in order to manage their time to market.

  1. Add Budget – You can’t always throw more money at a project, but, if you could, you might be able to complete the project on time, taking into account the law of diminishing returns. You have to take into account critical paths that might make adding budget redundant. This is not a preferred scenario for management.

  2. Skimp on Features – Neither developers nor management are keen on giving customers less than they are paying for. This is definitely not an option for many companies.

  3. Lower Quality – Although bugs are a part of our lives that we will always have to deal with, software quality is probably the most important aspect of any product. However, it is also the first thing to get shoved under the bus.

What we are left with is a sense of imbalance. The developers are under pressure (or lazy) and create code that is lacking in quality, while at the same time management is cutting down on QA. There is a fundamental flaw here. This is where Agile fundamentals can come into play.

It’s an Agile Thing

With Agile’s popularity bursting through the seams, developers and managers appeared to be able to find the way to great software. Like any great undertaking, though, there were, and still are, issues between those two sides that need to be worked on. However, one thing that everyone could agree on is that they wanted to produce the software in the shortest time possible, and, in management’s case, with as little investment as possible.

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. This is where things got a little worrisome. How can QA department costs be justified?

Fortunately, Agile development is about testing your own code properly. Passing unit tests ensure that the unit under test solves its problem. Of course, this requires a team effort working without silos. Product managers determine the product to develop which meets the customers’ needs. Development and testers work together to write testing specs. Developers write unit tests to solve the unit under test. Properly tested code is the only way to deliver working software, the core of Agile development. Done properly, a passing unit test ensures that the code does what the developer intended. While QA still has value testing fringe cases, developers recognized the need to take responsibility for their code. One of the pillars of Agile development is working software. Some Agile methodologies include TDD and unit testing performed by the developers. Unit testing is about checking your part of the code; doing your part in order 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 the design continuously changes, and changes in the software will eventually lead to more bugs and without knowledge of the bugs you create while developing the software, the development grinds to a halt.

Unit Testing - Possible QA Killer

Unit testing is a method of testing your specific piece of code to make sure that it is working properly and will fit correctly into the software puzzle. It has been shown that with unit testing you can properly check over 90 percent of your code, and, unlike QA’s manual testing tools, unit tests that are built correctly and tested automatically can evolve with your codebase, testing the code in real-time.

Now, I am not saying that unit testing is the answer to all of our development woes. However, as a platform for testing code (and creating abstract design), unit testing makes sense, costs less, and gets better quality software out the door quicker. Automated unit testing and TDD is the next best thing when it comes to making great software. It allows developers to adapt their code to new features and other changes on-the-fly.

QA testing may have been the savior during the Internet bubble of the late 90s, but companies are quickly realizing the inability of a QA team to adjust to design changes. With QA you have a department dedicated to sweeping for errors and then dumping the issues back on the developers for more iterations and fixes. Unit testing with Agile development promises working software once it leaves the developer’s hands.

Where Do We Go From Here?

I bet you are wondering why I chose this title for this piece. It may have something to do with the fact that I am a Don McLean fan. Beyond that, though, this felt like an apt title for an article on how software QA became a mainstay in corporate application development and why the QA department is on the proverbial brink of extinction. As the title points out, QA is dead. However, we are still seeing QA departments and professionals in corporate software development. The question is how long will this be the case? I personally feel that it is only a matter of time until we see a more dramatic shift to developer testing departments. What this means is that developers will be in charge of testing their own code and will not have a QA department to rely on.

Yes, there will still be many QA professionals working. I think we will see them working as part of the developer teams rather than in their own department. Agile demands cross-functional communication and the breaking down of silos, shown to be uneconomical and inefficient. Costs are too high and speed is an issue with traditional QA departments. There is only one logical way to go: developer testing. It’s not that Quality Assurance is dead, but QA will have to redefine itself and modernize itself. It cannot stay the same. They will have to merge into the development team and unit test automation or on the other side, merge with the product management to define product that delight their customers.

As we move into this age of developer responsibility, we will see developers produce cleaner software that works as intended and with fewer bugs. It is now up to the corporations to recognize where they can save money and still produce great software.

About the Author

Eli Lopian is the Founder and CEO of Typemock, the Unit Testing Company. Prior to starting Typemock, Eli has over 17 years of R&D experience at global companies such as AMDOCS (NYSE:DOX) and Digital Equipment Corporation (DEC). In these roles, Eli was responsible for optimizing the development process and led the transformation of the development environment to support efficient processes and tools.


Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Where can I down-vote this?

    by Ronald Miura,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Automated tests are good, people blindly executing test scripts are wasteful. I've learned so much today, thank you!

  • No news here...

    by Chris Webster,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Big Bad Waterfall: I've been in the industry 25 years and I've never worked on the kind of waterfall project described here. This is just a "straw man" for the writer to make cheap points against.

    QA Department: I've never seen a dedicated "QA" department anywhere either. Testing is already being integrated into the SDLC, whether you're hard-core Agile or not.

    TDD and automated testing: There surely cannot be anybody who visits the InfoQ site who hasn't already heard all about this.

    End of the QA department: See above. But there are in fact signs of a trend towards outsourcing testing/QA functions (basically because the big outsourcing companies have already swallowed up so much development work that they need fresh meat). So we could in fact be seeing the rise of the (outsourced) QA department in the next few years. Back to the future...

  • Depends on your defintion and utilization of a "QA Department"

    by Tim Lyon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think you are quite overreaching in your assessment and have probably not worked with a good technical independent QA staff that is still embedded with the development delivery team. Unit testing, TDD, BDD, and whatever the next level of developer -led testing evolves out it and is incorporated into systems will almost always provide value and earlier detection of issues but that is a grand oversimplification of the system. Unit tests are self-contained tests that mock interdependencies but those only tests the first layer of the application and not the continual integrated business flow of more complex apps. Multiple systems developed by different groups often have to be system integrated for overall business function testing that requires more than one developer writing unit tests. Now whether this requires duplicated unit tests as part of system integration tests that may waste some effort verses using more collaborative and contract-driven testing is another discussion on the best utilization of QA resources but it still should be done.

    Performance tests are often a time consuming and intricate process to map out and test effectively that developers may not be the best utilization of resources from cost efficiency and time consuming efforts. There are things like strict baseline functional performance tests, load tests, stress tests, capacity tests, scalability tests, and endurance tests that all fall into this category, albeit sometimes named differently by different folks. Base functional automation stress levels can and probably still should be written by developers to understand and adjust their base functional performance but the need for it at a higher level still exists – or the business accepts the risk of it not being done.

    Lastly there are often compliance and conflicting business and personal evaluation objectives that may require independent QA from a checks and balance perspective. Many times development teams and its upper management are incentivized and expected to make a delivery date while QA is supposed to help mitigate risk and inform the business on the level of existing quality of a deliverable that can be conflicting. Developers may be even encouraged to abandon or minimize unit tests because “it slows things down” and a contract worth $1 million dollars by a delivery date is required to meet their management’s bonus. What do you think their management is going to recommend? Independent QA theoretically can still do some testing, risk mitigation, and keep the business better informed on what is actually being delivered through that process. Sure the business may still accept that risk but then it isa business decision verses a personal benefit decision.

    Overall this really gets to a discussion of how you define and use your “QA Department”. Heavy-handed manual testing efforts that have risen in many shops over the years may eventually be thinned out to subject matter experts leading crowd-sourced our outsourced manual QA over time. This will probably be a requirement simply due to the growth of systems and lack of talented developers and technical QA staff coming into the business world from the colleges. More and more system complexity and evolution of code will require more and more automation efforts and management of these environments. The key is automation still needs to be done as you are advocating I am just not in agreement that it would all be held by “developers” – that are usually paid at a higher rate – than a properly skilled and utilized embedded technical QA staff. A suitable QA Department that can automate tests amongst different environmental constraints is key to the future of key effective QA testing efforts.

  • Re: No news here...

    by Paulo Pinto,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've seen both "Big Bad Waterfall" and "QA Department" at a mobiles company that used to own Symbian.

  • QA Department is dead.. NO way ..

    by Madhu RAJ Vaman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    QA has a much bigger role to perform in an Agile world where each developer tests only his changes.
    See the Video by James Whittaker at where he talks about how QA can add value to the work being done

  • QA and UnitTesting are not the same things

    by Bogdan Kushnir,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    While general idea of this article may be true and separate QA departments will die in some very distant future but definitely reasons described in article are not from this planet.

    Sure, modern QA departments don't do unit-testing, because of TDD approach on the dev. side. However they are involved in automating more complex test types, writing corresponding tools and reporting product metrics (code-coverage etc.). And if author would be patient enough for reading corresponding material on different test types (integration, functional, security, accessibility, performance, multi-box etc.), he could change his opinion on the modern QA role.

    Of course these all testing complexity applies to big projects while smaller and mid-size projects are trying to reduce costs on these fancy test types. Also maintenance costs of such tests is going down because quality and quantity of corresponding tools increases. As example, modern tools and testing frameworks allow to write browser-based tests which was practically impossible 10 years ago.

  • QA vs QC

    by Dennis Alexander,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    1. Stop confusing everyone!!!!! If they have different department, budget, head of the unit and so forth, they are not QA. They are QC. period. To be QA one must be proactive, so they must understand the full SDLC and be integrated at all stages, hence they are not separate silo.
    2. Google Zero Quality Control and Edward Deming. It has been here for 40 years now. Doh!!!!

  • Interesting that a founder of a company that sells unit testing software...

    by Mark Phipps,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ...would take such a view! Nothing else to say, bit late to the party on this one and all the previous commentators have made the case already.

  • Developers testing their own code is not sufficient

    by Hans-Peter Störr,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree that having QA people in your team during development is very valuable, since they could support the developers with writing automated tests. However it would be a very misguided and dangerous attempt to save money on QA by having only developers test their own code. To ensure quality it is necessary that someone else with the unique mindset of a tester and with a focus on understanding the interplay of all requirements tests the application. Of course, a tight integration of this QA process into the development process might be beneficial, and this does not necessarily require a separate QA team.

  • Agenda of article

    by Jim Tester,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Eli Lopian is the Founder and CEO of Typemock, the Unit Testing Company

    I think his title and alone indicate to me he has agenda on this issue. I will agree with the fact that QA needs to change. It should be involved in the upfront design of the software. It should also write features stories based off discussions with the business. Then take the features and create requirements and test scenarios in the same step in the BDD model of GIVEN WHEN THEN. QA should also be responsible for automating testing as much as possible. The problem is there are not enough talented QA people to do this because a lot of them have been brought into QA to click around on an app and find bugs. It’s a wonder that developers have little use for QA and want to do the testing themselves. Having developers test is not the solution, changing the skill set for what is required to be in QA is a start, but organizations need to realize that QA needs to be involved upfront in the design, along with a business and a developer. Once you have the three units working together as a team you will improve the quality of the software.

  • Fairly weak attempt at enlightenment

    by Dan Mills,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm really surprised such a quality site like infoq would publish such a thing.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p