Experience sharing software test case management

This paper involves the specification of test case writing and the sharing of use case management, so it has certain reference significance for junior test engineers and managers of quality teams. The methods and tools involved in this paper are not the only solutions. I hope you will gain more than just the surface of the text, but some views shared in this article.

Some people say: the test case is not known yet? Isn't it just a description of the test steps?

There is nothing wrong with this answer, but if you just think so in your heart, you can only say that you don't understand the test cases.

In addition to describing the test behavior, test cases are more used to verify whether the tested target meets the requirements, mainly testing the organizational induction ability of a test engineer. Input sources are usually commitments, use cases and their own experience in the business field. The professionalism of a software testing engineer is often reflected in the test cases he designs.

The test case set designed by professional engineers can not only describe their own behavior, but also guide others to realize it, which not only emphasizes depth, but also has excellent user thinking.

Although the format is basically finalized:

About this part, there are only many tutorials on the Internet, so I won't go into details.

It is only necessary to emphasize that the format can only ensure the clarity of test cases, but can not improve the design ability of test cases. So, how to write test cases? Still have to start with structured design. Here we need to mention a concept, HLTD(High Level Test Design), which can be simply and rudely understood as the design of test outline.

Just like writing an article, we will draw up a draft before writing the text, listing the central idea and paragraph outline, and then write it.

Writing test cases is a similar procedure. First, the test points are listed as an outline and have a structured layout. Usually, it is classified according to large functions or modules, and then the secondary or even tertiary classification is refined, and finally the specific test points are listed. In this stage of design, the author tends to use mind map (brain map), which is more intuitive than traditional document software tools.

Because in the end, it will be the overall situation, and the hard injury will also be reflected. It is only suitable for thinking and combing, not for document management.

Recording these structured test points is what we call test cases.

So we can see from here that the purpose of each test case is clear, that is, to verify one or a class of test points. The granularity needs to be weighed according to the actual situation of the company. Too thick is not conducive to summarizing the coverage of test sites, and too thin will consume more energy.

The test case is actually a very detailed document, which will inevitably consume a considerable part of the energy of the test engineer. In the era of traditional software development, even as an indicator of KPI.

But with the rise of the agile era, a voice began to impact this cognition.

Early agile practitioners, the interpretation of the agile manifesto only stayed on the surface of words, thinking that "only software is needed, and no documents are needed". This directly led to this period, a large number of teams lacked detailed documents, even some basic documents.

Nowadays, more and more agile practitioners realize that the Agile Manifesto does not advocate "no need for detailed documents". On the contrary, the Agile Manifesto recognizes that "detailed documents are very important" and puts forward a higher requirement-"working software is more important"

For the choice of document tools for test cases, many teams still stay in traditional office software, such as Word and Excel.

However, in today's market environment where everything is faster than others, the demand for team members to cooperate efficiently and enjoy team information in real time is getting higher and higher, and the platform management of test cases will eventually belong. In addition to documents, the platform is also used to make plans and display progress and results.

In fact, in the traditional era, larger software companies have used platforms to manage test cases, which proves once again that the agile era does not mean overthrowing past experience and achievements, but puts forward higher requirements.

At present, there are well-known management platforms based on Gila as plug-ins, such as Zephyr, Xray, synapseRT and TM4J, as well as independent open source platforms, such as TestLink, or charging independent platforms, such as TestRail.

We mainly consider from the perspectives of ecology, implementation cost, scalability and cost.

Zephyr has always had a great reputation, but in fact it is not in line with the habits of China people, and it is not convenient to use. The use case is directly issued by Gila, and the function is relatively simple. Use case management focuses on the relationship between plan and cycle. Because it is a Gila plug-in, it can be well related to other problems (requirements, tasks, defects) on Gila. But the visualization of its use case management is not very good, and there is no concept of use case set. In terms of migration, the types supported by data import are limited. In terms of extension, if you want to use its API, you need to install another plug-in. Its cost is moderate.

