Purpose
The purpose of this document is to guide QA teams at Memorres in logging and prioritizing defects in a structured, consistent, and transparent manner. In lean teams, defects can easily become chaotic if they are not documented properly. Developers may dismiss issues as non-reproducible, PMs may lose track of unresolved items, and clients may feel frustrated by recurring problems. This How-To ensures every defect is captured with sufficient detail, assigned the right severity and priority, and followed through until closure. Logging and prioritizing defects correctly protects delivery timelines, ensures development focuses on the right issues, and creates an auditable trail of quality management.
Scope
This document applies to all QA activities where defects are identified during planned test execution, regression testing, integration validation, or UAT. It covers how defects are logged in approved tools, how they are categorized, and how priority is determined collaboratively. It does not cover production incidents reported by clients, which are managed under incident management processes.
Process
Logging and prioritizing defects involves several structured steps, each designed to make defects reproducible, traceable, and actionable.
| Step | Activity | Detailed Description | Responsible Role | Output |
| 1 | Identify & Verify Defect | When an anomaly is observed, QA must first confirm whether it is reproducible and not an environment/setup issue. Multiple attempts may be needed to validate consistency. | QA Engineer | Verified defect candidate ready for logging |
| 2 | Log Defect in Tool | Defects must be logged in the approved tracking tool (e.g., Jira, ClickUp). Each entry must include: title, environment, build version, steps to reproduce, expected result, actual result, attachments (screenshots/logs). | QA Engineer | Complete defect record in tool with traceable details |
| 3 | Assign Severity | Severity reflects business/system impact: Critical (system down, blocker), Major (core feature broken), Minor (non-blocking issue), Trivial (cosmetic). Severity must be assigned objectively, based on predefined criteria. | QA Engineer + QA Lead | Defect severity field set in tool |
| 4 | Review & Confirm Severity | QA Lead reviews logged defect and confirms or adjusts severity based on impact analysis and requirement traceability. | QA Lead | Verified severity classification |
| 5 | Assign Priority | Priority determines the order in which defects should be fixed. It is set collaboratively by QA Lead, Dev Lead, and PM. Example: a Minor severity issue may still get High priority if it affects a client demo. | QA Lead + Dev Lead + PM | Defect priority field set in tool |
| 6 | Triage & Assignment | PM/Dev Lead assigns defect to a developer, ensuring ownership is explicit. QA must not self-assign to Devs without coordination. | PM / Dev Lead | Defect assigned to owner with due date |
| 7 | Track Lifecycle | QA monitors defect through lifecycle stages: New → Assigned → In Progress → Fixed → Retest → Closed. Status must always be updated in tool. | QA Engineer | Real-time defect lifecycle dashboard |
| 8 | Retest & Validate Fix | When Dev marks defect as Fixed, QA must retest the scenario in the same environment/build. If unresolved, defect is reopened with updated evidence. | QA Engineer | Retest result logged in defect entry |
| 9 | Close & Document | Once validated, defect is closed. If recurring patterns emerge, they must be flagged for Root Cause Analysis. | QA Lead | Closed defect log with validation evidence |
Example of Correct Logging
| Field | Poor Logging | Correct Logging |
| Title | “Login not working” | “Login error 500 after submitting valid credentials in staging build v1.2.3” |
| Steps | “Tried to log in” | “1. Open staging URL → 2. Enter valid credentials → 3. Click submit → 4. Error 500 displayed” |
| Expected Result | “Should work” | “User should be redirected to dashboard with active session” |
| Actual Result | “Error” | “Server error 500 displayed, user not redirected” |
| Severity | Not set | Critical |
| Attachments | None | Screenshot of error + server log extract |
Closing Note & Cross-References
This How-To ensures that defects at Memorres are never vague, misplaced, or mishandled. By logging with complete details and prioritizing collaboratively, QA creates defects that developers can reproduce, PMs can track, and clients can trust. Correct logging is inseparable from prioritization; both must happen together to keep delivery aligned.
This document connects with the QA Collaboration & Defect Lifecycle Framework, which provides the guiding principles, and the Test Execution & Bug Lifecycle Management SOP, which defines the operational steps for handling defects end-to-end.