Today, when a colleague was looking for product acceptance requirements, he found that the understanding of the product and testing and development was inconsistent, resulting in the use of this version of the function (the purpose of the requirements was not met); the testing and development agreed that the requirements of the product were not clearly written, as a bystander I don't think this is a problem that the product requirements are not clearly written.
How to align the understanding of testing and development with the product:
- The first time I came into contact with the requirements was the product requirements review. We all have a general understanding of the requirements. Maybe everyone has their own understanding of the requirements. If you have any questions, try to raise them during the requirements review, because you may forget this later . matter;
- When testing and designing test cases, design your own test cases comprehensively according to the design methods of test cases (such as equivalence class, boundary value, scenario method, etc.), and mark out the doubtful places; then organize a meeting to draw up corresponding Review the test cases for products and development . At the meeting, everyone once again understood the requirements and sorted out the business, asked targeted questions, and unified the problematic parts of the test cases;
- It does not mean that the test case review can solve all the problems. It is possible that the deepening understanding of the requirements may lead to other areas that need to be discussed or confirmed. At this time, our testers need to perform the following actions:
- If there is any problem, confirm the requirements with the product, slowly align, and continuously improve the test cases
- After perfecting the test case first, organize a test case review
Generally, the conference room is tight and it is difficult to occupy the whole time. In the work, if there is any doubt in the scattered time, it will be confirmed and aligned to improve the test scenarios and use cases.
Remark:
Sometimes you will encounter such and other problems during the formal testing process, but most of them are experience problems, and the priority of this kind is relatively low. You can raise it to see if the product needs to be optimized;
There are still very few problems that affect the realization of the current required functions or the use of other business lines (in fact, it is rare to encounter new functions that affect other functions). This kind of problem can be raised and pointed out, and the product and development need to be informed , and discuss how to solve it at low cost. If the current version does not have time, do you need to find a small version to iterate and bring it up;
Extension: If all of the above are taken into account, understanding and opinions are aligned, and there are unexpected problems in production, this cannot actually be blamed for testing, because no one has discovered or pointed out problems during the process; but in reality The sad thing is that as long as there is a problem, it will be blamed for the test. No matter what the reason is, if the test fails to detect this problem, it is the fault of the test~~~