30-60-90 day plan for QA engineers
On this page
- What to measure, and what not to
- Days 1-30: Learn the product and the test system
- Days 31-60: Own testing for a feature and stabilize the suite
- Days 61-90: Sign off a release and analyze what escaped
- What "on track" looks like
- A filled example
- Questions for the check-ins
- What the hiring manager owes the new QA engineer
- Common mistakes
- Adapting the plan
- Questions people ask
A QA engineer's work is judged by an absence: the bugs that did not reach users. That makes the first 90 days hard to plan with a generic template, because "number of tests written" is easy to count and nearly meaningless. A useful 30-60-90 day plan for QA engineers instead builds toward three things the team can check: a map of where the product is most fragile, an automated suite the developers trust, and a release the new engineer signed off.
This plan is written for the engineering manager or QA lead hiring a QA engineer, sometimes titled software development engineer in test, who does both exploratory and automated testing inside a product team. For developers, use the 30-60-90 day plan for software engineers. The general template is the 30-60-90 day plan template for new hires.
What to measure, and what not to
| Measure | Useful because | Watch out for |
|---|---|---|
| Escaped defects | Bugs found in production that testing could reasonably have caught; the clearest signal of test quality | Small numbers swing a lot; review causes, not just counts |
| Critical journey coverage | Whether the flows that make or lose money are tested, automatically or by a checklist | Line coverage percentages that look high but miss the journeys |
| Suite stability | The share of test runs that fail for reasons unrelated to code changes | A flaky suite teaches developers to ignore failures |
| Bug report quality | Developers can reproduce the bug from the report alone | Many vague reports inflate the count and waste time |
| Bugs filed or tests written | Rough activity signal only | Rewards volume over impact; do not set a target |
Days 1-30: Learn the product and the test system
Goals
- Get the development environment and the test suite running locally, and run the suite in the continuous integration pipeline, by the end of the first week.
- Use the product as a customer would, across every major feature, and file bugs found along the way.
- List the critical user journeys with the product manager and engineering lead, for example sign-up, checkout, data export, and mark how each is covered: automated, manual checklist or not at all.
- Inventory the flaky tests: which fail intermittently, how often, and the suspected cause.
- Read the last three months of production incidents and escaped bugs, and note which journey each came from.
- Write a few automated tests for an uncovered area, reviewed by a senior engineer, following the team's existing framework and patterns.
Deliverables by day 30
- The critical journey map with current coverage.
- A flaky test inventory, ranked by how often each blocks a merge.
- Reviewed automated tests merged, and bug reports developers reproduced without follow-up questions.
Days 31-60: Own testing for a feature and stabilize the suite
Goals
- Own testing for one feature from design to release: review the requirements or designs for testability, write a test plan with risks, add automated tests during development and run exploratory sessions before release.
- Fix or quarantine the worst flaky tests from the inventory, with the owning developers where the cause is in the product code.
- Add automated coverage for the highest-risk uncovered critical journey.
- Take part in bug triage and propose severity and priority for new bugs.
Deliverables by day 60
- A feature released with a written test plan and no high-severity escaped defects from it in the first weeks.
- A measurably more stable suite than at day 30, using the team's own failure data.
- One additional critical journey covered by automated tests running in the pipeline.
Days 61-90: Sign off a release and analyze what escaped
Goals
- Sign off at least one release, with the lead available but not deciding: list the known risks, the open bugs and why each is acceptable or not.
- Analyze every escaped defect from the last quarter: which journey, why testing missed it, and what would catch it next time.
- Propose one change to the team's testing approach based on that analysis, such as contract tests for an unstable integration or a pre-release checklist for a journey that cannot be automated well.
- Pair with a developer on writing tests for their own feature, to spread testing habits rather than become the only person who tests.
Deliverables by day 90
- A release signed off with a written risk summary.
- An escaped defect analysis with one agreed change underway.
- Updated critical journey coverage compared with day 30.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Suite runs locally; journey map agreed with product; bug reports reproducible; reviewed tests merged | Environment still not working; bugs filed without steps or expected results; no view of what matters most |
| Day 60 | Feature tested end to end with a plan; flaky tests falling; triage input respected | Testing starts only after development finishes; new tests are themselves flaky |
| Day 90 | Release signed off with risks stated; escape analysis led to a change | Sign-off is a formality or always deferred to the lead; escaped bugs treated as bad luck |
A filled example
QA engineer: Nikhil Rao (invented), the second QA engineer on a team of nine developers building a B2B invoicing product.
Day 30: Mapped seven critical journeys; two, bulk invoice import and payment reconciliation, had no automated tests. Found the end-to-end suite failed on roughly one run in six, mostly from tests that depended on the order they ran in. Filed 18 bugs, all reproduced without follow-up.
Day 60: Owned testing for recurring invoices, adding tests for time zone and month-end edge cases that the requirements had missed. Fixed the test-order dependency, and suite failures unrelated to code changes became rare. Added automated tests for bulk import.
Day 90: Signed off a release with two known low-severity bugs, documented and agreed with the product manager. The escape analysis showed most production bugs came from the payment provider integration, so the team added contract tests against the provider's sandbox.
Questions for the check-ins
- Which critical journey would you least want to see fail in production this week?
- Which test do developers ignore when it fails, and why?
- What did the last escaped bug have in common with the one before it?
- Where are you brought in too late to influence a feature?
What the hiring manager owes the new QA engineer
- A working environment with test data and access to staging by day one or two.
- An invitation to design and planning discussions, not only to the testing stage.
- Authority to block a release on a stated risk, and backing when they use it.
- Developer time to fix flaky tests whose cause is in the product code.
Common mistakes
| Mistake | Result | Fix |
|---|---|---|
| Targets on tests written | Many shallow tests, same escaped bugs | Measure critical journey coverage and escapes |
| QA as the last gate only | Bugs found when they are most expensive to fix | Involve QA in requirements and design review |
| Tolerating a flaky suite | Developers ignore red builds | Make flaky test reduction a day-60 goal |
| QA owns all testing | A bottleneck and a team that does not test its own code | Pairing with developers on tests by day 90 |
Adapting the plan
- The first QA engineer on a team: there may be no suite, no journey map and no habit of testing before release. Make the day-30 deliverable a test strategy proposal, and the day-90 goal automated coverage of the two or three most important journeys rather than a broad suite.
- Manual or exploratory testers moving into automation: keep the exploratory work as the core of the first 60 days and add automation goals gradually, with a senior engineer reviewing the framework choices.
- Mobile and hardware products: add device and operating system coverage to the journey map, and a day-30 goal to understand how builds reach test devices.
- Regulated software: in medical, financial or safety-related products, add traceability between requirements, tests and results to the first 30 days, since release evidence may be audited.
If you are still hiring, the QA engineer phone screen questions test for risk judgment as well as tooling, and the interview guide for software engineers covers the technical rounds that follow.
Questions people ask
What should a new QA engineer deliver in the first 30 days?
A working local test setup that runs the existing suite, a short list of the product's critical user journeys with how well each is covered by tests today, an inventory of flaky tests, and a few well-written bug reports and reviewed automated tests. Together they show the engineer understands the product and the test system, not just the tools.
How do you measure a QA engineer's impact?
Mostly by what does not reach users. Track escaped defects, meaning bugs found in production that testing could reasonably have caught, along with the stability of the automated suite and coverage of the critical journeys. Counting bugs filed or test cases written rewards volume rather than impact.
Should a QA engineer sign off releases in their first 90 days?
Yes, by the end of the period, for at least one release with a senior engineer or lead backing them up. Sign-off is the core judgment of the role: deciding whether known risks are acceptable. Waiting longer than 90 days to let them make it slows their growth and keeps the release bottleneck on someone else.
How is this different from a software engineer's 30-60-90 day plan?
A software engineer's plan is about shipping code. A QA engineer's plan is about knowing where the product is fragile, building tests that catch regressions reliably, and making release decisions based on risk. Both need the development environment working early, but the QA engineer's day-90 bar is a release they signed off and a suite the team trusts.