--- title: "New QA Engineer? Test the Risk, Not the Ticket" author: "Harry" published: 2026-10-31T04:46:54.332Z updated: 2026-10-31T05:06:50.055Z category: "Career & Teams" tags: ["qa-career-path"] canonical: "https://fxblog.dev/posts/new-qa-engineer-test-the-risk" --- # New QA Engineer? Test the Risk, Not the Ticket ## Key takeaways - Ten tests aimed at risk beat fifty shallow checks on the happy path. - Naming the technique behind each case (partitions, boundaries, decision tables, state transitions) turns a vague story into a countable, defensible set of tests. - A bug report that says where the fault is, for example the database and API agree but the UI shows a different total, gets fixed far faster than a symptom. - The first 90 days in a QA job have three jobs: learn in days 1 to 30, contribute in days 31 to 60, and own one thing in days 61 to 90. - A self-assessment of 15 skills scored 0 to 3, retaken every 6 to 8 weeks, shows a new tester where to grow; about 30 out of 45 with nothing at 0 means solid and independent. > **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](01-qa-career-ladder.md) 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: ```text 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. > **Tip** > > Ask one "what about…?" question in refinement: "what happens if the engineer is offline when the job is rounded?" A defect removed in refinement never reaches a build. ## 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. ![Localising a wrong total: UI 91.50, API 93.75, database 93.75, so the render layer is at fault](https://fxblog.dev/media/01a19047-dfd1-73c2-967e-1d44ea055584/1600) _Three checks turn a symptom into a fixable bug_ 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. > **Warning** > > Write for a developer who has 90 seconds and wasn't there. "It doesn't work" with no steps or evidence is how you become the tester developers ignore. ## 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. | Days | The job | Done when | | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | 1–30 | Learn: every access working; use FieldFlow as dispatcher, field engineer and API partner; ask support which bugs customers complain about most | You explain the product, the release flow and your area's top three risks without notes | | 31–60 | Contribute: a "what about…?" in every refinement, a first timed exploratory session, a small automation ticket merged | Your bugs rarely bounce; one automation PR is merged | | 61–90 | Own: one thing agreed with your lead (an area, the smoke suite, the test data), one recurring annoyance fixed | Your lead can name something that got better because you joined | ## 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 ```text Here is a story from my sprint: . 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 ```text 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. ``` > **Success** > > You can turn a story into countable cases and a symptom into a located bug. Next: **Manual to Automation Testing in Six Months: Skip the Tutorial Loop**. ## FAQ ### What should a new QA engineer do in the first week? Get every access working (tracker, environments, CI, logs, read-only database), read the team's Way of Working and bug template if they exist, use the product as each main user type would, and start a glossary of domain terms. ### How many test cases should I write for a story? Enough to cover the partitions, boundaries and rule combinations that matter, with the technique named for each. For a single billing option the source's exercise expects about 15 to 25 countable cases, not 100 vague ones. ### When should a new QA engineer start on automation? The 90-day plan has you run the suite locally in week 3 and pick up a small automation ticket in week 6, aiming for one merged automation PR by day 60.