Stages that cannot be ignored in software development

In development models, tests are often used as an afterthought action, but there are also test-centered development models. In this article, let's examine the V model to see if it has any problems?

The decades of software development have proved that division of stages in the development lifecycle is very beneficial. Based on the classic waterfall model, there are also spiral models and process Iteration Methods, rapid software development (RAD) and newer Rational Unified Process (RUP). However, in these process methods, the value of the test is not fully emphasized, and the test is not paid enough attention.

Just like developing a development model, testing also has a test model, although these methods are little known. This is partly because many testers have accumulated a lot of experience in their work and can use this experience to do their jobs well. In general, testing often takes up the entire development cycle, but even in many formal universities, software testing courses are not set for students about to start their software career.

Software experts are constantly providing new development models, which is also a result of actual development needs. At the same time, they are constantly aware of the shortcomings of these existing methods during the development process. For example, there are no more adequate methods than the RUP, but there are also some obvious shortcomings in the RUP, for example, it does not Position the test plan.

V-Model

The V model is only recognized by the software industry. V-the model claims that testing is not an action to make up after the event, but a process that is equally important to the development process. Shows the V model:

Figure 1: V model

The V model was first proposed by the late Paul Rook in the late 1980s s. The V model was included in the British National Computing Center literature and was designed to improve the efficiency and effectiveness of software development. The V model is accepted in Europe, especially in the UK, and is considered a substitute for the waterfall model. In the United States, the V model is misunderstood as another waterfall model.

In the traditional development process, the test process is only taken as a stage after requirement analysis, outline design, detailed design and coding. In fact, the launch of the V model is also an improvement. In the waterfall model, it does have a negative impact on people. That is, after many important development activities are completed, the test is just the final work, not the main process, although sometimes testing takes half of the project cycle, many project managers still insist on this.

Testing is a significant task

The V model describes some different test levels and describes the different stages in the lifecycles corresponding to these levels. As shown in the model diagram, the lower on the left is the stages of the development process, which corresponds to the rising part on the right, that is, the stages of each test process. Note that the name of the test phase may be different in different organizations.

On the development stage side of the model diagram, you must first define the business requirements, then constantly convert these requirements to the Outline Design and detailed design, and finally develop the program code. On the test execution stage side, the execution starts from the unit test, followed by the integration test, system test, and acceptance test.

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:

· The main purpose of unit testing is to address various possible errors in the encoding process, such as incorrect boundary values during user input verification.

· The purpose of integration testing is to solve possible problems in the detailed design, especially to check the interface between each unit and other program parts for possible errors.

· The system test mainly targets the outline design and checks whether the system is effectively run as a whole, for example, whether the expected high performance is achieved in product settings.

· Acceptance tests are usually conducted by business experts or users to confirm that the product is truly in line with the user's business needs.

Different types of defects and errors may occur in different development stages. Therefore, different testing techniques and methods are required to discover these defects.

 The art of discovering defects

Most testers are more likely to accept the V model, that is, testing and development are equal in the development process. Even developers also appreciate the test level proposed by the V model and the method corresponding to the development process, but few people make full use of the full power of the V model. Many people think that the test will only happen after the code or a part of the system is completed, and mistakenly view the test as "executing the test ". In this way, they knew that they really thought of the test before they started to execute the test.

Testing is not just testing. The test process also includes determining what to test (test scope and conditions) and how the product is tested (creating test cases), establishing a test environment, executing the test, and finally evaluating the test results, check whether the testing has been completed and report the progress. Besides, this is not enough. Based on the experience of many testers, when you think there is a problem somewhere, you may find the problem there. As said in the typical test book "Software Testing Techniques (Thomson computer Press, 1990)", test expert Boris beizer can discover defects and errors.

Moreover, if you put the test design in the final stage, you will miss the time to discover serious problems in the architectural design and business logic design. By then, it will be inconvenient to fix these defects, because the defects have spread to the system, it is difficult to find and fix such errors, and the cost is higher.

Flexible explanation, test as early as possible

The V model is easy to interpret in Europe, at least in the UK, but it is unacceptable in the United States. For example, although the V model does not clearly describe the early test design, Graham believes that it is embodied in the processing process and that it is the powerful force of the V model. The other test behaviors not explicitly stated by the V model are sometimes evolved into a W model, because the development is actually "V", and the test also overlaps with this "V ". Whether or not the V model clearly illustrates early test design behaviors, the test design is indeed worth emphasizing.

