New QA Engineer? Test the Risk, Not the Ticket

TL;DR A new tester who counts executed cases and tests only what the ticket says gets tuned out: 50 shallow checks lose to 10 tests aimed at risk, and a vague bug report bounces back. Your first 90 days as a QA engineer have three jobs: learn the product and people, contribute real tests and one automation PR, then own one thing your lead can point at.

Do this: Take one story from your sprint and write five test cases for it, with the technique's name next to each one.

Part 1 put you on the ladder by scope. At QA Engineer, your scope is assigned stories, and part 1 ended on one of them: FieldFlow's release R25 adds a "round to nearest 5 minutes" billing option, and you cannot test every duration a field engineer might log. Which tests count?

The repo is blunt about it: 50 shallow checks lose to 10 tests aimed at risk. Your first three months are about learning to write the 10.

QA Career Path, in seven parts:

1. The QA Career Path: Map Yourself by Scope, Not by Title
2. New QA Engineer? Test the Risk, Not the Ticket (you are here)
3. Manual to Automation Testing in Six Months: Skip the Tutorial Loop
4. Senior QA: Depth Everywhere Is Depth Nowhere
5. After Senior QA: Lead the Release or Own the Platform?
6. QA Manager to Head of QA: The Escape Bill That Wins Budget
7. Will AI Replace Testers? Make Your Judgment the Evidence

Name the technique, then count the cases

Turn "test the rounding option" into a set of cases you can count and defend by naming the technique behind each one. Say the valid labour duration is 1 to 1440 minutes, as the repo's exercise does:

Equivalence partitions   valid 1–1440 · below range · above range · not a number
Boundary values (2-value) 0, 1, 1440, 1441
Decision table           rounding on/off × VAT-exempt customer × discount applied
                         = 8 combinations
State transition         can a job be invoiced if it was never completed?
Error guessing           timezones, offline sync, concurrent edits, permissions

The repo's bar for this exercise is about 15 to 25 countable cases with technique names attached, not 100 vague ones. The ticket's acceptance criteria are where you start, not where you stop.

Report where the bug is, not just what you saw

"The total is wrong on screen" bounces back. Say where it is wrong: work down the stack before you file.

The repo's example: "DB stores 93.75, API returns 93.75, UI shows 91.50: render-layer bug." That report gets fixed in hours. Then give it a title that states the failure, numbered steps from a known state, expected and actual, the build and environment, and evidence. One bug per report.

Learn, contribute, own: one job a month

The engineer 90-day plan uses the same shape managers use: learn before you change things, then deliver, then own.

Score yourself, then score yourself again

At week 8 and week 12, score the Engineer part of the repo's self-assessment: 15 skills, each 0 (can't), 1 (know the theory), 2 (done it with help) or 3 (alone, and can teach it). A few:

1. Test a story beyond its acceptance criteria: negative, edge, permission and offline cases.
2. Send an API request and check the response body, not just the status.
3. Read a failing automated test and say: product bug, test bug or environment?
4. Use AI tools without pasting customer data, and check what they produce.

Around 30 out of 45, with nothing at 0, means you are a solid independent tester. Pick the two weakest items as next quarter's goals.

Try it

Here is a story from my sprint: <paste it>.
List the equivalence partitions and boundary values, then a decision table
for any combined rules. Label each case with its technique.
Then tell me which 5 cases you would run first, and why.
Do not invent requirements: list questions for refinement instead.

Week 6 of the plan asks you to pick up a small automation ticket. At FieldFlow that means walking into a suite of 300 Selenium UI scripts, about 30% of them flaky, that nobody trusts, while manual regression takes 7 tester-days. Which language do you learn, and what should your first pull request be? Part 3, Manual to Automation Testing in Six Months: Skip the Tutorial Loop, is that plan.

Read this with your AI

Read the post "New QA Engineer? Test the Risk, Not the Ticket".
1. Summarise it in 5 bullets for a tester in their first QA job.
2. Ask me 3 questions to check I understood; wait, then correct me.
3. Help me write my own 30-60-90 plan in the same three-phase shape.