Skip to main content
 
nz

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page


INSIGHTS / Articles

Lightweight Agile Test Planning

 6 Jul 2020 
Lightweight Agile Test Planning Lightweight Agile Test Planning
Lightweight Agile Test Planning
INSIGHTS / Articles

Lightweight Agile Test Planning

 6 Jul 2020 

Test planning, and for that matter, test strategy, needs to be more lightweight within Agile product delivery. In fact, the discussion and thinking about the best approaches for each has always been the key to driving the documentation.

However, so many test managers I have seen think test planning is simply taking a template and filling in the details to create a 30-page document, and that is the end of planning. That is wrong on many counts, as test planning is a continuous activity.

Both the strategy and plans should be living documents, updated as teams learn more. Therefore, it is good to move process and practice detail out of strategy and plan documentation, and into a Wiki where it can be updated based on feedback from retrospectives and chapter/guild/community of practice forums.

I know historically test plans have gone in a directory and probably never ever been referenced again, but it is important that these are living documents. As we discover new things, or learn and experiment, we should go back and update the plan, even if it is just to annotate your diagram.

Agile test strategy

Once an organisational test strategy is produced, the teams then just need to state any variance. This should, of course, be aligned to the test policy, which in itself is lightweight. I would recommend a couple of pages. Maybe even turn it into a poster which can be added to team walls.

You also may have an Agile test strategy, but it is going to be more lightweight. It may be at an organisational level, but it is important again that we reference back to this test strategy. If we have any variances for a particular product delivery, or even if just for this iteration, it is important that we document those variances.

Building quality in from the start

One of the techniques that I use with my teams is brainstorming sessions within the iteration planning meetings for each iteration. This means that the whole team discusses building quality in, and how they all (not just the testers) can help to meet the iteration goals.

I use a mind map to capture this as our discussions happen. That means, by the end of the meeting, we have an agreed plan that the whole team has committed to, and any issues/risks have been identified. No additional work is then required to write this up – it is simply saved into our tool/Wiki, either the map itself (if using a mind map tool), or a photo of the whiteboard.

This is an example of a partly completed iteration plan:

Session planning template

I have developed a template over the years that I use as a starting point for each planning session. The user story goes in the middle bubble, or if you are doing it at iteration level, then the iteration number you are planning for.

It is a very effective way to capture your planning, and it will obviously evolve over time. I use a template, just so that we cover everything in our planning session. I suggest that you develop one that suits your context.

When you are first starting to experiment using this technique, I recommend doing it at a user story level. As it becomes habit, you may be able to abstract out to the wider iteration level.

There are some key areas that I start with, and are normally always in the product:

  • Layout
  • Navigation
  • Business rules
  • Connectivity
  • Compatibility
  • Accessibility
  • Performance
  • Security

Take each one of these that is appropriate for your product context, and iterate around them so that you have branches coming from the middle. The idea is to discuss each of these as a team and capture appropriate levels of detail.

As a by-product of doing this type of lean test planning, you could also get:

  • Design ideas
  • Product risks
  • Clarification of requirements from the Product Owner
  • Testers driving delivery of code to them
  • Prioritisation of user story development
  • Better unit test coverage
  • “Automate first” practises (no need to take manual tests and automate these, but decide which tests to automate and just do that)

You can also get a view of who can start with what and some tasks to add to the board. It may also get you started thinking, as a team, about test data and who/how it can be sourced or generated.

Make sure that you speak with your compliance/audit team to ensure that any changes that you are making to your process, practices, and templates still fits with what they require. I have found that every time I have approached them to discuss, they have been more than happy to endorse these changes and, in fact, welcome them. Often, traditional test assets contain more than they need to, so leaner assets help them.

A mind map may be a big change, so you may find that you need to capture details in a more traditional Word template form as an overarching test plan. This should still only be a few pages, however.

This then means we have removed the obstacles for testing, and ensured that, as a team, all of the quality activities have capacity and capability within the team (not just assigned to testers) in order to be completed within the iteration.

A lighter approach

Agile has the ability to make test planning faster and more efficient, but only if it is done correctly. It can be very easy to fall into the trap of trying to do too much in too short a time, when a lightweight approach can often achieve the same outcome with less effort.

The steps outlined in this article are just some of the ways to simplify Agile test planning for better results. Getting certified provides a solid foundation for individuals to build their test planning skills, while organisations can unlock further efficiencies in delivery and quality with the help of our Agile expertise.

Leanne Howard

Business Agility Practice Director

Embed Quality in your Agile Delivery

No matter where you are on your Agile transformation journey, we offer a broad range of consultation, assessment, training, and coaching services that enable your teams to deliver better outcomes faster, embed quality in every iteration, and adopt 'shift left' practices.
 
Find out how our Agile Quality experts can help you understand your Agile maturity and fast-track your journey to Agile success with quality embedded throughout. .

 

Find out more

Get updates

Get the latest articles, reports, and job alerts.