Checking that software works before users get it, through a mix of automated tests and manual checking.
Why it exists
Shipping changes without checking them means users find the bugs, at the worst time and in public, and hoping it works is not a plan. QA and testing exist to verify that software does what it should before release, whether by people or automated checks, so problems are caught before customers hit them.
How it actually works
Testing comes in layers. Unit tests check tiny pieces in isolation. Integration tests check that pieces work together. End-to-end tests walk through whole user flows. Manual QA has a human try the product the way a user would. Each layer catches different problems.
Automated tests run constantly and cheaply (via CI); manual QA catches things automation misses, like whether something actually feels right. Together they're the safety net before release.
A senior PM walks you through it
A junior PM, stuck
The save delivery address change is up and Rafi says all tests pass, ship it, with a wall of green checks on the PR. Then Arif filed a bug against the same change. I cannot ship over QA, but I also cannot argue with a page full of passing tests, because I do not actually know what those tests checked.
Green does not mean tested, it means the cases we wrote passed. Those are not the same claim, and the gap between them is exactly where Arif's bug lives. This is the actual PR, the check summary and the QA comment, nothing paraphrased. Read it, then take the steps with me and you will see what the green never covered.
PR: Save delivery address, checks and QA
CI checks
Author: Rafi Status: all checks passed
unit tests: passed (142)
integration tests: passed (18)
end-to-end tests: passed (6)
Comments
Rafi All green. Ship it.
Arif (QA) Found a bug. On a slow network the save spinner never resolves and the address saves twice. None of the automated tests run on a throttled connection, they all pass on the fast CI box.
Click a step to see the lines it points at.
Mistakes I've seen
Reading a green checkmark as fully tested. It means the written cases passed on a fast machine, and the double-save on a slow network was never one of them.
Not asking what conditions the tests ran under. Network, device, and concurrency are exactly where automation on a clean CI box goes quiet, so that is where you probe.
Treating QA as a rubber stamp after CI is green. Manual QA exists to catch what automation cannot feel, and skipping it because the tests passed is how the slow-network bug reaches customers.
Shipping the moment checks go green without a real-device pass. The five minutes QA spends on a throttled connection is cheaper than the support wave from an address that silently saves twice.
Reply on the PR: "All three test layers are green, but they ran on a fast CI connection. Arif's slow-network bug is real and outside what they cover, so let's fix it and get a manual sign-off before we ship." You just separated the tests passed claim from the it works for every user claim, which is the whole reason QA and automation both exist.
Where a PM meets this
"How will we test this?" is a fair question during planning; hard-to-test features are riskier and slower.
No amount of testing catches everything, especially concurrency bugs like races; understanding the gaps sets realistic expectations.
Hear it in a meeting
"It passed automated tests but QA found the edge case on slow networks."