5 Rules to the Road For Test Planning in Agile

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, youll be off to a good start.