It’s not often in software development that one tool can ease the two leading concerns for teams developing and deploying a solution. For testing groups, communication and organization top the chart. Both are essential to create the highest quality mobile or web app in the least time. A software test plan template can help teams visualize, track and coordinate work from the creation of test cases through the documentation of access information.
Software teams know there are an infinite number of ways to tweak a process and get the job done — well. But, why miss out on the chance to lift the hood of another test plan and examine what makes the engine run?
In its simplest terms, a test plan lays the foundation on which quality software can be built. It captures the scope, technologies, process, resources, risks requiring contingency planning and schedule of testing activities. The document can be used to construct new software, to regression test or refactor a current solution.
Here we detail best practices to optimize the template.
Structuring the software test tool template
The plan begins by defining qualitative measurement metrics and visualizing priorities/statuses through color assignment, as captured in the Key tab.
Priorities
In the plan template, test case priorities can be marked critical, important and useful. Depending on the rigor of quality testing before release, your team may choose to validate all or, at a minimum, the cases marked critical and important. These designations can be selected from a drop-down.
Changes
The software test plan template also allows users to indicate the change frequency of each software component. This feature is especially important for teams relying on a risk-based versus automated testing strategy.
Risk-based testing is a tactic used by teams to schedule functional testing in order of priority. The method allows teams to manage budget and schedule, only testing the features most likely to be impacted by new development or critical to software function.
Implicit in its name, the strategy reduces overall risk by testing scenarios with the highest risk before the system is deployed. For risk-based testing to work properly, testing teams must be involved at the beginning of the software life cycle to fully understand the objectives of the project and prioritize accordingly.
The key benefit of risk-based testing: Testing is concentrated on critical functionality with focus given to the business risks of the project while delivering time and budget savings.
Option 1 – Changed several times: The functionality has been changed several times or built by different developers since the previous execution of the test case, so the test case must be executed with high priority.
Option 2 – Changed in this iteration: The functionality has been changed since the previous execution of the test case, so the test case must be executed with medium priority.
Option 3 – Not changed in this iteration: The functionality has not been changed since the previous execution of the test case, so the test case can be executed with low priority.
Actual results
Color designations for pass, fail, not executed and not implemented are also included as drop-down options within the software test tool template.
Identifying platform-specific test cases
Two tabs within the interactive planning deck allow for the identification and ordering of platform-specific test-cases. (iOS and Android are included.)
Project specs. In these test case tabs, the release platforms are captured (Mobile — iOS, Android or web) as are the OS browser versions (ex. iOS 5 +, Android 2.3 + / Chrome 29 +, IE 9 +). Additionally, test environments are identified where respective teams will be working.
Functionality. Here along with priority, change(s) and status, the name of the functionality/title of the test case, steps to execute, expected result and expected result picture can be logged.
The team would begin by identifying the functionality under test with a brief name, for example: Log in and forgot password. These descriptions can range from relatively simple directions to complex workflows.
A complex workflow for a property management app managing contractor tasks might read:
- Log in as PM, navigate to a property
- Create a new job with scope and change order
- Assign it to a contractor using a iOS device
- Tap on the created job
- Tap on the layout
- Add scope
- Go to PM web account
- Click on the added point
- Click update button
- Click ‘Accept Change Order’
Steps to execute. Teams would then list the details of the interaction chronologically in the Steps to Execute column for each test case. In our example, this may read, “The user navigates to the web solution, accesses the Home tab, attempts to enter password, then selects the ‘Forgot password’ button.”
Expected result. The expected result should explain, chronologically, the specific action the user should then experience after engaging with the software.
Expected result picture. Visualizing current results is a key component to delivering work the product team/client expects. Ideally, this picture would include the approved design. This can be added as a hyperlink or a screenshot.
Ordering pre-deployment tasks
The fourth tab in our software test tool template provides space for teams to organize a release validation checklist ordering the combination of iOS and Android test cases that should be executed before deployment. Here, some of the detail (including Expected Result and Expected Result Picture) is sacrificed to provide an aerial picture of final-pass testing tasks.
These tasks should be executed against the production environment. In ordering the Release Checklist, the quality teams and product owners must determine the depth of the pre-release effort being mindful of budget and timeline.
Summarizing the project progress and access
The Project Summary and Access tabs provide development highlights and access information at-a-glance for testing teams to use and/or provide to stakeholders at a glance.
The Summary tab provides an overview of test cases in each priority designation to be addressed in each Period (or phase) in development split out by operating system.
The Summary and Access tabs provide transparency into results and accounts should stakeholders need to review or access a given environment during development.
Why your next project needs a software test plan
1. Keep your test team organized and sane.
The software test plan template provides the document version of an air traffic controller affording direction for teams testing on-deadline with the ability to update and categorize progress visually.
Testing is complex and no team is perfect. Instead, they are human. Empower them with the resources to coordinate better and eliminate the potential for miscommunication.
2. Provide transparency as the project progresses.
The best software test plans are comprehensive, without superfluous detail. It should read simply, so if a decision must be made three quarters through the process, it can be shared with stakeholders for easy consumption.
3. Quick-draw project snapshots at the ready.
The test plan document provides scanable information for stakeholders to review in assessing return on investment, quality and effort invested — helping drive staffing and budget decisions that might otherwise be made without supporting data.
Where do you go from here?
Most teams consider the software test plan template a starting point. For optimal use, tailor it to the needs of your team. In some instances, our team has used it solely for regression testing or added additional features including:
- Story ID
- Business requirements
- Priority for automation
- Automation test case ID
Rather than organizing the test cases by operating system some teams also choose to break them apart by MVP phase. So, ready, set, test — smarter.
