Document: 35-quality-assurance.md
Version: 1.0.0

Purpose

This document defines the Quality Assurance (QA) standards used across all Rundown projects.

Quality Assurance ensures that every application satisfies agreed functional, technical, visual, and operational requirements before release. QA provides confidence that software is ready for production and minimizes avoidable defects after launch.

QA Philosophy

Quality is verified, not assumed.

Every feature, workflow, and deployment should be validated against defined acceptance criteria before release.

A project is considered complete only after it has successfully passed the agreed quality assurance process.

Responsibilities

Quality Assurance verifies:

• Functional requirements

• Visual implementation

• Responsive behaviour

• Accessibility

• Performance

• Browser compatibility

• CMS functionality

• Production readiness

Non-Responsibilities

Quality Assurance should not:

• Replace development testing.

• Replace code reviews.

• Replace client feedback.

• Define project scope.

QA validates implementation against agreed requirements.

QA Workflow

Every project follows the same QA process.

Development Complete

↓

Internal QA

↓

Issue Resolution

↓

Regression Testing

↓

Client Acceptance Testing

↓

Production Approval

No project should move to production without completing this workflow.

Functional Testing

Verify that:

• Every feature behaves as expected.

• Forms submit successfully.

• Navigation functions correctly.

• User journeys complete successfully.

• Error states behave appropriately.

Testing should reflect real user behaviour.

Responsive Testing

Applications should be tested across representative:

• Desktop devices

• Tablets

• Mobile devices

Layouts should remain usable and visually consistent across supported screen sizes.

Browser Compatibility

Applications should be validated in supported browsers.

At minimum:

• Chrome

• Safari

• Firefox

• Edge

Project requirements may expand browser support where necessary.

CMS Verification

Verify:

• Content editing

• Media uploads

• Drafts and publishing

• User permissions

• Collection management

• Global settings

The client should be able to manage content without engineering intervention.

Accessibility Review

Review key accessibility requirements, including:

• Keyboard navigation

• Semantic HTML

• Form labels

• Alternative text

• Color contrast

• Focus visibility

Accessibility should be considered throughout development rather than added at the end.

Performance Review

Verify:

• Core Web Vitals

• Image optimization

• Loading performance

• JavaScript bundle size

• API responsiveness

Performance targets should align with the standards defined in 23-performance-architecture.md.

Visual Review

Compare the implemented application against the approved designs.

Verify:

• Layout

• Typography

• Spacing

• Colors

• Components

• Animations

• Interactions

Visual inconsistencies should be resolved before release.

Regression Testing

After fixing identified issues:

• Retest affected functionality.

• Verify related features.

• Confirm that previous functionality remains unaffected.

Regression testing prevents new defects from being introduced during bug fixes.

Client Acceptance Testing (UAT)

The client should validate that the delivered application satisfies the agreed project scope.

Acceptance should focus on:

• Business requirements

• Content accuracy

• User workflows

• Operational readiness

Client approval marks the completion of the acceptance phase, not the end of engineering responsibility.

Defect Management

Each defect should include:

• Description

• Steps to reproduce

• Expected behaviour

• Actual behaviour

• Severity

• Status

• Resolution

Defects should be tracked within the project management system.

Release Readiness

Before deployment, verify:

• All critical defects resolved.

• Major defects reviewed.

• Acceptance criteria satisfied.

• Documentation updated.

• Deployment approved.

Release readiness should be based on objective criteria rather than schedule pressure.

Engineering Decision

Standard QA Process

Status: Accepted

Decision

Every Rundown project must complete a standardized quality assurance process before production deployment.

Reasoning

A consistent QA process:

• Improves reliability.

• Reduces production defects.

• Increases client confidence.

• Supports predictable releases.

• Reinforces engineering discipline.

QA Checklist

Before approving production deployment, verify:

• Functional testing completed.

• Responsive testing completed.

• Browser compatibility verified.

• CMS validated.

• Accessibility reviewed.

• Performance reviewed.

• Visual implementation approved.

• Regression testing completed.

• Client acceptance received.

Summary

Quality Assurance provides the structured validation process that confirms every Rundown application is ready for production.

By applying consistent testing standards and objective release criteria, Rundown delivers reliable, maintainable, and production-ready software while reducing operational risk and increasing client confidence.

Related Documents

• 11-testing-standards.md

• 23-performance-architecture.md

• 27-deployment-workflow.md

• 34-project-management.md

• 36-client-handover.md

Related ADRs

• ADR-003: Documentation Information Architecture