How to Create a Test Plan? Steps and Examples for Software Testing

For many software development teams creating any sort of plan sounds dull and boring. Creating a plan for the testing process sounds.. Well… Pretty much Hermione Granger-ish. That is definitely not the case. Remember that the whole effort that you put into testing is there for a very important business reason - to save you time and money. Creating a test plan is the first step to achieve this goal.

But how do you prepare a test plan for software testing?

What is a test plan document?

Stating the obvious - a test plan is a document describing the testing process of your web application. There is more into that though. This is a crucial document. It outlines the approach, objectives, scope, and resources required for testing a web application. It serves as a roadmap, guiding the entire testing effort and ensuring that all necessary activities are executed.

Creating it, is like answering to the “wh- questions” about the process:

• What will be tested
• Why it will be tested
• When it will be tested
• And how it will be tested (I always wondered why “how” is on the “wh- questions” list, but anyway)

A well-crafted test plan includes details such as the test objectives, tools, schedule, and roles and responsibilities of the testing team. It would be beneficial if It also identifies the test levels, entry and exit criteria, and the types of testing to be performed.

There are two important features of a good test plan. First - keep it a live document. Don’t set it in stone from the very beginning of the process. We all know that the only constant thing in software development is change. The test plan needs to react to those changes. Second - use the test plan. It is there for a reason. It will make the web application testing easier and more efficient. The worst thing you can do about it is to complete it and put it in a drawer. By doing so, you just wasted a lot of time and effort.

What is the importance of a test plan anyway?

Well imagine going for a long hike without a map (optional North American sport parallel - imagine playing football without a playbook) - will work somehow, but do you really foresee success by doing so? Not really, huh?

It is crucial for web application testing that all team members to understand the key aspects of it. Especially now, when we live in times of fast software and business development, IT teams often spread geographically across different languages and timezones and flat company structures when a startup CEO may also work as the PM or tech lead. We all need to be on the same page. Even literally.

This map (or playbook if you will) is vital for everyone involved to know what will be expected of them during testing and what should the pass/fail test criteria be for the application.

When to create a test plan in software testing process?

Given what we have stated above, on the web app test plan being a live document, the answer would be - create and improve it constantly. When to start creating it, is a bit of a different topic.

The planning process depends on your situation and web development approach. Of course the test plan needs to be created prior to the first testing activity. You have the waterfall vs agile decision to make, which implicates not only the testing but the development as well.

Waterfall gives you a bit more time to create the test plan, because the person who will actually create it may work parallelly to the development process. On the other hand there will not be much time left for modifying the plan after the tests start.

Agile approach is based on iteration which is also reflected in test planning. A few core parts of the plan need to be done right after the completion of the functional specification of the app. Those would be test plan objectives and scope, test environment and test strategy and approach. The rest (test case, test suite and test schedule) can be done in an iterative manner, basically side by side with the scrum masters’ backlog planning. For example if the first sprint of your web application creation aims to create the user authentication process, your test cases will include… yes, you are right - testing the user authentication process.

Example of test plan for web application

You might get different answers to that question all over the web. If your team is experienced enough, the list of components may vary especially from project to project. The following list comes from our expertise and will be described more thoroughly below.

In our opinion a good test plan has to include:

• Objectives and Scope
• Test Environment
• Test Strategy and Approach
• Test Cases and Test Suites
• Test Execution Schedule
• Defect Reporting and Tracking

What should be placed in the test plan template?

Objectives and scope

In this paragraph the creator needs to outline the specific goals the testing effort needs to fulfil plus the range of the tests themselves. It is wise to do a rather thorough description followed by a bullet point summary for readability. Also we recommend doing the positive / negative approach, meaning that first think and describe what you want to achieve, then reset and do the complete opposite - what are the limitations and boundaries and describe them as well.

This should answer the “what” and “why”. Are we just testing the functional aspect of the app? If so, why are we not doing the security testing or the performance testing? There might be business reasoning behind that decision, for example we might have an external team being responsible for the security.

Test environment

