In this blog we are discussed Defect Management and Reporting
What is Software Quality?
• Quality means consistently meeting with user requirements in terms of cost, delivery schedule & service.
• According to IEEE Software Quality means “the degree to which a system, component, or process meets specified requirements.”
• Software Quality is the degree of conformance to explicit or implicit requirements and expectations.
What is Software Defect or Software Bug?
• When a tester executes the test cases, he/she might come across the test result which is
contradictory to expected result. This variation in the test result is referred as a defect.
• These defects or variation are referred by different names in a different organization like issues, problem, bug or incidents.
Categories of Defects
1) Major – defects that affect main system functions but do not cause crash-down of the whole system.
2) Minor – bugs that do not have much impact on system functionality and do not affect workflow but that can have a negative impact on user experience.
3) Critical – defects are the most serious of the three defect types. Critical defects render an item completely unusable and/or could cause harm to the user or someone in the area of the system.
Origin of Defects
• A system defect (informally known as a bug)
• Defects have negative effects on software users.
• Software engineers work very hard to produce highquality software with a low number of defects.
1. Education: The software engineer did not have the proper educational background to prepare the software artifact.
2. Communication: The software engineer was not informed about something by a colleague.
3. Oversight: The software engineer omitted to do something.
4. Transcription: The software engineer knows what to do, but makes a mistake in doing it.
5. Immature Process: The process used by the software engineer misdirected his/her actions.
Origin of Defects
• Errors Human mistakes that cause the defect (for example, making a programming mistake or inputting incorrect data)
• Faults Incorrect conditions that are system-internal and not directly visible from outside the system’s boundary (for example, the system stores incorrect data or is in an incorrect mode or state)
• Failures Events or conditions in which the system visibly behaves incorrectly or has incorrect properties (that is, one or more of its behaviors or properties are different from what its stakeholders can reasonably expect)
Taxonomy of Defects
• Defect means the deviation in the accepted output and actual output. (e.g. requirements description, test plan, source code, configuration file etc.).
Software defects can be classified as following:-
• Errors of commission mean something wrong has done.
• Errors of omission refer to the thing left out after an accident.
• Errors of clarity and ambiguity refer to different interpretations about work done.
--------------------------------------------------------------------------------------------------------------
Defect Life Cycle
• From the discovery to resolution a defect moves through a definite life cycle called the defect life cycle. Below find the various states that a defects goes through in its life cycle.
• The number of states that a defect goes through varies from project to project.
Below life cycle, covers all possible states.
There are different state as below
New: When a new defect is logged and posted for the first time. It is assigned a status NEW.
Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to developer team.
Open: The developer starts analyzing and works on the defect fix
Fixed: When developer makes necessary code change and verifies the change, he or she can make bug status as "Fixed."
Pending retest: Once the defect is fixed the developer gives particular code for retesting the code to the tester. Since the testing remains pending from the testers end, the status assigned is "pending request.“
Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and change the status to "Re-test.“
Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected then it assign status “verified”.
Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to "reopened". Once again the bug goes through the life cycle.
Closed: If the bug is no longer exits then tester assign the status "Closed."
Duplicate: If the defect is repeated twice or the defect corresponds the same concept of the bug, the status is changed to "duplicate."
Rejected: If the developer feels the defect is not a genuine defect than it changes the defect to "rejected.“
Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs.
Not a bug: If it does not affect the functionality of the application then the status assigned to a bug is "Not a bug".
---------------------------------------------------------------------------------------------------------------
Defect Management Process
While reporting the bug to developer, your Bug Report should contain the following information.
Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.
Date Raised - Date when the defect is raised
Reference - Provide reference to the documents like requirements, design, architecture or may be even screenshots of the error to help understand the defect.
Detected By - Name/ID of the tester who raised the defect
Status - Status of the defect like new, duplicate etc…
Fixed by - Name/ID of the developer who fixed it
Date Closed - Date when the defect is closed
Severity - which describes the impact of the defect on the application
Priority - which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.
--------------------------------------------------------------------------------------------------------------
Defect Report Template
• After covering a defect (bug), testers generate a formal defect report.
• The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.
• In most companies, a defect reporting tool is used and the elements of a report can vary. However, in general, a defect report can consist of the following elements.
Below format of Defect Report
Advantages of good defect report
• Defect reports are among the most important deliverables to come out of test.
• They are as important as the test plan and will have more impact on the quality of the product than most other deliverables from test.
• It is worth the effort to learn how to write effective defect reports.
Effective defect reports will:
. Reduce the number of defects returned from development
. Improve the speed of getting defect fixes
. Improve the credibility of test
. Enhance teamwork between test and development
---------------------------------------------------------------------------------------------------------------
Defect Prevention
• Defect Prevention is a crucial step or activity in any software development process.
• Defect Prevention involves - analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of those types of defects in the future.
• The defects may have been identified on other projects as well as in earlier stages or tasks of the current project.
• The first stage of the defect management process is defect prevention.
• In this stage, the execution of procedures, methodology, and standard approaches decreases the risk of defects.
• Defect removal at the initial phase is the best approach in order to reduction its impact.
• Examples of defect prevention activities include: task kick-off meetings, causal analysis meetings, reviewing and planning proposed actions etc.
• Defect Prevention reduces the amount of rework and ensures low production cost and faster delivery.
• Defect Prevention activities such as 'Design Reviews' leads to a better design by identifying bottlenecks, roadblocks, and possible performance and security failures early in the development process.
The following are the defect prevention responsibilities for testers:
1) Requirement Specification Review
2) Design Review
3) Code Review
Defect Prevention Methods and Techniques:
1) Review and Inspection:
2) Walkthrough:
3) Defect Logging and Documentation:
4) Root Cause Analysis:
Download link for more detail: Defect Management & Reporting
Or follow my blog from the below link
Also, Join my Telegram channel with the below link
Also, join my Whatsapp group with the below link
0 Comments