Good use case Vs bad use case
Test case is one of the most critical documents that the test department should output. Agile development advocates light documentation and heavy communication, and many documents in traditional processes can be omitted, but I don't think test cases are among the documents that can be omitted. Instead, test cases can, to some extent, replace detailed design and summary design documents as a document of an interface nature.
Compared to runnable code, the advantage of documentation is readability, and another word is user experience. Good documents can help people think better. As the old saying goes, a good memory is not as good as a good document. Test case documentation must be written to help you and your team think better. Therefore, the first point of view is put forward here: good test cases must be user-centric; bad test cases are usually technology-centric.
How do you define a user? Users can be divided into internal users and external users. In view of the fact that the customer is God, the testing department should define the department function by the agent of the end user. Therefore, my second point of view: good test cases are based on the user experience of product functionality; bad use cases are usually based on functional code implementation.
How to reflect the user experience in the use case? The basic skeleton of a test case consists of three parts: {test steps, input data, observation points}. In the design of the test steps, the first thing to consider is the user's usage scenario. Therefore, my third point of view: good test cases should be organized according to usage scenarios; bad test cases are usually organized according to programmers' modification points.
An excellent team must be a team with accumulation. Build a team where the younger generation can stand on the shoulders of the elder and continue to climb, so that the organization can sprint for higher goals. Excellent organizations should be open and competitive, motivating people to explore and develop new tools and methods, and help newcomers quickly integrate and accept existing tools and methods. Therefore, my fourth point of view: test cases should not be scripted, test cases should not be deliberately omitted because the test conditions are difficult, good test cases should be selected according to requirements, and bad test cases should be avoided according to tools.
As a document, test cases must pay attention to format and readability. The document format should not only be unified, but also reflect the law and logic, proper arrangement of details, uniform distribution of test points and less redundancy. Therefore, my fifth point of view: a good use case structure is balanced and hierarchical; bad use cases are long and short, and the whole document is organized irregularly.
The construction of test environment is often the most time-consuming and troublesome link in the process of test execution. as a guide of test execution, use cases must consider the availability of the environment in the process of test execution. So my sixth point of view: good use case testing according to the deep technical implementation, build a simple and optimal test environment; bad test cases copy the user environment.
A test case is a document that needs to be updated. Fix points, online problems, and problems found in the test should be added regularly, and the automation of toluene and use cases should be kept in sync. So my seventh point of view: good test cases are easy to maintain and can find problems continuously; bad use cases are difficult to maintain and will soon lose value and become junk.
