Document: 11-testing-standards.md
Version: 1.0.0

Purpose

This document defines the testing standards followed across all Rundown projects.

Testing ensures that applications remain reliable, maintainable, and production-ready. Every feature should be verified before deployment to minimize regressions and improve overall software quality.

The objective of testing is to increase confidence in the application, not simply to increase test coverage.

Testing Philosophy

Testing should focus on validating business-critical functionality.

Not every line of code requires automated testing. Instead, testing efforts should prioritize features that have the greatest impact on users and business operations.

Testing should be practical, maintainable, and proportionate to the complexity of the project.

Testing Levels

Manual Testing

Manual testing is required for every project.

Developers should verify:

• Navigation

• Forms

• CMS functionality

• Responsive layouts

• Interactive components

• Animations

• Browser compatibility

• Error handling

Every feature should be tested manually before opening a Pull Request.

Automated Testing

Automated tests should be introduced where they provide long-term value.

Priority should be given to:

• Business logic

• Utility functions

• Critical workflows

• Complex calculations

Simple presentational components do not necessarily require automated tests.

Browser Testing

Every project should be tested on modern browsers.

Minimum supported browsers:

• Google Chrome

• Microsoft Edge

• Mozilla Firefox

• Safari

If project requirements specify additional browser support, those requirements take precedence.

Responsive Testing

Applications should be verified across common viewport sizes.

Minimum testing:

• Mobile

• Tablet

• Desktop

Layouts should remain functional without horizontal scrolling or overlapping content.

CMS Testing

Projects using Payload CMS should verify:

• Content creation

• Content editing

• Media uploads

• Draft publishing

• Authentication

• Role-based permissions

Changes made through the CMS should display correctly on the frontend.

Form Testing

Every form should be verified for:

• Required field validation

• Invalid input

• Successful submission

• Error handling

• Success messages

Forms should fail gracefully when external services are unavailable.

Performance Testing

Before deployment, verify:

• Image optimization

• Lazy loading

• Bundle size

• Lighthouse Performance score

• Core Web Vitals

Performance regressions should be investigated before release.

Accessibility Testing

Every project should include basic accessibility verification.

Minimum checks:

• Keyboard navigation

• Focus indicators

• Alt text

• Form labels

• Heading hierarchy

• Color contrast

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

SEO Testing

Verify:

• Page titles

• Meta descriptions

• Open Graph tags

• Canonical URLs

• Sitemap

• robots.txt

• Structured data (when applicable)

Deployment Verification

Before deployment, confirm:

• Production build succeeds

• Environment variables are configured

• Database migrations are complete

• Images load correctly

• Forms function correctly

• Analytics are working

• SSL is active

Regression Testing

Whenever an existing feature is modified, verify that related functionality continues to work correctly.

Regression testing should focus on areas affected by the change.

Bug Reporting

Every bug report should include:

• Description

• Steps to reproduce

• Expected behaviour

• Actual behaviour

• Screenshots or recordings (if applicable)

• Environment information

Clear bug reports reduce debugging time and improve communication.

Engineering Decision

Testing Strategy

Status: Accepted

Decision

Rundown adopts a practical testing strategy that combines manual verification with targeted automated testing.

Reasoning

Most Rundown projects are marketing websites, CMS-driven websites, and ecommerce platforms.

A balanced approach provides strong reliability while avoiding unnecessary maintenance overhead associated with excessive automated testing.

Automated tests should focus on functionality that is difficult to verify manually or likely to regress over time.

Pre-Deployment Checklist

Before deploying to production, verify:

• All agreed features are complete.

• Manual testing is complete.

• Critical workflows function correctly.

• Responsive layouts have been verified.

• CMS functionality has been tested.

• Forms have been validated.

• Performance has been reviewed.

• Accessibility checks have been completed.

• SEO metadata is correct.

• Documentation has been updated.

Summary

Testing is an essential part of the development process and should be integrated throughout the project lifecycle.

The goal is to deliver reliable, maintainable software while balancing engineering effort with project complexity.

Related Documents

• 07-development-workflow.md

• 08-coding-standards.md

• 10-documentation-standards.md

Related ADRs

• ADR-001: Repository Structure

• ADR-002: Git Workflow

---

## Review

I think **Phase 2 is now complete.**

And before we jump into Phase 3, I want to pause—not to redesign anything, but to review what we've built.

We've written these documents in the order a new developer would naturally learn them:

1. Set up your environment.
2. Understand the project structure.
3. Learn the Git workflow.
4. Follow the development workflow.
5. Write code to our standards.
6. Follow naming conventions.
7. Document your work.
8. Test before shipping.

Looking back, I think that's a coherent onboarding path. My only suggestion before starting Phase 3 would be to spend one session creating the **`glossary.md`**. It will make the architecture documents much cleaner because we can reference shared terms instead of redefining them repeatedly.

After the glossary, we can move into **Phase 3 – Architecture**, where we'll start documenting Payload CMS, databases, storage, authentication, and the rest of the technical architecture.