# QA testing

QA (quality assurance) testing is the work of checking that software does what it should before people rely on it, through automated tests that run on every change and manual testing of real flows on real devices.

Also called: Quality assurance, Software testing, QA, Automated testing, Regression testing.

## In short

- QA combines **automated tests** that run on every change with **manual testing** by people.
- Test the critical workflow most. A bug in sign-up or payment costs more than one in settings.
- Every bug found before launch is cheaper to fix than the same bug found by a customer.
- Testing is part of building, not a phase at the end. Ask how a team does it before you hire them.

## What QA testing covers

Quality assurance is everything a team does to make sure software works: that features behave as specified, that new changes do not break old ones, and that the product holds up on the devices, browsers, and connections real people use. Testing is the largest part of it.

QA is different from [usability testing](https://www.choie.co/glossary/usability-testing). QA asks whether the product works as built. Usability testing asks whether people can use it. A form can pass every QA check and still confuse everyone who fills it in.

## The main kinds of tests

**Diagram: The testing pyramid.**

- Manual testing (People trying real flows on devices)
- End-to-end tests (Whole flows, automated in a browser)
- Integration tests (Parts working together)
- Unit tests (Small pieces of logic, many and fast)

_Many fast tests at the bottom, fewer slow ones at the top. End-to-end tests on the critical workflow give an early product the most confidence per hour._

| Type | What it checks | Example |
| --- | --- | --- |
| Unit | One function or component on its own | Price calculation adds tax correctly |
| Integration | Parts working together | Saving an order writes the right database records |
| End-to-end | A whole flow, as a user would do it | Sign up, create a project, invite a teammate |
| Regression | Old features still work after changes | The full suite run before each release |
| Manual and exploratory | What automation misses | Trying odd inputs on a slow phone |

## How much testing an early product needs

Not every line needs a test, and an [MVP](https://www.choie.co/glossary/mvp) that changes weekly can waste time on tests for code that will be rewritten. The right amount follows risk: the more it costs when something breaks, the more it deserves a test.

- **Always test the money and the data.** Payments, permissions, and anything that could lose or expose user data.
- **Automate the critical workflow end to end.** If the core flow breaks, you want to know before users do.
- **Run tests on every change.** Continuous integration runs the suite automatically when code is pushed, so problems surface within minutes.
- **Test on real devices before release.** At least one recent iPhone, one mid-range Android phone, and the main desktop browsers.
- **Include accessibility checks.** Automated scans plus a keyboard pass catch common [web accessibility](https://www.choie.co/glossary/web-accessibility) issues.

> **Write a test for every bug.** When a bug is fixed, add a test that would have caught it. The same bug then cannot quietly return.

## QA when code is written with AI

With [AI-assisted development](https://www.choie.co/glossary/ai-assisted-development), code is produced faster, which makes checking it more important, not less. AI tools can write tests too, but a person still has to decide what needs testing and judge whether the tests check the right thing. Code that is generated quickly and never tested is a common source of [technical debt](https://www.choie.co/glossary/technical-debt).

At Choie, AI drafts implementation from a decided design and proposes tests. A senior person reads every line before it ships, and generated code that nobody understands is not merged. The [AI-accelerated development guide](https://www.choie.co/guides/ai-accelerated-development) covers how that works.

## Common mistakes

- **Leaving testing to the end.** A week of QA after months of building finds problems too late to fix well. A Choie build puts a new live link in the founder's hands every Friday, so working software is in use from the first week.
- **Testing only the happy path.** Empty states, errors, slow networks, and expired sessions are where real users get stuck.
- **Only testing on the developer's machine.** A fast laptop on office Wi-Fi hides problems that phones on mobile data reveal.
- **Tests nobody runs.** A suite that is not run automatically on every change slowly stops being trusted.

## Common questions

### What does QA stand for?

Quality assurance. In software, it covers the practices and testing used to make sure a product works correctly and reliably before and after it is released.

### What is the difference between QA and usability testing?

QA checks whether the software works as intended, such as whether a payment goes through. Usability testing checks whether people can figure out how to use it. A product needs both.

### Do I need a separate QA team?

Not for an early product. Developers can write automated tests and a founder or designer can do manual passes. Dedicated QA people become valuable as the product and team grow. Choie also fixes defects in its own work at no charge for 30 days after launch, while real use is still turning up what testing missed.

### What is regression testing?

Rerunning existing tests after a change to make sure features that used to work still do. Automated test suites make regression testing fast enough to run on every change.

Related: [Usability testing](https://www.choie.co/glossary/usability-testing), [Technical debt](https://www.choie.co/glossary/technical-debt), [Web accessibility (WCAG)](https://www.choie.co/glossary/web-accessibility), [AI-assisted development](https://www.choie.co/glossary/ai-assisted-development), [Minimum viable product (MVP)](https://www.choie.co/glossary/mvp).

HTML: https://www.choie.co/glossary/qa-testing