Standard Operating Procedure: Quality Assurance (QA) Execution

Quality Assurance (QA) is the systematic process of determining whether a product, service, or process meets specified requirements and standards. This SOP establishes a rigorous framework for conducting QA to minimize defects, ensure regulatory compliance, and deliver consistent, high-value outcomes to the end-user. By following this standardized checklist, teams can mitigate operational risk and ensure that every deliverable undergoes a comprehensive validation cycle before final sign-off.

Phase 1: Pre-QA Environment Setup

• Validate Environment: Ensure the testing environment mirrors the production environment to prevent "it works in staging, but not in prod" scenarios.
• Data Integrity Check: Verify that test data is sanitized, anonymized, and sufficient to cover all edge cases.
• Version Control: Confirm the build version, branch, or release candidate is documented and matches the scope defined in the project brief.
• Requirement Baseline: Review the final functional requirements document (FRD) or user stories to ensure the testing team understands the "Definition of Done."

Phase 2: Execution and Functional Testing

• Happy Path Verification: Validate that the primary user flow works as intended without errors.
• Negative Testing: Attempt to "break" the system by inputting invalid data, performing unauthorized actions, or triggering sequence errors.
• Boundary Testing: Test values at the extreme ends of allowed input fields (e.g., character limits, numeric thresholds).
• Cross-Browser/Cross-Platform Compatibility: Perform tests across designated browsers (Chrome, Safari, Firefox, Edge) and device types (Mobile, Tablet, Desktop).
• UI/UX Consistency: Check against the design system (Figma/Adobe XD) to ensure typography, spacing, and color hex codes align with the approved UI specs.

Phase 3: Performance and Security Validation

• Latency Testing: Measure load times under normal traffic conditions and document any bottlenecks.
• Stress/Load Testing: Verify system stability during peak usage simulations to determine breaking points.
• Security Scanning: Execute automated vulnerability scans to check for common OWASP threats (SQL injection, XSS, etc.).
• Permissions Audit: Test role-based access control (RBAC) to ensure users cannot access features or data outside their assigned privilege level.

Phase 4: Reporting and Sign-Off

• Defect Documentation: Log all bugs in the central tracking system (e.g., Jira, Asana) including steps to reproduce, expected vs. actual results, and severity ratings.
• Regression Suite Run: Ensure that fixes for previous bugs have not introduced new regressions in existing, stable functionality.
• Stakeholder Sign-Off: Obtain formal approval from the Product Owner or Lead Developer once the "Critical" and "Major" bug list is empty.
• Final Archiving: Archive the test results report for compliance audits and historical project analysis.

Pro Tips & Pitfalls

Pro Tips

• Shift Left: Begin QA planning during the design phase rather than waiting for the development phase to finish; this reduces the cost of fixing defects.
• Automate Repeatables: If a test case is performed more than three times, automate it. Free up your manual QA resources for exploratory, creative testing.
• Exploratory Sessions: Dedicate 15% of your QA time to "unscripted" testing where the QA engineer acts as a malicious or confused user to find non-obvious flaws.

Pitfalls to Avoid

• The "Optimism Bias": Assuming a feature works because it is "simple." Always test the simple features with the same rigor as the complex ones.
• Missing Documentation: Testing without documenting results is equivalent to not testing at all. If a bug isn't recorded, it will inevitably return.
• Ignoring Edge Cases: Focusing only on the "happy path" leaves the system vulnerable to crashes when a user performs an unexpected action.

Frequently Asked Questions (FAQ)

1. How do we determine the severity of a bug? Severity is determined by the impact on business operations. A "Critical" bug renders the system unusable or leads to data loss, while a "Low" severity bug is typically a minor cosmetic or UI inconsistency that does not affect functionality.

2. What is the difference between QA and QC (Quality Control)? QA is process-oriented and focuses on preventing defects by improving the development process. QC is product-oriented and focuses on identifying defects in the finished product before it reaches the customer.

3. When should we stop testing? Testing stops when the project reaches the "Definition of Done," all "Critical" and "Major" bugs are resolved, the regression suite passes, and the risk level is deemed acceptable by the project stakeholders.