By: Eli Lopian
This article was reprinted with permission from its contributor. Opinions expressed are the author’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 led 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 this situation, which QA testing finds itself in currently, is uncanny. QA was the big savior during the big 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 software continued soaring, automated testing began taking over. Just as manual labor became more 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 always been the method of choice for most software development teams since the 1950’s. This methodology allowed 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. Over time, systems were upgraded, development methods got better and faster, and we found ourselves producing so much software at such a fast rate, that we needed more testers. More testers were hired and developers just got lazier knowing that QA would catch their mistakes.
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 these 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 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, 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 better 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. While QA can still test fringe or flow 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 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 Automation tools, unit tests that are built correctly evolve with your codebase.
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 90’s, 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. Costs are too high and speed is an issue with QA departments. There is only one logical way to go: developer testing.
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.
Eli Lopian is the CEO of Typemock, the Unit Testing Company (http://www.typemock.com). 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). 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.
