In the previous lesson you learned when testing happens (levels). This lesson covers what kind of testing is performed. Testing types are grouped by the objective of the test. Questions such as "What is the difference between smoke and sanity testing?" and "Regression vs retesting?" appear in almost every manual testing interview, so pay special attention to the comparison tables.
Functional vs Non-Functional Testing
| Aspect | Functional testing | Non-functional testing |
|---|---|---|
| Question | What does the system do? | How well does the system do it? |
| Based on | Functional requirements and business rules | Quality attributes such as speed, security, usability |
| Example | Applying a valid coupon reduces the cart total by 10% | The cart page loads within 2 seconds for 10,000 concurrent users |
| Execution | Mostly manual or automated functional tests | Often needs specialised tools (for example, JMeter for load) |
Smoke Testing vs Sanity Testing
Smoke testing is a quick, broad check of the most critical functions to decide whether a new build is stable enough for detailed testing. The name comes from hardware testing: switch on the device and see if smoke comes out. Sanity testing is a quick, narrow and deep check of a specific feature or bug fix to confirm it works and is rational before spending effort on further testing.
| Smoke testing | Sanity testing |
|---|---|
| Wide and shallow: covers all major features briefly | Narrow and deep: focuses on specific changed areas |
| Done on every new build | Done on a relatively stable build after minor changes or fixes |
| Checks build stability ("Is it testable?") | Checks rationality of a change ("Does this fix make sense?") |
| Usually scripted and often automated | Usually unscripted |
| Example: app launches, login works, search returns results, checkout opens | Example: after a fix to the coupon module, check coupon application and cart total only |
Some companies use "smoke" and "sanity" interchangeably. In an interview, give the standard distinction above, and add that terminology can vary between organisations.
Regression Testing vs Retesting
Retesting (also called confirmation testing) means re-running the exact test that failed, after the developer fixes the defect, to confirm the fix works. Regression testing means re-running previously passed tests on unchanged areas to make sure the new code or fix has not broken existing functionality.
| Retesting | Regression testing |
|---|---|
| Verifies a specific defect is fixed | Verifies nothing else broke because of changes |
| Runs failed test cases | Runs previously passed test cases |
| Planned per defect | Planned per build or release |
| Cannot usually be automated in advance, since it targets a new failure | Excellent candidate for automation because it is repeated often |
| Example: verify "OTP not received" bug is fixed | Example: after the OTP fix, re-check login, password reset and payment authentication |
Exploratory, Ad-hoc and Monkey Testing
| Type | Description | Planning and documentation |
|---|---|---|
| Exploratory testing | Simultaneous learning, test design and execution. The tester explores the app guided by a goal (a "charter"), such as "Explore the refund flow for partially cancelled bookings for 60 minutes". | Time-boxed sessions with a charter; findings and notes are recorded |
| Ad-hoc testing | Informal, unplanned testing without documentation, relying on the tester's experience and intuition to find defects quickly. | No formal plan or test cases |
| Monkey testing | Random inputs, clicks and gestures to see if the application crashes. Can be done manually or with tools that generate random events on mobile apps. | None; random by nature |
Exploratory testing is especially valuable when requirements are thin, time is short, or you want to find defects that scripted test cases miss. It is a skilled, structured activity, not random clicking.
Non-Functional Testing Basics
Performance testing
Performance testing measures speed, responsiveness and stability under workload. Common sub-types:
- Load testing: behaviour under expected user load, for example 20,000 users booking tickets at the same time.
- Stress testing: behaviour beyond normal capacity to find the breaking point and check recovery.
- Spike testing: sudden large increases in load, such as a flash sale starting at midnight.
- Endurance (soak) testing: sustained load over many hours to detect memory leaks.
- Volume testing: behaviour with large amounts of data, such as an account with 50,000 transactions.
Usability testing
Checks how easy and intuitive the application is for real users: clear labels, logical navigation, readable fonts, helpful error messages, and minimal steps to complete a task. Accessibility testing is related and ensures people with disabilities can use the app, for example with screen readers.
Security testing
Ensures that data and functions are protected from unauthorised access. Basic checks a manual tester can perform include:
- Authentication: wrong passwords are rejected and accounts lock after repeated failures.
- Authorisation: a normal user cannot open admin pages by changing the URL.
- Session management: the session expires after inactivity and logout truly ends the session.
- Data protection: sensitive data such as card numbers is masked on screen.
- Input validation: fields reject script tags and SQL-like input.
Compatibility testing
Checks that the application works across browsers (Chrome, Firefox, Safari, Edge), operating systems, devices, screen sizes and network conditions. In India this often means testing on budget Android phones with smaller screens and slower networks, not only on the latest flagship devices.
A new build of a food delivery app arrives. The tester runs a smoke test, retests three fixed bugs, runs a regression suite for ordering and payment, does a 45-minute exploratory session on the new "schedule order" feature, and checks it on four Android devices for compatibility.
When comparing two types, always give one realistic example for each. Examples prove you have understood the concept, not just memorised definitions.
