The life cycle of a BUG is the process from when a BUG is discovered to when the BUG is closed. The specific process is: 1. Discover the BUG, that is, discover the loopholes or defects in the software program; 2. Submit the bug and try to describe it as much as possible. Defect attributes, reproduction environment, type, level, priority, detailed reproduction steps, results and expectations, etc.; 3. Assign the bug, that is, assign the problem directly to the corresponding developer; 4. Analyze and confirm it as a defect; 5. , handle and fix BUG; 6. Regression verification BUG; 7. Close BUG.
The operating environment of this tutorial: Windows 7 system, Dell G3 computer.
Software BUG, in the narrow sense, can be understood as referring to the loopholes or defects of the software program. In the broad sense, in addition to finding the program, it also includes test engineers or users The details of the discovered and proposed software that can be improved, or the functional implementation that is different from the requirements document, etc. That is, the intervention of testing can start from demand analysis and track the development process.
The life cycle of a BUG is the process from when a BUG is discovered to when the BUG is closed.
Defect status in the life cycle: New-->Assigned-->Resolved-->Pending-->Close
BUG found-->Submit BUG–>Assign BUG–>R&D to confirm BUG–>R&D to fix BUG–>Regression verification BUG–>Whether it passes verification–>Close BUG
If the BUG to be checked is not resolved during verification, we need to re-open--Assignment--Resolved--To be checked, and cycle this process.
Other states in the middle: rejection, postponement, etc.
BUG processing flow chart (life cycle diagram)
a. Follow the test case and find anything inconsistent with the expected results of the test case, which can be called a bug.
b. Test cases cannot be exhausted, there are always factors beyond your expectation, or bugs caused by divine operations.
c. Cost issues, insufficient time to write test cases, discovered bugs
Before submitting a defect, try your best first Describe the attributes of this defect, bug reproduction environment, bug type, bug level, bug priority and detailed reproduction steps, results and expectations , etc.
Of course, before submitting a question, we should first ensure that this defect has not been mentioned before, so as to avoid duplicate defect tickets.
This step is not necessary. It is related to the project model. In some companies, the testing department is independent of the development department, so the testers are not sure about their own testing. Which developer is responsible for the module. In this case, the tester assigns the problem to the project team leader or manager. The project team leader (or manager) confirms the problem and then assigns it to the corresponding developer again. .
Some testers are interspersed in different R&D teams, so the development modules responsible for different developers are very clear. At this time, problems can be assigned directly to the corresponding developers.
There is also a situation where this issue should have been the responsibility of developer A, but due to the transfer or resignation of developer A, these issues were transferred to other personnel to handle. "Distribution" emphasizes the relationship between superiors and subordinates; "transfer" emphasizes the relationship between equals.
When a developer receives a defect, they first analyze and reproduce it. If the analysis finds that it is not a defect ( It may be because the tester does not understand the requirements) or is unable to reproduce the problem, then the problem needs to be reported back to the tester and the reason stated. If it is confirmed as a defect it needs to be dealt with.
Postponing processing
After dealing with the problem, you still need to make a judgment whether it needs to be postponed. Some requirements have been confirmed to be problems. , because it may only appear in extreme circumstances, or require changes to the system architecture, or its priority is very low, so there is no need to deal with this problem for the time being (or it will be fixed in the next version).
Fixing:
Problems that have been postponed can be temporarily fixed ("fixed" is the name in QC.) Generally, fixed problems can only be fixed after consultation between the project manager and the test manager.
Defect processing:
When developers confirm that a problem needs to be solved, they will handle it. (For example, redmine supports the processor to update the problem processing progress from time to time, such as 30% has been processed, 80% has been processed, etc. Of course, for problems that can be repaired in a short time, there is no need to update the processing progress all the time.)
Regression defects are a very important task for testers, and they have three entrances and two exits.
Confirm non-defect problem: For a submitted defect, the developer handles it as non-problem or cannot be reproduced, and then directly transfers it to the tester for regression. The tester confirms again and if it's true as the developer says, the issue is closed. If a non-developer says that the problem is reproduced due to vague problem description or other reasons, the reason will be noted again and forwarded to the developer.
Confirm the problem to be fixed: Confirm the problem fixed by the developer again. If it is confirmed that it can be passed, the problem will be closed. If the confirmation fails, open the issue again and forward it to the developer.
Confirm fixed issues: Confirm fixed issues in a planned manner. Some fixed issues may no longer exist due to version updates over time. Such issues should be closed in a timely manner. Some fixed issues still exist and have become urgent. Such issues should be opened and handed over to developers for processing in a timely manner.
Close the defect that has been repaired. This is also the last status of a defect.
When doing interface testing, you can use the domestic interface testing and interface document generation tool apipost
Bugs will cause the software to fail when running Unexpected failures will cause losses to the enterprise, and the process of software testing is simply the quality assurance work around bugs. In order to improve the efficiency of testing work and manage bugs, submit bugs, and solve bugs more efficiently, it is very necessary to use some bug management software reasonably.
Zen Tao
Zen Dao is the first domestic open source project management software. Its core management idea is based on the agile method scrum, with built-in product management and project management. At the same time, it also supplements test management, plan management, release management, document management, transaction management and other functions based on the current domestic research and development status. In one piece of software, requirements, tasks, bugs, use cases, plans, releases and other elements in software development can be tracked and managed in an orderly manner, completely covering the core process of project management.
ZenTao is developed using the self-developed zentaophp framework and has a complete built-in extension mechanism. Users can carry out thorough secondary development of ZenTao very conveniently. ZenTao also provides a json interface API for each page, making it convenient for other languages to call and interact. Built-in multi-language support, multi-style support, search function, statistical function and other practical functions.
Tracup
Tracup is a lightweight team collaboration platform that provides simple and efficient bug tracking. , convenient project management, safe and stable data protection, perfectly combining bug management and team collaboration.
Whether it is to modify a bug or add a new feature, Tracup can provide an ideal working cloud platform. Convenient team collaboration, lightweight project management, complete problem system, and large-capacity file storage make users' work more convenient.
Bugtags
Bugtags is a new generation of defect discovery and management tools specifically designed for mobile testing. Committed to improving the testing process of mobile apps, connecting the user experience between defect discovery and defect submission, and improving the efficiency of testing and resolving defects. Help testers efficiently conduct app testing and bug tracking and management.
After the mobile app integrates the bugtags SDK, test users can submit bugs directly in the app using WYSIWYG. The SDK will automatically take screenshots and collect app runtime data, such as: device information, console data, user Operation steps, etc., developers can efficiently track and manage bugs in the bugtags cloud.
The biggest difference between Bugtags and other bug management systems is that:
Bugtags is specially designed for mobile development. It is not a simple modification of previous bug management systems for Web and desktop applications. It is a completely redesigned bug management system from the perspective of mobile app development and testing.
Bugtags does not require deployment, it can be used after registration in the cloud, which is simple and convenient.
Bugzilla
JIRA
JIRA is a defect tracking management system developed by Atlassian. The name JIRA is not an abbreviation, but is taken from "Gojira". JIRA is widely used in defect tracking, customer service, requirements collection, process approval, task tracking, project tracking and agile management. JIRA has flexible configuration, comprehensive functions, simple deployment, and rich expansion. Its more than 150 features have been recognized by more than 19,000 customers in 115 countries around the world.
WebIssues
WebIssues is a client/server model team collaboration tool and issue tracking system that can Support small development teams. It can be used to store, share and track various properties of issues, comments and file attachments. It's easy to install and use, and highly customizable. The server can be installed on any host that supports PHP and MySQL or PostgreSQL, and the client can be a Windows or Linux desktop.
Bugify
Programming Teaching! !
The above is the detailed content of What is the life cycle of a bug?. For more information, please follow other related articles on the PHP Chinese website!
What are the reasons why a mobile phone has an empty number?
Reasons for session failure
Introduction to welding method types
How to install wordpress after downloading it
nvidia geforce 940mx
The difference between distributed and microservices
How to unlock the password lock on your Apple phone if you forget it
How to use sort function
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