Remember our article on the best testing tools in 2023? This is where it comes in handy. In this chapter you need to describe all assets that will be used in the process. How many man-hours do you foresee using? Do you need any specific server / network / devices or maybe some fancy settings on those? And finally how are the tests going to be performed? Will your team code them by themselves? Or maybe you will use some no-code solution like BugBug?

This might sound less important from the testers’ standpoint, but trust me - it’s a must have from the business perspective since it enables “the money people” to do some cost estimations on the test process.

Test strategy and approach

We have addressed the “what” and the “why”, it is time to address the “how” we need to test. The strategy part needs to take care of describing the overall approach and principles that will be followed during the tests. The key here is to make sure that all information is relevant to your specific project.

The test approach on the other hand describes the actual activities that will be done within the process. There are different testing methodologies and a brief description of the one(s) chosen needs to be fit here. Are you going end-to-end? Do you require data-driven approach? Make sure you let all the team members know. Speaking of team members - it is wise to place the responsibilities description here, bringing us to a conclusion that we have another “wh-” question - who?

Test cases and test suites

This is the most crucial part of writing a test plan, because it covers the actual scope of testing. Single test case answers the question “what do I want to test?”, and the reply needs to be in singular. One test case covers one topic, but do note that it may be divided into a few separate scripts. For example one test case will cover the user login functionality, but separate scripts will cover logging in by using different web browsers.

A test suite is a collection of test cases grouped for test execution purposes. Moving along with the example from above a test suite would cover the whole user authentication process, and logging in, password reset, logging out etc. would be separate test cases.

Test execution schedule

The schedule has to cover both the high-level and low-level planning of the test phase. The first defining moment comes with the decision on waterfall vs agile that gives you a basic idea on when the testing will happen. Is it going to be post-development or mid-development?  Remember that creating a schedule is not only putting the test procedure into a calendar, the harder part sometimes is to figure out in what order the testing will take place.

For waterfall it is relatively easy since your whole test procedure takes place after the coding is done. You might consider what the testers are going to be doing during the development phase. For agile you have a bit more decisions to make, for example is there going to be a delay in testing? If so, how many sprints of a delay would you like to have. Testing in agile environments deserves a completely different article since this is truly a different software testing life cycle.

Defect reporting and tracking

First of all do have a bug reporting and tracking system implemented, this is the foundation of your communication within the process. If you don’t have one yet, create one. Even if it is writing a post-it with a bug description and smacking it at someone’s desk. Fortunately we have more sophisticated methods of monitoring software defects.

There are multiple project management and ticketing systems available. BugBug enables integration with the most popular ones via Zapier. This will make life easy for the test manager, since the majority of communication will be automated and whenever a bug occurs, a ticket will be created, an e-mail sent or whatever you require.

How to write a good test plan?

Define Test Plan Objectives and Scope

The author needs to start creating a test plan by writing the objectives and scope. In majority of cases the objectives included in the test plan are basically stating the obvious - that we want to make sure that all our functionalities work, the app is secure and will withhold increased traffic if our business is a tremendous success.

The scope on the other hand requires a tad more attention. As an exercise try writing the scope as you would for a person, who does not work for you yet and has no clue whatsoever about your software. The scope of your testing needs to be relevant for your app from the business perspective but from the subject matter point of view as well. For example you will not require too much UI testing for a console application do you?

Identify the test environment

After carefully analysing the market and choosing the best tool that suits your needs, you now need to reach out to people who take care of your network and servers. If there are any special requirements such as server structure, traffic limitations etc. those need to be put here since the test management strongly depends on those.

One thing that is commonly missing in this chapter is the test data. Those need to be either prepared beforehand or you may end up using data automatically faked by some external solutions. Whichever route you would like to take, make sure you let the readers’ know. Remember that each software product will require different types and quantities data to start the test so make sure you plan it both time- and money-wise.

Choose a Test Strategy and Approach

A good place to start is choosing your goals. Those need to be relevant to the objectives and scope you defined earlier. Remember, that a good goal is a SMART goal. Then you move to the team and responsibilities. Define specific members of your team, or profiles if you need to hire some additional testers. After that just “drag and drop” different pieces of the testing cake to those people.

