Why is manual QA still part of the conversation when automation exists?
Automation is good at repetition. It struggles with subjective quality, like whether a page feels confusing or a message reads as hostile to a user.
Manual review fills that gap. It is slower but catches the kind of issues that automated scripts do not have criteria to flag.
What has shifted in how small teams run manual QA?
The biggest change is the availability of structured templates. Three years ago, most small businesses had no formal test documentation. Now, tools like Notion, Linear, and dedicated platforms like TestLodge offer ready-made test case structures that take minutes to adapt.
This means a non-technical business owner can build a repeatable QA process without hiring a specialist to design it from scratch.
How do I know which parts of my software need manual testing most?
Start with anything that touches money, user data, or external integrations. Payment flows, form submissions, and third-party API connections are where errors cause the most damage and are also where automated tests are most likely to miss context-specific failures.
A simple risk matrix, listing features by frequency of use and consequence of failure, helps prioritise where manual effort goes each cycle.
Is there a minimum viable QA process for a very small team?
A written checklist, one person responsible for running it before each release, and a log of what was tested and what was found. That is the floor.
It is not sophisticated, but it is far more effective than informal checking with no record of what was covered.