What does quality assurance and testing actually involve?

Most founders think QA is a final checkbox, a last pass before the app goes live. That framing explains why so many apps ship with broken checkout flows, missing error messages, and features that only work on one browser.

Quality assurance is not a stage at the end of development. It is a process woven through every week of the build, and the difference between teams that do it well and teams that bolt it on at the end shows up in your user reviews within days of launch.

The IBM Systems Sciences Institute found that fixing a bug after release costs 4–5x more than fixing the same bug during development. Catch a broken login flow in week two of the build: two hours of work. Catch it after 10,000 users have signed up: two hours to fix plus a support inbox full of complaints, a trust problem, and a scramble to figure out how many people gave up and never came back.

QA starts before a single line of code is written. Before development begins, the QA process defines what "done" actually means for each feature: what a login screen should do, what happens when someone enters the wrong password, what the app should show if the internet drops mid-checkout. Without those definitions written down, developers build against their own assumptions and testers check against theirs. The gap between those two assumptions is where most bugs live.

Once development is underway, testing runs in parallel with building. As each feature gets completed, it goes into a testing environment. The QA team checks it against the original definition of done, logs anything that does not match, and the developer fixes it before moving on to the next feature. This cycle repeats every few days rather than waiting until the entire app is finished.

The final phase before launch is a complete end-to-end pass, where a tester walks through the product as a real user would, following complete workflows rather than isolated features. Sign up, verify your email, complete a purchase, get a confirmation, log back in, find your order history. That top-to-bottom journey often reveals bugs that feature-level testing misses entirely.

According to a 2022 Capers Jones study, teams that integrate testing throughout development ship with 40% fewer defects than teams that test only at the end. The cost difference is significant enough that continuous QA pays for itself even on small projects.

Manual testing is a human sitting in front of the app and using it the way a real person would. A tester clicks buttons, fills in forms, tries to break things on purpose, tests on different phones and screen sizes, and notices when something looks wrong even if it technically works. Manual testing catches visual problems, confusing flows, and the category of bugs that only surface when a human does something unexpected.

Automated testing is a set of scripts that check the app's behavior by running through predefined steps without any human involvement. A script might log in with a test account, add three items to a cart, apply a discount code, and verify that the total comes out correctly. That script can run in about 30 seconds. A human doing the same check every time a developer pushes a change would take 15 minutes. For an app with hundreds of features, the math becomes obvious quickly.

The practical difference for a founder: automated tests are fast, consistent, and run constantly. They catch regressions, situations where a change to one part of the app accidentally breaks something else. Manual testing is slower but finds things automated scripts cannot: that a button is nearly invisible on a white background, that a form is technically submitting but the confirmation message sounds like it was written by a robot, that a checkout flow works but feels confusing.

Google's 2019 testing research found development teams with strong automated test coverage spend 15% less time fixing bugs overall, because the automated suite catches regressions immediately instead of letting them accumulate.

The clearest way to understand this is by what each method is designed to find.

Automated testing excels at catching anything that can be expressed as a rule: "if a user enters this, the result should be that." It is the right tool for checking that calculations are correct, that data saves and retrieves properly, that the same workflow produces the same result whether a user runs it at 2 PM or 2 AM, and that a new code change did not break something that worked yesterday. Automated tests run every time the code changes, often within minutes, which means regressions get caught before they reach users.

Manual testing catches what automated scripts cannot predict. A screen that works correctly but looks broken on a small phone. A form that submits fine but takes eight seconds, and nobody thought to measure it. A flow that technically completes but leaves users confused about what just happened. Accessibility issues that affect users with visual impairments. The interaction between two features that each work fine in isolation but conflict when used together in a single session.

The NIST Software Assurance Metrics and Tool Evaluation project found that automated testing catches roughly 70% of functional bugs. Manual testing finds the majority of usability and visual defects that automated tools miss entirely. Neither method alone catches everything.

A well-run QA process uses both. Automated tests handle the constant regression checking. Manual testers focus their time on flows and experiences that require human judgment.

There is no perfect answer, but there is a useful frame: test every path a paying user is likely to take before they take it.

For most products, that means three categories of workflows get tested completely before launch. The signup and login flow is the most obvious. If a user cannot get into your product, nothing else matters. Payment and checkout flows are next. A broken payment flow is not a minor bug; it is revenue disappearing silently. Then any core feature that the product exists to deliver, if you are building a scheduling app, the process of actually booking a slot must work on every major device and browser before launch.

Everything else can be tested at a slightly lower level of completeness. Edge cases that affect a small percentage of users, features that are nice-to-have rather than core, admin tools that only your team uses: these can ship with lighter coverage and be tightened up after launch.

A 2021 SmartBear survey of 600 software teams found that teams who achieved 75–80% test coverage on critical paths reported 85–90% fewer critical bugs in production compared to teams with informal or manual-only QA. The return on investment drops steeply above that threshold. Testing every possible edge case in every possible order adds cost without proportional benefit for most products at the MVP stage.

The practical rule: test what breaks the business if it fails. Test it thoroughly. Test everything else adequately. Ship and iterate.

Small teams often skip QA because it sounds like a large-team luxury. In practice, a lean QA process that covers the important ground costs less than most founders expect.

At Timespade, QA runs throughout the build rather than at the end. As each feature gets built, automated tests are written alongside the code, checking that the feature works as specified. By the time the project reaches the final week, there is already a suite of automated checks running on every change. The final week adds a structured manual pass by a dedicated QA tester who focuses on real user workflows and device-specific issues.

For a product with 5–10 core features, that approach catches most critical issues without requiring a separate QA team of three people doing nothing else. AI tools have made this faster: generating the initial automated test scripts now takes a fraction of the time it did two years ago, compressing what used to be several days of setup into hours. A login system that needed half a day of manual test script writing in 2021 gets its initial test suite in under an hour now.

The coverage that matters for a standard launch includes three things. Every form that accepts user input gets tested with both correct and incorrect data, to confirm the app handles errors clearly. Every critical workflow gets walked through on at least two different devices (typically iPhone and Android, or Chrome and Safari for web). And the automated test suite gets a full run before anything goes to production, so regressions surface in the development environment rather than in front of users.

The cost of skipping this is specific. The IBM data on post-release bug fixes (4–5x the cost) is the clearest argument. But the less-cited cost is the founder's time. Every hour spent fielding support tickets about a broken feature, diagnosing issues in production, and deciding whether to push a hotfix is an hour not spent on sales, fundraising, or building the next feature. For a non-technical founder, post-launch bugs are expensive in ways that do not show up on an invoice.

A QA process built into development from day one costs roughly 15–20% of total development time. That investment returns itself within weeks for any product that real users are paying to use.

If you are planning a product and want to understand what a thorough, lean QA process would look like for your specific scope, Book a free discovery call.