Define an effective test plan

Define an effective test plan

By Alejandra Centeno, QA Manager at Financial Solutions

In the life cycle of a project or software development, it’s important to reserve an estimated time for testing, many times the biggest question is “How do you determine which tests are going to be performed?”, because there is where the famous “Test Plan” comes into play.

What is a Test Plan?

It is a planning tool where the actions to be performed by the testers is defined. There are different ways to create or design the test plan, however, there are elements that are fundamental to establish it.

The basic elements that may be missing when defining the testing strategy of a product are:

• Type of testing
• Reach
• Time and resources
• Test acceptance and discontinuation criteria

Which are the different types of tests? In the first instance we have to define the type of tests to be performed, this goes side by side with the methodology and working style of each project or company. It’s always preferable to be specific and each member of the team must be clear on which tests will be performed. These tests can be functional and/or non-functional and can also be:

• Integration tests
• Component tests
• Unit tests
• Regression
• Acceptance
• Smoke testing

What scope can I have?

For the scope, it is necessary to take as a base the documentation or requirements definition to know what the project consists of. Having the modules and/or basic functionalities listed, will help us a lot with the estimation of the number of tests or complexity of the system.

How to project the time and resources I need?

Being aware of the time that you will be able to dedicate to testing is key. It is like a formula, if you have enough time, you can allocate the minimum necessary resources, i.e.: more time = less resources, but if you don’t have much time, you should allocate more resources, or if at that moment the area doesn’t have many testers, you can request more time for testing: less time = more resources  

With these two elements we can play a little with timing, depending on our company’s circumstances.

When is it time to stop testing?

Acceptance seeks to finalize and close the project, which requires the customer’s approval, this is often complicated, either because it requests unplanned adjustments, or a significant number of project issues involved in the customer’s acceptance. This is why we must contemplate these scenarios before they happen. In the plan we can define a criteria that we find acceptable, not only to the QA area, but the team in general should feel comfortable and supported.

It will always be better to keep in mind, that an agreement could be reached with the client to release low priority incidents, or to detect and channel in time the changes and/or adjustments that aren’t defined within the scope.

In the other hand, the suspension of testing may cause a conflict, if the reasons or motives for stopping or slowing down testing, are not formally established. The quality of a product doesn’t depend entirely on the tester, it’s important to keep in mind that the higher quality of the creation, the better results of the tests that were performed, and when this doesn’t happen at the time of testing, problems may happen that could limit or completely stop the execution of the different scenarios.

In conclusion…

There are more elements that can be integrated in the test plan, in case of a waterfall methodology some of they are: the acceptable test cycles, the links or URLs of the QA environment, etc.

Remember that the test plan is a tool that help us to define the process or purpose of the tests, the more information is contemplated and the clearer the scope, the better the results that can be obtained, since this document should be exposed to all team members.

A good practice will always be integrating the expected result of each test case in order, only to be clear about the validations to be considered.

---