We’re going to use Janet’s latest model about holistic testing, to talk about specific practices that we use in different stages of the lifecycle. In this post, we extract the left top part of the infinite loop, and talk about testing early – in discovery and planning.
There are many different techniques to bring diverse team members together to talk about testing and find ways to deliver better outcomes for our customers. Because every organization and team have different contexts, we hope this look at testing can help you think about your own team’s test ecosystem.
Product managers engage in discovery activities to determine what value a particular feature offers to their customers and the organization, and what that might look like. This works better when delivery team members get involved, asking questions, and offering suggestions based on their own experiences.
Visual tools like mind maps can help to visualize how big the feature might be? What does it consist of? Keeping the implementation details out of this discussion helps focus the discussion on business value. Once these aspects of a feature are visible, teams and the product manager can make decisions about what is immediately needed, and what might be pushed out to a later release. We can test this artifact by questioning some of the assumptions behind the ideas.
In the planning stage, we can get into more detail. Identifying risks is a big part of the value added here. We talk in more detail in our Donkeys and Dragons video chat #4 on our YouTube Agile Testing Fellowship Donkeys & Dragons channel if you want to hear more.
Testing early includes testing assumptions. We all have biases based on our own experiences and make assumptions. Janet wasted about an hour last week based on an incorrect assumption. Fortunately, she realized her error and sent her client a quick email to check that assumption. She could have wasted a lot more without that simple test. If you think you have a different impression of a feature or story, ask the question. Be brave.
In planning, teams break features into stories – smaller bits that are easier to digest. However, often these stories are not testable. This leads to stories that need to wait for other stories to be complete before they can be tested. This results in delays, bottlenecks, slow feedback. Janet worked with a team that identified all these issues in one of their retrospectives and wanted to address these very real problems. Janet suggested they take their next feature and try using a flow diagram to visualize what it might look like. This flow diagram showed how many complexities they would need to address, so they identified the core – a slice through the application (or as we like to call it, the steel thread). Often this is the happy path. As they continued to identify the added complexities (new stories), Janet got some push back from the programmers.
They said, “But that’s not how we code”. We always do the configuration first, but now you are asking us to go into that file for every story. Janet brought them back to why they were doing this experiment – the retrospective issues, and after some discussion (some heated), they realized that this practice enabled the testers to give them faster feedback, so they agreed to try.
Small testable stories are the key to being able to complete the stories in a timely way. In the story above, the team never went back to component level stories. They quickly realized the importance of working with the whole team to slice the stories.
Another practice that is useful during planning is to visualize dependencies using dependency mapping – We’ll make a separate blog post about that next month.
Every testing activity we do is for the benefit of our delivery team and our customers, whether it’s automating repetitive tasks or creating a test strategy. Experiment with techniques that bring your whole team (or a representative cross-section, if your team is too large) together to learn what valuable feature you can build for your customer in small increments, getting fast feedback as you go. Visualization activities like dependency mapping and structured ways to explore requirements such as mind maps or flow diagrams are just two examples. The key is getting people with diverse viewpoints and skill sets talking, drawing and experimenting together.