3.4. Example Defect

🐞 What is a Defect? A defect (or bug) is a deviation from the expected behavior of the system, as defined by the requirements or acceptance criteria.

A defect, commonly referred to as a bug, occurs when the software does not operate as intended. This means that it doesn't align with the requirements or the acceptance criteria set before the software was developed. Accepting these definitions is crucial for quality assurance in software testing, as it guides testers in identifying deviations from the standard operational behavior expected of the application.

Think of a smartphone app designed to track fitness activities. If the app states that it will log the number of calories burned during a workout, but it fails to do so, then this is a defect. Users expect the calories burned to be recorded correctly as per the app's description, and any failure to do so is a bug that needs fixing.

📌 When to Report a Defect? ● A feature doesn't work as intended ● A requirement is incorrectly implemented ● There’s a mismatch between UI and user story expectations ● Performance, security, or usability issues are found

Defects should be reported whenever there is a noticeable issue in the software product. The four key areas to monitor include: first, when a feature fails to operate as designed; second, if any requirement seems to have been implemented incorrectly; third, instances where the User Interface (UI) does not align with what was established in user stories; and lastly, if any concerns arise regarding performance, security, or usability.

Imagine a car that has a feature supposed to alert you when you exceed the speed limit. If this alert doesn't trigger when it should, or if it gives false information, that's a feature not working as intended. Similarly, if the navigation system's interface is confusing, leading to missed routes or incorrect directions, these issues represent the mismatches and usability problems a user would rightly report as defects.

📝 Defect Report Template (Fields) Field Description Defec Unique identifier t ID Sum Short title of the issue mary Descr Detailed steps to reproduce iption Sever Impact on functionality (High, Medium, Low) ity Priori Business urgency (P1 - Critical, P2 - ty Moderate, etc.) Envir Where the issue occurred (Staging, Prod, onme etc.) nt Scree Visual evidence if applicable nshot s Statu Open, Assigned, Fixed, Retested, Closed, s etc. Repor Name of the person raising the defect ted By

The defect report template is a structured format for documenting issues in the software. It includes key fields such as 'Defect ID' for unique tracking, 'Summary' for a brief title, and 'Description' for detailed steps to reproduce the defect. It also assesses the severity, priority level, environment (like staging or production), and the current status of the defect. Each piece of information is vital for the developers and QA teams to understand, prioritize, and address the defect efficiently.

Consider it akin to filling out a maintenance request for a broken appliance in your home. You would note the appliance (like a refrigerator), describe the issue (not cooling properly), indicate how critical the failure is for food preservation, mention when and where the problem was observed, and finally, provide your contact information so the repair service can follow up. This structured approach ensures the service team has all the relevant information to address the issue effectively.

🔍 Example Defect Field Sample Entry Summary Error message not shown on invalid login Severity Medium Priority P2 Steps to 1. Go to Login Page Reproduce 2. Enter wrong credentials 3. Click Login Expected “Invalid username/password” message Result should appear Actual No message is displayed Result Status Open

In this example defect, the issue is that an error message does not appear when a user enters incorrect login credentials. With a medium severity and priority level, this defect has an immediate impact on user experience, as users depend on feedback from the system to understand why they are unable to log in. The steps to reproduce the defect provide clarity on how testers can consistently replicate the issue in order to analyze and fix it.

This situation can be compared to a customer service process where the system fails to provide feedback when a customer enters incorrect billing information online. If a message indicating the mistake does not appear, the customer may repeatedly attempt to enter their information without realizing the issue, leading to frustration. Hence, just as a clear error message can enhance user experience in a web service, identifying and addressing such defects in software is critical.

BA’s Role: ● Raise defects found during UAT or requirement validation ● Clarify misunderstood requirements during defect triage ● Retest or support test case updates after fix is applied

Business Analysts (BAs) play a vital role in defect management by identifying issues during User Acceptance Testing (UAT) or when validating the requirements. They are also responsible for clarifying any misunderstandings that occur during the defect triage process, helping to ensure that developers accurately address defects. After fixes have been applied, BAs support retesting to confirm that defects have been resolved effectively and that the software aligns with the requirements.

Think of the BA's role as that of a quality control manager in a manufacturing plant. As products roll off the assembly line, the manager identifies any defects, tells the production team what went wrong, and ensures that fixes are implemented before the products reach customers. Similarly, BAs ensure the software meets quality standards and user expectations through vigilant defect management.

--