Will testers disappear from the earth like dinosaurs? --on the impact of agile development on testing

Http://blog.sina.com.cn/s/blog_8f58d8050102v75h.html

With the rapid expansion and popularization of agile development, the question of whether Agile software development requires test engineers is being mentioned by more and more people, and the industry has two different views.

I think: with the further promotion of agile development, from the perspective of future trends, the role and status of testers are being marginalized, even in the future testers may be like dinosaurs from the earth disappear.

(Do not spray, read the following again ha ^_^)

Let's start by looking at the ratio of testers to developers.

Microsoft's tester and developer ratio is typically 1:1, while Google's testers and developers are 1:10.

Why are the differences between the two companies so great? The main reason is that two companies have different definitions of the scope of work for testers and developers. At Microsoft, unit testing is done by testers (Sdet), which is equivalent to Sdet writing a set of code to test the product code written by the developer, with no less effort than the developer. And Google's unit testing and functional testing is generally done by the developers themselves, testers mainly provide the support of automated testing tools, mainly for performance testing, load testing, security testing, and these are automated tools to complete, naturally require fewer testers.

Take a look at the history of software testing

Dr Bill Hetzel, a pioneer in software testing (on behalf of the Complete Guide to softwaretesting), gives software testing a definition of "evaluating the characteristics or capabilities of a program and system and determining whether it achieves the desired results." Software testing is any behavior that is intended for this purpose. "His core point is that the test method is to try to verify that the functionality of the software is carried out in accordance with a pre-designed design, with positive thinking, and verifying its correctness one by one, against all functional points of the software system." The software testing industry sees this approach as a first-class approach to software testing (the test is to verify that the software works).

This approach was later challenged and challenged by Glenford J. Myers (the Art of softwaretesting). Myers that the test should not focus on verifying that the software is working, but instead should first identify that the software is faulty and then use reverse thinking to find as many errors as possible. He also argues from the point of view of human psychology that it is very detrimental to testers to find software errors if the "Verification software is working" as a test. He then introduced his definition of software testing in 1979: "Testing is the process of a program or system that is executed to detect errors." Definition of ". Myers that a successful test must be a test to find a bug, otherwise it would be worthless and give the three important points related to the test:

Testing is to prove that the program is wrong, not to prove that the program is error-free;

A good test case is that it can find errors that have not been discovered so far;

A successful test is the detection of errors that have not been found so far;

This is the second method of software testing (the test is to verify that the software is faulty).

Myers put forward the concept of "the purpose of testing is falsification" and overturned the error of "testing for the correctness of software", pointed out the direction for the development of software testing, and the theory and method of software testing had been developed greatly.

However, "The purpose of testing is to falsify" can easily lead many testers to think that "the purpose of the test is to look for errors, and is to do the most possible to find the most error", and the number of bugs as a tester's performance assessment. When testers find defects as the only goal, and seldom pay attention to the implementation of the system to the requirements, testers will be more in reverse thinking, constantly thinking about the misunderstanding of developers understanding, bad habits, program code boundaries, invalid data input and various weaknesses of the system, trying to destroy the system, destroy the system, The goal is to discover a wide variety of problems in the system. Although this method can find more defects in the system, but this method is easy to deviate from user requirements and actual situation, testers often cross the system boundaries (such as a lot of abnormal operations, but many operations are not likely to occur in the user), resulting in a test cycle and test costs unreasonable growth, Delays in project delivery.

In the software engineering terminology proposed by the IEEE in 1983, it was defined as "the process of running or measuring a software system using manual or automated means to verify that it meets the required requirements or to ascertain the difference between the expected and actual results". This definition clearly states: The purpose of software testing is to verify whether the software system meets the requirements. It is no longer a one-time, but only a late stage of development activities, but with the entire development process into one integrated. This definition shifts the test from the opposite of development (bug-finding to development) to a measure of software quality.

The three definitions above correspond to stages 1 to 3 of the 5 stages of the cognitive division of the Boris Beizer to the tester.

Phase 1: The purpose of the test is that the real software is available to work

Phase 2: The purpose of the test is to show that the software is not

Phase 3: The goal of testing is not to prove anything, but to restrict the predictable risk that software may not work to an acceptable threshold.

That is, the purpose of testing from finding bugs to controlling quality risk. Because there is no way to improve the quality of the test, can only reflect the quality of software, and the quality of the software needs to rely on the earlier design and prevention, the more the test found the more bugs, the worse the quality, the project on schedule delivery of the higher risk. In addition, the test is not to find the more bugs the better, if the bug is not encountered in the customer's scene, then the bug is not very significant.

The transition from waterfall development to agile development

Waterfall Model development strictly separates the development of software projects into various stages of development: requirements analysis, summary design, detailed design, coding, single no test, integration test, system testing, etc. Using milestones, the inputs and outputs of each development phase are strictly defined. Waterfall model is more like the development pipeline, if the previous stage does not reach the required output, the next phase of the work will not unfold. In the waterfall development model, developers and testers work independently of each other, and testing is initiated only after the development of a testable version, and the entire project cycle is long.

The idea of agile development is to adapt to the rapid change of customer demand. Because only quickly can adapt to the current rapid pace of society, the initiative to accept changes in demand, so that the software designed to have flexibility, scalability, so that customer satisfaction, to achieve success. Agile development is a new way of development, to better meet the needs of customers, should be said to be a future development trend.