Foreword
Whether in traditional software companies or Internet companies, the design and writing of test cases has always been an indispensable basic work for testers. However, there have been controversies and discussions about whether it is necessary to write test cases and the granularity of test cases.
Basic project process
When talking about whether test cases need to be written, let's first talk about the R&D process of most Internet companies. Simply put:
Product managers write requirements => product, R&D, testing, etc., conduct requirements review => develop design, code, and test, write use cases and review at the same time => develop submit test => test execution test => product release
This is a general process, of course, every A company will make some adjustments according to its own situation, more in line with its own team, and continue to summarize and adjust as the project progresses.
Use case writing and execution phase
From the general process, we know that the test case is written at the end of the requirements review and after the project is approved, is it really necessary to write the test case?
From a personal perspective: the preparation of test cases is a must! Many testers think that the writing of test cases is a waste of time, because it is difficult to execute the pre-written test cases when they are finally submitted for test execution.
Testing is difficult to execute in accordance with pre-written use cases. I personally think that the main reason is: the requirements review was not done or did not do the requirements review at all, resulting in the development, product, and testing that did not reach a consistent understanding of the requirements. , The requirements may be imperfect, unclear, doubtful, etc., and the requirements are constantly changing during the coding process.
Even if there is a detailed requirements review process, often when testers are writing test cases, in order to cover as many test points as possible, they will constantly understand requirements from various angles and often find requirements. Some of the omissions and doubts, and then through timely communication, you can find problems early, reduce the risk of the research and development process, and reduce the changes between the completion of the use case and the final execution of the use case. This way, the process of writing the use case will help the test to understand the requirements.
Benefits of writing use cases
The great advantage of writing use cases is to avoid blindly executing tests. The use case is like a script, and the tester can do a more comprehensive test of the system under test according to the setting of the script.
Use case granularity
The granularity of the use case is like a script. It is easy to constrain the performer's self-expression if it is written carefully, and it is worried that the performer will miss some important links when it is written thickly.
If you are a traditional software company, a project may be delivered only once a few months or even six months or a year, so you have enough time to design your test cases, then I recommend that your use cases be as detailed as possible, and keep going Repair, supplement, and perfect.
However, in most Internet companies, they are basically agile, pay attention to small steps, fast trial and error, basically product iterations are very frequent, for example, a company's products are iterated every two weeks.
This leaves us with a very short test execution time, not to mention the time to write use cases. At this time, we have to make a compromise to some extent, simplify the test cases, and no longer describe each use case in detail. , And more is to write test points.
When encountering more complicated processes, I still hope to describe the use cases in as much detail as possible. The test point does not mean that there is no need to consider various user scenarios, but as much as possible to describe the summary of the scenario in one sentence, so that the tester can clearly know which use cases need to be executed through such a sentence summary under the premise of understanding the requirements. The requirements for testers will be relatively higher.
Use case modularity
If you write too many use cases, you will always find that many functional modules are similar, such as query function, page turning function, text box verification, time control verification, etc. At this time, you can learn programming ideas, and a certain piece of code is used in many places. , Then it is extracted into a public method for various places to call. When writing test cases in the same way, you can also extract similar test cases to form a use case library for reference by the same functional modules.
Use case iteration
The use cases are iterated, and each new iteration is based on the use cases of the previous iteration to make additions, deletions, and changes. For example, suppose I manage my use cases through excel, then every time I start a new iteration, I will make a copy of the old use cases, and modify the copied use cases to form the latest version of the test cases, so that I can retain The previous iterative test case (which can facilitate the function backtracking) can also have a complete test case of the current system.
to sum up
Use case review is also very necessary, especially some experienced or business-familiar old drivers can quickly help point out the omissions of the use case in the use case review, which helps testers open their ideas and cover as many user scenarios as possible. It is worthwhile It should be noted that the uncertainties encountered in the use case review should be recorded immediately, and the relevant personnel should be confirmed in time after the end to avoid guessing.
Software testing exchange group: 785128166
WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"
Next update: Analysis of the thinking of test cases
Here is a collection of selected dry goods articles for functional testing: