I first wrote this article on 22 November 2024. I am rewriting it because some of the old explanations were not complete enough, but the learning order stays the same: understand what this job is doing first; the process and pile of documents can come later.
The concept
The first question people usually ask when learning Manual Testing is:
What is software testing?
Saying that software testing means looking for bugs is not wrong. A tester who goes a whole month without meeting a single bug might start to feel suspicious. But that answer is a little short, because much of a tester's work happens before there is any code to run.
For example, a BA gives us a requirement like this:
If a user enters the wrong password several times, the account will be locked.
You should immediately ask: how many times, within what period, for how long, can the user unlock it themselves or must they call support? There is no screen and no build yet, but reviewing this is still testing. Catching the problem here saves the BA, developer and tester from redoing work later.
So, more completely, software testing is a set of activities for evaluating software work products and the related work products around them. We check whether the product follows the requirements, serves a real need, and still has defects or risks, then give that information to the people who need to make decisions.
It includes:
- Static testing: reviewing requirements, design, code and test cases without running the programme.
- Dynamic testing: running code, calling APIs, clicking through an app and observing what it does.
Typical question: What is software testing?
Software testing is a set of activities to evaluate software work products, find defects, verify requirements, validate user needs and provide information about quality and risk.
Objectives
Go back to “testing is for finding bugs”. Keep asking:
Why find bugs?
So developers can fix them.
Why fix them?
So the product works properly and causes less damage.
There we are. It still comes back to quality and risk.
A banking app that calculates the wrong amount can lose someone money. An online shop that crashes at every payment loses revenue. A button placed somewhere nobody can find may not crash the app, but if customers cannot use the feature, the feature may as well not exist.
Depending on the project, testing may aim to:
- Find defects and prevent them from appearing early.
- Check whether the product follows the agreed requirements, design and criteria.
- See whether the product actually solves the user's need.
- Provide quality information for deciding whether to release, delay release or accept a risk.
- Reduce the chance that the product fails in operation.
Testing cannot prove that a product has no bugs left. It gives the team more evidence to decide that, with the time, money and scope available, this build is good enough to move on.
Verification and validation
These two are very easy to memorise backwards.
| Concept | Roughly | Example |
|---|---|---|
| Verification | Did we build it according to what was written? | The requirement says a password must have at least 12 characters. Does the system reject 11? |
| Validation | Is what we wrote and built actually what users need? | Is forcing 12 characters appropriate for how users use the product and for the security requirement? |
You can build a product that follows every line of a document when the document describes the wrong need. Verification may pass in that case; validation will not.
Who performs testing?
In the old article I grouped people into Tester, Developer and Customer. That is enough for an introduction, but the real project is wider:
- Developers test code, components and integration, and review one another's code.
- Testers analyse requirements and risks, design and execute tests, and report quality.
- BAs, Product Owners and domain experts review business rules and acceptance criteria.
- Customers or end users take part in acceptance testing.
- Depending on the product, security, performance, accessibility or operations specialists may also be involved.
Quality is not something to throw over to the tester's desk. Whoever creates a product also has a share of the responsibility for checking it.
Why do we still need testers?
Then comes the question:
Developers can test their own code, so why hire testers?
First, developers absolutely should test. You cannot finish coding, never run it once, and throw it over to the test team with “please check this for me”. A tester is not a compiler powered by food.
But asking one person to design, code, invent every test, test the whole product and fix all the bugs is a lot. If we hire another group of developers solely to test what the first group wrote...
Hang on, how is that different from hiring testers?
Exactly.
Testing also has its own techniques. Boundary analysis, state transitions, risk, coverage and investigating a failure are not things you automatically know just because you can code.
Finally, there is viewpoint. Someone who has just built a flow knows how it was meant to work, so it is easy to follow the path they created. Someone outside the implementation asks more irritating questions: what if the network dies during payment, what if I click twice, what about old data, what if I go back halfway through?
The old article called the developer a builder and the tester a breaker. It is funny and memorable, but not quite right at work. Testers are not paid to smash things for fun, and developers do more than build. Both are working on the same product; the tester simply has a more independent position and focuses more on where it can go wrong.
Can one person do both development and testing? Yes. But reviewing your own work always brings bias. That is why code review, peer review and independent testing exist.
Typical question: Why do we need testers when developers can test their own work?
Developers should test their own work. Testers add an independent point of view and specialised testing skills, helping the team find risks that the author may overlook.
How does testing happen?
Testing has its own process, and that process sits inside the larger software development process. If I put SDLC, Test Levels and Test Process here as well, this article would become an epic poem, so for now remember two moments.
Before there is a build, a tester can review requirements, question acceptance criteria, prepare test data, think through test conditions and write test cases. This is when correcting a wrong sentence is cheap.
When there is a build, the tester runs tests, observes the actual result, compares it with the expected result, investigates differences and logs bugs. This is dynamic testing, the part everyone usually sees.
Do not wait until developers have finished all the code before the tester appears. Asking “what does this requirement mean?” at that point makes the whole team tired.
The seven testing principles
This comes up often in interviews. Do not just memorise the English names; understand what each one is warning you about.
| Principle | Roughly |
|---|---|
| Testing shows the presence of defects | Tests can find defects, but not finding one does not mean the product is bug-free. |
| Exhaustive testing is impossible | We cannot test every input, device and action order. We have to choose based on risk. |
| Early testing saves time and money | Catching a wrong requirement in review is cheaper than catching the same error after coding and deployment. |
| Defects cluster together | Bugs often gather in a few complex or frequently changed modules. That is no reason to abandon everything else. |
| Tests wear out | Running the same old suite forever gradually checks only what we already know. Tests need review and additions. |
| Testing is context dependent | A personal notes app does not need the same controls as a banking app or medical device. |
| Absence-of-defects fallacy | Software with few bugs can still fail if it does not do what customers need. |
The first and last principles are easy to mix up. One says we cannot prove that all bugs have been found; the other says even few bugs do not guarantee a useful product.
Typical question: What are the seven testing principles?
Testing shows the presence of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out; testing is context dependent; and absence of defects does not guarantee a useful product.
Closing
The one thing to keep is this: software testing is not sitting around waiting for a build and clicking until a bug appears. It starts while the team is still discussing what to build and continues until there is enough information to decide whether the product should move on.
In this article I have used error, defect and bug somewhat interchangeably. They are related, but they are not the same thing. The next article deals with that mess separately, because without it, discussions of Severity, Priority or Bug Logging become a tangle quickly.
