Testing 101: Test Cases, Test Plans, and Test Runs
A practical guide to test cases, test plans, and test runs, what each one means, and why they matter in modern software testing.
Efficient testing of the software under test is a vital part of making sure a business delivers a high-quality product. Software quality should always be a collaborative effort across the lifecycle, but the QA function still needs to be organised, efficient, and clear on the fundamentals.
In this post, I want to look at three core concepts in modern software testing: test cases, test plans, and test runs. What are they, and why do they matter?
Test Cases
A test case is a set of steps and conditions used to determine whether a particular feature or function of an application is working as expected.
In simple terms, a test case is a recipe. It clearly defines the ingredients, meaning the inputs and setup, and the steps needed to reach an outcome.
If you want a more formal definition, a test case is often described as:
A set of conditions through which a tester will determine whether an application, software feature, or system is working as intended.
A well-written test case can include:
- a clear title
- a description of what the test covers
- preconditions or setup requirements
- any relevant test data
- expected results
- the test type, such as functional, smoke, regression, or performance
Not every test case needs every one of those elements, but the stronger the structure, the easier it is for the test to be understood, repeated, and maintained.
It is also common for test management platforms to hold extra metadata, such as whether a test is automated, how critical it is, or whether it blocks a release path.
A very simple test case might look something like this:
| Step | Data | Expected Result |
|---|---|---|
| 1. Navigate to the login page | The login page is displayed. Email and password fields are visible. A login button is visible. | |
| 2. Enter an email address associated with an active account | rick@rickandmorty.com | |
| 3. Enter a password that is not associated with the entered email address | P1ckleR13K | |
| 4. Click Login | An inline error message is displayed. No navigation occurs. The user does not gain access to the platform. |
Why Test Cases Matter
Test cases bring calm and clarity to testing. Ad-hoc and exploratory testing absolutely have value, but by their nature they are less structured and less repeatable.
Well-written test cases matter because they:
- provide a clear procedure to verify functionality
- can be repeated consistently across test cycles
- can be understood and reviewd by people outside QA
- help identify new defects and regressions as software changes
- give visibility into what has and has not been tested
- make expectations clearer for both product and engineering
- give confidence that important scenarios have been considered
Test Plans
A test plan outlines the scope, objectives, timeline, resources, and activities for a specific testing effort. It acts as a guide for how testing will be executed in an organised way.
To stick with the cooking analogy, if a test case is a recipe for one dish, a test plan is the plan for the whole meal. It tells you what needs to be made, when it needs to happen, who is involved, and what success looks like.
Typical elements of a test plan include:
| Element | What it means | Example |
|---|---|---|
| Scope | What is being tested | New user registration flows, a payment processing module, integration with a third-party billing system |
| Objectives | What the testing is trying to achieve | Uncover defects before launch, validate new features against requirements, achieve suitable coverage across critical workflows |
| Timeline | When key testing activities happen | September: regression testing, October: integration testing, November: UAT, December: final validation |
| Resources | What is needed to support the effort | Team members, staging environments, test data, tools such as Playwright or Postman |
| Activities | The kinds of testing that will be carried out | Functional testing, exploratory testing, performance testing, security checks, usability validation |
If a test case tells someone how to verify a behaviour, a test plan tells the wider team how the whole effort is going to be approached.
Why Test Plans Matter
Test plans are useful because they help organise and optimise testing effort.
Without a plan, testing can become fragmented, rushed, and incomplete. A well-constructed test plan gives teams a clearer idea of:
- what matters most
- what needs to be covered
- when work needs to happen
- what resources are required
- how progress and success will be measured
In practical terms, a good test plan helps the team avoid wasting effort. It gives people a route to follow, keeps momentum up, and reduces the risk of critical areas being missed.
Test Runs
A test run is the actual execution of a test case or set of test cases against the software under test.
This is the point where the work becomes real. The same test cases can be executed repeatedly across multiple test runs as the software evolves.
During a test run, the steps in each test case are followed and the actual result is compared with the expected result. That is how teams identify defects, unexpected behaviour, and regressions.
Test runs also often capture useful detail such as:
| Detail | Why it matters |
|---|---|
| Environment used | Helps teams understand where the test was executed and reproduce issues more reliably |
| Test data | Makes it easier to trace what inputs produced the result |
| Logs or evidence | Gives useful context for debugging when something fails |
| Pass or fail result | Provides the clearest possible signal of the current state of the check |
Why Test Runs Matter
Test runs are critical because they:
- validate that new code or features behave as intended
- uncover bugs and areas for improvement
- provide confidence ahead of release
- generate useful data across successive runs
They are the execution layer of the testing process. If test cases define what should be checked, and test plans define how the effort is organised, test runs are where that strategy is actually carried out.
Final Thought
Test cases, test plans, and test runs are all basic concepts, but they are basic in the same way good engineering fundamentals are basic: they are simple, but they matter.
When those three things are understood and used well, testing becomes clearer, more repeatable, and much easier to scale. And when teams get that right, they give themselves a much better chance of shipping software with confidence.