One of the most important strategic decisions comes next - what tests would you like to automate. Is the test automation tool relevant to your needs in that matter? The high level listing of “to be automated” aspects would be a good place to do some self-compliance. Last but not least comes the answer to the crucial question - when do we do functional testing. There is little point to define the test plan on security, UI etc if our app just does not do what it is supposed to.

Develop Test Cases and Test Suites

In theory the applications functional requirements are your best friend if you want to write a software test plan. Keep your fingers crossed that the requirements were created correctly and thoroughly. In such a case your work here is relatively easy even though it will be quite monotonous. Basically you create test cases by checking and adapting the whole list of functionalities, user actions, security and whatever falls into your test scope. Then after creating such a list, you divide it into test suites that cover different areas and groups of functionalities.

Worse case scenario - your functional requirements are described on a very high level. In such case the test plan is typically a much more "live document" as one would desire. The test management process might be a bit harder, but this does not mean that it is not an effective test plan. You just have to come back to this part in a more iterative manner and implement changes to the test plan as soon as the development team completes a functionality.

Create test execution schedule

That is another part of the test plan that might be partially covered from a different source. If your team does agile development, you should have a backlog created in sprints. Nothing prevents you from using this backlog to your needs, there is no need to reinvent the wheel there. You end up having functional test deliverables just like that.

Other test scopes need to be covered here as well. Remember that a test plan is a detailed document that requires not only your knowledge and expertise, but lots and lots of inter- and intra-team communication. You have to understand for example if starting performance testing may happen only after completing the whole app, or are there any circumstances that will allow doing it sooner. There is no universal truth here, only project relevant stuff. Those are data, you have to collect and process on your own. If you never tried to create a test plan, you would have to learn how to write it. The first version of the test plan might be similar to a first pancake. It will be thrown away. Trust us, expertise, especially in scheduling the test plan comes with repetitions.

Define defect reporting and tracking mechanisms

The main goal of a testing project is to report every test result. The dream is to have as few negative results as possible, but a comprehensive test plan (like the one we are describing here) needs to consider the “what if?” scenario.

In this final part you need to describe two things. First - which tools and integrations are needed for a proper bug reporting path. The idea if bugs are the only things worth reporting is also something to think about. Maybe it is a good thing to report the completion of a test phase as well. Next you write down who the information recipients should be. Use as much automation as possible. Thanks to multiple integrations a detected bug might immediately trigger an email to a bunch of recipients, a ticket or a task and even a creating a git branch for the issue to be resolved.

Executing a software test plan. How to work with changes to the test plan?

Ok, you have created a detailed document that outlines your plan for testing. It contains the success criteria for testing, describes many test cases and includes all steps to report bugs. And now what? Well, the testing obviously, but this is not the point here.  The key importance of a test plan in software testing is not to hide in the drawer. The test plan helps in all phases of software development process and all aspects of testing only if you use it properly.

First things first. From the very beginning understand that even the best plan will need some changes and updates eventually. Every test plan is created with no possibility to foresee how many bugs the tests will uncover. Creating your test plan has to assume some time flexibility, both ways actually. Your test estimation will rarely be 100 percent accurate. Of course if your development team did a splendid job and there are virtually no bugs whatsoever, you need to make sure that your updated test plan contains it too.

In addition to that, remember that the most important soft criteria for a test plan is readability. You need to make it easy to understand to all audiences. You are probably wondering why we put this into the “how to execute” part of our article. That's simple - all team members have to be aware that the test plan exists and how far we have progressed. Remember, they are the ones actually working with the plan, you have created. Without them, the test plan becomes just another document.

We hope, that with this article we were able to emphasise the importance of test plan creation. There many types of test plans out there for you to check. If we were to suggest you one crucial thing it would be just to create one and do so as a team effort.

Make sure you check the next article, that will cover how do we at BugBug write the test plan. What are our steps to create a plan. It will include a template and an example as well! A good test project plan will make as happy as John Hannibal Smith always was.

Happy (automated) testing!