The short version
What is QA testing? Quality assurance testing is checking that software does what it's supposed to before customers find out it doesn't. That covers writing down what "supposed to" means, running through it, and deciding whether what you found is worth fixing now.
Who does it? On most teams, nobody whose job it is. Developers test their own work, a product person does a final pass before release, and support finds the rest. Teams with a dedicated QA function are the minority among the ones we talk to, and the ones who had one often lost it in a reorganisation.
Manual or automated? Both, and the honest split is that manual testing is for judgement – does this feel right, is this confusing, is this actually what the customer asked for – and automation is for repetition, which is where most of the hours go.
Where do I start? One flow. The one you'd cancel a release over. Get that checked automatically on every change, then add the next one. Teams that start by trying to cover the whole product stall in week three.
What is QA testing?
QA testing is the practice of establishing what your software is supposed to do, exercising it against that expectation, and deciding what to do about the difference. That's the whole job. The rest is detail about who does which part and how much of it a machine can handle.
It gets called quality assurance, but most of the day-to-day work is verification: does this flow still work, did that change break something else, is this error message the one we intended. Assurance – the part where you change how you build so fewer defects appear in the first place – is the more valuable half and the one teams reach last.
The reason any of it pays for itself is timing. A defect found while the change is still in review costs a conversation. The same defect found by a customer costs a support thread, a hotfix, a release out of cycle, and some amount of trust you don't get an invoice for. QA testing is the practice of moving discovery earlier.
QA testing vs. software testing
Software testing is the act of running the product to find out whether it works. QA is the wider system around that: what gets reviewed, what has to be true before you release, what runs automatically on every change, and who is accountable when something slips. On real engineering teams the two words get used interchangeably and it almost never causes a problem – if someone says "the QA is done", they mean somebody exercised the product.
Who actually does QA on your team
Every beginner guide on this subject describes an idealised QA function: a team, a test plan, a lifecycle with named phases. That is not what the teams we talk to have. Here is what they actually describe, in their own words.
"We don't have a QA team. It's the engineers to do their own testing locally. And then I would be the one to sort of test things as they go out… We have another gate where our support team kind of goes in and verifies things. That sometimes gets missed because support team are busy as well. So things happen. The gate is with me really, and sometimes things slip through as well." – a CPO at a US healthcare-software company
"The testers are developer testers, so it's not a separate position. We don't have dedicated testers. The developers are testing each other's work in a way." – an engineering lead at a European IoT company
"We're pretty small company. Eight people… we used to be two more developers, one more designer and a dedicated tester. So we had to scale down and now we're looking for getting a solution for replacing the tester that we used to have." – a product lead at a Norwegian software company
"I'm the director of product, so I do a lot of kind of the final testing before we get the sign off to go live." – a director of product at a US healthcare-software company
And what that feels like from the inside, before a release:
"When we tell her we are ready to release, she goes into the website, into the mobile application, and starts running the flows that she knows patients or providers are going to do. So you see, it's very, very suffering-focused." – a director of engineering, describing a colleague's release process
"It's ready for testing. I do testing. I find things. I send it back. Start over again. So this week is probably like the third time." – the colleague in question
Four shapes, then, and each one has a specific failure mode.
- Developers testing their own work. Fast, cheap, and blind in a predictable direction. As Vilhelm, our co-founder, puts it: "if you let developers do this, they inherently don't necessarily think about all the things that they could potentially break. There is some kind of inherent bias in letting developers test their own stuff." The bug you don't imagine is the bug you don't check for.
- One person as the human gate. Works well and scales to exactly one person's calendar. When they're busy, on holiday, or gone, the gate is open.
- A product owner doing the final pass. Excellent at judgement – is this what we meant – and structurally unable to cover the twenty flows nobody changed this sprint but might have broken anyway.
- Support as the last line. This is not a QA process. It's a customer-funded one, and the currency is goodwill.
None of these is wrong. They're what you get when quality isn't anybody's explicit job. Worth saying plainly, since we sell testing software: we don't necessarily have an army of QA checking our own application either, which is ironic in a way. The point isn't to hire a department. It's to make the routine part automatic so the human gate is spending its attention on the things only a human can judge.
There's a related reason AI-written code doesn't remove the need for this. Vilhelm again: "research has shown that AI is pretty good at fixing things and coding, but it's not really that good at finding bugs in the first place. And when you think about it, it's not that weird, because if you only look at the code, even as a developer, it's very hard to make sure that everything will function in the end, because there's so many components that come together."
What are the types of QA testing?
There are more than a dozen named types. Six matter when you're deciding where to spend the next month, and the column that's usually missing from lists like this is whether it's worth it yet.
| Type | What it checks | When it's worth it |
|---|---|---|
| Unit | One function or class in isolation | Always, and your developers are probably already doing it. Cheap to write, fast to run, and it never tells you whether the product works. |
| Integration | Two or more pieces working together, usually across a boundary like an API call | As soon as you have more than one service or a real database. This is where "both parts work, together they don't" gets caught. |
| End-to-end | A whole user journey through the real interface | First priority if you have customers. Expensive per test, and the only kind that fails for the same reasons your users do. End-to-end testing is where most customer-visible breakage lives. |
| Regression | That what worked last release still works | The moment you ship more than once a month. This is the work that eats the hours, which makes it the first thing to automate. See regression testing. |
| Exploratory | Whatever a person can think to try, without a script | Every release, in small doses. It finds the things no test case anticipated. Exploratory testing is judgement work and shouldn't be scripted away. |
| Performance, accessibility, security | Load behaviour, assistive-technology support, attack surface | When you have a specific obligation – a traffic spike you know is coming, a procurement requirement, a compliance audit. Specialist tools, specialist attention, and premature otherwise. |
Manual and automated aren't types – they're how you run any of the above, and the interesting question is which flows deserve which. That's the section further down.
What a QA process looks like when you have no process
The lifecycle diagram – requirements, planning, case design, execution, reporting – is real and no team in our call transcripts works that way. What they describe is this:
"My processes are all pretty manual today, just kind of getting it there, testing the normal path, the edge cases, basically trying to break it. And find anything on the front end, or experientially, that might be an issue before we go live." – a director of product at a US healthcare-software company
"With each PR, at least two people review the changes and the scope is more or less about the PR itself. We don't test everything. I guess I can say the team is relatively experienced and knows much about where to look at it. And they have a focused approach and it works for us." – an engineering lead at a European IoT company
"These testers are very experienced and high skilled persons, so they will apply their experience, skills and the speed of the testing process as well. Because they know each and everything inside the app, what is going on, where the bug might come." – a QA lead at an Indian edtech company
That last quote is the real point of this section. Most teams' QA process is one or two people's memory. It works, and it works well, right up until those people are busy, on holiday, or gone – and then the process leaves with them. That's the argument for writing things down, and it's a better argument than any diagram: not because documentation is virtuous, but because an undocumented process has a single point of failure and it's a person.
Writing it down also surfaces the anxiety that's already there:
"We need to know what we don't have." – a test manager at a UK fintech
"Right now, I have the suspicion that we're focusing so much in the good case, and we're skipping all the: what if the user does something unexpected?" – a director of engineering at a US healthcare-software company
Both of those are answerable once the flows exist as a list. Neither is answerable while they exist as intuition.
Test cases, without the ceremony
A test case is one sentence about one behaviour: the flow, the action, the expected result. "Auth – incorrect password returns an invalid login error" is a complete test case. Keep each one atomic, name the expected result in the title, include whatever login or data it needs, and write it so it survives the next release. That's the whole standard. Anything more elaborate is documentation you'll stop maintaining by the third sprint.
How QA testing fits into how you ship
Forget phases. In practice there are four moments where checking happens, and the useful exercise is deciding what belongs at each.
- While the change is being written. Unit and integration tests, run locally and on the branch. Fast, developer-owned, and the cheapest place to catch anything.
- On the pull request. The critical flows, on a preview or staging build of that specific change. This is the highest-leverage moment in the whole pipeline, and it's where teams that run E2E tests on every pull request stop shipping the obvious regressions.
- Before the release. A regression pass over what you didn't touch, plus a human looking at what you did. Deciding the scope of that pass is what testing strategies are for – which flows, how often, and what you're consciously choosing not to cover.
- After the release. The same critical flows against production, on a schedule, so you find out from a test rather than a customer.
If your team ships several times a week, the second and third moments are where the manual hours go, and they're the hours worth buying back.
How to start, if you're starting from nothing
This is the section nobody writes, and it's the one first-time buyers ask for directly:
"What we do today is mainly manual testing of our applications. And as a next step, definitely thinking about various ways of regression testing and automated testing… what we're looking for is essentially a support on that journey, right from manual testing towards more automated testing." – an engineering lead at a Swedish property-software company
"We develop a feature, we have good unit tests, but it's not enough. We have integration tests, but it's not enough. And then is there any solution in the market that can, with very low friction and very low maintenance, just test the full suite? I mean, that's a dream, I know." – a CTO at a French software company
Four weeks. This is our recommendation, not a customer's, and it assumes nothing except that you have a product in front of users.
- Week one: write down the flows you'd cancel a release over. Usually three to six. Sign up, log in, pay, the one thing your product is for. Not a test plan – a list.
- Week two: check them by hand, deliberately, and time it. You need the number, because it's the number that justifies everything after.
- Week three: automate the first one. One flow, running on every change. Not a suite. One. If you'd rather not hand-write it, you can generate test cases with AI from the flow description and correct what it gets wrong – that's usually faster than starting from an empty file.
- Week four: decide what a failure means. Who looks at it, how fast, and whether it blocks a release. A test nobody acts on is worse than no test, because it costs the same and teaches people to ignore red.
The honest caveat: this ordering assumes you have somewhere to run a change before customers see it. If you don't have a staging or preview environment, that comes first, and it's a bigger job than any of the four weeks above.
QA testing tools
Tool choice matters less than what you point the tool at, which is why it's the fourth decision here rather than the first. Broadly, three families:
- Code-first frameworks – Playwright, Cypress, Selenium. Full control, run anywhere, and you own every selector forever. The maintenance is the cost, and it grows with your release rate.
- Record-and-replay and no-code platforms. Fast to a first green test, and generally brittle in the same way scripted tests are, because underneath they're still scripts.
- Agentic platforms – including QA.tech. You describe the goal in plain language and an agent drives a real browser to reach it, deciding the steps as it goes.
We've written the comparisons out properly rather than repeating them here: the best AI testing tools covers the current field with what each one is actually for, and QA.tech compared with Cypress is the closest thing to a like-for-like if you already have a framework suite.
Manual, automated, and agentic testing
The three aren't a progression where each replaces the last. They're different answers to "who executes this, and how much judgement does it need".
Manual testing is a person exercising the product. It is the only approach that notices the thing nobody thought to specify – that the copy is confusing, that the flow technically works but nobody would finish it, that this isn't what the customer asked for. That work is not going away and there's arguably more of it now.
Automated testing is a script repeating a known check. It's ideal for regression work, and its weakness is structural: the script is tied to the shape of your interface, so a redesign breaks tests that were never wrong about the product.
Agentic testing gives an agent the goal instead of the steps. It crawls your application, works out the flows, and judges whether the outcome was right, which means a moved button or renamed field usually doesn't break anything. Being specific about the limit, because vague hedging isn't useful: as with any agentic tool it won't catch everything, but on the repetitive verification most teams are spending their release days on, it will get you a large majority of it – and if the simple checks stop consuming your QA time, that time goes to the complex cases that actually need a person.
There is no silver bullet, and we're not it either. It's a tool that takes over one part of this. If you want the longer version of how agents fit alongside the suite you already have, our AI QA testing guide covers it in depth.
Top QA testing practices
Four, not seven. These are the ones that survive contact with a team that's busy.
- Test the flows your product is for, not the code you happen to have covered. Vilhelm puts the failure mode better than we can paraphrase it: "it's easier than ever now to just generate a lot of test code, but unless you know what you're doing you're just doing more noise. Because you can have 10,000 tests but still have extremely bad products. They can all be green, but if they don't test what your users or your product really cares about, then you're not really testing anything." There are plenty of companies with a high coverage percentage and no idea whether they test what the user experiences – which is why 100% test coverage isn't the goal.
- Run the critical flows on every change, not before every release. A regression pass you do weekly tells you something broke sometime this week. One that runs on each pull request tells you which change did it.
- Keep a small amount of exploratory testing, deliberately. Half an hour of someone trying to break the new feature finds a class of bug no test case contains. Put it in the process so it isn't the thing that gets dropped.
- Decide what a red test means before you have one. Who triages, in what time, and whether it blocks the release. Suites die from unacted-on failures far more often than from bad tests.
Common questions
What is QA testing?
Checking that software behaves as intended before customers encounter it, and deciding what to do about the gaps. It includes defining what correct means, exercising the product against that, and judging severity. The name comes from "quality assurance", though most of the work is verification rather than assurance.
What is the difference between QA and testing?
Testing is running the product to find out whether it works. QA is the broader practice of making it likely to work – how changes get reviewed, what has to be true before a release, what gets checked automatically. In everyday usage on engineering teams the two words are used interchangeably, and it rarely causes confusion.
Do we need a dedicated QA person?
Not necessarily, and most teams we talk to don't have one. What you do need is for quality to be someone's explicit responsibility, because when it's everyone's it's nobody's. That can be an engineer with a defined remit, a product owner who owns the release gate, or tooling that makes the routine checking automatic. What doesn't work is assuming it's happening.
What are the main types of QA testing?
Unit tests check one function. Integration tests check that pieces work together. End-to-end tests check a whole user journey through the real interface. Regression tests re-check what already worked. Exploratory testing is a person deliberately trying to break things. Performance, accessibility and security testing are specialisms with their own tools. Most teams need end-to-end and regression coverage first, because that's where customer-visible breakage lives.
How do I start QA testing with no experience and no budget?
Write down the three to six flows you'd stop a release over. Check them by hand and time how long it takes. Automate the single most important one. Decide who acts on a failure. That order matters – teams that start by choosing a tool tend to end up with a tool and no idea what to point it at.
Is manual testing dead?
No. What's changing is which part of it is worth a person's time. Repeating the same regression pass every release is work software should do. Deciding whether a flow makes sense, whether an error message helps, or whether a feature actually solves the problem it was built for is judgement, and there's more of that work now, not less.
Can AI do QA testing?
It can do a growing share of the execution. An agent can drive a real browser, follow a plain-language goal, and judge whether the outcome was right, which covers most repetitive regression work. It cannot decide what matters, and it has no opinion on whether your product is any good. Treat it as capacity, not judgement.