Agile testing theory and practice-3

[This is the third article in Agile Testing Theory and Practice (Article 1, Article 2, Article 3, Article 4, Article 5, Article 6, Article 7 )]

 

 

Now let's summarize the problems with the above model:

1.The customer said angrily:This product does not seem to be what we want! I knew that you gave me such a product, so I won't place an order. You also told me earlier that this product is like this. Now, I 've just showed it to me, wasting my time and energy, I don't want to buy it! (After delivery, the customer finds that the product is inconsistent with the original requirement. Therefore, the customer is angry and has serious consequences.)

2.The design team was excited to say:After such a long period of development, you need to modify the functions and add functions. This will affect many other functions, the last release time, and the final quality, I cannot guarantee. (Dude, I have to pay for your products. Of course I have to do it for me if I want to add any functions and change some functions. Otherwise I will not pay for them!)

3.The developer said with great enthusiasm: You guys are doing this test. Don't mention it later. You always give us so many bugs before the final release. Are you sure you want to find something for us! If it cannot be released on time, you will be responsible! (The tester complained:We also want to find this bug early and fix it early, but you didn't test it before !)

 

In this way, we constantly complain about each other, that is, the so-called contradictions. in philosophy, contradictions are the driving force for the development of things. Therefore, the emergence of these contradictions indicates that, we need a solution to these contradictions. Fortunately, many of our predecessors have already helped us solve this problem. It is accurate to say that this problem has been solved theoretically, let me hear about it.

 

First, there are only two reasons why customers cannot get the products they want,

The first is that the demand points we designed at the beginning are actually different from what the customer wants.This can be solved immediately after the requirement design is completed and confirmed with the customer.

 

The second point is that customers can only see this product at the last moment, which means that even if they find that their previous ideas are wrong, it is too late to change their ideas, because the product has come out, it may take a long time to change it. No one can afford it.In this regard, we can often deliver an available build to the customer, so that the customer can see the implemented functions and determine whether the changes are required.

 

For our design team, the second point above can solve their problems,Because there is an available build, we can immediately let the customer see after the well-designed functions are completed. Once something needs to be modified, it will not be as before because all functional points have been completed, if you change one, you will get started.As mentioned earlier, the earlier a bug is found, the lower the repair cost.

 

For our developers and testers, we also need to make some changes to help customers get the products they want, but it is also very simple. Just a few words,After a function is developed, the tester needs to test the function. Then, the developer needs to repair the detected bug immediately, and finally confirm and fix the repaired bug.. In this way, we can solve the problem that tests can be carried out in the last phase before a large number of bugs can be found, resulting in the occurrence of uncertain factors such as the increase of release costs and delay.

 

Of course, there is another point that must be mentioned here. Even if a new method is adopted and the cost increases, the delay may still happen, however, the new method can help you predict the possible cost and time problems. It will not be discovered until the last moment as before. This will be of great help to the leadership in making decisions.

 

Here, we should find that the test process is completely parallel with the development process. Although the W model mentioned previously has parallel features, it is only a "pseudo-parallel" model ", it takes a stage to complete the next stage. For example, testing can only start after all the functions are developed. For this model, testing is always involved, I don't know which stage is completed or not. I only care which function has been designed and developed. For designed functions, there are also specialized design and testing Engineers (design QA) in the test to specifically check whether the design meets the customer's requirements, and even to communicate with the customer; for the developed functions, on the one hand, after the code is complete, the development requires immediate unit testing, and then full-time testers get the daily
After the build, you need to perform a regular test immediately to check whether it is working. If a serious bug is found, you can immediately upgrade it for development. After all the functions have been confirmed and tested, testers should continue to carry out integration testing, system testing, and stress testing. Even in the later maintenance phase, testers should continue to participate, many technical support staff do not know much about the product, so they still need the help of testers to solve the problem.

 

Therefore, from the initial design to the final release, testers have been involved throughout the process. This has greatly changed with the previous model, the requirements and pressure on testers are already different. This new model is the prototype of the agile test model. Of course, it is not a complete agile test model.Quasi-agile mode.

 

Now that we have a quasi-agile model, what is the real agile testing model? Well, let's try again.

 

(To be continued)