Agile testing-Do we need test plans?

If you have worked in a project executed & delivered using waterfall model, you must be very familiar with the test planning process. Usually these test plan documents are comprehensive with a lot of information regarding scope, entry-exit criteria for each gates & phases 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 going to talk about

1. Why is there a need to a have a test plan for agile projects when the changes are delivered to production in small chunks?
2. When do you need them?
3. What constitutes a test plan? What is the minimum level of information a test plan should contain which would benefit your team?

1.0 Why is there a need to a have a test plan for agile projects?
Though the changes are delivered in small batches every agile iteration, at the end of the day, 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 ‘dark’ or ‘off’ state until the end2end functionality is available. Thus, the need to test the “system as a whole” & 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.

2.0 When do you need test plans? What is a test plan anyway (in 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 has 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 is considered for testing to having detailed information about the test cases. The point of “test planning” process is for you to think through your testing and communicate your thoughts & 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.

3.0 What constitutes a test plan?
A test plan IMO should address the “W”s of the planning process. These are some of the fundamental areas that a test plan can entail

1)What is the change about?
a.Describe the change from customer perspective—why do you need this feature? How will it benefit the customer? How will the customer be using it? Testers can obtain this information as early as envisioning phase
b.Provide links to the tool where the epics and story cards are created.

This section helps the tester to understand the changes from customer perspective before diving into the functional and technical details.

2)Where are the changes made in the architecture?
(Imagine an ecommerce website before reading through these bullet points)
a. Describe where the changes are made in the stack, what are the impacted hosts and layers?
b. Is the code writing or reading data to/from your database? Is the schema changing?
c. 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?
d. What is the impact on Finance and Accounting areas?
e. Are there any reporting needs depending on the tools used by your organization? Examples: Cognos, Webtrends etc
f. 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 end2end testing is conducted by all the teams involved or should be involved.

3)How is your testing planned?
Knowing what the changes are and where the changes are, determine how testing should take place.
a.What are the different types of tests written? Examples below

b. Where are the tests located and how can they be accessed?
If everyone reviewing your test plan is aware where the tests are usually stored, then there is no need to have this section.

4.0 Timelines & Logistics
As the team makes decisions about the releases every iteration & the timelines could keep changing as well, 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, who do you need to document it for?

Finally, the Mantra is to cater your documentation to your audience & the ‘feature under test’ thus keeping the test plan simple, clean and meaningful to your team.