Every software application needs a test plan before it’s launched. While small software projects can get away without any significant testing, you need a laid out plan of attack when you want to work with enterprise software. You need to know how the software works, the software functionality specifications and the programming specifications to identify bugs. All of these are important with your planning.
Basic Test Plan Information
The top of the plan has some basic information you should include with the test plan. The first part of the information is your name and the test plan creator. You could be the creator or someone else. Your name is to identify who went through the tests and verified that the application was working properly. Usually, the test planner and the creator work together, because it gives you a better understanding of how the plan works and how the software must be tested.
You also have a basic table of contents. Some testers prefer to tackle test plans in a different order than how it’s laid out. As long as one test scenario does not rely on another, you can perform the test plans in any order you prefer.
You also need to identify the hardware specifications for the software. The testing computer should have the minimum hardware requirements needed to run the software. Specifications including hard drive, memory, and CPU requirements should be listed.
Features to Test
Every application has several functionality requirements. These functionality requirements are laid out in the functionality documentation that’s given to the developers. You use these functionality requirements to lay out your test plan. In these test plan scenarios, you need to list each feature you want to test.
Your application can be separated into “screens.” For instance, you have a login screen, a main control panel screen and a screen where users perform their departmental tasks. Each of these can be considered a part of the application, and you can use these screens as a way to segment your test scenarios.
Within each screen is a list of controls and user input features. For instance, a screen that asks a user to enter shipping information will have the user’s address, phone number, zip code and city and state. The input fields are controls you must test. These user input fields have basically functionality such as entering a zip code and a drop-down box pre-populating the corresponding state. These types of activities are the functionality you need to test. Your test plans might also have a requirement to validate user input. For instance, if the company only ships to the United States, the zip code should only have numeric input. You would then make a test plan that ensures only numeric input can be entered. This type of input validation is important for applications that store data in a database. If the wrong type of data is entered, it can throw an error from the application.
Most applications rely on some kind of logical flow. For instance, if I’m a user who wants to buy a product, I am sent to a shopping cart system. However, if I’m a user who wants to just browse products, I’m sent to a product list where I can view detailed information.
Control flow can become a complicated part of an application, but the test plan should account for each fork in the logical flow. It should also test for errors as well. For instance, if a user enters a shipping address but doesn’t give you a phone number, you can display an error but pre-fill the information when you return the user to the shipping information page.
Some applications have dependencies. For instance, you might have an application that requires users to sign up and pay before they can access a private area. In this scenario, the payment processing application and the customer signup area are both dependencies for the backend private access-only area.
To properly test your software and create a well designed test plan, you need to know your dependencies and the order in which the software depends on these dependencies. In the example of the payment and signup system, you would first test the signup system. Ensure that the system records a signup up. Then, you test the payment system. The payment system, however, is dependent on the signup system. If the signup system fails, then the payment system will fail.
You then test the payment system. You should also include all functionality for a payment system including returns, returns and debits. If any of these fail, the user can’t access the private area. All of these dependencies must be tested in a specific order, and the sample test plan must account for that order.
Approval and Denials
Each test includes an approval or a denial. Any bugs or function that doesn’t work as intended would lead to a denial. Any denials go back to the developer for review. Sometimes, bugs are not bugs but intended features that the tester missed. If this happens, then you must make a new test plan with the fixed scenario.
The goal is an approval. An approval means that the screen and all its functionality work as intended. The downside to a denial is that any dependencies or screens that rely on that particular function must be retested. Testing can sometimes take months, especially if it’s a large application.
With great test plans and well written scenarios, you can create applications that have little (or even no) bugs. Bugs cause frustration for the user, so well written test plans can avoid losing users to competitors.