Every app on your phone, every game, every website, and every system that runs a bank, a hospital, or an airline was written by people. People make mistakes. Software testing is the work of finding those mistakes before they reach the people who depend on the software.
This primer is the first step in our software testing learning path. It assumes no background at all. By the end you will know what testing is, why it matters, and the core ideas that every professional tester uses, whether they work on a mobile game or on the software inside a medical device.
Software is instructions, and instructions can be wrong
A program is a very long list of instructions that a computer follows exactly. The computer does not guess what the programmer meant. If the instruction says "add 1" when it should have said "add 10", the computer adds 1, every time, without complaint.
Modern software contains millions of these instructions, written by many people over many years, connected to other systems that other people wrote. Somewhere in all of that, some instructions will be wrong, some will be missing, and some will be right on their own but wrong when combined with others. That is not a sign of careless programmers. It is what happens whenever humans build something this complicated.
So the question is never "does this software have mistakes?" It does. The useful questions are: where are the mistakes most likely to be, which ones would hurt the most, and how do we find them first?
What testing actually is
Testing is a structured way of answering those questions. At its simplest, a test has three parts:
- Something you do. Type a password, tap a button, upload a file, send a payment.
- What you expect to happen. The account opens. The file appears. The payment goes through once, not twice.
- A comparison. Did what actually happened match what was supposed to happen?
When the actual result does not match the expected result, the tester has found something worth investigating. Sometimes it is a mistake in the software. Sometimes the expectation was wrong, because the requirements were unclear. Both are valuable to find, because both would have caused trouble later.
Testing is not just clicking around
People often imagine testers poking at an app until something breaks. Some testing does look like that, and it is useful. Most professional testing is more deliberate:
- Planning. Deciding what to test, how much, and in what order, based on what matters most.
- Designing tests. Choosing specific inputs and situations that are most likely to reveal problems, instead of trying things at random.
- Running tests. Carrying them out by hand, or writing code that runs them automatically, often thousands of times a day.
- Reporting. Describing problems clearly enough that a developer can find and fix them, and telling the team how ready the software is to release.
Later steps in this learning path cover each of these in depth.
Five ideas the whole profession is built on
Testers around the world share a common vocabulary, much of it captured in the ISTQB (International Software Testing Qualifications Board) syllabi that professionals study for certification. A few ideas sit underneath almost everything:
1. Testing shows that problems exist. It cannot prove there are none. If a test finds a problem, you know the problem is real. If a thousand tests pass, you know those thousand situations work, but there may be a situation nobody tried. That is why testers think hard about which situations to try.
2. Testing everything is impossible. Even a simple form with a few fields has more possible combinations of input than anyone could ever try. Testers use techniques to pick a small set of tests that cover the most important possibilities.
3. Test early. A mistake caught while the software is still being designed costs a conversation to fix. The same mistake found by customers after launch can cost far more: emergency fixes, refunds, lost trust. Good teams start testing ideas and requirements before any code exists.
4. Problems cluster. Mistakes are rarely spread evenly. They tend to bunch up in the most complicated parts of a system, the newest parts, and the parts that changed most recently. Experienced testers look there first.
5. Context matters. Testing a video game and testing the software that controls a car's brakes both count as testing, but the stakes are completely different. How much testing is enough depends on what happens if something goes wrong.
Why this matters beyond computers
Testing is a way of thinking that is useful far outside software. It means asking "how could this go wrong?" before it does, checking your assumptions instead of trusting them, and describing problems precisely instead of vaguely. Those are habits that make people better engineers, scientists, writers, and decision-makers.
It is also a real profession. Companies of every size employ testers, test automation engineers, and test managers, and many developers spend a large part of their week writing tests for their own code. The final primer in this level covers what those roles look like and how people get started.
Try it yourself
Pick an app or website you use every day. Choose one feature, such as signing in, searching, or adding something to a cart. Write down three things you would try to check that it works correctly, and for each one, write what you expect to happen. Then try them.
Congratulations: you just designed and ran your first tests. The next step in this path explains what to call the problems you find, and why testers are careful to tell the difference between an error, a defect, and a failure.