One of the things you should always do as a developer is test your changes before you move the changes into a production environment. Testing is a critical part of the software development lifecycle as functional builds become the norm across agile teams. For this simple reason, it’s still essential to write great software test plans.
What is the difference between a Test Procedure and a Test Plan?
Most good software development models call for both a Test Plan and a Test Procedure. Although in principle this sounds good, test procedures are extremely costly to develop, costly to maintain and don’t catch enough of the bugs in a short enough time. Simply put – a test plan tells you what you are going to test while a test procedure tells you how you are going to test it.
Creating a Test Plan
1. Scope and Objectives
Every project is different and the approach is often different from program to program. No two applications will have exactly the same requirements and will usually will not leverage all of the same test cases. The QA team must determine what’s possible in the project scope of testing and the objectives of each test during the planning period. This step will be critical to ensuring a successful strategy that meets each project’s unique requirements, especially in an agile environment.
Before you can commit to a deployment schedule, you have to understand the level of testing required and how long the required testing will take to complete. Scheduling appropriate resources is a requirement to verify the testing happens as planned and on the schedule required to meet your overall development schedule.
3. Defect Management
The key to making sure users are getting a quality product is identifying issues and mitigating them as you maintain reliable delivery schedules. These basic practices must in every great software testing plan. The QA team must be capable of identifying issues, mitigating risk, and also knowing when testing must stop if specific criteria is met during these tests.
Who is doing what steps and on what schedule is an important part of identifying and documenting assigned responsibilities. You should not assume everyone just knows what to do or who to communicate issues to during an incident.
5. Establish criteria for starting and ending testing
Certain criteria must be in place to validate the preparedness of a project because QA teams can’t just test as long as they might like. You must create the criteria that will help QA teams ensure that everything is ready and that they also must have benchmarks in place to identify when it’s okay to go to the next phase of the project’s lifecycle.
Generally speaking every test case should define expected results as a result of the defined inputs. Every requirement of the application should be tested beyond its boundary conditions as well as mid-points to make sure they aren’t any application conditions that might generate user errors.