Process of handling bugs

Also belongs to a popular article, I hope that they are attracted by various technologies at the same time, can often come to collate and summarize the most basic software testing knowledge.

From the first defect management tool that came in contact with the new work, to Redmine, JIRA, Bugzilla, to the current QC, and of course other kinds of open source or commercial defect management tools, the essence of them is to manage the life cycle of defects.

In fact, you understand any of the tools, other tools will certainly be able to taught. This does not talk about a tool, it is the essence of some of the things out to share with you.

Properties of the Bug

Bug Reproduction Environment

This should be a precondition for us to reproduce the bug, without which we may not be able to reproduce the problem, or we can not do it with Ben.

Operating system

This is a general software operation of a major premise, basically all the software is dependent on the operating system, for a software, to run on an operating system, the operating system must be supported, which requires the design and development of true. For different operating systems, there may be differences (such as: Win XP vs Win 7) or essential differences (such as Win 7 and CentOS Linux), so the operating system environment is an important precondition for reproducing the problem.

Browser

For b/s system, or for the public Internet products (websites, mailboxes, etc.), browser compatibility is also a must test a focus, for the current browser market, all kinds of browsers have its user base, to make products popular, we must consider the compatibility of these products.

There may be compatibility issues between different browsers (IE, Firefox, Chrome, opera, etc.), or even a series of different versions (IE6/IE7/IE8/IE9, etc.), so for such applications, the browser environment reproduces one of the bug prerequisites.

Other (this "other" is very important)

For different system discovery reproduce the problem, there will be a specific premise, take my test mailbox, must describe whether it is in the test line or the current network environment, but also with a recurring problem account.

For C/S software, may also consider with other commonly used soft compatibility, for example, is installed in a software, the installation and use of the software has an impact. These are the environments that must be described to reproduce the problem.

Problem type

According to the Jira management system, the bug is just one of the problems that can be used to track many different types of problems (in fact, he just makes the bug a subclass).

The Jira system defaults to the type of problem (most systems can be custom type, which adds flexibility.) ）

• BUG: The test process, maintenance process found to affect the system operation defects. (This is the bug submitted by the general tester)

• New Feature: A feature that is presented to the system. (a single small demand can be, if large, the equivalent of a demand, put here is unreasonable.) ）

• Task: One of the tasks that needs to be done. (Development or test task assignments.) ）

• Improvement: Improvements to existing system functionality. (What the general product Manager or product Experience master does)

Of course, different companies, their personnel positioning and responsibility is not the same, according to the above classification, Jira is not a simple defect management system, it covers a project (or product) needs to deal with the tasks, requirements and defects.

Bug type :

Narrowing the scope here means that the defects found by our testers during the testing process, and that the defect is actually the main purpose of the tester's work. Of course, you need to identify the type of problem and also have a deep understanding of the project (or product). Code defects or design flaws are sometimes not easy to distinguish, of course, this division, for the development of positioning problems have little impact, but the problem of the type of statistics is more important.

Here are some common categories:

Partitioning method One:

Code Error

Design flaws

Interface optimization

Configuration related

Installation deployment

Performance issues

Standard specification

Test code

Other

Dividing mode two:

Functional Class (function)

Performance Class (performance)

Interface Class (UI)

Ease of Use class (usability)

Compatibility Class (compatibility)

Other (ELSE)

This classification of course is customizable, with my exposure to the defect management can be customized, since it is the management of the problem, then you can certainly be used in a specific environment of the system to use, or I would like to use this system to assign tasks, then my custom type is front-end tasks, back-end tasks, test tasks, configuration deployment ...

Defect level

Defect level, this division is also more flexible, there are three or four levels, there are five levels.

Fatal

A trick to kill the defect, so that your system can not run, there is a security problem caused by data leakage.

Serious

can cause abnormal conditions that are easy to correct, faults that can cause easy repair, or defects that are unacceptable to the appearance of the product.

So so

Refers to defects that do not affect the operation and operation of the product, do not become a cause of failure, but have a greater impact on the appearance of the product and the next process

Slight

Minor defects are defects that may have a slight effect on the appearance of the product and the next process.

Suggestions

Suggested issues that increase the user experience. (in general, recommendations are also made as a defect.) This is related to the type and requirements of the system)

Defect priorities (priority)

When problem handlers are confronted with many issues that need to be addressed, they need to prioritize issues. We do things, the operating system has processing processes, etc. are in use priority.

Priority partitioning:

--------emergency

Deferred processing---normal queueing----Priority handling

The severity and priority of bugs are two concepts that have different meanings but are closely interrelated, and they describe the process and processing of software defects ' impact on software quality and end-users from different sides.

In general, software defects with high severity programs have a higher priority. A high degree of severity indicates that the defect is harmful to the software, it needs to be prioritized, and the defect of serious program is that the software is not perfect and can be processed later.

