Testing has a lot of jargon, and the terms often get mixed up, even inside software teams. This guide explains the basics in plain English. For the different types of testing, we'll use one running example everyone knows: a restaurant getting ready to open.
The basics
1. What is software testing?
Software testing is checking that an app or website does what it should, and finding problems before your customers do. It covers more than "does the button work": it also checks that the product is easy to use, fast enough, secure and works on the devices your customers use.
2. Is QA the same as testing?
Not quite. Testing is the activity of checking the product. Quality assurance (QA) is the bigger picture: the habits and processes that prevent bugs in the first place, like clear requirements, code reviews and testing early. Testing is one part of QA.
3. What is a bug?
A bug (or defect) is anything in the product that doesn't work as it should or as users reasonably expect. In testing terms, a person makes an error, which creates a defect in the code, which may cause a failure that users see. Not every defect causes a failure straight away, which is why some bugs stay hidden for months.
4. What is a test case?
A test case is a written check: the steps to follow, the data to use and the result you expect. For example: "Add one item to the cart, apply code SAVE10, and the total should drop by 10%." Good test cases are clear enough that anyone on the team could run them and get the same answer.
5. What is a test plan?
A test plan describes what will be tested, what won't, how, by whom and when. For a small website it can be one page. Its real value is agreeing on scope and risks before testing starts, so nothing important is assumed.
Verification and validation
6. What is verification?
Verification asks: "Are we building the product right?" It checks the work against the requirements, designs and specifications. Reviewing a design, checking a form against the spec and code reviews are all verification.
7. What is validation?
Validation asks: "Are we building the right product?" It checks that the product actually meets the user's real needs. User acceptance testing and watching real users try the product are validation.
8. What's the difference between verification and validation?
Analogy: a customer orders a vegetarian pasta. Verification is the chef checking the dish against the recipe: right pasta, right sauce, right portion. Validation is checking it's what the customer actually wanted. If the recipe accidentally includes bacon, the dish passes verification but fails validation.
You need both. A product can match every line of the spec and still not solve the user's problem, and a spec can be wrong.
Types of testing, explained with a restaurant
9. What is unit testing?
Developers test the smallest pieces of code on their own, like a single function that calculates tax.
Analogy: checking each ingredient before cooking. Is the milk fresh? Is the flour the right type?
10. What is smoke testing?
A quick check of the most important functions right after a new build or release, to decide whether it's stable enough to test further. The name comes from hardware: switch it on and see if smoke comes out.
Analogy: before opening, the manager checks the lights turn on, the stoves light, the fridge is cold and the door unlocks. If the stove won't light, there's no point tasting the menu yet.
11. What is sanity testing?
A quick, focused check that one specific fix or small change works, before spending time on wider testing.
Analogy: the repair person fixes the oven, so the chef bakes one tray of bread to confirm it heats properly.
12. What is functional testing?
Checking that each feature does what it's supposed to do: login works, search returns the right results, the contact form sends.
Analogy: tasting each dish to confirm it matches the menu description. The "spicy chicken" is chicken, and it's spicy.
13. What is integration testing?
Checking that separate parts work together correctly, for example your website and your payment provider, or your booking form and your calendar.
Analogy: the waiter takes an order and the kitchen receives exactly that order. Each side may work fine alone, but the bug is in the hand-over: "no onions" gets lost between the table and the kitchen.
14. What is regression testing?
Re-testing things that already worked after a change, to make sure the change didn't break them. This is where automated tests save the most time.
Analogy: the chef changes the house tomato sauce. The new pasta is great, but the pizza and the lasagne use the same sauce, so those need tasting again too.
15. What is end-to-end (E2E) testing?
Testing a complete user journey from start to finish, the way a real customer would: find a product, add it to the cart, pay, get the confirmation email.
Analogy: a mystery diner books a table online, arrives, orders, eats, pays and leaves a review. If any step fails, the whole experience fails, even if every station passed its own checks.
16. What is user acceptance testing (UAT)?
The client or real users try the product to confirm it meets their needs before it goes live. It's validation in practice.
Analogy: the couple taste the menu at a tasting session before their wedding. The kitchen is happy with it, but the couple decide whether it's what they want.
17. What is exploratory testing?
Learning the product and testing it at the same time, guided by experience and curiosity instead of a fixed script. It's how testers find the bugs nobody thought to write a test for. We wrote more about it in 10 things AI still can't do in exploratory testing.
Analogy: a food critic who asks for substitutions, orders the odd combinations and visits at closing time, just to see what happens.
18. What is performance (load) testing?
Checking how fast and stable the product is when many people use it at once, and finding the point where it slows down or breaks.
Analogy: simulating a Friday-night rush. The kitchen handles 10 orders easily, but what happens at 100 orders in 15 minutes?
In practice
19. Manual or automated testing: which is better?
Both, for different jobs. Automated tests are best for checks you repeat often, like regression tests and monitoring key journeys every day. Manual testing is best for new features, usability and exploratory testing, where human judgment matters. A good rule: automate what's stable and repeated, test by hand what's new or needs a human eye.
20. How much testing does a small website need before launch?
Less than you might think, if it's focused. Before launch, check at least:
- the main journeys end to end (contact form, checkout or booking)
- the site on real phones as well as desktop browsers
- broken links, missing images and page titles
- speed on a mobile connection
- basic accessibility, like keyboard use and readable text
After launch, regular automated checks of those key journeys will catch problems before customers do.
Noel Aparece
Senior QA Engineer with 13+ years in software testing, ISTQB Certified Tester (CTFL) and co-founder of Qualiteq HQ.