10. Test Automation Strategy

← Previous: Defect Management | Back to QA Strategy | Next: Quality Standards & Definition of Done →

Test automation at Spline Studio is a strategic process focused on maximizing product quality and delivery efficiency. This section describes the principles, prioritization, maintenance, and integration of automated tests, ensuring that automation efforts are targeted, sustainable, and aligned with business goals.

flowchart TB
    A["Test case selection for automation"] --> B{"Smoke/Critical?"}
    B -- Yes --> C["Automate in e2e smoke suite"]
    B -- No --> D["Assess automation feasibility"]
    D -- Feasible --> E["Automate in relevant suite"]
    D -- Not feasible --> F["Manual testing"]
    C --> G["Integrate into pipeline"]
    E --> G
    G --> H["Periodic execution & maintenance"]
    H --> I["Analyze results, update tests"]

    style A color:#000000,fill:#D50000
    style B color:#000000,fill:#FF6D00
    style C fill:#FFE0B2,color:#000000
    style D fill:#FFCDD2,color:#000000
    style E fill:#FFCDD2,color:#000000
    style F fill:#FFD600,color:#000000
    style G fill:#FFF9C4,color:#000000
    style H fill:#C8E6C9,color:#000000
    style I fill:#00C853,color:#000000

10.1 Principles and Prioritization

Test automation focuses on the most critical scenarios that ensure product stability and core functionality.
From all test cases, those with the highest business impact and risk (Smoke, Critical Path, High Priority) are selected. These are marked as "Smoke" and automated first in the dedicated e2e file.
For each feature, 1–4 key tests are chosen to cover the main functionality. These are automated as a priority.
Other important tests (High/Medium Priority) are automated gradually as resources allow. They are grouped into feature-specific files.
In the second stage, sequential scenarios are created for the most effective execution of automated tests (end-to-end flows).
Before automating any test, feasibility is assessed: are the costs (time, resources) justified compared to manual testing?
Critical cases are automated after integration testing and only for finalized functionality to avoid rework.

10.2 Maintenance and Evolution of Automated Tests

Regression tests are automated gradually, even after release if not completed before production. Smoke tests for new features should ideally be automated before release.
When new features are introduced, the impact on existing automated tests is analyzed and they are updated as needed.
Automated tests should be adaptable for execution across different environments (DEV, RC, PROD).

10.3 Integration and Execution

Automated tests are integrated into the CI/CD pipeline for automatic and periodic execution (e.g., on every pull request, nightly build).
Test run results should be transparent to the whole team (dashboards, reports).
Adherence to company standards for structure, style, and quality of automated tests is mandatory.

10.4 Quality Gates

Automation scope and objectives are defined and approved
Automated test coverage meets the agreed target for the sprint/release
All automated tests pass in the target environment
Test automation code is reviewed and follows coding standards
Automation documentation is updated and accessible

10.5 Supporting Guides & Templates

Automation Preparation – Describes approaches to test selection for automation, prioritization criteria, feasibility assessment, and best practices for starting automation.

Automation Coding Standards – Requirements for structure, style, best practices, naming conventions, and code review guidelines for automated tests.

Gitflow for Automated Tests – Processes for creating, reviewing, merging, and branching automated tests, and integration with CI/CD.

Automation Results Processing & Maintenance – Analysis of automation run results, test updates, retrospectives, and maintaining relevance of automated tests.

← Previous: Defect Management | Back to QA Strategy | Next: Quality Standards & Definition of Done →