Test strategy and audit

How to organise testing in a small team without a dedicated tester

A small company does not need a dedicated tester to know what was checked before each release and what risk remains. Testing here is an agreement about who checks a change, what matters most, and when the product should not be deployed.

This approach is for an owner, product lead, and developers who currently test largely by instinct. The goal is not to remove every possible defect. It is to spend limited time where a defect would cause the most harm to customers or the business.

Why “the developer checked it” is not enough

The author knows the technical details of a change, but will naturally exercise the path they have just built. They may not notice that a registration change damaged password recovery, or that a discount works for one product but not for a combination in the basket. This is not about blaming an inattentive person. It is a consequence of missing a second perspective and shared priorities.

Without an agreement, the scope changes with whoever happens to have time. Before an important release, people may click through the product without knowing whether payments, permissions, or error states were covered. A later customer report then finds the team without a record of the version and conditions it checked.

Start with a map of business risk

List five to ten activities without which the product does not serve its purpose. For a shop, these might be finding a product, paying, and processing the order. For an internal system: signing in, creating a record, approving, and exporting. For each activity record:

• what a customer or the company would experience if it failed;
• how often the activity is used;
• which user types and devices matter;
• which integration, such as a payment or accounting service, could affect the outcome.

You do not need a precise score. High, medium, and low risk with a reason are enough. Our guide to risk-based testing explains the principle. This map decides what must be checked and what can wait.

Example: a five-person team changes invoice generation

Three developers, a product manager, and the company owner build a small B2B product. The team is changing the rule that creates an invoice after an order is paid. Without a shared process, the author might check one order and deploy. The risk map reveals three possible impacts: the customer receives no document, two invoices are created, or the wrong company details appear on it.

The author therefore checks a normal payment and repeated delivery of a confirmation from the payment service. They add an automated assertion that exactly one invoice exists for one order. As the second person, the product manager changes the company details and opens the generated PDF. Before release, the responsible colleague uses a short basic-functionality, or smoke, checklist: order, payment, invoice, email, and the document in the customer account.

The team deliberately does not retest every old screen. It records that credit notes are outside the change’s scope. If the same module turns out to handle them, the risk is reassessed. The example shows the essence of a small process: not a large testing effort, but a visible link between the change, plausible impact, and specific evidence.

Divide checking into three simple moments

Before handing over a change, its author checks the new behaviour and at least one invalid input. The developer adds fast code- or API-level checks where appropriate. They note what changed, what they checked, and what remained outside scope.

Before merge or deployment, a second person checks the expected result and one adjacent critical journey. For a delivery-price change, they verify the basket calculation, order, and confirmation rather than the whole system. Their perspective should not exactly repeat the author’s steps.

Before release, a named person reviews the highest-risk checklist and automated results. The role can rotate, but the decision needs a rule: which failed checks stop the release and which may be accepted after assessing impact.

Agree on the minimum for a completed change

A one-page “done means” agreement can state that:

1. the requirement includes understandable examples of expected behaviour;
2. the author checked a normal and an error scenario;
3. critical logic has a proportionate automated check;
4. a second person reviewed the change and its relevant impact;
5. the team knows how to verify or roll back the change after deployment;
6. an intentionally deferred risk has an owner and due date.

Automation need not begin with a large UI suite. Fast, precise checks sit close to the code, while fewer end-to-end (E2E) tests exercise complete journeys. The test pyramid without dogma explains the distribution. Start with stable, repeated, business-critical scenarios; our guide to selecting the first test cases helps set priorities.

Fit the scope of checking to the change

Not every work item needs the same checklist. Correcting a typo in static text has a different risk from changing sign-in or a price calculation. Ask four questions during planning: what is changing, what uses this area, what is the worst realistic consequence, and what is the least expensive way to reveal it before release?

For low risk, the author’s check and a second person’s preview may be enough. For medium risk, add an adjacent scenario and an automated regression check, which checks that repaired behaviour has not returned. For high risk, cover the normal journey, error states, roles, and connected services; prepare a rollback approach where the impact justifies it. The category does not prescribe a number of clicks. It determines the strength of evidence required for a decision.

An urgent production repair may have a narrower pre-deployment scope when delay would cause greater harm. The team should name the exception, obtain approval from the responsible person, and complete the omitted checks after stabilisation. An unrecorded “we had no time” creates invisible debt; an explicit exception with an owner can be managed.

Keep the process light and visible

Once a week or before a release, ask: what changed, what could fail, and what evidence shows that critical journeys work? Record findings with other work, not in private messages. For a defect, include the version, environment, steps, expected result, and actual result.

Track only information that changes a decision: how many defects reach customers, how long a critical defect remains open, and whether the team repeatedly loses time in the same area. A raw count of tests or found defects does not show whether the product is safer.

How to verify that the lightweight process helps

After four to six releases, review concrete evidence. Were critical journeys genuinely checked or were boxes merely ticked? Did customers encounter failures the map classified as high risk? When an automated check is red, can the team identify within a few minutes who decides what happens next? These answers reveal a weak process more accurately than the number of written test cases.

Time from completed development to a release decision is another useful signal. If a second review routinely waits two days for one person, introduce a rotation or reduce the scope. If failures recur in the same area, add a durable automated check or clarify the requirement. If the checklist keeps growing, remove items without a link to a real risk.

The process is working when the team can answer four questions for every release: what changed, which material risks were checked, what evidence supports the decision, and what knowingly remains open? This does not mean no defect will escape. It means the decision is not based only on intuition, and experience from an incident changes the next release process.

When to bring in external help or hire a tester

External help can be useful when the team needs its first risk map, an independent release check, an automation design, or help with an unstable suite. A permanent quality assurance (QA) role may fit better when the volume of change and daily coordination create sustained work. Neither choice transfers quality to one person: requirements, code, and risk decisions remain team responsibilities.

What you gain

The owner gets an understandable view of residual risk instead of a general “it looks fine”. Developers know the minimum expected from a change, and checks focus on revenue, customers, and operations. If the team later hires a tester or expands automation, it will not have to start from scratch.

Next step

At the next short team meeting, choose five critical product activities, assign each a risk, and name the person who will check it before release. Write the six-point “done means” agreement and use it for one change. If you need an independent design proportionate to the size of the team, the next step can be a no-obligation consultation.