A release qualifies on evidence,
or it does not qualify.
► View as a slide presentation
The Automation Test Development Lifecycle — how scope becomes coverage, coverage becomes execution, and execution becomes a defensible go or no-go. This is the engineering depth behind GVS QAS and VVQ, and the basis on which we advise on test strategy.
The ATDLC route
Requirements to feedback, with testing sitting where it can still change the outcome rather than only report on it.
Requirements
Testable acceptance criteria agreed before design, not derived after build.
Design — HLD
High-level design; integration points and failure modes identified early.
Design — LLD
Low-level design; component boundaries that determine test granularity.
Development
Build, with automation written alongside rather than retrofitted.
Testing
Functional and non-functional, at component and system level.
Deployment
Sequenced, with the rollback position defined before the window opens.
Delivery · support · operations
Run and maintain; production behaviour observed, not assumed.
Customer feedback
Returns to requirements. Escaped defects are traced back to the stage that missed them.
The two stages most often collapsed are HLD and LLD. Where the low-level design is skipped, component boundaries are decided during coding, and test granularity is then dictated by accident rather than intent — which is where most untestable systems originate.
Coverage model
Two axes: what the system must do, and what it must withstand. Each tested at both component and system level.
Functional testing
Does the system do what was specified — for one component in isolation, and for the whole workflow a user actually traverses.
- Unit and integration behaviour at the boundary
- Interface contracts between components
- Negative and edge-case handling
- System acceptance against agreed criteria
- Key functionalities under realistic configuration
- Entire workflow, end to end
Non-functional testing
Does it hold under conditions nobody designed for — sustained load, sudden spikes, and long duration where leaks appear.
- Latency and throughput per service
- Resource behaviour under concurrency
- Failure and recovery of the single component
- Load — expected concurrent demand
- Stress — beyond expected, to find the break point
- Performance — latency, throughput, concurrency against target
Load models
Five shapes of demand. Testing only the average is how systems pass qualification and fail in production.
| Model | Demand shape | What it exposes | Typical miss |
|---|---|---|---|
| Burst load | Short, sharp arrival of requests above steady state | Queue depth, connection pool exhaustion, thread starvation | Passing average-rate tests |
| Peak load | Highest expected sustained concurrency | Capacity headroom, autoscaling behaviour, latency degradation curve | Testing at mean, not peak |
| Spike load | Near-instant multiple of normal, then release | Recovery behaviour, back-pressure, cascading failure | No recovery measurement |
| Soak / endurance | Moderate load sustained over long duration | Memory leaks, connection leaks, log and disk growth, slow drift | Test window too short |
| Stress | Beyond design capacity until failure | The break point, and whether failure is graceful or catastrophic | Never run — break point unknown |
The endurance test is the one most often cut for schedule, and the one that catches the defects that surface three weeks after go-live — when the cost of finding them has multiplied and the release team has moved on.
Tooling & reports
What gets used, and what has to come out the other end for a gate decision to mean anything.
Tooling
Open, scriptable, and observable — so results can be reproduced by the client's own team after handover.
- Scriptable, so the suite is version-controlled not clicked
- Observable, so a failure is diagnosable not just red
- Transferable, so the client runs it once we leave
Qualification reports
A gate decision is only defensible if these exist. Without them, "tested" is an assertion.
- Coverage against acceptance criteria
- Pass, fail and blocked, with cause
- Open defects by severity at gate time
- RPS and TPS sustained against target
- Latency distribution, not just the mean
- Behaviour over the endurance window
- Break point and recovery characteristics
The Q-Gate
Where the evidence becomes a decision. Three outcomes, and the middle one has to be written down.
| Outcome | Condition | What must be recorded |
|---|---|---|
| Pass | Coverage complete, no open blocker or critical, stability targets met | Evidence pack, sign-off, and the baseline the next release is measured against |
| Conditional | Residual risk accepted to meet a date | The condition, the accepting owner by name, and the date the residual risk is cleared. Unwritten conditions become permanent |
| No-go | Blocker open, coverage incomplete, or stability target missed | The specific failing criterion, remediation owner, and the re-gate date |
Most quality failures are not test failures. They are conditional passes whose conditions were never written down, never owned, and never cleared — so the next release inherits them silently. GVS QAS exists to make the condition an artefact rather than a conversation.
Run the gate, not the argument.
GVS QAS structures the launch-readiness gate with evidence per criterion. GVS VVQ carries the ATDLC pipeline, defect tracking and Q-Gate qualification. Both run in your browser, and the evidence stays on your device.
Open GVS QAS → Open GVS VVQ