1. What is a defect
Problems that do not meet the needs of users, affect the realization of software functions, and faults
are what people usually call bugs.
ex. Which option is not a software defect___.
A. The software does not implement the functions required by the product specifications
B. The software contains functions that should not appear in the product specifications
C. The software implements the functions that are not mentioned in the product specifications
D. The software implements the requirements required by the product specifications Functional but not considered portability due to performance limitations
Answer: D
2. Defect identification
The cause of the defect
- Insufficient communication between personnel (users, design, development, testing, technical support, etc.), misunderstandings, or no communication at all
- Incomplete or even no documentation (especially for domestic small and medium-sized software companies)
- Demand constantly changes
- The limitations of the technical capabilities of the participants
- The programming itself is wrong
- The software is complex and defects are hard to avoid (such as Windows, Word)
- Short deadlines, heavy tasks, and high time pressure
- Software development tools and system hardware and software support are limited
Basis for Judging Defects
- Identify bugs by referring to documentation
- Requirements Specification
- Outline design, detailed design
- user manual
- ...
- Find defects by understanding software industry standards, industry background (or referring to similar typical software)
- Confirm and identify defects through communication (ask developers, ask requirements people, ask users...)
3. Reproduce and optimize defects
The necessity of reproduction (also called reproduction) and optimization defects
Optimization defects do not refer to the optimization defects themselves, but the reproduction steps of the optimization defects
Why reproduce and optimize defects?
How to deal with "random" defects in software?
Methods for Reproducing and Optimizing Defects
- In-depth familiarity with requirements, starting from the requirements themselves
- Familiar with program design, start from design and development
- Familiar with commonly used test methods, means, and typical routines
- The same defect is verified multiple times with different test processes (including steps and data), analyze the phenomenon and cause of the defect, find out the law and the simplest implementation process
- Find dependencies and race conditions
- Continuously accumulate experience in dealing with defects
4. How to effectively record defects
Guaranteed to reproduce defects
A simple way to judge whether a defect report is good or bad: Let non-defect report writers (technicians) reproduce the defect based on the defect report. If the defect can be reproduced simply and quickly, it indicates that the defect report is better
Analyze Failures - Reproduce the defect using the fewest number of steps
Reduce the time for developers to repeat defects
and enable developers to locate defects more accurately
Contains all necessary steps to reproduce the bug
Testers assume that developers are not necessarily familiar with commonly used operating steps, omitting necessary steps makes developers unable to reproduce defects.
other considerations
easy to read
Example:
Overview: Use "Notepad" to save only the word "China Unicom" and then open the file, garbled characters appear.
Description steps:
1. Click "Start" → "Programs" → "Accessories" → "Notepad" to open the Notepad software;
2. Only enter the word "China Unicom" and click "File" → Save;
3. In the opened " Save the file in the "Save As" dialog box and exit (the file name and save location are arbitrary);
4. Open the saved file, and there are garbled characters, not the word "Unicom".
pay attention to your tone
Example:
Overview: The default file suffix in the "Save As" dialog box in "Notepad" is written as ".txk".
Description steps:
1. Click "Start" → "Programs" → "Accessories" → "Notepad" to open the Notepad software;
2. Only enter the word "China Unicom" and click "File" → Save;
3. In the opened " In the "Save As" dialog box, the default file suffix should be ".txt". Did you developers think about the problem with your heels, and actually wrote ".txt";
6. Defect report
A defect report is a collection describing software defect symptoms and reproduction steps.
Software defect report Sottware Bug Report (SBR) or software problem report Software Problem Report (SPR)
The role of bug reports
1. Defect report is one of the work results of software testers, which reflects the value of software testing
2. Defect report can accurately describe the defects existing in the software, which is convenient for developers to correct
3. Defect report can reflect the current quality status of the project/product , to facilitate the overall progress and quality control of the project
4. Software testing defect report is one of the output results of software testing, which can measure the working ability of testers
The "5Cs" of defect reporting
- The content is accurate (Correct)
The description of each component is correct and will not cause misunderstanding - The steps are concise (Concise)
only include essential information, do not include any superfluous content - Clear content (Clear)
The description of each component is clear and easy to understand - Structurally complete (Complete)
contains complete steps to reproduce the bug and other essential information - Consistent style (Consistent)
Write all defect reports in a consistent format
Contents of bug reports
The title of the defect
The basic information of the defect:
1. The tested software and hardware environment
2. The tested software version
3. The type of defect
4. The severity of the defect
5. The processing priority of the defect
Operation steps to reproduce the
defect The actual defect Result description
Expected correct result description
Annotation text and captured defect image
The 28 theorem of flaws
The review and testing work in the analysis, design, and implementation phases can find and avoid 80% of the defects, and the system test can find out 80% of the remaining defects. It will only be revealed after use.
7. Record defects and defect reports
- Ensure that defects are reproducible with fewer, necessary steps
- Use professional terminology and pay attention to writing format when recording defects
- Defects should be concise and concise, try to report one defect at a time
- Defects that are really not reproducible also need to be reported, and reported as soon as possible
- The number of defects and the level of defects cannot be exaggerated
- Record defects in time
Eight, the classification of defects
Classify according to severity classification, defect priority, defect type and function module, etc.
by severity
Fatal errors: such as data loss, crash, system crash
Serious errors: such as incomplete functions, incorrect function completion
General errors: such as incomplete functions, interface problems, etc.
Suggestions (minor): How to deal with better problems that testers think
According to the modification priority
Modify immediately
Modify in this version
Modify before the product is released
Problems that may exist in the released version
by defect type
Function, Pressure/Load, Interface, Compatibility, Ease of Use, Install/Uninstall, Safety
According to the function module
Function module 1
Function module 2
Function module 3
Function module 4
…
Process flow for bug reports
