Your First 90 Days
The offer is signed. Now the goal quietly changes — from proving you could do the job to becoming someone the team trusts. The first weeks of a junior QA role follow a learnable arc, and the difference between a rocky start and a strong one is mostly knowing what "useful" looks like before you're senior enough to define it. This page hands you that definition, phase by phase.
A new doctor's residency is the model. The license got you in the door; the first rotations are structured trust-building — supervised cases first, complexity added as judgment shows. Nobody hands the new resident the ER on day one, and the good ones don't sulk about it. They collect cases.
Weeks 1–2: Learn the Product Like a Tester
Resist the urge to find a big bug on day two. First, use the product as a customer — book the stay, feel the friction (your Chapter 10 usability eyes, before you're too expert to see it fresh). Then map the machinery: the environments (Chapter 2 — which is staging, which is prod, how do builds get there?), the tracker's landscape (Chapter 6 — and yes, you may find its own 82-ticket graveyard), where requirements live (Chapter 2 — stories, wiki, or people's heads?), and who owns what (the real cast). The deliverable that makes this visible: your own notes-map of the product — which teams, delightfully often, adopt as onboarding docs for the next hire, because nobody sees a product as freshly as its newest tester.
Weeks 3–6: Earn Trust with the Fundamentals
Now you contribute, and you start where trust is cheapest to build. The verification queue first (Chapter 6.3's gate): re-testing fixes is bounded, useful, and — bonus — teaches you the product's bug history as you go. Then small features end-to-end. Your first bug reports are your reputation (Chapter 6.2 — over-invest in them; a junior remembered for crisp reports is a junior who gets trusted with more). And ask questions with your homework shown: not "how does cancellation work?" but "I checked the story and the wiki — is it intentional that cancellation is blocked at exactly 48 hours, or should that be inclusive?" The homework-shown question reads as senior; the bare question reads as risk. Same curiosity, opposite impression.
Weeks 7–12: Find Your Seams
With trust banked, you extend into gaps. Volunteer for the unowned: the smoke checklist nobody ever wrote (Chapter 5.3 — write it), the flaky-test triage nobody loves (Chapter 9.2 — you know exactly how). Join refinement and ask one good question per session (Chapter 2's ambiguity hunting, now in public — the gift-card question, but yours). And start your bug catalog for this product (Chapter 4.6) — the beginning of the personal asset that compounds for a career. Notice the arc: weeks 1–2 you absorb, weeks 3–6 you deliver on known ground, weeks 7–12 you claim territory. Rush it and you skip the trust; drag it and you stall. The pace is the skill.
The Relationships
QA's influence is entirely relationship-borne — Chapter 7's lesson made personal: your power is the clarity of your picture, and clarity only lands where there's trust to carry it. So invest in three relationships deliberately. The developer who gets your first great bug report — approach as respect, not gotcha (Chapter 6.1's tone); a developer who learns your reports are fair and precise becomes an ally who fixes fast. The PM whose ambiguities you catch early — you make their stories stronger, and they remember. The senior tester whose review you actively ask for — "would you look at my test cases before I finalize?" is not weakness; it's how you improve fastest and signal coachability at once. Relationships aren't a soft add-on to the job; on a QA team, they are the delivery mechanism.
The Traps, Named
Four ways new testers stumble — not on skill, but on pacing and posture. The gatekeeper cosplay: blocking releases you don't own (Chapter 7 — you inform, you don't veto). The silent struggler: stuck for two days, asking no one — the opposite of the homework-shown question, and pure risk to the team. The tool-collector: learning every product name in Chapter 9's landscape while filing mediocre reports — breadth as procrastination from depth. And burnout-by-conscientiousness: trying to test everything (Chapter 7.1 exists precisely so you don't — risk-based, remember). Each trap is a good instinct overshot: care, thoroughness, curiosity, diligence — all virtues, all dangerous unbounded. The cure for every one is a lesson you already have from earlier chapters.
Fernway, One Last Time
The book's fiction closes its loop. Your real first 90 days will replay the Fernway arc you've been living: the tracker cleanup was your weeks 1–2 (learning the product by fixing its memory). The FW-312 report was your trust-builder — the crisp bug that made developers take you seriously. The refinement questions arrived around week 7, once you'd earned the room's attention. The fiction was a rehearsal, run at a comfortable distance; this page hands you the same schedule for the real thing, where the tracker is real, the developer is real, and the trust you build is yours to keep. You've already done this once. Now do it where it counts.
- "I should find big bugs fast to prove myself." Early credibility comes from verification discipline and report quality, not heroics. Big finds follow product knowledge — which you're still building in weeks 1–6.
- "Asking questions looks junior." Questions with homework shown read as senior; silence reads as risk. "I checked the story and wiki — is X intentional?" builds trust the bare question can't.
- "The first months are about impressing the manager." They're about becoming load-bearing to the team — the manager reads the team. Relationships with developers, the PM, and a senior tester are the real scorecard.
- "More thoroughness is always better." Testing everything is burnout-by-conscientiousness — the trap risk-based planning exists to prevent. Every first-90-days trap is a virtue overshot; the cures are earlier chapters.
- Onboarding is where junior careers actually wobble — not on skills, but on pacing and trust. A 90-day map turns the book's whole toolkit into a sequence with a first step.
- The homework-shown question pattern is the single most reputation-building habit a new tester can adopt — it converts inevitable questions into demonstrations of diligence.
- Naming the four traps as virtues-overshot lets you catch yourself early: the cure for each is a lesson you already hold.
Knowledge Check
What should weeks 1–2 focus on?
- Learning the product like a tester: use it, then map environments, tracker, and requirements
- Finding the biggest, most impressive bug possible
- Asking pointed questions in every refinement meeting
- Blocking the next release until you understand everything
Why does the verification queue come first in weeks 3–6?
- It's bounded, useful, and teaches the product's bug history while building trust cheaply
- Because it's the least important work, so mistakes won't matter
- Because no one else on the team is willing to do it
- Because it requires writing automated tests immediately
Which question reads as senior?
- "How does cancellation work?"
- "I checked the story and wiki — is the 48-hour cutoff meant to be exclusive?"
- Saying nothing and figuring it out alone for two days
- "Can someone explain the whole product to me?"
A new tester spends two days blocked without asking anyone. Which trap is this?
- The gatekeeper cosplay
- The silent struggler
- The tool-collector
- Burnout-by-conscientiousness
You got correct