Doomsday QA
This is a translation of an article by Eli Lopian, the founder of Typemock. He is the executive director of the corporation. Eli has over 17 years of experience in development. During this time, he managed to work in such global organizations as AMDOCS (NYSE: DOX) and Digital Equipment Corporation (DEC). His responsibilities included streamlining the development process and making the necessary adjustments to maintain its effectiveness. This article explains how unit tests will affect the traditional approach to testing in the future, and what effect they have now.
Since the beginning of the Industrial Revolution, about 250 years ago, machines began to actively replace human labor in factories, mines and mines. On the one hand, this leads to an increase in economic growth, on the other - to the dismissal of workers whose work has been replaced. Often people are not able to find a new job or retrain after being fired. What is happening in QA now is strikingly similar to the processes described above. Just look at the incredible increase in the number of companies involved in testing, such as Mercury Interactive, during the nineties of the last century. The testing process and the QA teams themselves came in handy at the time of the Internet boom in the nineties. Then the number of programs released to the market increased exponentially. This has led to an increase in the number of development tools and expansion of testers. However, over time, the unstoppable growth of the economy began to gradually subside, budgets became increasingly scarce, Agile-methodologies became more and more widespread, the software itself became more widespread and automated testing gained momentum. Before manual testing, the same problems arose that were characteristic of manual labor in enterprises during the Industrial Revolution. Many QA engineers began to move to new positions that involve the use of programming and development skills in everyday tasks. Testing teams began to undergo changes, become multifunctional. Borders between departments gradually began to fade.
But let's go back a few steps and see how it was before. The overwhelming majority of companies have chosen the waterfall development model since the 1950s. This approach allowed the team to first fully design the design, then concentrate on the code, transfer it to testers, and then begin to correct defects. As developers are constantly under pressure, they have begun to rely more on the QA department. This led to a vicious circle. New testers are hired, developers are even more relaxed and pass more raw code to QA. At some point, developers completely stopped testing their code.
')
This extremely negatively affected the work efficiency and ultimately resulted in the failure of the contract terms. The final product did not reach the customer by the planned moment.
At the same time, in February 2001, at the time of the Internet boom already mentioned, the Agile Manifesto was adopted and from this point on, a different point of view appeared on the development process. Agile seemed to breathe new life into this process. A new goal in the world of Agile was the adaptation to endless changes and the rapid creation of working software modules. The main emphasis fell on programmers and as the distribution of the new methodology, QA services were needed less and less. This meant that testing was one foot behind the IT business.
More testers - more problems
Development of corporate software is not cheap. For this reason, it is often found in the middle of a project that the team no longer fits into the original budget. In this case, the leadership is forced to find ways to solve the problem before them. There are three main ways in which, in this case, the command can go:
1. To replenish the budget - you can always add more money, then you can meet the time. But keep in mind that then the return on investment will be less. Always consider all risks. According to the results of the analysis, you can come to the conclusion that further investments are not advisable. Not the best of options.
2. To give up part of the functionality - neither the developers nor the management want to supply the client with a program that does not do what is expected of it. This is also not an option.
3. To keep the quality low - in everyday life, we often encounter certain defects. As for the software, the quality of the product plays a primary role here. However, the third way becomes the most common among companies.
As a result, we get a violation of the usual order - on the one hand, the developers are either busy or too lazy to bring their code to the optimal level, on the other hand, the management cuts down the costs of testing. This is where the principles of Agile can help.
Agile Benefits
Due to the popularity of Agile, developers and management are actively applying the methodology to solve their problems on the way to improving software. However, there are still problems that need attention. What the views of management and programmers agree on is that they want to produce software in the shortest possible time and, preferably, with minimal expenses.
After the Internet boom and subsequent rollback in economic growth, companies have realized the need to produce high-quality software without high production costs. But how to cut QA costs?
Fortunately, the Agile methodology involves testing your own code. Passing unit tests indicates that the selected module is working and performing its function. Of course, this implies close cooperation of all departments. The product manager determines what the program should be to meet customer requirements. Developers and testers work together to write specifications. Next, developers write unit tests for their modules. Correctly tested code is the only way to deliver a working program, so to speak, the core of the Agile process. Carried out by standards, unit testing confirms that the code works as the programmer intended. The QA department is still testing non-standard situations, while the developers are gradually becoming aware of the responsibility for the quality of their code. One of the fundamental pillars of the Agile methodology is working software. And some of the principles of the above methodology, such as TDD (Test Driven Development) and unit testing are performed by developers. So what is the essence of unit tests and why should they be used? A feature of unit testing is that it performs a check of a specific piece of code. When everyone watches over his module, the defects found corrects quickly and efficiently - the cost of the entire project decreases. Without a well-defined unit testing process, it is extremely difficult to stay within Agile. All of these endless changes in requirements, design, and the code itself ultimately lead to even more defects, and without knowing their specifics, development risks failing.
Unit testing is a possible cause of death QA
To repeat: unit testing is a process aimed at verifying the performance of your particular piece of code. It ends only when there is confidence that this piece will harmoniously fit into the overall picture of the system. It has been proven that applying unit testing can achieve code coverage equal to 90 percent, and, unlike manual testing, unit tests can evolve over time to solve more complex problems.
Just do not think that the main idea of the article - unit tests will save the world. They are not a panacea. However, these are the most suitable candidates for testing code, due to their low cost. In addition, the final product turns out to be of better quality and it is possible to shorten the time.
If you use QA departments, the process is delayed. Bugs are sent to the developers, then their changes go back to the testers. The use of unit tests minimizes the likelihood of defects once the developer has finished working on his module.
findings
As can be seen from the title of the article - QA is more unsustainable, in the traditional sense. However, we can still see the widespread use of QA. The question is, how long will it last? Personally, I hold the opinion that in a short time the testing tasks will be transferred directly to the developers and QA specialists will have to adjust to the new order.
Yes, we will still see testers, but they will more likely be part of a development team than a separate department. The QA content in Agile application conditions becomes too expensive, so testers will have to change.
I sincerely believe that we are moving towards a bright future, where developers will write more advanced, high-quality code. The case remains with the leadership of corporations. Before them there are ways to reduce costs and release competitive products. It remains for them to apply them.
Translation of "The Day the QA Department Died", Eli Lopian.
www.infoq.com/articles/day-qa-dept-died
Since the beginning of the Industrial Revolution, about 250 years ago, machines began to actively replace human labor in factories, mines and mines. On the one hand, this leads to an increase in economic growth, on the other - to the dismissal of workers whose work has been replaced. Often people are not able to find a new job or retrain after being fired. What is happening in QA now is strikingly similar to the processes described above. Just look at the incredible increase in the number of companies involved in testing, such as Mercury Interactive, during the nineties of the last century. The testing process and the QA teams themselves came in handy at the time of the Internet boom in the nineties. Then the number of programs released to the market increased exponentially. This has led to an increase in the number of development tools and expansion of testers. However, over time, the unstoppable growth of the economy began to gradually subside, budgets became increasingly scarce, Agile-methodologies became more and more widespread, the software itself became more widespread and automated testing gained momentum. Before manual testing, the same problems arose that were characteristic of manual labor in enterprises during the Industrial Revolution. Many QA engineers began to move to new positions that involve the use of programming and development skills in everyday tasks. Testing teams began to undergo changes, become multifunctional. Borders between departments gradually began to fade.
But let's go back a few steps and see how it was before. The overwhelming majority of companies have chosen the waterfall development model since the 1950s. This approach allowed the team to first fully design the design, then concentrate on the code, transfer it to testers, and then begin to correct defects. As developers are constantly under pressure, they have begun to rely more on the QA department. This led to a vicious circle. New testers are hired, developers are even more relaxed and pass more raw code to QA. At some point, developers completely stopped testing their code.
')
This extremely negatively affected the work efficiency and ultimately resulted in the failure of the contract terms. The final product did not reach the customer by the planned moment.
At the same time, in February 2001, at the time of the Internet boom already mentioned, the Agile Manifesto was adopted and from this point on, a different point of view appeared on the development process. Agile seemed to breathe new life into this process. A new goal in the world of Agile was the adaptation to endless changes and the rapid creation of working software modules. The main emphasis fell on programmers and as the distribution of the new methodology, QA services were needed less and less. This meant that testing was one foot behind the IT business.
More testers - more problems
Development of corporate software is not cheap. For this reason, it is often found in the middle of a project that the team no longer fits into the original budget. In this case, the leadership is forced to find ways to solve the problem before them. There are three main ways in which, in this case, the command can go:
1. To replenish the budget - you can always add more money, then you can meet the time. But keep in mind that then the return on investment will be less. Always consider all risks. According to the results of the analysis, you can come to the conclusion that further investments are not advisable. Not the best of options.
2. To give up part of the functionality - neither the developers nor the management want to supply the client with a program that does not do what is expected of it. This is also not an option.
3. To keep the quality low - in everyday life, we often encounter certain defects. As for the software, the quality of the product plays a primary role here. However, the third way becomes the most common among companies.
As a result, we get a violation of the usual order - on the one hand, the developers are either busy or too lazy to bring their code to the optimal level, on the other hand, the management cuts down the costs of testing. This is where the principles of Agile can help.
Agile Benefits
Due to the popularity of Agile, developers and management are actively applying the methodology to solve their problems on the way to improving software. However, there are still problems that need attention. What the views of management and programmers agree on is that they want to produce software in the shortest possible time and, preferably, with minimal expenses.
After the Internet boom and subsequent rollback in economic growth, companies have realized the need to produce high-quality software without high production costs. But how to cut QA costs?
Fortunately, the Agile methodology involves testing your own code. Passing unit tests indicates that the selected module is working and performing its function. Of course, this implies close cooperation of all departments. The product manager determines what the program should be to meet customer requirements. Developers and testers work together to write specifications. Next, developers write unit tests for their modules. Correctly tested code is the only way to deliver a working program, so to speak, the core of the Agile process. Carried out by standards, unit testing confirms that the code works as the programmer intended. The QA department is still testing non-standard situations, while the developers are gradually becoming aware of the responsibility for the quality of their code. One of the fundamental pillars of the Agile methodology is working software. And some of the principles of the above methodology, such as TDD (Test Driven Development) and unit testing are performed by developers. So what is the essence of unit tests and why should they be used? A feature of unit testing is that it performs a check of a specific piece of code. When everyone watches over his module, the defects found corrects quickly and efficiently - the cost of the entire project decreases. Without a well-defined unit testing process, it is extremely difficult to stay within Agile. All of these endless changes in requirements, design, and the code itself ultimately lead to even more defects, and without knowing their specifics, development risks failing.
Unit testing is a possible cause of death QA
To repeat: unit testing is a process aimed at verifying the performance of your particular piece of code. It ends only when there is confidence that this piece will harmoniously fit into the overall picture of the system. It has been proven that applying unit testing can achieve code coverage equal to 90 percent, and, unlike manual testing, unit tests can evolve over time to solve more complex problems.
Just do not think that the main idea of the article - unit tests will save the world. They are not a panacea. However, these are the most suitable candidates for testing code, due to their low cost. In addition, the final product turns out to be of better quality and it is possible to shorten the time.
If you use QA departments, the process is delayed. Bugs are sent to the developers, then their changes go back to the testers. The use of unit tests minimizes the likelihood of defects once the developer has finished working on his module.
findings
As can be seen from the title of the article - QA is more unsustainable, in the traditional sense. However, we can still see the widespread use of QA. The question is, how long will it last? Personally, I hold the opinion that in a short time the testing tasks will be transferred directly to the developers and QA specialists will have to adjust to the new order.
Yes, we will still see testers, but they will more likely be part of a development team than a separate department. The QA content in Agile application conditions becomes too expensive, so testers will have to change.
I sincerely believe that we are moving towards a bright future, where developers will write more advanced, high-quality code. The case remains with the leadership of corporations. Before them there are ways to reduce costs and release competitive products. It remains for them to apply them.
Translation of "The Day the QA Department Died", Eli Lopian.
www.infoq.com/articles/day-qa-dept-died
Source: https://habr.com/ru/post/248051/
All Articles