What Is Software Testing? A Beginner's Guide With a Hands-On Exercise

Introduction

Software testing is checking whether software does what it should, and finding out what it does when things don't go to plan. A tester compares what the software does with what people expect, and reports the differences clearly enough that someone can decide what to do about them.

This guide is the first part of our QA Foundations path. By the end you'll know the vocabulary, the principles, and the main kinds of testing, and you'll have done a real testing session on a practice shop, with an answer key to check yourself against.

What testing is, and what it isn't

Testing is:

• Finding information. A test result is useful whether it passes or fails, because it tells you something about the product.
• Reducing risk. You can't check everything, so you check what matters most first.
• A skill. Deciding what to test, how, and when to stop takes judgment.

Testing isn't:

• Proof that software has no bugs. No amount of testing can show that.
• Only clicking around at the end. Reviewing requirements before code exists is testing too, and often the cheapest kind.
• The same as quality assurance. Testing finds problems in the product; quality assurance improves the process that builds it. In job titles the two are often mixed.

Seven testing principles

The ISTQB Certified Tester Foundation Level syllabus, the most widely used entry-level certification, lists seven principles. In plain language:

1. Testing shows that defects are present, not that they're absent. A passing test means you didn't find a problem, not that there isn't one.
2. Exhaustive testing is impossible. A single form with a few fields has more input combinations than you could ever try. You choose, based on risk.
3. Early testing saves time and money. A misunderstanding caught in a requirements discussion costs a conversation; the same misunderstanding found after release costs a fix, a release, and maybe customers.
4. Defects cluster together. A small number of areas usually contain most of the problems. When you find one bug, look nearby.
5. Tests wear out. Repeating the same tests finds fewer new bugs over time. Change your tests and data, and explore.
6. Testing depends on context. A banking app and a game need different testing. There's no single right way.
7. The absence-of-defects fallacy. Software with no known bugs can still fail if it doesn't solve the user's problem.

Test levels: how much of the system each test covers

Lower levels are faster and pinpoint problems more precisely. Higher levels are closer to what users experience. A good strategy uses all of them; see understanding the test pyramid.

Test types: what each test is looking for

• Functional testing checks what the software does: can I log in, is the total right.
• Non-functional testing checks how well it does it: speed, security, accessibility, usability.
• Regression testing re-checks existing features after a change, to catch things that used to work and now don't.
• Exploratory testing means learning, designing, and running tests at the same time, guided by a goal rather than a script.
• Smoke testing is a quick check that the most important things work at all, before deeper testing.

Any of these can be done by hand or automated. That choice is covered in manual vs automated testing.

Exercise: your first testing session

Theory sticks when you use it. Sauce Demo is a free practice shop from Sauce Labs with several accounts; most of them are deliberately broken. The usernames and the shared password are printed on its login page.

Set a timer for 30 minutes. Your mission, written as an exploratory testing charter:

Explore the Sauce Demo shop using each account listed on the login page, to discover problems a customer would notice.

How to work:

1. Start with standard_user. Log in, sort the products, add items, open the cart, and complete a checkout. This is your baseline of "correct".
2. Repeat the same journey with each other account. Compare everything with the baseline: text, images, prices, speed, error messages.
3. Write down every difference as you go, even small ones: which account, what you did, what you expected, what happened.
4. Try variations when something looks odd. A different field, a different order of steps, typing instead of pasting.

Don't read the answer key until the timer ends.

Answer key

These are problems we reproduced ourselves in September 2026. The site may change, so if you found something different, check it again carefully: it might be a new bug.

Scoring yourself:

• Found most of them? You're already testing like a professional: comparing against a baseline and noticing differences.
• Found things not in the table? Great. Write them up properly using our guide to bug reports, which uses the problem_user checkout bug as its example.
• Missed several? Normal on a first session. Notice which kind you missed (visual, speed, or behavior) and look for that kind first next time.

Bonus: a first automated check

Many testers' first automation is a smoke test that checks an environment is up before manual testing starts. This Python example uses pytest and the requests library against Restful Booker, a public practice API:

import os
 
import requests
 
BASE_URL = os.environ.get("BOOKER_URL", "https://restful-booker.herokuapp.com")
HEADERS = {"Accept": "application/json"}
 
 
def test_api_is_up():
    response = requests.get(f"{BASE_URL}/ping", timeout=10)
    # Restful Booker answers its health check with 201 Created.
    assert response.status_code == 201
 
 
def test_new_booking_can_be_read_back():
    booking = {
        "firstname": "Ada",
        "lastname": "Lovelace",
        "totalprice": 120,
        "depositpaid": True,
        "bookingdates": {"checkin": "2026-10-01", "checkout": "2026-10-03"},
    }
    created = requests.post(f"{BASE_URL}/booking", json=booking, headers=HEADERS, timeout=10)
    assert created.status_code == 200
 
    booking_id = created.json()["bookingid"]
    read = requests.get(f"{BASE_URL}/booking/{booking_id}", headers=HEADERS, timeout=10)
    assert read.status_code == 200
    assert read.json() == booking

Save it as test_booker_smoke.py, then install the two libraries and run it:

python -m pip install pytest requests
python -m pytest -v test_booker_smoke.py

Our run:

test_booker_smoke.py::test_api_is_up PASSED                              [ 50%]
test_booker_smoke.py::test_new_booking_can_be_read_back PASSED           [100%]
 
============================== 2 passed in 2.91s ==============================

Notice the comment in the first test: this API answers its health check with 201 Created, where most would return 200 OK. We only know because we sent the request and looked, which is the habit this whole guide is about. More on testing APIs in our API testing beginner guide.

Conclusion

Testing is structured curiosity: know what "correct" looks like, compare carefully, choose what to check based on risk, and report what you find so others can act on it. The seven principles explain why you can never test everything; the levels and types give you a map of what to test; and the exercise shows that a careful person with a baseline and a notebook finds real bugs in half an hour.

Next in the series: how to write effective test cases.

Sources and further reading

• ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus
• ISTQB glossary
• Martin Fowler: Test Pyramid
• pytest documentation
• Sauce Demo practice shop