careersoft-skillsonboardingprocessqa

A QA's first 30 days on a new project — how to ramp up without doing anything dumb

Day one on a new project looks the same almost everywhere: the product is unfamiliar, the environments are confusing, the wiki has twenty outdated pages, everyone’s running somewhere — and someone is already asking you to “take a quick look at this feature, you’re QA after all.” Two feelings fight inside: “I should already be useful” and “I don’t know where the login is yet.” That fight is what produces the classic first-month blunders — more on those below.

I’ve been through several of these starts and worked out a structure for the first month that I’ll share. It’s not about “completing the onboarding plan” — it’s about being useful after 30 days, not merely “settled in.”

Fresh eyes are a resource with an expiration date

Let me start with the non-obvious. In your first month you have a superpower that will disappear: you see the product through a new user’s eyes and the processes through an outsider’s. In a month or two you will get used to it — to the crooked onboarding flow, to the environment that “yeah, it’s down in the mornings,” to the bug that “is a known one, ignore it.” The team stopped noticing all of this long ago; soon you will too.

So rule number one: from day one, write down everything that seems strange, awkward, or unclear. Not to bring a list of grievances tomorrow (more below), but because in a month you won’t be able to see these oddities anymore. That list is the raw material for your future improvements, and it can only be mined now.

Week 1: be a user, not a tester

The temptation of the first week is to bury yourself in test cases and process docs right away. I do the opposite: the first week, I live in the product as a user. Every day. Go through registration (yes, by hand, with a real mailbox), the core scenarios, pay for something (on a test environment — to genuinely understand what payment looks like), break something over your knee the way a regular user would.

In parallel — two questions whose answers determine all future testing: what does the product promise the user (the core value — if it’s broken, nothing else matters) and what does the product make money on (critical paths are money; their regression always matters most). Sounds trivial, but ask a new tester to name the top-3 scenarios by importance — and it often turns out that knowledge lives only in the veterans’ heads.

And yes — ask questions. All of them, even the “dumb” ones. The first month is the only time when any question is legitimate by default; later the same question costs a bit more. Experienced people know this and squeeze the maximum out of colleagues in month one.

Weeks 1–2: the map of the terrain

Alongside the product, I assemble a map of everything I’ll be working with: where requirements and designs live (and how alive they are), what the bug tracker looks like and — importantly — what a good bug report looks like here (open a dozen bugs filed by people the team respects and study the style), what environments exist and which belongs to whom, whether test cases/checklists exist and how current they are, how the release cycle works: how often releases happen, who says “ready,” what runs in CI.

No evaluating anything at this stage — just understand how things are. The evaluations come later, and they’ll be far more accurate.

The risk map: three questions that replace documentation

The most valuable thing I do in the first two weeks is short conversations with every team member (developers, the PM, support — especially support!) built around three questions:

  • What breaks most often here?
  • What was the last serious incident and what caused it?
  • Where are you yourselves afraid to touch?

The answers are a ready-made risk map of the product, more accurate than any documentation: people unerringly remember where it hurts. “Just don’t touch the sync module, it was written by a guy who left” — that’s information no wiki contains. I supplement it with six months of bug history from the tracker: sorting by module gives an objective top of problem areas. The intersection of “the team’s fears” and “the bug statistics” is where to look first.

Weeks 2–3: first tasks — small and exemplary

I take my first real tasks small and carry them to completion: not “test this big feature,” but bug — report — retest — closed. The reason is simple: the team will form an opinion of you from your first artifacts, and that opinion is hard to change later. So the first bug reports are exemplary: reproducible steps, environment, evidence, sane severity. One brilliant report in the first week does more for your reputation than ten “works fine” passes.

And separately: don’t criticize processes in the first weeks. Even if you’re right. Especially if you’re right. “Well, at my previous job we used to…” is the phrase after which people stop listening to you. Half of the local oddities have a reason you don’t know yet; the other half’s reason is fatigue, and there your careful question “why is it like this?” will highlight the problem better than any criticism. Fresh eyes are served as questions, not verdicts.

Week 4: first improvements — small and finished

By the end of the month you have the oddities list (from week 1), the risk map, and an understanding of the processes. From that I pick one or two small improvements and carry them to completion: not “let’s rewrite all the test cases” (that’s a six-month war), but “here’s a release smoke checklist, I ran it on the last two releases, it catches these things.” Small, finished, with visible value. It’s both a contribution and a statement: I’m not here just to work tickets.

And at the same moment — a conversation with your lead about mutual expectations: what’s expected of me by day 90? In the spirit of Rands’ classic essay on the first ninety days: the first month you learn, the second you integrate, and by the end of the third you’re expected to deliver independent value. Better to learn the specifics of those expectations on day 30 than on day 90.

First-month antipatterns

Staying silent so as “not to bother anyone.” A month of silence — and you’re “that quiet new person, unclear what they do.” Questions, notes in shared channels, first reports — visibility is needed from week one.

Criticizing everything. The opposite extreme, see above. Questions — yes; verdicts — no.

Taking a big feature right away. Failing it due to missing context is the worst possible start. Small finished tasks win.

Not writing things down. In a month you’ll forget the questions, the oddities, and the answers people gave you. One note where everything lands is cheap insurance.

Pretending you understood. Nodding and going off to google — fine once. Systematically — you accumulate a debt of misunderstanding that surfaces at the worst moment.

The 30-day checklist

  • Walked the core user scenarios by hand; use the product daily
  • Know what the product promises the user and what it earns on (top-3 critical paths)
  • Keeping an “oddities” list from day one
  • The map: requirements, tracker, environments, test artifacts, release cycle, CI
  • Three questions to everyone on the team: what breaks / last incident / where are you afraid to touch
  • Six months of bug history: top problem modules
  • First bug reports — exemplary; first tasks — small and finished
  • Not a single “well, at my old job”; oddities delivered as questions
  • One or two small improvements finished and shown
  • A conversation with the lead: expectations for day 90

The first month isn’t the one-way probation period people usually suffer through. It’s the only month when you simultaneously have fresh eyes, the right to any question, and zero speed expectations. These three resources melt away from there — and whether you use them is decided in week one.