Monday, December 24, 2012

Can we really automate the test plan?!

8-18-2012

Well let's see if we can!  As products or projects are being required to be released to the market sooner, regardless if you are part of a traditional testing or agile testing team, testers have been challenged with keeping pace of the required testing activities within the scope of a development project.  We need to encapsulate many of the traditional testing activities into even shorter time frames than we had before.  For some of us, many testing activities have been forsaken like test planning.  In it's antiquated state, a test plan can be a very detailed and information intense word document describing the scope and characteristics of the project/product/feature under test.  Let's be honest, we invest the time and energy to create it and utilize it but it is often neglected in re-use and often rarely/never read by non-testing team members.

If we need a refresher course or an introduction on what a test plan is, refer to http://en.wikipedia.org/wiki/Test_plan for more information.

In our ongoing endeavor to find ways to optimize the workload, test management systems have come to the rescue!  A good test management system comes with pre-defined forms that are customizable and as a bonus often include a WebService API!

I would begin by exploring robust test or life cycle management tools that allow you to customize the forms, create and perhaps populate custom fields and of course attach links and files.  Some of the leading test management tools like SilkCentral or TestDirector of course are quite robust in nature and provide features for test planning, requirements, and/or user stories.

I will not recommend a tool but I have used a few to accomplish a similar goal.

Leverage it by:
  • Customizing the existing form so that it can contain the data/information you would capture in your word document.  For agile testers, it may mean utilizing it as your testing checklist.
  • Utilize the field descriptions as a guide to what information should be captured.
  • If the test management tool includes a configuration or test environment feature, utilize it to define the test environments your product/project supports.  This can then be easily linked to your test plan.
  • If you require multiple test plans for multiple product configurations or projects, you can inherit it from a template or previously created plan and leverage some of the predefined information to help build new test plans.
  • The email feature can be used to notify other team members of the test plan's creation and modification.
  • Leverage the WebService API to get information from the test plan that can provide input to the test automation framework or other reporting requirements or even other required documents produced by other teams.
If you are a pure agile shop, think of the time saved by combining the epic/user story with the test plan.  Here you can truly support TDD techniques by defining test characteristics at the time the user story is being created.  I have also found it to be a proactive approach in predefining test cases, also captured in the test management tool that can be used for any type of testing including automated tests.  But that is another topic :).

Utilizing this method, you can easily link the test plan to dependent artifacts such as the test cases, releases, builds etc as well as to non-test activities and hence make it a very usable part of the project's/product's information flow as well as creating the required tracibility that helps us better track dependent information as well as evolving and expanding the test coverage.

Regardless if you are a traditional tester or an agile tester, this method can truly reduce waste involved when creating and maintaining test plans.

No comments:

Post a Comment