Contents
A small team organises manual testing without a separate department: checklists of critical flows, a staging environment with clear data, exploratory testing of new features and one bug report format. A dedicated QA engineer can do the checking or, without one, a developer who did not write the feature plus the product owner at acceptance.
Here is how to set up the process, what to check before every release and how to report bugs so they get fixed quickly.
Does a small team need a dedicated tester?
A dedicated tester is needed when the product is complex, releases are frequent and mistakes are costly — for example, there are payments or many user roles. In a team of three or four developers on a small product, developers and the product owner can share the role if the process is clearly defined.
How to share testing without a tester:
- the developer checks their own task against the scenarios in its description and writes automated tests;
- another developer checks the task during review — not just the code but its behaviour on staging;
- the product owner accepts the feature at the demo, checking it through a user's eyes;
- before a release, one person runs the regression checklist.
An experienced tester pays off when this setup stops coping: bugs regularly reach users and developers spend more and more time on checking.
What should be checked before every release?
Before every release, run a regression checklist — a short list of flows that must never break, whatever changes: sign-in, sign-up, the key user journey, payment. Anything on the list that can be automated is gradually moved into automated tests.
| Type of check | What we check | When |
|---|---|---|
| Task check | Scenarios and acceptance criteria of a specific feature | After development, before merge |
| Exploratory testing | Unusual actions, edge-case data, unexpected paths | For new and risky features |
| Regression | Key flows across the whole product | Before every release |
| Device check | Popular browsers, phones, screen sizes | For UI changes |
| Post-deploy check | A quick run of the main flow in production | Right after release |
We covered how to decide what to automate and what to leave manual in automated testing strategy.
Photo: Unsplash
Checklists or test cases?
For a small team, checklists are more practical than detailed test cases: they are shorter, quicker to update and cover what matters. Detailed test cases with steps and expected results are justified for critical flows — payments, calculations, access control — where nothing must be missed.
A sample regression checklist
Pre-release regression — online store
[ ] Sign-up, sign-in, password reset
[ ] Catalogue search and filters, product page
[ ] Cart: add, change quantity, remove
[ ] Checkout with delivery and pickup
[ ] Card payment: success and bank decline
[ ] Account: order history, reorder
[ ] Admin: new order visible to managers, status change
[ ] Emails: order confirmation and status updates
[ ] Mobile: checkout on a phone
The checklist lives next to the code or in the knowledge base and is updated whenever a new key feature appears.
How do you report bugs so they get fixed quickly?
Report a bug so a developer can reproduce it on the first try: steps, expected and actual results, environment and data, a screenshot or screen recording. Half the time spent on a fix usually goes not into code but into understanding and reproducing the problem.
A bug report template:
- Title — what broke and where: "Promo code not applied to discounted items".
- Steps — numbered actions from the start.
- Expected result — how it should work.
- Actual result — what happens, including the error text.
- Environment — staging, browser or device, user account.
- Priority — how much the bug hurts users and the business.
- Attachments — screenshot, video, a link to the log entry.
How do you organise the test environment and data?
The test environment should be as close to production as possible but with safe test data: accounts for every role, products and orders in various states, test payment cards. Real customer personal data must never be used on staging.
What to prepare:
- a separate staging environment where the main branch deploys automatically;
- test users for every role with known passwords;
- test data created with one command, so it is easy to restore after testing;
- test modes of the payment provider and email service;
- access to logs so they can be attached to bug reports.
Regular manual checks together with automated tests and review make timelines more predictable — fewer bugs bounce back after release, as covered in why software projects miss deadlines.
In short
- In a small team, developers and the product owner share testing; a tester is needed for complex products and frequent releases.
- Run a short regression checklist before every release and gradually automate it.
- For small teams checklists beat test cases; detailed scenarios are for critical features.
- A bug report has steps, expected and actual behaviour, environment and attachments.
- Staging needs test data and accounts for every role, with no real personal data.
FAQ
Can developers test their own code?
They can and should, but it is not enough: authors know how the feature should work and unconsciously avoid the weak spots. A second check by someone else finds noticeably more bugs.
Which devices should a site be tested on?
On the ones your audience uses: take the list of browsers and devices from web analytics. A few current desktop browsers and a couple of popular iOS and Android phones are usually enough.
How long does pre-release regression take?
For a small product with a good checklist, from half an hour to a couple of hours. If regression stretches over days, it is time to automate most of it.
