We all know that as long as it is software, there will be some defects. These defects are mild and serious. If they are not resolved in a timely and effective manner, some defects may cause catastrophic consequences, while others are relatively minor. Almost everyone Won't notice it.
Like most things in this universe, there is a law of diminishing returns in software defect repair: unless you have unlimited resources to allocate all defect repair tasks, you must focus on the defect repair with the highest ROI on. So the question is-"How to determine these defects?"
In an enterprise, there are many factors that can drive the development direction of the development team at the same time. These factors can be the sales team, QA team, financial department, end users, and online media such as blogs, Twitter, forums, and traditional media. There are too many, and all these factors are important (at least most of them are). For example, if a software installed in the broadcasting system of a TV station has a defect during prime time, I'm sure this must be the first thing the leadership wants to solve quickly. If you don’t have media factors that drive you to deal with first, then focus all your attention on the issues that are most important to you.
In this article, I will use the scope of impact and severity to measure the defect level, instead of measuring the urgency and business value because the urgency and business value do not accurately reflect the major difference between adding new features and fixing defects.
-
Scope of impact: the number of users affected or the number of systems affected
-
Severity level: the importance of the defect, that is, data loss, data damage, appearance problems, etc.
Of course, these are just two criteria for me to measure defects. You also need to analyze specific issues in detail.
Sphere of influence
Level 1: Affected users are very few/affected system functions are very small
Level 2: Affect a small group of users/a small part of system functions
Level 3: Affect a group of users/system functions
Level 4: Affect a large number of users / a wide range of system functions
Level 5: Affect most or all users/a wider range of system functions
Severity level
Level 1: Irrelevant problems or some functions are not available, but there is a simple solution
Level 2: Accessibility is not available, but there are reasonable solutions
Level 3: Important functions are not available, but there is a reasonable solution
Level 4: Important functions are unavailable and there is no solution
Level 5: Data loss, data corruption, or system unavailability
°
Scope of impact × severity level = priority
The above picture is a defect card, which determines which defect should be dealt with first by balancing the priority.
Teamwork promotes efficiency
Through the above methods, the priority of defect handling can be easily determined. Of course, the above picture is only for reference and not a guideline. How to determine it requires teamwork. Only when everyone in the team has reached a consensus can it be implemented.
Written at the end,
if you are interested in python automated testing, web automation, interface automation, mobile terminal automation, interview experience exchange, etc., you can follow the WeChat official account: [Programmer Erhei] to get an interview with a software test engineer data! My learning exchange group: 785128166 There are technical experts in the group to exchange and share~
If the article is of interest to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updates.