Development test?

foreword

The development test is an important hurdle to officially start the test. The quality of the test will directly affect the efficiency of the test phase, and then affect the progress of the project. Better test quality can improve test efficiency and optimize project progress with twice the result with half the effort. How to better promote development and improve the quality of testing? The following editor combines the problems encountered in my own project (for example as follows), and shares with you the optimization plan related to the development of self-test cases.
Q:

• After the development verification self-test case passes the test, the test verification self-test case fails;
• In the development cooperation requirements of each end, the development responds to the self-test case before the actual joint debugging is successful;
• The development and product parties communicated and adjusted the requirements, but did not synchronize them to the test;
• ……

Develop a self-test case

There are many ways to promote the improvement of test quality. Each project team will have its own characteristics and corresponding applicable matching methods and processes. Combined with the experience accumulated in the mining pit in the project, the editor now summarizes the following methods for implementing it in the actual project.

In the development and implementation before the official test launch, the implementation quality and expected results can be improved through the program explanation meeting and code review; in the formal test launch stage, the quality can be checked through self-test cases, interactive walkthroughs, visual walkthroughs, etc.; Finally, there can be methods such as product acceptance. Here, I mainly communicate with you about the self-test case in the formal testing phase.

When it comes to developing self-test cases, I believe that many test partners are familiar with them, or even familiar with them. Combining the actual application of my project, I will briefly introduce the self-test cases.

1. Introduction to self-test case

To develop a self-test case is to develop students to provide a test function in the form of email before the tester needs to provide a copy in the shortest time to verify whether the function on the main process of the test module has been developed, whether the requirements are covered, and the interaction is clearly defined. The details of the main path of the product, so as to ensure that the product meets the expected results of the product in its initial form.

2. Self-test case selection

Based on the product requirements/interaction documents, development and implementation process (engineering-led requirements), the test students sort out the main path case of the function (including buried point requirements).

3. Self-test case process

Develop self-test case cooperation

Based on the process specification of the above self-test case, the problems encountered in the actual project cannot be well solved (in the preface). This part will combine the implementation of the actual project self-test case and the implemented solutions to the cooperation problems, and further supplement the cooperation details of the self-test case development.
1. Self-test case sending timing

Self-test case emails are sent at least one day in advance of the development and testing schedule. According to the type of requirements, they can be classified and refined as follows.

• Product requirements in the project release plan:

After the requirements review meeting, when the project test starts, send the self-test case first;

• Insertion/requirement changes between project versions:

After the three parties have communicated and reviewed the details and logic of the required change/insert task, the test students will reply to the self-test case email on the basis of the product required change/insert email;

• Engineering optimization requirements:

After the three parties communicate the details of the requirements and the corresponding version plan, test the specific logic of communication between classmates and developers, and then reply to the self-test case email on the basis of the corresponding engineering optimization email.

2. Self-test case test preparation instructions

• Multi-terminal and multi-person cooperation requirements self-test case division:

For the requirement of multi-terminal cooperation, the test needs to send a self-test case email corresponding to the corresponding functional logic to the corresponding development students. When the specific logical division cannot be determined, you can communicate with the development in advance and send a unified self-test to all the development students who cannot be distinguished. Test case emails are communicated between developers to divide self-test case verification, and reply to emails for testing.

• More complex module self-test case email form:

There are relatively many self-test cases corresponding to complex modules. In order to facilitate the synchronization of development mark results, you can add the self-test case documents as attachments in the email.

3. Self-test case cooperation specification

• Specifications for developing and verifying self-test cases (emphasis added)

The three parties agreed that the development needs to be verified by the release version in the build system before the self-test case can be tested , and the local debug package cannot be used to verify the self-test case. In this way, on the one hand, it can prevent the problem that the actual multi-terminal development has not been completed and the test progress is affected, and on the other hand, it can avoid the problem of blocking bugs caused by the difference between the debug package and the build package for secondary testing.

Say important things three times:

The development must use the build package to verify the self-test case test! ! The development must use the build package to verify the self-test case test! ! The development must use the build package to verify the self-test case test! !

• Develop self-test case and test email specification

1. The development branch of the build system needs to be explained in the test promotion email. Note that it also involves the interactive functions of multiple SDKs at the same time, and the corresponding development branch needs to be explained at the same time; (if it has been explained in the project optimization email, no remarks are required)
2. If the test environment is involved, the host of the test environment must be stated in the test submission email, and synchronized to the test students;
3. If there is a later demand change or a change point in the development and implementation logic (which has been synchronized with the product), which does not match some cases, it needs to be noted in the body of the email;

• Synchronous test preparation for self-test case test

While the development is sending self-test case emails, it is necessary to send visual walkthrough notification emails to visual classmates and interactive classmates walkthrough notification emails.

visual walkthrough

In order to avoid the problem of repeated compatibility testing workload caused by the failure of the visual walkthrough or the change of the visual draft in the later stage, the timing of the visual walkthrough is advanced to the development and testing stage in the project where the editor is located, so as to ensure that before the compatibility test, the UI To reach the testable standard, the basis for the test students to start the compatibility test of the UI layer is to visually check and pass the email.

The specific cooperation process is as follows:

Example of email format:

Remarks: The form of the problem description: it can be described in the body of the email or attached in the attachment.

Summarize

In the process of actual project testing, we will inevitably encounter problems of cooperation, efficiency, and quality. Different project teams will have different solutions. Process specification is only one of the effective means. Friends can according to the actual project situation Choose the solution that suits you best.

[A full 200 episodes] Ultra-detailed advanced tutorials on automated testing of Python interfaces, truly simulating the actual combat of enterprise projects! !