QA Engineer to SRE: Transferable Skills and a Practical Learning Plan

What transfers from QA to SRE?

QA experience can provide a useful starting point for reliability work: investigating failures, automating checks and explaining what an observation does or does not prove. The next step is to extend that reasoning to a running service, its users and the decisions required when it degrades.

Begin with evidence from your own work. Have you investigated intermittent failures, improved a deployment pipeline, or separated an application defect from an environment problem? Write down your contribution and what you still needed help to understand. A job title alone cannot establish which skills transfer.

The plan below is an editorial learning exercise, not a hiring rubric. An automation-heavy QA role and a primarily manual testing role may need different starting points. Ask the team you hope to join what its reliability engineers actually own.

Which skills need production context?

Use a small service to connect each unfamiliar concept to something observable. You do not need an impressive collection of tools to begin. You need to understand how a request moves through the system and how you would notice a failure.

Understand the measurement before building a dashboard

Google’s SRE book distinguishes a service-level indicator (SLI), a measurement of service behavior, from a service-level objective (SLO), the target for that measurement. Choose behavior that represents a user need; a convenient server metric may only be a proxy. The source chapter explains these definitions and their tradeoffs.

For the exercise, imagine a small read-only catalog API. Define eligible requests, what makes a response successful, where you measure it and how missing observations are handled. A dashboard without these definitions can make an unreliable service look healthy by silently excluding its failures.

Work through one bounded reliability project

This is a synthetic example, not a production result. Suppose a sandbox service receives 10,000 eligible requests during a fixed exercise window. Your illustrative objective is that 99% return a valid response within 500 milliseconds. If 9,920 meet both conditions, the measured good-request ratio is 99.2%. The target permits 100 bad requests in that window; 80 have occurred, leaving 20 before the target is missed. These numbers are chosen for arithmetic, not recommended service targets.

Now introduce a dependency timeout in the sandbox. Check whether the affected requests reach the denominator and whether your instrumentation distinguishes slow responses from missing observations. Compare what the application logs say with what a caller experiences. Record discrepancies rather than changing the definition to make the result pass.

Write a short runbook: the symptom, the first diagnostic checks, a safe mitigation, the point at which to ask for help and the recovery check. Have a colleague follow it without your narration if that is practical. Record where instructions were ambiguous. Only inject faults into an environment you are authorized to test.

1. Describe the service, user need, indicator and target before choosing dashboard software.
2. Instrument the normal path and at least one controlled failure; retain the observations.
3. Show the calculation, including excluded requests and missing data.
4. Rehearse mitigation and recovery; explain what your sandbox cannot establish about production.

Choose automation that changes the recurring work

Google describes toil as operational work with characteristics such as repetition, manual effort and limited enduring value. Its distinction helps you ask whether a script removes a recurring burden or merely makes one instance faster.

For a second exercise, document a repetitive sandbox task before automating it. Include permissions, failure handling, review and recovery in the comparison. Keep the manual fallback usable. The useful result is an explanation of what became easier and what new maintenance the automation introduced, even if you decide not to keep it.

Use the work to plan a readiness conversation

Bring the indicator definition, failure record and runbook to someone familiar with the role. Ask which assumptions would break in their environment, what you should learn before supervised operational work, and what support exists for on-call responsibilities. A completed project is evidence to discuss, not proof that you can independently operate every service.

Choose the next learning topic from the weakest part of that explanation. If you could configure a graph but could not explain a timeout, investigate the request path. If the runbook required unwritten knowledge, practise making the handoff explicit. Set a review point around completed evidence rather than promising a job transition by a fixed month.

• Turn a technical development into a useful learning action
• Build evidence for a move from mid-level to senior developer