Testing
What to test first when you have no QA team.
A team without a QA role still has to decide where testing effort goes. The evidence marks on a specification turn that decision from a guess into a short list: behaviours that exist, matter, and have no tests.
The problem with “test everything”
Everyone agrees the product should be tested. Without a QA team nobody owns the list, and the work slips into the gaps between features. Developers write tests for the code they are touching. Bugs that reached a customer get a test afterwards. What stays untested is the quiet middle: behaviours that work today and nobody is looking at.
The difficulty is knowing what is there. A list of what the product does, with the tests beside it, is the thing that is usually missing.
Reading the marks
In a SpecTrail specification, each requirement carries small marks that show what backs it. They are a map of confidence:
Built, and covered by tests. Lowest priority.
Built, with tests for only part of it. Look at what is missing.
Built, with no tests. The candidates for your first new tests.
A simple order
- Money, access and data. Behaviours that charge a customer, decide who can see what, or change or delete stored data, if they have no tests.
- Recently changed behaviour. Requirements that moved in the last few weeks and have thin or no coverage. Change is where bugs enter.
- What customers use most. You know which features carry the product. Partly tested ones come before untested ones nobody uses.
- Everything else, as time allows.
An example
Take the requirement “A code stops working at the end of the day it names, in the store’s time zone”. It is built, and its flask is amber: partly tested. Reading the requirement points straight at the gap. Time zones and end-of-day boundaries are where bugs hide, so the first new test is a code that expires at midnight in a store whose time zone is not the server’s. Nobody had to guess where to look.
Let changes feed the list
When SpecTrail flags a merged change that alters behaviour, the card names the requirement that moved. If that requirement has few or no tests, the change gives you a test to write while the change is still fresh. The test list grows from what is actually changing in the product and not from a spreadsheet nobody updates.
As the team grows
The first QA engineer inherits something better than a blank page: a document that lists the behaviours, with the gaps marked. They can start testing from it on day one, and the work they do shows up in the same marks.
Related: how a small startup keeps track of its product · inherited codebases · onboarding new team members