What is software quality
The quality of software is the life of software. In order to ensure the quality of software, people have accumulated a lot of experience and formed many effective methods in the long-term development process. But with these methods, we can only minimize the errors and deficiencies in the software, but we cannot completely avoid all errors.
If the developed software is regarded as a product produced by an enterprise, then software testing is equivalent to the quality inspection part of the enterprise. Simply put, after we write a piece of code, we check whether it runs as we expect, this activity can be regarded as a kind of software testing work. New testing theories, testing methods, and testing technical means are constantly emerging, and software testing institutions and organizations are also rapidly emerging and developing. As a result, the software testing technology profession is also simultaneously improved and perfected.
What is a software defect
Software defects (Defect), often referred to as bugs. From the inside of the product, the defect
It is a variety of problems such as errors and defects in the development or maintenance of software products;
From the outside of the product, a defect is a failure or violation of a certain function that the system needs to achieve.
Back. At the end of the software development life cycle, the cost of repairing detected software errors
The cost is higher.
For the accurate definition of software defects, there are usually the following 5 descriptions:
(1) The software does not realize the functions required by the product manual.
(2) The software has an error that the product manual indicates that it will not occur.
(3) The software exceeds the functions mentioned in the product manual.
(4) The software does not realize the goal that the product manual does not clearly indicate but should be realized
Mark.
(5) The software is difficult to understand, difficult to use, slow to run, or end users recognize
For not good
Classification of defects
1. Defect product design meets the requirement design department
2. Error Undefined or unknown error message
3. The fault (fault) caused the product to fail due to some reasons, and the user can be restored to use after restarting the adjustment
4. Failure (failure) The product fails due to some reasons and cannot be recovered by itself
The purpose of bug management
1. Ensure that every defect is modified
2. Ensure that every defect is returned
3. Completeness and consistency of defects
4. Avoid disputes and reduce communication costs
Significance of defect management
1. Improve work efficiency (BUG classification, status person in charge)
2. Record the only defect information to ensure that the BUG is complete and consistent (achieved by setting permissions)
3. Record intermediate links, BUG can be traced
4. Provide data for the test report
Roles involved in defect management
Test engineer: find and return BUG
Test Manager: Judging the effectiveness of BUG
Development Manager: Assign BUG
Development Engineer: Modify BUG
Review: resolve conflicts
Key points of the defect report
If a software defect is found, it needs to be recorded. Not only must the results be recorded, but the steps that were discovered need to be described in detail, so that the programmer can reproduce the problem and solve it.
The report is required to be clear and accurate. Sometimes using screenshot technology to save the situation at the time as a picture, you can achieve the effect that a picture is worth a thousand words.
Types of software defects
There are many manifestations of software defects, not only in the failure of functions, but also in other aspects. The main types of software defects are:
1. Functions and features are not realized or partially realized.
2. The design is unreasonable and there are defects.
3. The actual results are inconsistent with the expected results.
4. Operation error, including operation interruption, system crash, and interface confusion.
5. The data result is incorrect and the accuracy is not enough.
Other problems that users cannot accept, such as long access time and unsightly interface.
Source of defect
1.Requirement: Defects caused by problems with requirements (incomplete requirements or logical errors)
2.Architecture: Defects caused by architectural problems (login session failure)
3.Design: Defects caused by design issues (image size, page element display issues, etc.)
4.Code: Defects caused by coding problems
5.Test: Defects caused by testing problems (errors in the design and implementation of software testing. In particular, system-level functional testing requires a complex test environment and database support, as well as scripting for testing. Therefore, the software testing itself Errors may also occur. In addition, if the tester lacks understanding of the system or makes a wrong interpretation of the specifications, many errors will also occur.)
6.Integration: Defects caused by integration problems
Main parameters of defect analysis
Status: The current status of the defect (open, repaired or closed, etc.).
Priority: The relative importance of the defects that must be addressed and resolved.
Severity: The relative impact of the defect. Impact on end users, organizations or third parties, etc.
Origin: the origin of the defect and its location, or the component that needs to be repaired to exclude the defect
Defect status
1.New: Testers submit bugs
2.Open: Confirm that the "Bug submitted" is waiting to be processed
3. Assigned: Bugs assigned by related personnel
4.Fixed: The defect is fixed
5.Closed: Confirm that the defect is repaired, close the defect
6. Reopen: Reopen after the defect is repaired
7.Reject: The bug description is unclear and rejected
8.Invalid: Confirm that it is not a bug, no need to fix
9.Later: It can be modified later, but the date must be clear
10. Postpone: Delayed modification, no date is specified
11.Wontfix: The discovered bug cannot be modified
12.Duplicate: Duplicate Bug
13. Abandon: The bug after rejected, invalid, duplicate is confirmed by the tester to have no problem, and it is modified to this state
14.Renew: The bug after rejected, invalid, duplicate is confirmed by the tester to be valid, and modified to this state
15.Typical: Appears many times, is representative, and can remind others to pay attention
16.Remind: Due to the change of function, the bug cannot be verified, modify it to this state
Defect priority
Classified by priority: P1----P5 (agree that BUG may change)
Severity classification of defects
Blocker obstructed (the development test after the BUG is not modified cannot be executed)
Critical crash (available by the system department)
major (severely affect the function use process)
normal (will not affect the main functional process)
Minor minor (does not affect the business process and does not affect the use)
trvival interface
suggestion (usability, ease of use, focus on user experience)
Defect management flowchart
Test engineer (2)
New
Fixed->Reopen
Fixed->Closed
Test manager (1)
New->Open
New->Abandon
Development Engineer (2)
Open->Fixed
Reopen->Fixed
Assign->Fixed
Development Manager (1)
Open->Postpone
Postpone->Assign
Open->Assign
Defect analysis report
1. The defect count can be reported as a function of time, that is, a defect trend chart or report can be created;
2. The defect count can also be reported as a function of one or more defect parameters, such as the severity or status parameter used in the defect density report.
3. These analysis types provide judgment basis for revealing the defect trend or defect distribution of software reliability.
BUG single writing guidelines (5C)
correct (accurate) The description of each component is accurate and will not cause misunderstanding
clear (clear) The description of each component is clear and easy to understand
Concise (concise) only contains essential information and does not include any redundant content
complete (complete) contains the complete steps to reproduce the defect and other essential information
Consistent (consistent) write all defect reports in a consistent format
Notes on BUG description
1 The BUG that can be reproduced can not be written "repeated several times and appeared several times. I think, the steps cannot be written in the title, and it cannot be described in subjective words. I am in..., uncertain sentences: some seem to be , It’s forbidden to use "after", and then "and the like"
2 Errors other than the requirements specification can be reported as a suggestion, or an improper BUG report. The development can be modified or not modified
3 If it is a BUG that appears randomly, write the operation several times, and how many times it appears
4 If the software under test is cross-platform software, it must be written as correct under other platforms
5Prohibit writing redundant operation steps. Common-sense steps do not need to be written into defect operation steps
6 Specify the environmental data, how to select the data, and how the data is destroyed
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.