According to the requirements of the V model, once a document is provided, the test conditions should be determined in a timely manner and test cases should be compiled, which makes sense to all levels of the test. After a requirement is submitted, You Need To determine advanced test cases to test these requirements. After the outline design is compiled, You need to determine the test conditions to find the design defects of this stage.

If the test documents can be submitted as soon as possible, more time is available for inspection and review. These documents can also be used to evaluate development documents. Another major benefit is that testers can face the specification challenges as early as possible in the project (testing is a challenge ).

This means that testing not only evaluates the quality of software, but also identifies defects as early as possible to help improve the quality of the project. Testers who participate in the preliminary work can estimate the problem and difficulty in advance, which can significantly reduce the overall test time and speed up the project progress.

What-how-do

For the traditional waterfall life cycle model, the V model is often mistakenly considered to require that development and testing maintain a linear relationship between the front and back. A strict instruction is required to indicate that the previous stage has completely ended, to officially start the next stage. In this way, iteration, spontaneous, and change adjustment are not supported. For example, Brian marickarick (author of the craft of software testing (Prentice Hall, 1995) mentioned in the article "new models in the test process, "The problem with the V model is that the system development process must be divided into stages with strict boundaries, which makes it impossible for people to hand over and exchange test information between these boundaries."

In fact, this is not the case. Strict rules are not effective methods used by developers and testers to apply various models. In fact, various models simply remind us that it is necessary to define what needs to be done-what, and then describe how to do (Design)-How, then, it takes a lot of effort to implement (CODE)-do. What the V model does is to emphasize that each development level has an associated test level, and it is recommended that the test be designed before each level.

The workload of each model is not specified. Effective developers can always break down a project into small stages that can be operated. For example, in iterative development, the entire project is divided into many small fragments, and the actual size of each segment is ignored. At this point, the what-how-do sequence of the model is of great significance for the on-time delivery, and it is also important to ensure the implementation of each stage goal.

What the V model cannot do

The V model is applicable to all types of development processes, but not necessarily to all aspects of the development and testing processes. Unit Testing, integration testing, system testing, and acceptance testing are required for GUI, batch processing, mainframe, web, Java, and Cobol. However, the V model itself does not tell you how to define the unit test or integration test content, how to work smoothly, how to perform a specific test design, and how the input data is, the output result is correct.

Some testers think: "whether to use the V model depends on the project of the application. Some projects need to apply the V model, while some projects do not. It can be used only in projects that require the V model ." This is actually harmful to any model. We should try our best to apply the practical value of the model to the project, but do not forcibly use the model to use the model. Otherwise, it has no practical significance.

For example, opponents of the V model often claim that the V model is useful only for documented projects that have very clear requirements, because all developers and testers need to strictly define the requirements and design to carry out their work. Developers and testers are faced with the same confusion when many documents need to be supplemented afterwards or there is no document at all (this has become a development culture. In this case, the concept of the V model is still useful, but it is more difficult to apply it in the case of unclear requirements, because no matter what work is to be carried out or what to test, first, you must be clear about what you have developed.

Opponents of the V model may claim that the V model is not applicable to extreme programming (XP). In XP, rapid development and Pair programming are promoted, and test cases have been completed before encoding. First of all, we advocate to apply both methods at the same time. In addition, we also need to point out that the XP method also emphasizes discovering requirements as much as possible before programming.

The V model does not clearly indicate how the requirements and design documents should be defined, how many documents should be defined, and the V model does not show how to conduct the test design in each test phase. During the development process using the XP policy, the supporter of the V model believes that unit tests can be applied to the code segments divided, however, the V model does not define how to match each unit test. Integration testing is required only when necessary, and the final integration test is system testing. Although some XP workers regard these tests as "acceptance tests", the purpose is to reduce the necessity for users to perform tests, at the same time, we hope to ensure that the system meets the user's business needs in terms of functions.

Replacement of the V model-x model?

It may have been because the V model has been around for a while, and it has been abused to some extent, especially in urgent projects in the Internet era.

Marick believes: "We need the V model just like fish needs the bicycle. "In his article, he proposed a new model for the test process. He believes that some tests are earlier than commercial operations, while others are later. Furthermore, the V model makes it difficult for people to integrate the system description at different stages.

The supporter of the V model believes that, although none of the models present themselves impeccable, some models are useful in practice. In the next article, we will examine the X model promoted by Marick.

 

The address of this article is: http://www.itmarks.cn/onews.asp? Id = 85 reprinted please indicate the source!