Types of Testing

How to read the rest of this lesson

There are dozens of named testing types, and different books slice them differently. Instead of a flat list, we group them by the question they answer:

1. Build health checks

Smoke testing

Smoke testingSmoke testingA quick check of the most important features to decide if a build is stable enough to test further.Open in glossary → is a quick, shallow pass over the most important flows of a new build. The name comes from hardware: you switch on a new circuit board, and if smoke comes out, there is no point testing further.

• When: every time a new build arrives, before any deeper testing. Usually 10 to 30 minutes.
• Goal: decide “go” or “no-go”. If login is broken, there’s no point running 300 test cases.
• Mobile example: install build 4.2.0 (311), open the app, log in, search for “pizza”, add one item, reach checkout.
• Web example: the home page loads, search returns results, a product can be added to the cart, login works.

A smoke test is broad (it touches many areas) but shallow (it doesn’t dig into any of them). Many teams automate it so it runs on every build. See Regression and Smoke Suites for building one.

Sanity testing

Sanity testingSanity testingA quick, focused check that a specific fix or change works and nothing obvious around it broke.Open in glossary → is a quick, narrow check of one area after a small change, to decide whether it is sensible to continue with deeper testing.

• When: after a small fix or tweak, often before a bigger regression run.
• Mobile example: the tip calculation changed. You quickly check 0%, 10%, 15% and a custom tip, and that the total updates.
• Web example: the currency formatter was patched. You check prices on the product, cart and checkout pages.

2. Change-related testing

These two are the bread and butter of a manual tester’s week, and they are often confused.

Retesting (confirmation testing)

RetestingRetestingRunning the same test again to confirm that a reported bug is really fixed.Open in glossary → means repeating the exact steps from a bug report on the new build, to confirm the bug is really fixed. ISTQB calls it confirmation testing.

• When: a developer marks a bug as fixed.
• How: same steps, same test data, same type of device or browser as the original report. Then note the build you verified on. See the bug life cycle.
• Example: BUG-207 said “Coupon SAVE10 applies twice on a quick double-click”. You double-click “Apply” on build 512 and check the total.

Regression testing

Regression testingRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → means re-checking things that used to work, to catch unwanted side effects of new changes. A “regression” is a feature going backwards.

• When: after any change, and always before a release. The bigger or riskier the change, the wider the regression run.
• Example: a developer changed the shared price-formatting code to fix the coupon bug. Now the cart total, order history, receipts and push notification texts all need checking, because they use the same code.

	Retesting	Regression testing
Question	Is this bug fixed?	Did anything else break?
Scope	One bug, exact steps	Areas that worked before
Planned in advance?	Steps come from the bug report	Usually a maintained test suite
Good for automation?	Rarely	Very often

3. Quality attributes

These are mostly non-functional. Some have their own lessons on Bugwise, so here is the short version of each.

Usability testing

Usability testingUsability testingChecking how easy and pleasant the product is for real people to use.Open in glossary → checks how easy, clear and pleasant the product is for real people. Formal usability studies watch real users try tasks; testers do lighter usability checks every day by asking “would a normal person understand this?”.

• Mobile example: five users try to reschedule a fitness class. Three can’t find the option, because it hides behind a long press.
• Web example: shoppers hesitate on checkout because “Continue” and “Place order” look identical.

Accessibility testing

Accessibility testingAccessibility testingChecking that people with disabilities can use the product, for example with a screen reader.Open in glossary → checks that people with disabilities can use the product: blind users with a screen reader, people who can’t use a mouse, people with low vision or color blindness. It is usually measured against WCAGWCAGThe Web Content Accessibility Guidelines, the main international standard for accessibility.Open in glossary →.

• Mobile example: with VoiceOver on, the “Transfer” button is read as just “button”.
• Web example: you can’t reach the cookie banner’s “Accept” button with the Tab key, so keyboard users are stuck.

Deep dive: Accessibility basics.

Compatibility testing (cross-browser, cross-device)

Compatibility testingCompatibility testingChecking the product works across different devices, OS versions, browsers and screen sizes.Open in glossary → checks the product works across the browsers, devices, OS versions and screen sizes your users actually have. On the web this is called cross-browser testingCross-browser testingChecking a website works and looks right in different browsers and browser versions.Open in glossary →; on mobile, cross-device testing against a device matrixDevice matrixThe list of devices and OS versions a team tests on, chosen to represent real users.Open in glossary →.

• Mobile example: the booking calendar is fine on iOS 18, but dates overlap on a small Android phone.
• Web example: the date field works in Chrome but shows a plain text box in an older Safari.

Deep dives: Cross-browser testing, Device fragmentation, Responsive design testing.

Localization and internationalization testing

Two related ideas, often shortened to L10n and i18n (the numbers count the letters in between):

