The Day the QA Department Died
谢誉
Address: http://www.infoq.com/articles/day-qa-dept-died
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.
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.
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.
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.
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.
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 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.
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 aDon 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.
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.
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.
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.
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 aDon 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.
类似资料：