How important is an effective defect management process? I’ve seen teams that don’t have a process in place, but instead do defect management verbally or by email, which can lead to problems such as:
Testers and product managers say: We found 15 bugs. The product manager gave it to the developer for a while, and the developer said, “I fixed 14, and the other one wasn’t a Bug. The product manager, of course, has to submit it to the tester. The tester says, “There’s one Bug that hasn’t been fixed, and I found nine new bugs.” The product manager is full of ten thousand beasts.
So, if you don’t want to go crazy as a product manager, you need to learn to develop an effective defect management system.
Today I’m going to demonstrate how to build an effective defect management system using CORNERSTONE, a project management platform.
Defect management process
Create test cases
For effective defect management, first of all, the testers can’t test where they want to, as in the above scenario, so we can’t count on the launch of the product… So the first step is to go to the test case page and create the test case.
CORNERSTONE provides flexibility in customizing use case templates based on product features, adding priorities/status/responsibilities, adding descriptions, comments, and so on.
With use cases, it’s just a matter of knowing what the tester is going to test, and figuring out how to test it next, so create a test plan.
A test plan is a document that describes the scope, methods, resources, and schedule of test activities to be performed. It is the assembly test and validation test for the whole information system application software. It can identify the test items, the characteristics being tested, the test task, who performs the task, and various possible risks. The test plan can effectively prevent the risk of the plan and ensure the smooth implementation of the plan.
With CORNERSTONE, users can initially set attributes such as accountability, priority, status, classification, iteration, deadline, and so on in the test plan.
I remember hearing an old product manager joke that testers could write test cases for a project as thick as the complete works of Shakespeare. You can see how difficult it is to write test cases… However, tools such as the Test and defect management module provided by CORNERSTONE now allow for one-click generation of test cases from mind maps
(2) Defect discovery
When everything is ready, testers are ready to start testing. Testers test against what’s on CORNERSTONE’s test plan page, fail the test, find a defect, go to the defect page and create a defect… It’s not that much trouble! At CORNERSTONE, we can associate test cases with defects, and once the test status is set to “fail,” the defect will automatically update the status. Below is a common defect state flow diagram:
Defects are displayed as unresolved, and testers will assign a “responsible person” to the appropriate responsible person, who will receive a defect change notification from CORNERSTONE.
Refused to
In CORNERSTONE, also support all members modify defect status, because sometimes developers think of submitted defect is not really a defect, such as cache, network problems, for example, defect status should be marked as “declined”, and attach description, at this time the test team need to test or to provide more defect information.
Addendum: CORNERSTONE users can customize the flow of defects.
Such as:
L If the defect received by the development team is a duplicate or similar to other ongoing defect issues, it may be marked as “duplicate”.
L Defects that are not urgent and may be fixed in future product iterations, for example, may be labeled “delayed.”
Under test
When the development team fixes the defect, it should mark the defect status as “ready to test” and hand it over to the tester to test again. When the test fails, the tester changes the status again to unresolved and adds a note.
Shut down
After the test is passed, the defect status is changed to “closed” or completed.
You see, defect management goes like this, “is there a Bug”, in the process has been dealt with.
Set the right defect Priority. A key word we mentioned earlier in the process was “priority.” We all know that defects in software products are inevitable. These defects range from mild to severe, some of which could have very serious consequences if not addressed promptly and effectively, to minor ones that almost everyone would not notice even if not fixed.
There’s really no need to waste time with these bugs, unless you have unlimited resources to allocate to all bug fixes, you need to focus your resources on bug fixes with a return on investment first.
Develop a set of defect Handling Guidelines To effectively deal with defects, you need to establish a process. To establish a process, you need to establish a set of common defect handling guidelines across teams. Instead of a detailed assessment of every defect issue, we can quickly deal with it through our management tools, directly following our guidelines.
Here is a sample of defect rating criteria that you can refer to and set up your own rating standard according to your actual situation.
L Low: An insignificant problem or some feature is not available, but there is an easy fix
In l: Accessibility is not available, but there is a reasonable solution
L High: Important features are not available, but there is a reasonable solution
L Major: Data is lost, damaged, or unavailable
Critical: Must be addressed immediately, inserted into the current iteration of the product, above other requirements development.
High: Fast processing, inserted into the current product iteration, but below part of the requirements development tasks for this iteration.
Medium: processing, which can be processed with the next product iteration.
Low: selective processing, which can be processed in the next iteration or several iterations according to the iteration progress.
The key advantage of this approach is that it greatly reduces the time spent discussing how to deal with each defect. In addition, the impact range and severity of the two factors considered by the team are relatively objective, which reduces the error caused by subjective factors, makes the measurement standard easier to judge, and makes it easier and efficient to determine the priority level of system defect treatment.
Here’s how to build a defect management system.
Finally, it has to be said that the team needs data support to timely discover and solve problems and improve the defect management process after the completion of numerous defect processing. At the same time, it can well measure the team’s work results and progress, and detect the defect change trend of each module of the product. Therefore, a good defect management tool should have multi-dimensional data reports to view the repair situation globally and effectively prevent risks.
One-stop project collaboration platform covering the whole industry
Official website link, close not thank!
www.cornerstone365.cn
