Usually these test plan documents are comprehensive with a lot of information regarding scope, entry-exit criteria for each gate and phase of testing, testing types, environments, timelines, point of contacts etc.
So, is there a need to have test plans for Agile based projects? – Yes, depending on the nature of the project.
Do you need to carry over the traditional (waterfall project) test plan template for Agile projects? – A big No!
In this article I am not going to focus on the pros and cons of having a test plan template but rather the following:
- Why there is a need to a have a test plan for Agile projects when the changesare delivered to production in small chunks.
- When you need them.
- What constitutes a test plan? What is the minimum level of information a testplan should contain which would benefit your team?
Why There Is a Need to Have a Test Plan for Agile Projects.
Though the changes are delivered in small batches every Agile iteration, at the end of the day the customer will consume the feature only if the project is available end to end. Your team could choose to deliver the code to production every iteration but, in most cases the code will be in a ‘dark’ or ‘off’ state until the end to end functionality is available. Thus, the need to test the system as a whole and look at the broader picture in addition to focusing on the individual pieces of code modified by your team and a test plan should help you to envision this bigger picture right during the envisioning and definition phases of your project.
When do You Need Test Plans? What Is a Test Plan Anyway (in the Agile context)?
Irrespective of the size of the project and its impact on the system, some level of test planning should be done by the testers. Simple projects may warrant you to directly dive into the test cases while others may require high level planning across different layers in your system – in essence, your approach towards test planning would depend on the nature of the change. Having said that, your test plan need not be as elaborate as the traditional waterfall test plans nor does it need to be derived from a standard template. Any view that works for your team and helps your team to understand all aspects of testing is the way to go. Again your plan can be as simple as describing what areas in the system are to be considered for testing to having detailed information about the test cases. The point of the test planning process is for you to think through your testing and communicate your thoughts and expectations to everyone in the team early in the lifecycle, so the feedback becomes useful. How you plan to do this is totally up to you.
What Constitutes a Test Plan?
A test plan, in my opinion, should entail these fundamental areas:
What is the change about?
-
Describe the change from the customer’s perspective—why do you need this
feature? How will it benefit the customer? How will the customer use it? Testers
can obtain this information as early as the envisioning phase. - Provide links to the tool where the epics and story cards are created.
This section helps the tester to understand the changes from a customer’s perspective before diving into the functional and technical details.
Where are the changes made in the architecture? (Imagine an ecommerce website before reading through these bullet points)
-
Describe where the changes are made in the stack, what are the impacted hosts
and layers? - Is the code writing or reading data to/from your database? Is the schema
changing? -
If your system replicates data from the database(s) on a regular basis, then
are the schema changes carried over so the new data shows up in the replicated
database? - What is the impact on finance and accounting areas?
-
Are there any reporting needs depending on the tools used by your
organization? Examples: Cognos, Webtrends etc -
Agents-Do you need to provide any servicing to customers in which case the
servicing tool (used by agents) should be tested.
This section in the test plan will be very beneficial especially if the Agile teams in your organization are not truly cross functional, that is, they don’t have developers who make changes across the stack. In this scenario, QE can use This test plan to connect all the dots and ensure that end-to-end testing is conducted by all the teams involved or should be involved.
How is your testing planned?
Knowing what the changes are and where the changes are, determine how testing should take place.
- What are the different types of tests written? Examples below:
-
Where are the tests located and how can they be accessed? If everyone
reviewing your test plan knows where the tests are usually stored, then there is
no need to have this section.
Timelines and Logistics
Iterations and timelines may change as the team makes decisions about the releases. There is no need to talk about the release timings and other related logistics in your test plan unless absolutely warranted. When everyone in the team knows when a release is planned, there is not a need to document it.
Finally, the mantra is to cater your documentation to your audience and the feature under test thus keeping the test plan simple, clean and meaningful to your team.
About the Author
Manju Anandan