Quality assurance in a small product team

Quality assurance in software development is the set of practices that keep defects from reaching users: clear acceptance criteria before work starts, code review and automated tests while it is built, a staging check before release, and monitoring after. Testing is one part of QA. The rest is process, and in a small team the process has to be light enough that people follow it on a busy Friday.

We are a team of 10 to 20 engineers in Managua, and this is how we organize QA at that size.

QA, QC and testing are different things

People use the three words as synonyms. Separating them helps when you decide who does what.

Quality assurance is about the process. It asks whether the way the team works will produce correct software. Are requirements written down? Does every change get reviewed? Do releases go through the same steps every time?

Quality control is about the product. It checks a specific build against the requirements and finds the defects that got through.

Testing is the main tool of quality control. Unit tests, feature tests, end-to-end tests and manual checks are all ways of looking at the product.

A team can have hundreds of tests and poor QA, if nobody agreed on what the feature should do before the tests were written. The tests then confirm the wrong behavior very reliably.

Quality starts in the ticket

Many of the defects clients report are not crashes. They are features that work as coded and not as the client expected. That gap opens before anyone writes code, so that is where we start.

Every ticket we pick up has acceptance criteria written as things a person can check. "Users can export invoices" is not enough. "An admin can export the invoices in the current filter as CSV, with one row per invoice, and a user without the billing permission doesn't see the button" is something the engineer can build, the reviewer can verify, and the client can accept or reject.

When a ticket can't be written that way, the work isn't ready, and we say so in planning instead of guessing. Our article on defining a project scope covers how we get there at the start of a project.

The engineer who builds it tests it first

In a small team, the engineer who builds a feature owns its tests. We don't hand code to someone else to find out whether it works. Each pull request comes with the automated tests for the behavior it adds or changes, and the engineer has clicked through the feature in a browser or on a device before asking for review.

Code review is the second check. The reviewer reads the change against the acceptance criteria, runs it when the change is risky, and looks for the cases the author didn't think of: the empty list, the user without permission, the second click on a submit button.

Then the automated checks run on every pull request: tests, static analysis, formatting. A pull request that fails them doesn't get merged, and nobody needs to remember to run them.

Test the parts where mistakes cost money

No team tests everything equally, and pretending to is how the important paths end up with the same thin coverage as the settings page. We spend the most testing effort where a defect would hurt the client's business: payments and billing, permissions, anything that deletes or overwrites data, and integrations with outside systems.

Permissions get special attention because their failures are silent. A user who can see another company's data doesn't report a bug. On 1Click's package-tracking platform, for example, permissions are set per action on packages, rates, pickups and billing, and the platform keeps an audit trail of who changed what, when, the before and after, and why. Rules that fine-grained need tests for each role, or nobody can say with confidence what a given user is allowed to do.

Every release goes through the same environments

We keep at least three environments: development, a staging or testing environment with realistic data, and production. Changes reach production only after passing through staging. That is how 1Click's releases work, with unit and end-to-end tests, and it is how we ship small releases without interrupting the client's daily operations.

Staging is where the client sees the work before their users do. We send a short note with each release candidate: what changed, how to try it, and anything we want them to check in particular. Client acceptance is part of QA. They know their business rules better than we do, and a ten-minute check from the person who wrote the requirement catches things no test suite will.

For larger changes we ship behind a feature flag. The code goes to production turned off, the client tries it with their own account, and we turn it on for everyone when they are happy. If something goes wrong, turning the flag off is faster than a rollback. Our engineers working alongside a US nonprofit's developers build feature flags into the backend of its platforms, and their work ships through staging, a QA step and automated GitHub checks.

After release, watch for what got through

Some defects will reach production anyway, so we set up error monitoring on the projects we build or maintain, so an exception in production reaches an engineer within minutes, with the stack trace and the request that caused it, instead of reaching the client as an angry email the next morning.

When a bug does get through, we fix it and then ask which check should have caught it. Sometimes the answer is a missing test, and sometimes the acceptance criteria were vague. Then we add the test or tighten how we write criteria, so the same kind of bug doesn't come back.

A user who can see another company's data doesn't report a bug.

How we handle bug reports

Clients report bugs in whatever way is easiest for them, and we turn each report into a ticket with steps to reproduce, the expected result, the actual result, and a severity. We use three levels. Critical means users can't do their main job or data is at risk, and someone starts on it right away. High means a feature is broken with a workaround, and it goes into the current cycle. Normal waits for planning.

Agreeing on these levels at the start of a project avoids a lot of friction later. When everything is urgent, the team switches tasks all day, and the real emergency waits in the same queue as a misaligned button.

When a dedicated QA engineer makes sense

A dedicated tester earns their place on mobile apps that have to work across many devices and OS versions, on products with heavy regulatory requirements, and on large teams where no single engineer sees the whole system. For a web product built by two to five engineers, we find that strong acceptance criteria, tests written with the code, review, staging and monitoring catch more than a tester working at the end of the line.

When a client asks us to add manual QA, we add it, and we put it as early as possible. A tester who reads the acceptance criteria before development starts finds problems while they are still cheap to fix.

What QA costs, and what skipping it costs

QA time is in every estimate we send. Writing tests, reviewing code and preparing a staging release take hours, and those hours are visible on the invoice. Cutting them makes the first release cheaper and every release after it more expensive, because defects found by users take longer to diagnose, come with support time attached, and sometimes come with data to repair.

When a client wants a cheaper first release, we would rather cut scope than tests, and we say so. We also list testing as part of the work instead of hiding it in a buffer, so the client can see what they are paying for.

If you want a team that builds your product with this process from the first sprint, see our product development services.