How do you build a test strategy for a new service from scratch?

A test strategy explains what could go wrong, how we will find out before customers do, and how much each kind of check costs. I build it in a fixed order so the tests follow from the risks rather than from the tools I like.

1. Understand the service

Questions I ask early:

• What does it do and who calls it: a UI, other services, partners?
• What are the dependencies: databases, queues, third-party APIs?
• What are the non-functional expectations: latency targets, throughput, availability, data retention, compliance?
• How is it deployed, and how often? Is there feature flagging?
• What does failure cost: lost revenue, wrong data, a regulatory incident?

I read the design document and API specification, and draw a simple context diagram if none exists.

2. Identify and rank risks

I list risks with rough impact and likelihood. For a typical service: incorrect business rules, data corruption, broken contracts with consumers, authorization gaps, performance under peak load, failure handling when a dependency is slow, and migration or deployment errors. The top risks get the most attention and the most automated coverage.

3. Map risks to test layers

The rule is to catch each risk at the cheapest layer that can actually detect it.

Layer	Owner	Catches
Unit	Developers	Business rules, edge cases, calculations
Component / API (service in isolation, dependencies stubbed)	Dev + SDET	Endpoint behaviour, validation, error handling, authorization
Contract	Dev + SDET	Breaking changes between consumer and provider
Integration (real database, queue)	Dev + SDET	Queries, migrations, serialization, messaging
End-to-end	SDET	A handful of critical journeys across services
Exploratory	Whole team	Unknown unknowns, usability, odd states

End-to-end tests are kept to the journeys that would be a business incident if broken.

4. Non-functional testing

• Performance: baseline load test against agreed latency targets (p95, p99), then stress and soak before major releases.
• Security: authorization matrix, input validation, dependency scanning, SAST in the pipeline.
• Resilience: timeouts, retries and behaviour when dependencies fail or slow down.
• Accessibility if there is a UI.

5. Environments and data

Which tests run where: unit and component tests in CI with containers (for example Testcontainers), contract tests against a broker, integration and E2E in a shared or ephemeral environment. Test data is created by tests through APIs or builders; no real personal data.

6. Pipeline and quality gates

Fast checks on every pull request, broader suites on merge, and long-running performance or security scans nightly or before release. Gates are explicit: tests green, no new critical vulnerabilities, coverage not decreasing on changed code, contract verification passing.

7. Production

Testing does not end at deployment: health checks, synthetic monitoring of critical flows, dashboards and alerts on error rate and latency, and canary or feature-flag rollouts so problems are contained.

8. Keep it alive

A strategy is a living document. I review it after incidents and major features, and track a few signals: escaped defects, flaky test rate, pipeline duration and time to detect issues in production.

What interviewers look for

• Starting from context and risk, not from a list of tools.
• A deliberate split across layers with ownership.
• Non-functional and production concerns included, not bolted on.
• Clear quality gates and a feedback loop for improving the strategy.