← Back to Overview

1. Requirements & Planning

QA Process

The first phase of QA begins before development is completed. QA involvement at the planning stage helps identify gaps, ambiguities, and risks early in the lifecycle, reducing the chances of defects reaching later stages.

A. Requirements Review

1. Read & Understand PRD

Before writing any test cases or starting validation, the Product Requirements Document (PRD) is reviewed completely from start to finish. The purpose of this step is to understand:

  • The business goal of the feature
  • Expected user behaviour
  • Functional requirements
  • Validation rules
  • User flows
  • Edge cases mentioned by stakeholders

While reviewing the PRD, special attention is given to identifying:

  • Missing requirements
  • Conflicting logic
  • Unclear workflows
  • Undefined behaviour
  • Areas where assumptions may create implementation issues

Any ambiguity is documented immediately instead of making assumptions.

2. Review Figma Designs

Once the requirements are understood, the corresponding Figma designs are reviewed screen by screen.

During this review, every UI state and interaction is validated, including:

  • Screen layouts
  • Buttons and CTAs
  • Hover states
  • Empty states
  • Error states
  • Loading states
  • Responsive layouts
  • Typography and spacing

The design review ensures that:

  • The UI matches the product requirements
  • Design flows are logically connected
  • No screen or interaction is missing
  • Visual inconsistencies are identified early

If the design behaviour conflicts with the PRD, clarification is raised before development or testing proceeds.

3. Review API Contracts

API documentation such as Swagger collections or Postman documentation is reviewed before integration testing begins.

This review helps understand:

  • Available endpoints
  • Request payloads
  • Response structures
  • Authentication requirements
  • Validation rules
  • Error codes
  • Pagination behaviour
  • Filtering and sorting logic

The purpose of this step is to ensure that frontend expectations and backend implementation are aligned before testing starts.

4. Raise Clarifying Questions

Whenever unclear behaviour or missing information is identified during requirement or design review, questions are documented and raised with the Product Manager, developer, or relevant stakeholder.

Examples include:

  • Undefined validation rules
  • Missing empty states
  • Unclear business logic
  • Missing API mappings
  • Undefined user permissions

This process prevents assumptions from turning into defects later in the development cycle.

5. Identify Dependencies

Every feature usually depends on other systems, APIs, services, or modules.

During dependency analysis, the following are identified:

  • Third-party integrations
  • Shared backend services
  • Authentication systems
  • Feature flags
  • Environment dependencies
  • Dependencies on other teams

This helps estimate testing impact and identify possible blockers early.

6. Define Entry & Exit Criteria

Before QA execution starts, entry and exit criteria are defined with the team.

Entry criteria define what must be completed before QA can begin, such as:

  • Development completed
  • Build deployed successfully
  • APIs available
  • Test environment stable
  • Requirements finalized

Exit criteria define what conditions must be met before QA sign-off, such as:

  • Critical test cases passed
  • No blocker defects open
  • Regression completed
  • Acceptance criteria validated
  • Stakeholder approval received

7. Understand Acceptance Criteria

Each user story or feature contains acceptance criteria that define expected behaviour.

During QA validation:

  • Every acceptance criterion is mapped to test coverage
  • Validation is performed individually for each condition
  • Evidence is captured for completed validations
  • Missing acceptance criteria are flagged immediately

Acceptance criteria act as the minimum quality baseline before a feature can be approved.

B. Test Planning

1. Write a Test Plan

A detailed test plan is prepared before execution begins.

The test plan usually includes:

  • Scope of testing
  • Out-of-scope items
  • Features being tested
  • Test types involved
  • Test environments
  • Tools being used
  • Testing timelines
  • Risks and assumptions
  • Resource allocation
  • Test deliverables

The purpose of the test plan is to align the QA process with project expectations.

2. Define Test Strategy

The testing strategy is selected based on:

  • Project complexity
  • Risk level
  • Release timelines
  • Feature stability
  • Automation feasibility

The strategy defines:

  • Manual vs automation coverage
  • Smoke testing scope
  • Regression approach
  • Exploratory testing areas
  • API testing coverage
  • Performance and security considerations

The goal is to ensure the right testing approach is used for the release.

3. Estimate Effort

Effort estimation is performed for:

  • Requirement analysis
  • Test case writing
  • Test execution
  • Regression testing
  • Bug retesting
  • Reporting and sign-off

The estimation considers:

  • Complexity of features
  • Dependency risks
  • Environment readiness
  • Number of platforms/devices
  • Historical bug trends

Accurate estimation helps teams plan releases realistically.

4. Identify Test Environments

Different environments are identified and validated before testing begins.

This may include:

  • Local environment
  • Development environment
  • Staging environment
  • UAT environment
  • Production mirror environment

Environment validation includes:

  • Deployment verification
  • API availability
  • Database connectivity
  • Authentication functionality
  • Third-party service availability

Testing should never begin in unstable environments.

5. Risk-Based Prioritisation

Features are prioritised based on business and technical risk.

High-risk areas receive deeper coverage, such as:

  • Payments
  • Authentication
  • Critical workflows
  • Data-sensitive operations
  • High-traffic features

Lower-risk areas may receive lighter regression coverage.

This approach ensures testing effort is focused where failures would have the highest impact.

6. Define Test Data Strategy

Testing often requires multiple types of data.

During this step, required test data is identified, including:

  • Valid user accounts
  • Edge-case values
  • Invalid inputs
  • Role-based accounts
  • Large datasets
  • Seed data
  • Expired or inactive states

The process also includes planning how the data will be:

  • Created
  • Maintained
  • Reset
  • Shared securely across environments

Proper test data management prevents false failures during testing.