5 Rules to the Road For Test Planning in Agile

agile test planning

In the traditional waterfall methodology of software development, there is an emphasis on defining detailed requirements of a software product before proceeding on to the design phase, which includes application design and test planning. Since the requirements of the expected product are well known up front when following the waterfall methodology, it is possible to define a detailed test plan that will require little modification during the lifecycle of the project.

In agile development, however, the requirements are teased out over the course of the entire project. Requirements are often written on a “just in time,” or “just soon enough to get to code” basis. While this has many business benefits, it makes the task of a Quality Assurance Lead very challenging. Test plans must be developed without a complete understanding of the scope of the project, and they must be adapted to meet changing requirements. Below, we will outline some best practices that we have found helpful.


The Three Pillar Way to Agile Test Planning

Three Pillar follows a set of best practices in Quality Assurance Testing that proves its value when delivering products to our customers. Test planning is an important milestone in the development process that needs to be very carefully planned. Here are five rules to the road for test planning in agile that we incorporate in every Three Pillar engagement.

1. Define a Test Strategy

While it may not be possible to identify the scope of items to be tested early, it is possible and in fact critical to project success to determine a test strategy. The test strategy should include:

  • QA Build strategy: Who is responsible for the QA build? At what points in the sprint will a build be delivered to QA? is additional hardware required?
  • Test data creation: In the early sprints dependencies between components that are still under development may require mocking up of test data. Or later on, in order to perform certain tests, such as performance testing, users may need to be loaded into the DB. The Test Plan needs to identify when Test Data may need to be created and who is responsible for creating it.
  • Types of testing and test tools: Who is responsible for unit testing? At what point in the product lifecycle will the product be stable enough to develop automated tests? What tools should be used for automated testing? What tools are to be used for performance testing? Most importantly, the Test Plan needs to ensure that time and resources are allocated to each of these testing types.
  • Integration testing: How will the interfaces between the product and external systems be tested? What tools will be used to test these interfaces?

2. Define Scope

In an agile development effort, QA takes place throughout the project, i.e., within each sprint. Every sprint, with the possible exception of “sprint zero” should have demonstrable code that can be tested. Since there are only a few days (typically 2-4 days) allocated to QA and bug fixing at the end of a sprint, the Test Plan needs to clearly define the expectations in terms of code quality for the sprint demos. It should also define the kinds of tests to be run during a sprint. Typically, the early sprints where a lot of new functionality is being developed will only have time for testing the “happy path.” As one gets to the later sprints, the code matures, and more time needs to be allocated for automated testing and performance testing, as well as negative testing. Depending on the overall complexity of the product, 1-2 sprints may need to be devoted exclusively to testing and bug fixing. It is important that the Test Plan tie in closely with the Product Roadmap, which captures the features planned for each sprint.

3. Be Prepared to Re-Scope Often

Because scope changes often during an agile development project, the Test Plan needs to be a living document that is updated to reflect changes in the project. For example, a decision may be made to expose backend functionality using REST APIs to allow for the creation of mobile and desktop clients. This may not have been in scope when the Test Plan was created. The Test Plan needs to be updated to include the different types of tests required to validate the REST APIs, such as security tests to ensure only users with the appropriate privileges have access to certain information, performance tests to determine how the system behaves under load, and negative tests to ensure the system can handle invalid data.

4. Identify Risks and Mitigation Strategies

It is essential that the Test Plan identify risks. A feature may be very complex and require testing multiple execution paths, for example, and there may be insufficient time allocated to test the feature. A mitigation strategy would be to allocate more resources for a short burst to do the testing or pick the execution paths that are most likely to be executed by end customers after discussion the risks with the client.

5. Have an Open and Continuous Feedback Loop

It is critical that the product be designed with quality in mind. Changes in product features or addition of new features impact the Test Plan and thereby product quality. Hence the QA Lead needs to be fully engaged in product decisions with product owners and development leads who in turn need to take QA testing estimates into consideration while developing/changing the Product Roadmap.

As with most things in life, there are countless other rules to the road that can and should be followed when QA testing software products in an agile environment. Even if these are the only five tenets you follow, though, you’ll be off to a good start.

Sabin Pilipautanu

Sabin Pilipautanu

Engineering Manager

Sabin Pilipautanu is an Engineering Manager in 3Pillar’s Cluj, Romania office, and the head of our quality assurance competency center. As Engineering Manager, Sabin is responsible for collaborating with all members of our software development teams, including software architects, developers, and quality assurance testers. He works with our clients to help formulate and plan major software development initiatives into version release plans then oversees development of those development projects in an agile development environment. As head of 3Pillar’s quality assurance competency center, Sabin is responsible for establishing corporate best practices for software testing across a variety of platforms. This includes implementing best practices and conducting training for test strategy, test planning, mobile testing, test case design and reporting, and automated testing. Sabin has a BS in Mathematics from Liceul Teoretic Ion Luca Vatra Dornei in Romania.

3 Responses to “5 Rules to the Road For Test Planning in Agile”
  1. Ashish Chaurasia on

    How to proceed and implement Agile Methodology for Testing?

    Reply
  2. Charles Emer on

    I need the full copy

    Reply
  3. Cedric Johnson on

    Since Agile methodology allows for changes and QA manages those changes in a living test plan, when the scope changes and requires unplanned QA work in the sprint to be consumed how is this managed, so the spint is not busted? Our experience has been to align the changes in subsequent scripts, not to disrupt the sprint in process. This has the tendency to impact sprint cadences

    Reply
Leave a Reply

Related Posts

4 Reasons Everyone is Wrong About Blockchain: Your Guide to ... You know a technology has officially jumped the shark when iced tea companies decide they want in on the action. In case you missed that one, Long Isl...
3Pillar Recognized as a Leading Experience Designer by Forre... Fairfax-based product development company named to its second Forrester report in 2018 FAIRFAX, VA (June 18) - Today, 3Pillar Global, a global cust...
3 Cloud Optimization Projects That Will Pay for Themselves i... AWS introduced 1,430 new features and tools in 2017, including 497 in the 4th quarter alone. This means that it can be a challenge for even the mos...
The Connection Between Innovation & Story On this episode of The Innovation Engine, we'll be looking at the connection between story and innovation. Among the topics we'll cover are why story ...
Go Native (App) or Go Home, and Other Key Takeaways from App... I just returned from my first WWDC. I feel like I learned more in a week at Apple’s annual developer’s conference than I have in years of actually dev...