How QA Should Respond to 'Spec' Claims

When a developer or planner responds to an issue found by QA by saying it's "Spec," QA should not simply accept this but should respond based on clear evidence. Here, spec refers to the documented requirements (Specification) that the product must meet, i.e., the planning document.

If the discovered symptom is included in the expected results of the planning document, it can be classified as Spec in close and the issue can be closed. However, if the planning document does not contain such content, a discussion process is needed to determine whether to acknowledge it as spec or treat it as an issue to be fixed.

The step-by-step procedure for an effective response is as follows:

• Create a ticket in the Bug Tracking System (BTS) and keep it in Open status.
• Inquire with the developer/planner to confirm which part of the planning document the symptom corresponds to.
• If it is specified in the planning document, process it as Spec in close.
• If there is no specification, discuss whether to add the spec or fix the issue, taking user experience into account.

QA's role goes beyond simply finding bugs—it is to identify root causes and improve product quality to deliver the best experience to customers.