Recently, I joined a company that mainly focuses on web system testing. The test output is especially emphasized, and the test case is one of the main output, and the requirements are more detailed.
1. The title of the use case is in the form of a briefing report, lacking a clear purpose
There are advantages and disadvantages to this method. The advantage is that the test points are clear at a glance, but the disadvantage is that the purpose is not clear, and you need to check the expected results to understand. (Personally, I prefer the use case title to be a summary of the use case, and the purpose needs to be pointed out)
2. The steps do not correspond to the expected results
The recommended steps correspond to the expected results one-to-one. Even if the log output content is one of the expected results, it also corresponds to the “view log” step.
3. Steps are substituted in the expected results
The expected result is the data, status, or page presented after the operation. Should not bring in actions, such as failed to submit login prompt, typical “step + result”.
4. Use case redundancy
Test cases are recommended to cover test points as much as possible with the smallest set of use cases. Invalid use cases (remove invalid equivalence) should be eliminated. Use cases should not be piled up too much. The data is good-looking but not conducive to execution.
5. After the use case is written, the Zen Tao is imported, and the necessary organizational relationship is lacking
If the use case import tool does not have a good organizational relationship, it will inevitably bring difficulties to the subsequent extraction and execution of the use case. Therefore, before writing the use case, you must consider the organizational relationship after the use case import tool.
Finally, to join a company, you must first adapt to the rules, then learn from each other’s strengths, and then influence and promote the improvement of the rules.