Smoke, sanity, regression, and the rest: types of software testing with real Indian examples

Every QA interview asks: what is the difference between smoke and sanity testing? Most candidates give a textbook line they have memorised. Here is what these terms actually mean on a working team, with examples from UPI, IRCTC, and Swiggy that anyone in India can picture immediately.

Smoke testing

Smoke testing answers one question: is this build alive at all? It is the first test that runs after a deploy, takes 60 seconds, and either green-lights the rest of the test cycle or sends the build back. The name comes from hardware: power on the device, if smoke comes out, do not bother running the full diagnostic.

Example. A typical UPI app smoke pack: the app opens, the user can log in, the home screen loads with a balance, and one rupee can be sent to a saved contact. If any of those four steps fail, the entire QA team stops and asks for a new build.

Sanity testing

Sanity testing is narrow and focused. A bug was fixed in the coupon engine. Sanity testing checks that the specific scenarios the fix targeted now work, plus a few obvious sibling cases. Sanity is shallow and quick. Regression is broad and deep. They are not the same thing.

Example. Swiggy fixes a bug where the FRESH50 coupon was applying to non-eligible categories. The sanity pack runs FRESH50 on eligible items (works), on non-eligible items (rejected), and on items at the boundary like promotional combos. Five minutes, you ship.

Regression testing

Regression testing makes sure that yesterday's code did not break today's features. It is the test suite that runs on every commit, every nightly build, every release candidate. The bigger the product, the bigger the regression pack.

Example.IRCTC's Tatkal flow is the highest-stakes regression target on the site. The booking window opens at 10:00 a.m. for AC and 11:00 a.m. for non-AC, and a 0.3-second regression in the payment step on that day is catastrophic. So the regression pack rehearses the full flow: search, select train, fill passenger details, hit payment, receive confirmation, get PNR. Every release.

Black-box, white-box, grey-box

These three describe how much the tester knows about the internals.

• Black-box testing. The tester treats the system as a sealed box. They know inputs and expected outputs, nothing else. Most manual testing is black-box. So is most end-to-end automation.
• White-box testing. The tester reads the code and writes tests that exercise specific branches, loops, and edge conditions. Unit tests written by developers are white-box.
• Grey-box testing. Somewhere between. The tester has access to the database, logs, and architecture diagram, but is not reading code line by line. Most senior QA engineers work in grey-box mode every day.

Example.Testing UPI's collect-request flow:

• Black-box: send a request, see the notification, accept it, money moves.
• White-box: write a unit test for the function that validates the VPA format and rejects malformed handles like rahul@upi#.
• Grey-box: send a request, then query the database to confirm the row in upi_collect_requests has state='pending' and expires_at is roughly 30 minutes in the future.

Functional vs non-functional

Functional testing asks: does this feature do what the spec says? Non-functional testing asks: does it do it fast enough, for enough users, without falling over?

Levels of testing: unit, integration, system, acceptance

These four are the “V-model” levels, named for what is under test rather than how it is tested.

• Unit testing. One function, one class, in isolation. Mocks out everything around it. A pricing function gets 30 unit tests covering edge cases.
• Integration testing. Two or more components talking to each other. The pricing service talks to the inventory service. The login service talks to the OTP provider.
• System testing. The full stack, end to end. Open the IRCTC app, book a ticket, complete payment, see PNR.
• Acceptance testing (UAT).The business confirms the system does what they paid for. A bank's compliance team runs through audited test scenarios before giving sign-off.

Exploratory testing

Exploratory testing is not random clicking. A skilled exploratory tester runs sessions with a charter: “explore the checkout for 90 minutes, focus on coupon edge cases.” They take notes, file bugs, and the post-session report goes to the dev team.

Automation cannot replace exploratory testing. Automation runs the same path every time. Exploratory testing finds the path nobody thought of.

Ad-hoc testing

Ad-hoc is exploratory without the charter, without the notes, and usually without the discipline. Useful for 15 minutes of kicking the tyres on a new build. Not a substitute for either regression or exploratory testing.

Alpha and beta testing

• Alpha. Inside the building. The product team, QA, and a handful of friendly internal users try the build before it leaves the company.
• Beta. Outside the building. A small slice of real users gets the build before general release. Most app stores let you ship a beta channel separately.

Visual regression testing

A relatively new category. Tools like Percy, Chromatic, and Applitools take a screenshot of every page on every commit and flag pixel diffs. Catches the CSS regression that breaks the Pay button layout on the day of a marketing push. Worth its weight on consumer apps.

Contract testing

When two services talk over an API, contract testing verifies that the producer keeps the promise the consumer relies on. Tools like Pact let the consumer publish what it expects, and the producer's CI runs those expectations on every commit. Microservices teams that adopt this catch breaking changes before they reach staging.

Quick reference table

Closing

These categories overlap. A single test can be a regression test and a smoke test and an automated black-box system test all at once. The labels matter because they tell you when to run the test, who maintains it, and what budget it earns.

We teach every one of these in our Pro Software Testing program, with hands-on labs against real Indian apps. If you prefer to read first, the test case writing guide is the natural next step.