Nine functional analysis of excellent test management tools

With the development of the Times, the software scale is more and more large, the complexity is more and more high, the test work also put forward higher requirements, testing field has emerged a variety of theories, methods and tools. A very important branch of this is the test management tool, which mainly solves the problem of team collaboration during testing, such as defect management, use case management, test task management, etc.

Currently on the market more popular test management tools have QC, Mantis, BugZilla, Testlink, Trac, Redmine, Bugfree and so on. There are open source software, there are commercial software. The respective focus of these software is different: For example Mantis, bugzilla emphasis on defect management, testlink bias test Case management, QC is more comprehensive, TRAC and Redmine project management concept is stronger. We summarize and analyze the advantages and disadvantages of these software, combined with their daily actual work needs, designed a set of test management software, this article is in the design of this software process summary and thinking, hope can give you some inspiration.

In the design process, we established the goal is in a set of software can be implemented in the whole process of testing management. So, what features are essential in this management process? After intense discussion and constant revision, we summarize the following nine features: test requirements management, test case management, test suite management, test Release management, test plan management, test execution management, defect management, release management, and analysis reports. The following author describes these features one by one.

First, test requirements management

Demand is the soul of a software product and is the most important reference standard for development and testing. It is hard to imagine how a software without requirements can design its test cases. Whether it is a test case or a defect, it is based on a specific requirement. Therefore, a good test management software first has the test requirements management.

1.1 Demand splitting

In the traditional project management process, the demand is often presented in the form of demand scale specification. Requirements specification is more comprehensive, but the disadvantage is not split into demand points, can not achieve a specific function point tracking. So in the test management tool we designed, the requirements are presented in the form of demand function points. This facilitates the writing of test cases for each function point and the tracking management of the tests.

Large modules into small demand, small demand to split into demand points, after the split, a layer of hierarchical management is essential. In order to adapt to the increasingly complex needs and changes in response, the requirements of the module also need to achieve an infinite level of division, so as to form a tree structure, whether from browsing or management is more flexible and convenient.

1.2 Demand Management

With the modules, the next thing to do is to manage the test requirements. We need an interface to input requirements, common fields include: Title, description, priority, etc. In addition, the requirements can be modified, deleted and other operations.

1.3 Demand Search

After implementing the basic requirements maintenance function, we also need to implement the search function of the requirements, so that we can find the needs we want.

Second, test case management

Well, now that we have the testing requirements, we can write test cases for each requirement. The maintenance of test cases involves such functions as module partitioning, test case maintenance, import and export, and search.

2.1 Use Case Module partitioning

Similar to the requirements of module maintenance, use cases also need to be separated by the module to maintain the use cases. In the software we are designing, the modules of the test cases and the modules of the requirements are separated. Readers are sure to ask, why do you still need to maintain a set of templates for Force? Why not reuse the module partitioning of requirements? This is because in the actual project, the demand is from the user and product point of view, the demand is more to help the user how to achieve an operation, realize a function. But the use case design not only needs to consider the requirement, but also needs to consider some unusual situations to design the use case, the separate module management for the use case will not affect the original requirement management part.

2.2 Maintenance of Use cases

The following is what we want to achieve is the basic addition of test cases, editing and other operations. This functionality is implemented in most tools that have test case management, but it is particularly stated that in most management tools, the steps of the test case are not separate, and the expectations of each step are even mixed in one field. In fact, this is not scientific, will not only reduce the granularity of use case execution, but also affect the subsequent generation of some data, as to what kind of data to generate, first sell a xiaoguanzi here, the following explanation:-). In the system we design, the steps of the use case are completely separate from the expectations of each step.

2.3 Import and export of use cases

Many companies are still using Excel to write and save test cases, and if a company is prepared to adopt a test management system, manual import of these use cases will be a heavy task. Therefore, the test management tool needs to be able to import the use cases in Excel into the system, as well as the ability to export test cases to files in Excel format.

The function of exporting Excel from the database is better, the import function of Excel, the idea of the author is that we can get the data automatically through the VBA programming of Excel, and it can be updated back to the system, which will be more convenient and quick. is currently in the study of groping.

2.4 Use case search function

As with the search function of the requirement, we also need to make the test case easy to retrieve, in order to find the test case that we want to use.

