Note: This article is based on ALMComplete, version 9.7.226
To continue the discussion began in this article, Can we really automate the test plan, I would like to both share and collaborate on an idea of ditching the idea of creating traditional test plans using MS Word or whatever word processor you enjoy using. I believe we can all agree agile has imposed new challenges on the Quality Assurance / Software Testing profession. Today, many of us are asked to cram an entire test process into short, time-boxed sprints of 2 – 4 weeks in length. So we must ask ourselves, what can we identify as waste in our testing process? What can we streamline that can help us to become more agile? I challenge the test planning process can be streamlined and made more effective and usable to the cause.
For the newbies, a test plan traditionally is a process of
- identifying the scope of the testing effort and the requirements for testing
- identifying the resources required
- prioritizing the test requirement efforts
- performing a risk assessment of the overall effort
- and perhaps even capturing the intended cases
Now wait, wait! Before you guys crucify me, yes some of our colleagues must write test plans because the effort is mandated by a company quality assurance process and/or external governing entities. If you must do this, then yes you must but then we can’t argue that it is a wasteful effort now can we? However, for those of us where the test plan is often an overlooked effort, then yes we can rethink how we create and use our test plan.
If we look at the basics of a product developed using an agile method, we are taking a planned release and dividing the effort into sprints that are governed by selected user stories as identified by an originating product plan. This entire effort has to be flexible to change. So looking at the very basics, we can do either release-based, sprint-based or user story-based test planning.
The benefit of selecting one of these methods is we can contain the scope of the test planning effort by selecting the best method that is a good fit for our agile team. Currently, I decided to use User Story-based test planning. Now that I have selected the test planning technique, I can customize ALMComplete to fit our needs (the ALMComplete administrator’s guide explains how to customize the product for your use).
Note: This method is not limited to ALMComplete. It can fit any test management tool that allows customization.
For my use, the Requirements feature was best suited for my test planning needs. It was easy to configure to support User Story-based test planning. So let’s step through how we can create a test plan in ALMComplete
Step 1 – Customize the foldersIn this example, the folders represent:
- the product under test
- the release of the product
- the pre-planned sprints for the release
Step 2 - Define your User Story-based test plansIn this example, a test plan was defined for each planned user story within the sprint.
Step 3 – Complete the test planThe requirements form was customized for our test planning needs.
The highlighted areas demonstrate an example of information we wish to capture in the user story-based test plan:
- Which product this user story applies to
- Reference to the actual user story as defined by a product plan
- We can define a number of items to help track required activities and can provide input into the team’s definition of done.
- We can leverage ALMComplete’s traceability features to link artifacts to the test plan, for example:
- What test environments do we require for testing (Configuration)?
- What release does this user story-based test plan refer to?
- What tests have we defined to verify the user story?
Some other ideas are to leverage the notes and files feature of the test plan to add additional information or link useful information, e.g. setup and configuration requirements of a test lab machine to support the test effort.
The benefits? Well let’s see,
- Deciding a test plan method automatically structures the scope of your test planning effort which can lead to saving time
- Test planning can more easily support changes to planned efforts
- We invest far less time in the test planning effort and thus reducing waste
- We have made our test plan visible and easy to find for all of our team members
- The invested effort to create the test plan is actually utilized and maintained through the life of the user story, sprint or release
- Changes to the form are more easily propagated to all created forms as well as support future test plans.
- One can leverage workflows to help automate some of the management of the test plan
- Team members can be notified of changes to a test plan
- Information can easily be defined to be reusable such as configuration information.
- The Definition of Done is a natural incorporation into the effort
- New test plans can be created from existing ones.
- Because ALMComplete has a webservice layer, you leverage it to help manage your test plans with any tool you are using like soapUI, TestComplete, Selenium WebDriver and more.
Perhaps my fellow testers you have other interesting ideas. Comment and share your ideas. I would love to hear them.