What testers do
About 25 minutes · read, practise, then check your understanding
Every software team needs people who can find problems before customers do. Testing is a real engineering role, and a common entry point into IT for freshers.
You will learn
- Where testing fits in how software is built
- The difference between a bug and expected behaviour
- How to write a simple test case
Before you start
- You have used a mobile app or website. Nothing else.
The idea, simply
Software is built in a loop: someone decides what a feature should do (the requirement), developers build it, testers check it, and then it is released. Testers ask: does it do what it should, and what happens when people use it in unexpected ways?
A bug is when the software behaves differently from what it is supposed to do. To call something a bug, you need to know the expected behaviour. That is why testers read requirements carefully.
A test case is a small, repeatable check. It has a title, the steps to perform, the test data you use, and the expected result. Anyone on the team should be able to follow it and get the same result.
Title: Login fails with a wrong password
Steps:
1. Open the login page
2. Enter a registered mobile number
3. Enter a wrong password
4. Tap Login
Expected result: An error says the password is incorrect.
The user is not logged in.See it in action
- Positive test: correct mobile number and password logs in.
- Negative test: wrong password shows an error.
- Boundary test: a password of exactly the minimum allowed length works.
- Unusual input: spaces before the mobile number are handled sensibly.
Common mistakes
- Testing only the normal, happy path.
- Always add negative and boundary cases.
- Vague expected results.
- Write exactly what should appear or happen.
Key takeaways
- A bug is a difference from expected behaviour.
- Test cases have steps, data and a specific expected result.
- Positive, negative and boundary tests together give good coverage.