X-ray is quite satisfactory, and it also uses Gila's questions to create test cases. However, there are as many as five new types of problems, which are extremely complicated. The association ability is the same as that of Zephyr, but the data import support types are limited, and its own API is available. Its cost is moderate.

SynapseRT was developed by China people, with the best localization effect and powerful functions. The concept of useful use case set, use cases also expand with the Gila problem. Data import supports other platforms, such as TestLink and Zephyr. The ability of association is the same as that of Zephyr. The types of data import support are still limited, and there are also its own APIs to use. And the cost is relatively low.

TM4J uses an independent page to manage test cases, which is separated from the complex Gila question page and difficult to use. Data import is powerful, covering many types and some well-known platforms. The association ability is consistent with the above plug-in, and there are APIs available. But the cost is relatively high.

As an independent test management platform, TestLink is fully functional and free. You can think of a well-known platform like Gila, but because it is not the Atlantis system, the ecological experience is not high. Hard injury means that the interface is ugly, which easily affects the engineer's mood. I used to beautify the UI with its own API.

TestRail is a powerful business platform, so I don't have much contact with it, so I won't comment casually.

Generally speaking, although TestLink, as the top-level free and open source use case management platform, is very scientific in use case management, which is always worth learning, but my company is already using Gila and is landing DevOps, and I often get the support of the vice president of Atlassian China Community Research Institute, so TM4J has become the final choice:

The producer is still quite strong. In addition to TM4J, Zephyr is actually its product, and Swagger is already a highly recognized product at present.

It can be seen from official website's introduction that TM4J is still relatively modern:

First, let's look at how to write test cases using TM4J.

Hierarchically, we create directories and subdirectories according to HLTD for everyone to understand and read, and the final test point is instantiated as a test case, which has a globally unique key.

Click the New button to create a new test case. By default, it is located in the Details tab, where you can define the name, purpose and prerequisites of the test case. You can set the status, priority, belonging components in the details, and add some labels that are easy to manage.

Switch to the Test Scripts tab, the default is Step-by-Step type, and add each test step according to STEP-TEST DATA-EXPECTED RESULT.

It is also worth mentioning that in the Traceability tab, you can associate the Gila publishing and merging pages.

Usually we need to set the scope for the release and delivery of each product, so plan management is essential.

Plan management suggests making a top-level directory according to the release version, and then creating a second-level directory for test types, such as regression, new functions, end-to-end, interfaces, performance and so on.

The creation of the test plan itself is not complicated, except defining the name, purpose, status and person in charge of the plan, plus some labels.

You also need to associate a requirement or a fusion page. When the test plan is first created, the test cycle may not exist, but when the test cycle is created later, it will be related in two directions.

Test cycle is the key link between the preceding and the following, which connects the test plan and the specific test cases.

Usually, a release delivery will go through 3-5 sprints, and the scope of each sprint may not be exactly the same.

After creating a new test cycle name, description and details.

Enter the Test Case tab, click+Add Test Case, and add the written test case.

This step makes the test case have project attributes.

Finally, click the magnifying glass behind the test plan on the Traceability tab of the test cycle.

Correlate completed test plans by searching.

After creating a test cycle, you can enter this cycle and browse the test cases assigned to your own name. This is an interface that all test executors need to use, and you can also classify according to different rules through Group by, such as different directories made during the test cycle.

For the execution of use case steps, TM4J provides some shortcut buttons, which can directly mark pass, fail and block. You can click the gear button to quickly create and find the Gila problem for correlation. Of course, in addition to associating questions with steps, you can also mark questions for this use case and click+▼ after the questions. This is the advantage of a unified platform.

Although we can see the progress of the test when we look at the test cycle list, more data can be displayed through the test report.

The report function of TM4J provides us with rich templates, which is convenient for some inexperienced test quality managers.

Finally, the author wants to say that testing can't be an independent business, but should be more about collaboration with other roles. Especially in the current agile era, the execution of test cases may require the attention of development engineers, and the testing situation may require the involvement of product managers at any time. Therefore, we strongly recommend that software testers try to choose some cross-functional collaboration platforms.