Defect Management

Defect Management

Defect Management Process

Because one of the main goals of testing is to find defects, an established defect management process is essential. Although we refer to "defects" here, the reported anomalies might actually be defects or something else (e.g., false positives, change requests)—this is resolved during the process of handling defect reports. Anomalies may be reported during any phase of the software development lifecycle (SDLC) and their form depends on the SDLC. At a minimum, the defect management process includes a workflow for handling anomalies from their discovery to their closure and rules for classifying them. This workflow typically includes activities to log the reported anomalies, analyze and classify them, decide on a suitable response (such as fixing or keeping them as they are), and finally closing the defect report. This process must be followed by all involved stakeholders. It is advisable to handle defects from static testing (especially static analysis) similarly.

Objectives of Defect Reports

Typical defect reports have the following objectives:

  • Provide those responsible for handling and resolving reported defects with sufficient information to resolve the issue.
  • Provide a means of tracking the quality of the work product.
  • Provide ideas for improving the development and test process.

Contents of a Defect Report

A defect report logged during dynamic testing typically includes:

  • Unique identifier.
  • Title with a short summary of the reported anomaly.
  • Date when the anomaly was observed, issuing organization, and author, including their role.
  • Identification of the test object and test environment.
  • Context of the defect (e.g., test case being run, test activity being performed, SDLC phase, and other relevant information such as the test technique, checklist, or test data being used).
  • Description of the failure to enable reproduction and resolution, including the steps that detected the anomaly, and any relevant test logs, database dumps, screenshots, or recordings.
  • Expected results and actual results.
  • Severity of the defect (degree of impact) on the interests of stakeholders or requirements.
  • Priority to fix.
  • Status of the defect (e.g., open, deferred, duplicate, waiting to be fixed, awaiting confirmation testing, re-opened, closed, rejected).
  • References (e.g., to the test case).


Hau.vo
................................
Source: itsqb.org

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

Software testing level

Hình ảnh
 Software testing level There are 4 basic levels of testing, including: 1. Unit Test Concept: Unit testing is a type of software testing in which individual units/components of the software, such as functions, classes, and methods, are tested. Unit testing is conducted during the application development process. Errors at this level are usually fixed immediately after they are found, without being logged and managed like other test levels. Typically, programmers are the ones who perform testing at this level. Purpose: Isolate Components : Separate each component to verify and demonstrate that they accurately fulfill the functional requirements specified.  Early Bug Fixing : Errors are rectified early in the software development cycle, thereby saving time and cost in error correction.  Increased Code Reusability : The source code can be reused more frequently.  Enhanced Confidence in Modifications or Maintenance : Increases confidence in making changes or maintaining ...
Đọc thêm

The Seven Principles of Testing

Hình ảnh
The 7 principles of testing Software testing is an essential part of the software development process, ensuring that the final product functions correctly and efficiently, meeting all requirements and customer expectations. To conduct software testing effectively and save time and effort in identifying and addressing errors, you can adhere to the following seven fundamental principles of testing. 1. Testing shows the presence of defects Testing proves that the product has defects but cannot prove that the product is defect-free. This means that there will always be defects undetected in the software, even if no defects are found, it does not mean that the software is defect-free. 2. Exhaustive testing is impossible  It is very difficult to test all modules as well as features, combined with all inputs and outputs of the entire system throughout the testing process. Instead of attempting to test everything, identify the importance and priority to test the necessary cases or those wi...
Đọc thêm

Testing methods - Overview of black-box & gray-box testing

Hình ảnh
  Testing Methods   Software testing methods are conducted by testers with the aim of ensuring that all features of the system operate correctly according to the requirements of the customer or end users. There are three basic software testing methods: white-box testing, black-box testing, and gray-box testing. In the previous session, we learned about the white-box testing method. Now it's time to move on to the other two testing methods. 1. Black-box testing What is the black-box testing? Black-box testing is a software testing method that focuses on testing the functionality of an application without needing to know its internal structure or source code. In this approach, testers are only concerned with the inputs and outputs of the system to determine whether the functionality operates correctly, without considering how it works internally. Black-box testing is similar to inspecting a black box, where you only observe the input and output transformations without knowi...
Đọc thêm