A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
I am also a popular article, hoping that I can sort out and summarize the most basic knowledge of software testing while being attracted by various technologies.
From the first defect management tool that I first came into contact with at work,Redmine,JIRA,Bugzilla, And nowQCOf course, there are other open-source or commercial defect management tools. They are essentially the same, that is, to manage the lifecycle of defects.
In fact, if you understand any tool, other tools will certainly be self-taught. We will not talk about a tool, but share some of its essential things with you.
BugREPRODUCE THE ENVIRONMENT
This should be our reproduction.BugIf we do not have this premise, we may not be able to reproduce the problem, or we can't start with it.
This is a prerequisite for general software operation. Basically, all software depends on the operating system. For a software, to run on an operating system, support for this operating system is required, which requires a true design and development. For different operating systems, there may be differences (for example:Win XPAndWin 7) Or essential differences (suchWin 7AndCentos Linux). Therefore, the operating system environment is an important prerequisite to reproduce the problem.
ForB/SSystem, or public-oriented Internet products (websites, mailboxes, etc.), browser compatibility must also be tested. For the current browser market, all types of browsers have their own user base, to make products popular, you must consider the compatibility of these products.
Between Different browsers (IE,Firefox,Chrome,Opera), Or even different versions of the same series (IE6/IE7/IE8/ie9And so on.BugOne of the prerequisites.
Others(This "other" is very important)
Different systems have specific preconditions for discovering and recreating the problem. In my test mailbox, We must describe whether the problem is in the test line or in the current network environment, it also includes an account with an existing problem.
ForC/SSoftware may also be compatible with other commonly used software. For example, it may affect the installation and use of the software after a software is installed. These are the environments that must be described to reproduce the problem.
AccordingJIRAManagement System Division,BugIt is only one of the problems. It can be used to track a variety of different types of problems (in fact, he justBugAs a subclass ).
JIRADefault problem type provided by the system (most systems can customize the type, which increases flexibility .)
Of course, the positions and responsibilities of different companies are different. According to the above classification,JIRAIt is not a simple defect management system. It covers the tasks, requirements, and defects that a project (or product) needs to handle.
Narrow down the scope here. It refers to the defects found by our testers during the testing process. Discovering product defects is actually the main purpose of the testers. Of course, to determine the type of a problem, you also need to have a deep understanding of the project (or product. YesCodeDefects or design defects are sometimes not easy to differentiate. Of course, this division has little impact on the Development Positioning problem, but it is important to collect statistics on the problem type.
The following describes some common categories:
Installation and deployment
Function class (Function)
Performance class (Performance)
Interface Class (UI)
Ease of use (Usability)
Of course, this category can be customized, and defect management in my contact can be customized. Since problems are managed, of course you can use it as a system in a specific environment, or I want to use this system to assign tasks, then, my custom types are frontend tasks, backend tasks, test tasks, and configuration and deployment....
Defect level, which can be divided into three or four levels and five levels.
Your system may fail to run due to a fatal defect, which may cause data leakage and security issues.
Vulnerabilities that can easily be corrected, faults that may easily be repaired, or unacceptable to the product appearance.
It refers to a defect that does not affect the operation and operation of the product and does not become the cause of the fault, but has a great impact on the product appearance and next process.
A minor defect is a defect that may have a slight impact on the appearance of the product and the next process.
Increase the user experience. (In general, it is recommended to be a defect. This is related to the system type and requirements)
When the problem handler needs to handle many problems, it needs to sort the priority of the problem. We make the arrangement of things, and the operating system processes all use the priority.
Low -->Medium -->High -->Urgent
Delay processing -->Normal queue -->Priority -->Emergency Handling
BugThe severity and priority of Software defects are two concepts that have different meanings but are closely related. They describe the impact of Software defects on software quality and end users from different aspects.ProgramAnd processing method.
Generally, Software defects with High severity procedures have a high priority. High severity indicates that the defects are harmful to the software and must be prioritized. The low severity of the defects may be that the software is not perfect and can be processed later.
High severity is not necessarily high priority:
If a serious software defect is generated only under extremely extreme conditions, it is not necessary to deal with it immediately.
If a software defect needs to be modified, the overall architecture of the software may lead to more potential defects, and the software must be released as soon as possible due to market pressure, even if the defect is serious, whether the modification is required requires full consideration.
The severity priority is not necessarily low.
If a software name or company name is misspelled, although it is an interface error and the severity is not high, it is related to the software and the company's market release and must be corrected as soon as possible.
For a problem, the processing process is a cycle, and the status of the problem varies with different stages of the cycle. Different States correspond to different handlers.
Open: The problem is submitted for processing.
Re-assign: The problem was re-assigned to someone for handling.
Processing: The problem is being processed.
Fixed: Confirm that the problem exists, but will not be handled for the time being.
Regression: Perform regression confirmation for fixed problems.Reopened:
Close: The last status of the problem.
The following uses a relatively completeBugProcessing flowchart for a deeper understandingBugToBug.
Submit (open) Defects
When submitting a defect, first try to describe the property of the defect.BugReproduce the environment,BugType,BugLevel,BugAnd detailed reproduction steps, results and expectations.
Of course, we should ensure that this defect has not been raised before submitting a problem, so as to avoid repeated defect tickets.
If the regression fails, the status changes to open.
Allocation (transfer) Defects
This step is not necessary. It is related to the project model. Some companies have independent test departments and Development Departments, so testers are not sure which developer is responsible for the module they are testing, in this case, the tester assigns the problem to the project leader or manager, and the project leader (or manager) confirms the problem and re-assigns it to the corresponding developer.
Some testers are interspersed with different R & D teams, so they are very clear about the development modules that different developers are responsible for. In this case, they can directly assign problems to corresponding developers.
There is also a situation where the problem should have been causedADevelopers are responsibleATransfer or resign a developer. "Distribution" emphasizes the superior to the lower level; "transfer" emphasizes the inter-level.
When a developer receives a defect, the first step is to analyze it and reproduce it. If it is found that it is not a defect (probably because the tester does not understand the requirement) or the problem cannot be reproduced, you need to back the problem to the tester and indicate the cause. If it is identified as a defect, it must be addressed.
After the problem is solved, you need to make a judgment to determine whether to postpone the handling. Some requirements have been confirmed as problems, because they may occur in extreme situations, you may need to modify the system architecture or have a low priority. Therefore, you do not need to deal with the problem temporarily (or upgrade it to the next version for repair ).
The problem of deferred handling can be temporarily fixed ("fixed" isQC.) Generally, fixed problems can be fixed only after negotiation between the project manager and the test Manager.
When the developer confirms that a problem needs to be handled, the developer will handle it. (For example, redmineThe handling personnel can update the problem handling progress from time to time, for example, handled30%, Processed80%Of course, there is no need to update the handling progress from time to time for issues that can be fixed within a short period of time .)
Regression defects are very important for testers. They have three entrances and two exits.
Confirm non-defect issue: For a submitted defect, the opening staff handles the non-problem or cannot reproduce it, And then directly transfers it to the testing staff for regression. The tester confirmed again that the problem would be closed if it was said by the developer. If the problem is reported by a non-developer due to fuzzy problem description or other reasons, the cause is again indicated to the developer.
Confirm to fix the problem: re-confirm the problem fixed by the developer. If the problem is confirmed to be successful, the problem will be closed. If the problem persists, open the problem again and forward it to the developer.
Fixed issue confirmation: there are plans to confirm fixed issues. Some fixed issues may have been updated or no longer available over time, and such problems should be closed in time. Some fixed problems still exist and become urgent. Such problems should be promptly opened and handed over to developers for handling.
Disabling a repaired defect is also the final state of a defect.
Note1: Products and projects are mentioned in this Article. Many people have different understandings about projects and products. I personally divide it from the user group. If it is oriented to specific customer needs, it is called a project, such as a hospital's medical system and a company's management system. A product, such as a website or online game, is a long-term operation requirement for mass users.
If smallALet me create a website for him? For me, smallAIt's my customer. This website is a project for meAFor example, his website is intended for mass users, so smallAFor example, a website is a product of its own.
Foxconn works with Apple's mobile phone. Foxconn receives an order from Apple, which is a project for Foxconn. after the project is completed, the project is complete even if the project is complete. Apple mobile phone is a product for Apple. It has long-term ownership of the product and updates its own product without delay.
Note2: Used in this articleBugDefects, problems, and other three words, the word is vague, this article represents a thing.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service