Third, test suite management

With the test case, the next question arises: how to organize and maintain these use cases. In addition to the module features described above, import and export and search, test suite functionality can also be very handy to help testers organize their own test cases.

Test suite may be a disagreement more than a concept, in our view, the test suite is a collection, you can easily put some of the use cases according to a certain characteristics of the organization together, convenient for subsequent management and maintenance. Thus, the functionality of the test suite from this point of view includes the creation of test suites, associated test cases, and the browsing and maintenance of test suites, which are not described in detail.

Iv. Beta version Management

In the current software development process, the code version control has been widely used. And thus we can derive the concept of the test version. A test version can be either a build or a point in time, the concept of a beta version is important, and through it we can identify the scope of our current testing and know what test cases we need to execute. While the developer fixes the bug, it can also clarify which version the current fix will affect.

4.1 Version and requirement, bug Association

The first thing we need to do is correlate the beta version with the requirements and bugs. That is, when we create a beta version, we need to determine what the requirements of this release are and what bugs are resolved, thus defining the scope of our testing. is the associated page of requirements and bugs that are implemented in the system that we designed to create the build.

Integration of version 4.2 and source code management systems

A version must correspond to a path in the source control system, typically corresponding to a directory similar to Tags/xxx.1.0.build1. The attentive reader may have noticed that the source code and the storage address shown in the image above are presented as text boxes. This is also a feature that we are planning to implement, that is, the source code version can be automatically obtained from the source code control software. For example, I can get the corresponding code version from one of the paths of subversion, so that the test management system and the code management system can be organically combined.

V. Test Plan Management

Now that we have the test requirements, the beta version, the test case, and the test suite, then we're ready to start executing the test? Don't worry, it's best to have a plan, and the test work is no exception. The so-called test plan, in fact, is how to test a version, to ensure the quality of its code. From a test organization management perspective, this includes several tasks:

5.1 Submit test, create test task

When a beta version is created, we can submit tests for testing. The submission test mainly indicates which version to test, what the expected start and end times are, and some information about the notes.

5.2 Determination of test cases

When a test task is created, we need to determine which test cases will be executed for this test task. Since each beta version has the requirement to register this version or fix the bug, the process of identifying the test case that needs to be performed is the process of filtering the test case based on the appropriate requirement or bug.

5.3 Allocation of test cases

Then, with the use case filtering feature described above, after determining the use case for this test, the next step is to allocate the test case as well. Of course, if a test task is done on its own, the job can be dispensed with. But if a test requires a lot of people to do it together, or if it needs to be outsourced to a third-party company, you can use this function to assign test cases.

Vi. Test Execution Management

Once the test plan is done, the test cases that everyone is responsible for executing are very clear. The only thing everyone has to do is execute the test cases that are responsible for their own head.

6.1 Test Case execution

First, let's take a look at the execution page of the test case:

Since the test cases we designed are separate steps, the results of each step execution can be clearly determined when the test case is executed.

In the test task's use case list interface, you can view the final execution of each use case.

6.2 Creating a bug from test results

Once a test case fails, you can create a bug directly from the test results and assign the appropriate developer to resolve it.

As you can see, we can automatically generate the repro steps of the bug:-) This is the benefit of separating the test case steps.

Vii. Management of defects

Defect management is the most important feature in a test management tool. When a bug is generated during testing, the interaction between the developer and the tester is made through bugs. This includes basic create bugs, fix bugs, edit, verify off, activate and more. The function and logic of this piece are familiar to us, and we will not repeat it.

What we want to share with you in particular is the conversion of bugs to test cases. Some bugs are very classic, but also very important, but when this bug occurs, there is no use case covering it in the current system, so we need to put it in the use case library, to ensure that the subsequent version no longer return to similar issues. So the system we designed also provides the ability to turn bugs into use cases.

Is it cool to automatically calculate the steps of a bug as a use case?

VIII. Release Management

Once a developer resolves several bugs, it is time to recreate a test version, submit the test, then test the plan, test execution ... So round-trip until the final phase of the test work is finished, we can create a release.

When creating a release, you need to select a test version (build), which is associated with the requirements of the release, the use cases that were designed, and the bugs that were submitted, resulting in a complete closure of the previous work.

Nine functional analysis of excellent test management tools