Common problems during testing and Solutions

1. When do testers need to participate in requirement analysis?

In principle, the deeper the tester understands the requirements, the more favorable the testing work. Therefore, it is best to participate in the requirement analysis work from the very beginning. This can bring the following benefits:

Testers participate in the demand analysis throughout the process and have a deep understanding of the requirements, which reduces the interaction with developers and saves time. The testers participated in the preliminary development discussion and directly grasped unclear requirements;

The idea of writing test cases was determined in the early stage, laying a foundation for Project (product) testing;

You can obtain some test data to help you design test cases;

Unreasonable requirements can be found, reducing testing costs.

One of the major tasks of testers is to check whether the system meets the requirements correctly. If the tester is not involved in the preliminary work, he can only rely on the final requirement documents, and even the developers can explain the requirements, which may cause "problems ", because this requirement has been analyzed, a lot of content may be different from the real requirements of users. At the same time, if you only look at the final requirement documents, there will also be deviations in understanding the requirements. Therefore, as a tester, it is necessary to obtain the "first line" of required information as much as possible to truly understand the user's business, so as to better test the system.

Of course, if testers are not allowed to participate in the requirement process, they must ensure the correctness of the requirements through other means, such as holding a project meeting with developers to focus on the demand questions, in addition, it is necessary to strengthen the test case review, or even the review of test requirements.

2. What should I do if there are many low-level defects in the system test phase?

In the system test phase, if there are still many low-level defects, it indicates that the test object is unqualified and fails to meet the test standard. If there are many simple defects found in the system stage (that is, there should be no defects), it is best to stop the test and report it to the developers for testing and immediately modify the problems found, the costs of testing by testers are high, and repeated interactions may delay the project progress.

We recommend that you establish a pre-test system: conduct spot checks on the core modules before the system test. If there are many problems (such as more than 20 defects in the core functions), you can stop this test, feedback to the development team for testing. The system test can be started only when there are few problems after the test.

3. What are the consequences of defect migration to the customer?

If a software defect is left to the customer, the result is a costly telephone or on-site support cost, which may also require repair, retest, and release of new products, even worse, the product will be recalled or even sued by the customer. This cost is very high, almost several times or even dozens of times the number of internal defects modified.

Philip Crosby, the father of quality, divides the cost of quality into two categories: Integration cost and non-integration cost. Integration cost refers to the full cost associated with one-time plan and execution test, which is used to ensure that the software is performed as expected. If a defect is discovered and the defect is solved through a series of defect processing procedures, the cost is not integrated. In his work, Philip Crosby elaborated on the sum of the internal integration fee and the internal non-integration fee, which is far less than the external, that is, the customer's non-integration fee.

Software testing is an effective means to ensure the quality of software, but it is not the only means. High-quality software is not tested, but designed. This requires the participation of all Members to Improve the Quality awareness of all members and improve the quality of software together.

In short, Software defects must be solved internally as much as possible, which is of great significance for cost saving and product visibility improvement.

4. What should I do if the status is modified and the defect is not modified?

First, analyze such defects:

(1) Some problems are not reproduced in the development environment, and developers are often marked as modified due to the progress pressure. In this case, testers should communicate directly with developers;

(2) If the tester does not clearly describe the problem, the developer determines that the problem does not exist and may mark the problem as modified (the correct method is to mark the problem as discussed or non-reproducible ). Testers should clearly describe the problem and reduce the occurrence of such problems, especially the running environment and reproduction steps of defects;

(3) The third type of situation is purely personal behavior: due to the pressure on progress, developers may intentionally mark some problems as being modified so that they can be modified after the next test. The solution to this problem is to count the number of defects modified, analyze which repeated defects belong to which developers, and then inform the project manager (which may be combined with performance appraisal .) In this case, the tester needs to re-open the unmodified and marked defects.

The fundamental way to solve this problem is to strengthen project management and improve project execution capabilities. once resources are abundant, testers and developers will invest more in solving the defects together, together to improve software quality. This requires that the project plan should be made as reasonable as possible.

5. Who will release the product after the product test is completed?

In many cases, the product is released by developers after the last test or by the Quality Management Department. This is not suitable.

Releasing a product by a developer often leads to incomplete defect resolution. A common phenomenon is that after the last regression test, the developer modifies the last few defects and releases the product directly from the development environment. In this case, the actual defect is a test, because modification defects usually introduce new ones, or even serious ones.

The product release by the tester does not conform to the process. The tester is responsible for reporting the software quality. In addition, the release of products by testers may lead to chaotic version management.

The correct method is to store the product and defect changes in the product baseline database after the last test to form a release version. One premise of releasing a product in this way is that a pre-release version is required before each product is submitted for testing. If a problem needs to be fixed after the test or regression test, the developer can modify the pre-release version. After so many times, until the last test, all the defects were modified or reviewed, and the developers did not make any changes to the product after the test, we can store the last pre-release version to the baseline database.

After correct version control, we can use the Configuration Management Library for product release management. When releasing external products, you can directly extract them from the Configuration Management Library.

6. Who will handle the new requirements or change comments generated during the trial phase?

During the trial phase, users may propose new requirements or modify their opinions. What are the feedback channels for these opinions? Is it reported to testers, Quality Assurance personnel, project managers, or project owners? The actual situation confirms that the feedback to the Project Manager or project owner is the best channel for these new demands or suggestions, in this way, the Project Manager or project owner can directly obtain the project modification comments or add new requirements, rather than repeat the other personnel. Because the project manager or project owner is the project designer and developer, they are most familiar with the software system and can provide new requirements or suggestions for modifications based on the actual situation of the system, answers reasonable demands and reasonable modification suggestions. Block unreasonable demands or comments, or give users a reasonable explanation that cannot be modified.

If a tester or quality assurance engineer is given first, the effect will not be very good. After the tester receives a new requirement or change suggestion, the tester cannot immediately confirm whether the change is made, it is unclear whether the workload of modifying these functions and whether there are technical difficulties. Second, after obtaining the required information, the tester still needs to report it to the Project Manager or project owner, which wastes some time. The main manifestation is that, if the tester does not fully understand the new requirements or modify their opinions, there will be deviations during the referral, the Project Manager or project owner must re-confirm the requirement or change comments, resulting in unnecessary workload.

 

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/xiagaoming/archive/2006/11/29/1420481.aspx