Test Case vs Test Plan Documents
What is the difference?
One of the most common interview questions you will get is, “What is the difference between a test case and a test plan?” A Test Plan is a document that describes the major scope of the testing. A Test Case is a single detailed scenario that tests a specific feature of an application.
Test Plan
A test plan is a high-level document. You can think of it as a contract written by the QA Lead for the team. The test plan document contains outlines of what will and will not be tested. What you include in the plan will vary based on the project, so you will need to use your best judgment to determine what is important to include.
Approach
How will the tests be executed? Will this be a manual black box execution? Will the focus be on data validation via SQL scripts? This section is for you to talk a little bit about how the tests will be executed.
Feature or Project Description
Usually, you won’t be creating test plans on a feature by feature basis, but it does happen with short projects. Typically you will create a test plan for a larger scoped project. This section is used to describe the general feature or project that the plan will cover.
Resources
What do you need to be able to execute your tests? Do you need any special hardware or software? Do you need an army of mobile devices? This section is for you to call out anything specific you might need to complete your testing.
Included and Excluded Features or Scenarios
Are you responsible for testing the entire application? Are there any scenarios that are out of scope. This section is for you to call those out. You will want to specify what you are going to focus your work on. This is very important so that 3 months down the line there won’t be a conversation about, “Weren’t you guys supposed to test that?”.
Test Areas
This section is going to include what type of testing you will or will not perform. Typical things that a web tester would put on here are functional testing, accessibility testing, and globalization testing. If you don’t know what these things are, we will go over each in future posts.
Test Case
Test cases are the documents that a QA Engineer is going to spend the majority of their time writing, other than bugs of course. We will go over how to make good test cases in a future post.
The test case is the detailed scenario for validating the functionality of a specific feature. The number of test cases per project will vary based on the size and complexity of the application. All test cases should have a minimum these three things.
Scenario Title
The title of the scenario should be short but clear on what exactly is being tested. Anyone on your team should be able to scan through your test cases and be able to find the scenario that they need without having to dig into the details of each one.
Steps
The steps are the detailed list of things you need to do to perform the test.
Expected Results
This is where you specify what should happen after you have executed all the steps.
Sample Test Case:
Scenario:
Searching for a non-stop flight using specific depart and arrival dates
Test Steps:
- Enter the origin airport code “PDX” into the “From” field
- Enter the destination airport code “LAX” into the “To” field
- Enter a departing date “Dec 24, 2017” into the “Depart Date” field
- Enter a returning date “Dec 25, 2017” into the “Return Date” field
- Set the number of Adult Travelers to 4 from the travelers dropdown
- Select “Business or First” from the cabin class dropdown
- Check the “Nonstop” checkbox
- Click the “Search” button
Expected Results:
- Processing overlay is displayed for a few seconds
- User is redirected to a results screen
- Departure date is displayed and correct
- Departure airport code, city, and state are displayed and correct
- Arrival airport code, city, and state is displayed and correct