V model or X Model

In terms of software testing, the V model is the most widely known model, although many experienced testers are still not familiar with the V model or other models. The V model has existed for a long time and has some common characteristics with the waterfall development model, which has been criticized and questioned like the waterfall model. The V model has been discussed in detail in the first article "test-a forgotten stage". Here we only give a brief introduction.

The procedure in the V model describes the basic development process and test behavior from left to right. The value of the V model is that it clearly identifies different levels in the test process and clearly describes the mappings between these test phases and various stages during the development process.

In the V model, unit tests are code-based tests that are initially executed by developers to verify that each part of the executable program code meets the expected functional requirements;
The integration test verifies whether the integration between two or more units is correct, and checks the interfaces between the units defined in the detailed design in a targeted manner;
After all unit and integration tests are completed, the system test starts to simulate the running of the system in the customer environment to verify whether the system has achieved the functions and performance defined in the outline design;
Finally, after the technical department completes all the tests, the business experts or users will carry out the acceptance tests to ensure that the products can truly meet the user's business needs.

Although many people disagree with the V model, few really discuss these issues in detail. Brian Marick (《The craft of software testing(Prentice Hall, 1995), author of the book) once said so. At the star2000 (Software Testing Analysis and Review) Eastern Conference, Marick once had a debate with Dorothy Graham (another author of this series, he also raised some pertinent objections to the V model on his personal website www.testing.com.

X Model
Marick has put forward some opinions and opinions. First, Marick does not recommend creating an alternative model. Here I took the liberty to refer to some Marick ideas and reorganize them to form an "X model ". In fact, this name is not used to correspond to the V model, but for some other reasons: x usually represents unknown, marick also believes that his point of view is not enough to support the complete description of a model, but there is already some of the main content required by the model, which also includes the example of exploratory testing) such a bright spot. I also need to apologize to Marick for using text, because most of the ideas that I agree with Marick belong to Generation X (Generation X ). In addition, I have outlined an X-shaped image. I believe this image can reflect Marick's point of view in another form.

 

Since the X model has never been documented, the content of the X model needs to be inferred from the related content of the V model at the beginning, which has already been reflected in the related articles of Marick. Here, we will briefly discuss the X model, because it has not been fully expanded from text to V model, and I don't want to repeat the concepts of many testing technologies mentioned in the previous article here.

Marick's primary criticism of the V model is that the V model cannot guide the whole process of the project. He believes that a model must be able to handle all aspects of development, including handover, frequent and repetitive integration, and lack of Requirement documents.

Solve the issue of handover and frequent integration cycles
Marick believes that a model should not specify behaviors that are inconsistent with the currently accepted practices. I also agree with this. The left side of the X model describes the code and test of the separation of individual program fragments. After that, the code is frequently handed over and integrated into executable programs. These executable programs also need to be tested. Finished Products that have passed the integration test can be finalized and submitted to the user, or as part of a larger scale and scope of integration. Multiple Parallel curves indicate that changes can take place in each part.

As shown in the middle, the X model also locates exploratory testing (lower right ). This is a special type of test that is not planned in advance, such as "What will happen if I test it like this ?", This approach often helps experienced testers discover more software errors beyond the test plan. Although Marick does not clearly describe this, it is certainly happy to see the definition of this method.

However, focusing on such low-level behaviors may lead to different discussions. A model differs from a separate project plan. The model should not describe the details of each project. The model should provide guidance and support for the project. Of course, code handover can also be considered as an integrated form. The V model does not limit the number of creation cycles.

Both Marick and Graham agree that the test design should be carried out before the test is executed. Marick suggests: "design when you have the relevant knowledge, and test when you have the content to deliver ." The X model contains the test design steps, just like the steps to be included using different test tools, but the V model does not. However, the Marick example shows that the X model is not a real model in this sense. Instead, the test design step should be allowed at any time.

Pre-plan
Marick challenges the V model because the V model is based on a set of development steps that must be strictly arranged in a certain sequence, which may not reflect the actual practice process.

Many projects do not have sufficient requirements. The V model starts from requirement processing. The V model prompts us to test the content we have obtained in each development phase, but it does not specify how much content we want to obtain. If there is no required information, do developers know what they want to do? I advocate that the X model and other models must have sufficient requirements and be released at least once. Although it is necessary to work normally without a model, an effective model can encourage the adoption of many good practices. Therefore, one of the strengths of the V model is its explicit need for role validation, while the X model does not. This is probably an inadequacy of the X model.

Marick also questioned the differences between unit testing and integration testing, because in some cases people may skip unit testing and are keen to directly perform integration testing. Marick is concerned that people blindly follow the "V model of Schools" and follow the steps guided by the model. In fact, some practices are not practical. I have made every effort to integrate Marick's expectations for a lot of scalable behaviors into the X model. In this way, the X model does not require that each program fragment be tested (the behavior on the left in the figure) before being tested as an integral part of the creation of an executable program (in the upper right corner of the figure ). However, the X model does not provide judgment criteria for skipping unit tests.

Beyond the stage
The main goal of a model is to describe how to do something well. When the basic requirements of a model are incomplete, the model helps us to recognize these shortcomings, which are also the value of the model. Although we acknowledge that system development can continue without sufficient requirements, the X model may advocate additional efforts for more practical activities. Similarly, you can skip the unit test because you like integration test. However, the value of unit test may be illusory, because in general, in unit tests, the cost for solving problems is small, and the cost for discovering problems in integration tests is much higher.

A model that represents lagging practices only exists because it is common and common. Such a model can only ensure that we can maintain the repetition of lagging practices in the future, instead of making changes to improvements. People even think that backward practices are not only inevitable, but also inevitable, and finally refuse to take improvement as a virtue.

For example, developers sometimes do not really study how to better define users' business needs, but simply think that such a job is unrealistic, because "users do not really know what they want", or they think "requirements always need to change ". As a result, these developers may further claim that they do not understand the needs of the practice is reasonable and feasible, because they can use more advanced practices, such as the original method. Although such a technology is useful in reaching consensus on the validation requirements, it is not actually a shortcut to coding. In this case, encoding is very inefficient and requires a lot of work to discover real user business needs. From the perspective of the overall project plan, it is more valuable to adopt iterative methods and some more direct methods to discover requirements.

Similarly, the recommendation of the X model and its exploratory test is to avoid spending a lot of time writing the test documentation. In that case, the time actually used for testing is reduced. (I don't know why, some test experts don't seem to regard writing a test plan as a virtue. I may be the last person who encouraged me to write documents and enter some forms. I think this is of its own value. I have seen many examples of redundant test plan documents that are not worth writing so much time. However, this does not mean that writing a test plan is a bad behavior. It should be said that writing a bad test plan is a bad behavior. On the other hand, writing down important information can return several times. This allows us to have a better understanding, avoid forgetting, and achieve more sharing.

In the next two articles, I will reveal how a reasonable structure makes software development faster, lower costs, and better results in actual projects, the model I call a "pre-test" will be displayed. My customers, students, and myself feel that this model is of practical value. I believe that this model fills in the defects of the V and X models and can provide significant help to testers and developers.