The first two weeks of a QA engagement

There is a version of outsourced QA that starts on Monday and files forty tickets by Friday. It looks like value. It is mostly duplicates, known issues, and design decisions reported as defects, and it costs the engineering team a week of triage to find that out.

We start slower on purpose. Here is what the first ten working days actually contain.

Days one to three: read, do not test

The first job is to learn what the product is for. Not the code, and not the backlog. The product.

That means the marketing site, the onboarding flow as a new user, the support inbox if we are given access, and one conversation with whoever answers "who uses this and what breaks most often". An hour of that conversation removes a week of guessing.

Testing before you know what the product promises is how a team files its first twenty tickets against intended behaviour.

Week one: build the map

By the end of the first week there is a written map of the product, and it is the artifact everything else hangs off:

• The flows, ranked by what a failure would cost. Money and data loss at the top.
• The environments, with the exact browsers, devices and builds that count as supported.
• The known issues, so we do not re-report them and neither does anyone else.
• The gaps, meaning the areas nobody has looked at in a year.

We send that map before we send a single bug. If it is wrong, correcting a document is cheap. Correcting three weeks of misdirected testing is not.

Week two: the first real pass

Testing starts at the top of the ranked list, never at the top of the feature list. The highest paid attention goes to the flows where a defect costs real money, and everything else waits.

The output is small and deliberate:

1. A test pass over the top flows, with a written result for each one.
2. Bugs filed in the agreed format, with severity set against user impact rather than our frustration.
3. A short note on what we did not cover yet, so nobody assumes a silent area is a clean one.

That last item matters more than it sounds. A report that only lists findings reads as complete coverage, and a reader will believe it.

What you should have on day ten

Four things: the product map, a ranked flow list, the first real findings, and a reporting cadence everyone has agreed to. No dashboards, no tooling migration, no opinion about your test framework.

What we deliberately do not do

We do not rewrite your test suite in the first month. We do not ask you to move tools. We do not open a ticket for anything we have not reproduced twice.

Those are all things that feel like progress and produce none. The measure of a good first two weeks is that in week three, nobody on the engineering team has to explain the product again.

How we work walks through the artifacts from that first fortnight on live engagements, redacted. If you would rather ask than read, the contact form on the home page reaches us directly.