High severity priority is not necessarily high:

If a serious software defect is generated only under very extreme conditions, there is no need to deal with it immediately.

If a software defect, the need to re-modify the overall architecture of the software, may lead to more potential defects, and the software due to market pressure must be released as soon as possible, even if the severity of the defect is very high, need to be corrected, need to consider overall.

Severity priority is not necessarily low

If the software name or company name is misspelled, although it is an interface error, the severity is not high, but it is related to the software and the company's market Kaixie, must be amended as soon as possible.

Defect status

For a problem, its process is a cycle, the different stages of the cycle, and its state is not the same. Different states of the corresponding handlers are not the same.

Open : Indicates that the problem is being committed and waiting for someone to process.

Reassign: The problem is reassigned to someone to handle.

processing : The problem is in process, not yet completed.

fixed : Verify that the problem exists but is not processed for the time being.

regression : A regression confirmation of an issue that has been fixed. Reopened:

Close : The last state of the issue.

Bug Handling Process

The following is a more complete bug of the processing flowchart, a deeper understanding of the state of the bug as a bug in the life cycle.

Submit (Open) defect

In submitting a defect defect, first try to describe the attribute of this flaw. Bug reproduction environment, bug type, bug level, bug priority and detailed repro steps, results and expectations, etc.

Of course, before submitting a question, we should first ensure that this defect is not mentioned, so as not to cause duplicate defect orders.

If it is a defect that is not passed by the regression, its state becomes open again.

Distribution (transfer) of defects

This step is not necessary, in relation to the project model, some company testing department and Development Department independent, then the tester is not sure which developer is responsible for the module that they test, in this case, the tester unifies the question to the project leader or manager, The project leader (or manager) is assigned to the appropriate developer after confirming the issue.

Some testers are interspersed with different research and development teams, so it is very clear that the development module is responsible for different developers, and this time it is possible to assign the problem directly to the appropriate developer.

There is also the case that this problem should be the responsibility of a developer, but due to the removal or resignation of a developer, some issues are referred to other personnel. "Distribution" emphasizes the superior to the subordinate; "turnover" emphasizes the level of the peer.

Identify defects

When a developer receives a flaw, it is first analyzed and reproduced, and if it is analyzed and found not to be a defect (perhaps because the tester is not aware of the requirements) or if the problem cannot be reproduced, then the problem needs to be reversed back to the tester and noted for the reason. If it is identified as a defect, it needs to be processed.

Deferred processing

After dealing with the problem, there is a need to make a judgment, whether it needs to be deferred, some of the requirements have been identified as a problem, because it may be in extreme circumstances, or need to change the system architecture, or its priority is very low, so temporarily do not need to deal with this problem (or to the next version of the fix).

Fixed

The problem of deferred processing can be fixed temporarily ("fixed" as the term in QC.) General fixed issues need to be fixed after the project manager negotiates with the Test manager.

Handling defects

When a developer confirms that a problem needs to be addressed, it is processed. (for example, Redmine is to support handlers to update the progress of the problem at all times, such as 30% has been processed, 80% has been processed, of course, for a short period of time can fix the problem there is no need to constantly update processing progress. ）

Regression defects

Regression defects are a very important task for testers, with three entrances and two exits.

Identify non-defect issues: for a defect submitted, the person handling is non-problematic or cannot be reproduced, and then forwarded directly to the tester to return. The tester confirms again that if the developer says so, the problem is closed. If the non-developer says that the problem is due to a fuzzy or other reason for the issue, repeat the reason to the developer.

Confirm fix problem: Once again confirm the problem that the developer fixes, confirm can be over, close the problem. Confirm that the problem is not passed, open the issue again and transfer it to the developer.

Confirm fixed issues: Fixed issues are scheduled to confirm, some fixed problems over time, the version of the update or no longer exist, for such issues should be closed in a timely manner. Some fixed problems persist and become urgent, and should be opened to developers in time for such problems.

Closing defects

It is also the last state of a flaw to close a bug that has been repaired.

Note 1: The article mentions the product and the project, many people cannot separate the project and the product, each has respective understanding. I personally divide it from the user base. If you are targeting a specific customer's needs, then call it a project, such as a hospital's medical system, a company's management system. For the mass users and long-term operation of the demand, called the product, such as, a website, a network game.

What if little a asked me to make a website for him? For me, small A is my client, this site for me is a project, for small A, his website is for the public users, then for small A, the site is its own products.

Foxconn with the Apple phone is the same reason, Foxconn received Apple orders, then for Foxconn is a project to complete the project, get the money even if the project is over. The iphone is a product for Apple, which has long held ownership of the product and has not updated its products.

Note 2: This article uses the bug, the flaw, the question and so on three words, the word is more vague, this article is expressed as a thing.

Please pay attention to what you like! Share and grow together!

Process of handling bugs