• Internationalization (i18n) is how the product is built: ready for any language, long texts, right-to-left scripts, different currencies and date formats.
• Localization (L10n)LocalizationAdapting an app to a language and region, including translations, dates, currency and layout.Open in glossary → is adapting it to one specific market: German translations, euro prices, “14.10.2026” dates.

Testers check translations are present and correct, texts fit (German words are long), currencies and dates are formatted for the localeLocaleRegional settings that control language and formats for dates, numbers and currency.Open in glossary →, and Arabic or Hebrew layouts are mirrored. Deep dive: Localization and RTL.

• Mobile example: in German, “Add to basket” becomes “In den Warenkorb legen” and gets cut off.
• Web example: French users see “$1,299.00” instead of “1 299,00 €”.

Performance testing (and load and stress)

Performance testingPerformance testingChecking how fast, stable and responsive the software is under different loads.Open in glossary → checks speed and responsiveness. As a manual tester you notice slowness every day: a menu that takes 6 seconds on mobile data, a list that stutters when scrolling. Report it with numbers (device, network, seconds).

Two specialist forms are worth knowing by name:

• Load testing: does the system cope with the expected number of users, for example Black Friday traffic?
• Stress testing: what happens beyond that, and how does it fail and recover?

These need tools that simulate thousands of users, so they are usually done by performance engineers. Deep dive: Performance basics and Network conditions.

Security testing

Security testingSecurity testingChecking that data and features are protected from unauthorized access and attacks.Open in glossary → checks that data and accounts are protected from people who should not see or change them. Full penetration testing is a specialist job, but manual testers catch many security bugs with simple curiosity:

• Mobile example: after logging out, pressing Back shows the account balance again.
• Web example: changing /orders/1001 to /orders/1002 in the address bar shows another customer’s order.

Deep dive: Security basics.

4. Life on a real device

Installation and upgrade testing

Checks that the app installs cleanly, updates from older versions without losing data, and uninstalls properly. Upgrade testingUpgrade testingChecking that updating from an older app version keeps the user's data and settings working.Open in glossary → is the risky one: millions of users will update, and none of them want to lose their saved addresses or be logged out.

• Mobile example: updating from 3.9 to 4.0 logs everyone out and deletes saved delivery addresses.
• Web example: after a release, some users still get the old JavaScript from their cacheCacheStored copies of data or files that make apps and websites load faster.Open in glossary →, so the cart breaks until they refresh.

Deep dive: Install, update and uninstall.

Interruption testing

Checks how the app copes when something takes the user away mid-task: a phone call, an alarm, a notification, the screen locking, low battery, switching apps. See interruptionInterruptionAnything that takes the user away from the app mid-task: a call, an alarm, a notification, low battery.Open in glossary →.

• Mobile example: a call arrives during card payment. After the call the app shows a blank screen and the order is lost.
• Web example: the user switches tabs during a 3-D Secure check and comes back to “Session expired”.

Deep dives: Interruptions, Background and foreground.

5. Approaches and styles

These describe how you test rather than what you check. You can combine them with any type above.

Exploratory vs ad-hoc testing

Exploratory testingExploratory testingLearning, designing and running tests at the same time, guided by curiosity and a goal.Open in glossary → means learning the product, designing tests and running them at the same time. It is structured: you work to a goal (a charter, such as “Explore split-bill with odd amounts and people leaving the group”), in a time box (say 60 minutes), and you take notes of what you tried and found. See Exploratory Testing.

Ad-hoc testingAd hoc testingInformal testing with no plan or documentation, trying things to see what breaks.Open in glossary → is the informal cousin: unplanned, undocumented “let me try this” testing based on intuition. It finds bugs too, but nobody can repeat or review what you covered.

	Exploratory	Ad-hoc
Goal	A written charter	None, just curiosity
Time	Time-boxed session	Whenever
Notes	Yes, what was covered and found	Usually none
Repeatable	Mostly	No

Positive vs negative testing

• Positive testingPositive testingTesting with valid input to confirm the software works as expected.Open in glossary → uses valid input and expects success: transfer $50 to a saved payee.
• Negative testingNegative testingTesting with invalid or unexpected input to check the software handles it gracefully.Open in glossary → uses invalid or unexpected input and expects a clear, safe error: transfer -$50, $0, letters, or more than the balance.

Beginners often write only positive tests. Real users mistype, paste, double-tap and lose signal, so most bugs hide on the negative side. See Writing test cases and the Text field page for practice.

Manual vs automated testing

Manual testing: a person runs the checks. Automated testing: scripts run them. Almost every type above can be done either way, but each suits some types better:

Often automated	Usually manual
Smoke tests on every build	Exploratory testing
Large regression suites	Usability and look-and-feel
Load and stress tests	New features still changing
Running the same checks on 20 devices	Interruptions and real-world device quirks

More in What is software testing?.

Putting it together: a typical release

Here is how the types usually line up in a two-week release of a mobile app:

To see where these activities sit in the bigger process, read SDLC and STLC.