Developing a Software Test Plan & The Impact of it 

Within every organisation there are a number of documents that have a hieratical order. When it comes to testing deliverables, you would expect to find the test policy document at the top of the tree; this document is only a couple of pages long but does at executive level spell out the quality needs of the organisation and gives the vision of what is expected of every project. This document is owned by the CIO or IT Director and should be mandated to ensure every programme and project works to the same expected standards every time.

The next document down is the overarching test strategy; this document details the processes, methodologies and tooling to be used, it principally sets the cornerstones and building blocks to give a guidance to all testing practices. The test strategy is a reflection of the test policy and should be used as a guide on all programmes and projects.

It’s worth noting that whether your organisation decides on a Waterfall, Agile or DevOps approach, the test strategy is still required as it sets out the rules and approach for testing. Now it would be sensible, if developing in an Agile or DevOps fashion, that you put as much detail into the test strategy so that your project level test plan need only refer back to the strategy document thus making the production of the test plan very easy and more fitting for an Agile/DevOps project.

It is worth noting that Agile/DevOps doesn’t mean no documentation. Documentation is important part of the test as it sets out the principals of testing and explains the approach i.e. what needs to be tested and how.

When a programme or project is initiated a software test plan will be required, the ISTQB definition is that a test plan is a document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

With best intentions all projects, including Waterfall, Agile and DevOps projects, can change direction or shape at any point. Budgetary and time constraints, may alter your test approach and how much scope of testing you need to do, therefore plans need to change in accordance with that. Be prepared for the test plan to be a working document and update it when necessary but don’t lose the fundamentals of what the desired outcome needs to be. Always remember to get sign-off when making changes.

It is however, vital that you have a good template throughout, so that you always start right and have the required sections in the template to allow you to be thorough and use the latest version of the document thus giving you the best opportunity to cover of all the details required for that testing phase. Starting with the right test plan template will give you the best opportunity to have a complete and thorough document every time.

Lower level details like the test case and test scripts sit outside the test plan and would ideally detail the inputs, execution conditions, testing procedure, and expected results of the test to be executed, in which the results would verify compliance with a specific requirement.

If you have a set of good test scripts, then you may want to automate them to save time and money. When working in an Agile or DevOps method, there can be a tendency to push through the latest development too quickly and without performing due diligence, focus, and attention to detail which will result in making avoidable mistakes and thus consequently will require even more time to complete the task satisfactorily.

Automation is a great way to reduce time and ensure consistent quality, but be careful as so many organisations get it wrong and spend unnecessary time and money in getting this right. Creating a robust framework is the first step in creating good automation. Automation greatly increases the speed of the testing process and shortens the testing lifecycle. Automation never sleeps, so you can run scripts at any time of the day or night, along with running automation around a range of machines and platforms at the same time. Obviously, automation test scripts run faster than executing them manually.

Ultimately, writing a test plan describes how you should test, whether you decide to manually test or automate or a combination of both, getting the test plan right and with enough detail is the key to success. Not only will it provide the guidance to the test team, but provide the relevant stakeholders with assurances that the overall organisational goals detailed in the test policy are being adhered to and core principals are followed.