Standard Operating Procedure: Software Quality Assurance (SQA)

This document establishes the standardized framework for the Software Quality Assurance (SQA) lifecycle. The objective of this SOP is to ensure that all software deliverables meet predefined functional, performance, and security requirements before deployment. By adhering to these protocols, the organization minimizes post-release defects, optimizes development cycles, and ensures a high-quality user experience. This SOP applies to all members of the engineering and QA departments involved in the software development lifecycle (SDLC).

Phase 1: Test Planning and Strategy

• Review product requirements (PRDs) and user stories for testability and clarity.
• Define the scope of testing (e.g., unit, integration, system, UAT).
• Identify the target environments (e.g., Staging, QA, Pre-prod).
• Define resource allocation and timeline milestones.
• Select necessary testing tools (e.g., Jira, Selenium, JMeter, Postman).

Phase 2: Test Case Design

• Create comprehensive test cases based on user stories.
• Develop edge cases and negative test scenarios (e.g., invalid inputs, extreme load).
• Document expected results for every test step.
• Map test cases to specific requirements to ensure 100% coverage.
• Establish data requirements (e.g., synthetic datasets, database snapshots).

Phase 3: Execution and Defect Management

• Execute manual and automated test suites in the designated environment.
• Log every failure in the centralized bug tracking system (e.g., Jira).
• Categorize defects by severity (Critical, Major, Minor, Trivial) and priority.
• Verify that developer fixes are implemented and perform regression testing on affected modules.
• Document all testing results and metrics in a summary report.

Phase 4: Release Readiness and Sign-off

• Conduct a final regression suite to ensure no new defects were introduced.
• Perform security/vulnerability scanning.
• Execute Performance/Load testing to verify stability under peak traffic.
• Obtain sign-off from Product Managers and Engineering Leads.
• Finalize the "Release Notes" detailing known issues or limitations.

Pro Tips & Pitfalls

• Pro Tip: Automate the "Happy Path" immediately. Prioritize automating repetitive regression tasks to free up QA time for exploratory testing.
• Pro Tip: Shift Left—Involve QA in the requirements gathering phase to catch logic gaps before a single line of code is written.
• Pitfall: Ignoring "Flaky Tests." If a test fails intermittently, investigate it immediately rather than re-running it; flakiness is usually a sign of architectural instability.
• Pitfall: Over-documentation. Do not write test cases for every single button if the logic is trivial. Focus documentation effort on high-risk, complex workflows.

Frequently Asked Questions (FAQ)

Q: How do we determine if a bug is "Critical" or "Major"? A: A "Critical" bug halts the entire business process or compromises data integrity (e.g., user cannot pay). A "Major" bug is a significant failure in functionality, but a workaround may exist or the impact is isolated to a specific, less-frequented feature.

Q: When should we stop testing? A: Testing is typically stopped when all high-priority test cases have passed, no "Critical" or "Major" open defects remain, and the risk assessment indicates the software is stable enough for the target audience.

Q: Should QA be responsible for writing unit tests? A: No. Unit tests are the responsibility of the developer who writes the code. QA focuses on functional, integration, and system-level testing to ensure the software behaves correctly from the user's perspective.