As a qualified test engineer , you must master the daily workflow of testing.
So in a product cycle, when do test engineers get involved? What specific tasks did you undertake? These two questions are also often encountered in daily interviews. Here I use a mind map to make a simple summary (as shown below)
Today we will talk about " test case design " and "test case review".
01 Test case design
Common test case methods have been used by everyone online and in daily testing. Here I will explain to you how to design use cases for some special test points.
1. Details page field verification
Method: Scenario Combination Design Use Cases
Implementation: Different fields on the same details page can be verified based on the "same piece of test data" through scenario combination use case design, thus saving testing workload.
Through the above scenario, it is possible to verify "different fields and different enumeration values" on the basis of "the same test data". Originally, 8 test cases were needed. After "scenario use case design", only 3 test cases were needed for verification.
2. Query condition verification
Method: global to detailed
- Globally verify whether the query condition fields are complete or correct
- Specific query condition function verification
02 Test case review
Due to the standard for designing test cases: a test case only verifies one point as much as possible.
Therefore, the test cases designed by testers are simply "stinky and long" for development. During the test case review, most developers are probably in a fugue...the review meeting lasts one or two hours, but the effective absorption for the development is less than one percent
So how to conduct use case review effectively?
1. Use case marking focus
Demand questions: After product confirmation, output specific test cases
Design interaction: The UI does not provide interaction, and the actual interaction details of the function are not described in the requirements document.
…
During the process of designing test cases, the above [not clearly described in the requirements document & confirmed with the product during the process of designing test cases] needs to be reminded during the use case review to keep the information synchronized.
2. Logical overview + core review
Global Process - Logical Overview Use the "Xmind" mind map to make a brief logical overview and explain the basic process of use case description. After the description of this stage, if there is no doubt after product and development confirmation, this part of the basic test cases can be skipped when conducting use case review.
Local details - highlight the core details of use cases. In addition to the basic business process, test cases with some special scene details may affect the business process or cause losses to the company. Use bold/color markings to remind developers during use case review.
Special scenarios include:
Front-end and back-end data synchronization and interaction, multiple people operating data at the same time, etc. The following are the core test cases for logic verification (for reference only)
03 Summary
Whether in test case design or use case review, using the "overview first, details later" approach is beneficial to both development and testing itself.
For testing:
✅ Maintain clear review logic to avoid confusion during review
✅ Improve the efficiency of use case review and save team time and cost
✅ Increase development emphasis on test cases
For development:
✅ Save energy and increase attention and absorption of core use cases
✅ Improve code design defects in a timely manner and improve development quality
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you!