Ask Your Dev Team about manual QA

Manual quality assurance gives a person time to use your software with intent, judgment, and context. It complements automated testing by noticing problems that aren’t well expressed as repeatable code checks.

You want both. Automation is excellent at rerunning known checks consistently. A person can question whether a workflow makes sense, recognize confusing feedback, and explore an unexpected path.

What a person sees differently

Consider a hotel booking flow. Automated tests can verify that available rooms appear, a valid card is accepted, and a confirmation record is created.

A human tester may notice that the cancellation policy is hidden until after payment, the date picker is awkward on a phone, or the confirmation screen makes it unclear whether breakfast was included. The software may satisfy its programmed checks and still create support calls or abandoned bookings.

Manual QA is especially valuable for:

• New or substantially changed customer journeys
• Visual behavior across screen sizes and browsers
• Copy, feedback, and error messages
• Accessibility checks that require context and judgment
• Exploratory testing around unfamiliar risks
• Realistic workflows that cross software and human operations

This isn’t random clicking. A thoughtful tester works from product risks and expected behavior, records what they tried, and provides enough evidence for someone else to investigate.

Accessibility is a good example of the boundary, and an important place to be precise. The W3C’s Web Accessibility Initiative explains that no evaluation tool alone can determine whether a site is accessible. Knowledgeable human evaluation is required.

That doesn’t mean any manual tester can certify accessibility. A general QA pass may catch a missing keyboard focus indicator or a confusing form label. A serious accessibility evaluation also needs people who understand relevant standards, assistive technologies, and disability barriers. W3C further recommends combining evaluation with input from users with disabilities, while cautioning that user testing alone doesn’t establish conformance.

Decide where human attention is worth the cost

Manual testing takes time each time it is performed. That makes it poorly suited to every repetitive check in every release. If the same stable scenario must be verified constantly and can be expressed reliably in code, it may be a good candidate for automation.

Human attention belongs where context changes, the cost of confusion is high, or the team is still learning what can go wrong. A payment flow deserves more deliberate coverage than a low-traffic informational page. A small internal tool may need less device coverage than a public consumer product.

The mix should reflect your risks, users, budget, and release pace. “We test everything manually” can become slow and inconsistent. “The automated suite passed” doesn’t prove the experience is ready for a person.

Keep QA independent enough to challenge the work

Developers should test what they build, but familiarity creates blind spots. Someone approaching the change from the user’s perspective can challenge assumptions the builder no longer sees.

That person doesn’t always need a dedicated QA title. On a small team, it might be another developer, a product owner, or a knowledgeable stakeholder following a clear review plan. What matters is that the release receives a fresh look, the reviewer has the expertise the check requires, and concerns can stop or change it.

Issue 11 introduced the broader testing strategy. Manual QA should fit that strategy rather than appear as a final scramble before launch.

Ask how a release earns confidence

1. “Which parts of this change will a person test, and why those parts?” Look for risk-based choices.
2. “What devices, roles, data states, and workflows are in scope?” The plan should resemble real use.
3. “Who performs the review, what expertise does it require, and can they stop the release?” Responsibility without skill or authority is weak protection.
4. “How are findings recorded and retested?” A chat message isn’t a durable QA record.
5. “Which repeated checks should become automated?” The balance should evolve as the product matures.

Use manual QA where judgment can change the outcome. That is the role I expect it to play at Cuttlesoft, alongside automation and specialist evaluation where the risk calls for it.

Go build something and expect better from your developer.