Why we test: the test pyramid and types of testing
Testing is how a team finds out that the software works before customers do. Learn what bugs cost, the test pyramid, the main types of testing, and how this track fits together.
Imagine Brew & Bean, a coffee shop in Indiranagar, launches its pickup-order website on a Friday evening. A customer orders two cappuccinos and the page shows a total of ₹36 instead of ₹360. Another customer enters a phone number with 9 digits and the order silently disappears. Nobody notices until the shop owner sees angry reviews on Saturday.
Testing is the work of finding problems like these before real users do. It is not only about finding bugs. Good tests also tell you that a change you made today did not break something that worked yesterday.
Why testing matters
A bug is cheaper to fix the earlier you find it. A wrong price spotted while you are writing the function takes a minute to fix. The same bug found by a customer needs a support call, a hot-fix, a re-deploy and an apology.
Tests also give you confidence to change code. Without tests, every edit is a gamble, so teams become afraid to touch old code. With a good set of automated tests, you can refactor, upgrade a library or add a feature and know within minutes if something broke.
What tests give a team
| Question | Without tests | With tests |
|---|---|---|
| Did my change break anything? | Click through the whole app by hand | Run one command, wait a few minutes |
| Is the bug fixed for good? | Hope nobody re-introduces it | A test fails if it ever comes back |
| Can a new teammate change this code? | Scary, so they avoid it | They run the tests and see |
| How do we release? | Rarely, after long manual checks | Often, because checks are automatic |
Verification and validation
Two phrases appear in almost every testing textbook and interview.
Verification asks: did we build the product right? Does the code do what the specification says? For example, the spec says an order total is the sum of price times quantity, and the code does that.
Validation asks: did we build the right product? Does it solve the user's real problem? A perfectly coded order form is still the wrong product if customers actually wanted to pay with UPI and it only accepts cash on pickup.
Most of this track is about verification, which you can automate. Validation needs real users and good questions.
The test pyramid
Tests come in different sizes. A unit test checks one small function. An integration test checks that several parts work together, such as your API and its database. An end-to-end (E2E) test drives the whole app through a browser the way a user would.
The test pyramid is a rule of thumb for how many of each to write. Many fast, small tests at the bottom. Fewer, slower tests in the middle. A handful of slow, broad tests at the top.
The pyramid, from bottom to top
| Layer | What it checks | Speed | Cost to write and maintain | Typical tool |
|---|---|---|---|---|
| Unit (bottom) | One function or class, nothing else | Milliseconds | Low | pytest, Vitest, JUnit |
| Integration / API (middle) | Parts working together: API plus database, API plus another service | Seconds | Medium | pytest with a test client, Postman, Bruno |
| End to end (top) | The whole system through the real UI | Many seconds per test | High, and often flaky | Playwright, Cypress, Selenium |
Why a pyramid and not a rectangle? Because the higher you go, the slower the test, the more it breaks for reasons that are not real bugs (a slow network, a button that moved), and the harder it is to find out what went wrong. When a unit test fails, you know which function to look at. When an E2E test fails, the cause could be anywhere.
The opposite shape is called the ice-cream cone: very few unit tests and lots of manual or E2E checking. It is slow, expensive and a common problem in real teams. You will build the pyramid the right way up in this track.
Some teams prefer a 'testing trophy' with more integration tests in the middle, because integration tests often give the best confidence for the effort. The shapes differ, but the idea is the same: match the kind of test to the thing you are checking, and do not put everything at the slow top.
Types of testing
Testing can be described along two different lines. One is what level you test (unit, integration, system, as above). The other is what quality you test. The second list is long, but a handful of types cover most of your daily work.
Common types of testing
| Type | The question it answers | Brew & Bean example |
|---|---|---|
| Functional | Does it do what it should? | Ordering 2 espressos gives a total of ₹240 |
| Negative | Does it refuse bad input safely? | Quantity -1 returns an error, not a free coffee |
| Regression | Did an old feature break after a change? | After adding discounts, plain orders still total correctly |
| Smoke | Is the build alive at all? | GET /menu returns 200 after every deploy |
| Integration | Do the parts work together? | An order saved by the API can be read back from the database |
| Performance / load | Is it fast enough under many users? | 200 people order at 9 am during a cricket match |
| Security | Can someone abuse it? | Can one customer read another customer's order? |
| Usability | Is it easy for people to use? | Can a first-time user order in under a minute on a phone? |
| Exploratory | What surprises can a curious human find? | A tester tries odd names, emojis, double clicks |
Manual and automated testing
Manual testing means a person runs the checks and uses judgement. It is best for exploring new features, judging how something looks or feels, and one-off checks.
Automated testing means code runs the checks. It is best for anything you will repeat: regression checks, the same API call with 50 different inputs, running on every code push.
They are partners, not rivals. A common mistake is trying to automate everything. If a check runs once, or the feature changes weekly, automation may cost more than it saves. Automate what is stable, repeated and important.
Who tests what
In modern teams, developers write unit tests and many integration tests for their own code. QA engineers or SDETs (Software Development Engineers in Test) design the test strategy, write API and E2E automation, build test tooling and explore the product for risks. Quality is a team habit, not one person's job at the end.
How this track is organised
- 1Test by hand with curl, browser dev tools, Postman and Bruno so you understand what an API really does.
- 2Design good test cases so your tests find real bugs instead of repeating the happy path.
- 3Automate with pytest and Vitest, then API, mocking, integration and contract tests.
- 4Go beyond functional tests with Playwright for E2E, k6 for load and OWASP ZAP for security scans.
- 5Run it all in CI with GitHub Actions and plan a test strategy for a real project.
How this comes up in interviews
Common questions for QA and SDET roles: "What is the test pyramid and why is it a pyramid?", "What is the difference between verification and validation?", "Smoke vs sanity vs regression testing?", "What would you automate and what would you leave manual?", "How do you decide when to stop testing?" A good answer to the last one: you never prove there are no bugs. You stop when the risk that remains is acceptable for the release, based on what you covered and how important each area is.
Exhaustive testing is impossible
Testing can show that bugs exist. It can never prove there are none. If someone says 'we tested everything', ask what 'everything' means. For even a simple form, the number of possible inputs is effectively endless, which is why test design (a later lesson) matters.
Try it: Sort these checks into the pyramid
For a food-delivery app, decide for each check whether it is best as a unit test, an API/integration test, or an E2E test, and give one reason.
1. A function that applies a 10% coupon to a total. 2. Placing an order through POST /orders and reading it back with GET /orders/{id}. 3. A customer opens the site on a phone, adds a coffee to the cart, pays and sees the confirmation page. 4. A function that checks whether a phone number is 10 digits. 5. Confirming that a cancelled order is not shown on the kitchen screen.
Try it: Write a bug story
Pick any app you use daily (a UPI app, IRCTC, a food app). Write down one bug you have seen or can imagine, then decide: which type of testing would have caught it, at which layer of the pyramid, and could it be automated?
Key takeaways
- Testing finds problems before users do and gives you confidence to change code.
- Verification asks 'did we build it right?'; validation asks 'did we build the right thing?'.
- The test pyramid: many fast unit tests, fewer integration or API tests, a few slow end-to-end tests.
- Types of testing cover different qualities: functional, negative, regression, smoke, performance, security and more.
- Automate what is stable and repeated; keep human judgement for exploring and usability.
- You cannot prove there are no bugs, so testing is about managing risk.
Check yourself
Finishing the quiz marks the lesson as done.
1. Which layer of the test pyramid should have the most tests?
2. The spec says an order total must equal the sum of price times quantity, and a test confirms the code does this. Which activity is this?
3. After a deploy, a 30-second check confirms that GET /menu returns 200 and the home page loads. What is this?
4. Why are E2E tests kept to a small number?
5. Which check is the best candidate for automation?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.