Testing the Big Picture on Agile Teams
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the top seven agile testing success factors that we talk about in the summary chapter of our book Agile Testing: A Practical Guide for Testers and Agile Teams is “Look at the Big Picture.” In that section we talk about using the agile testing quadrants to help think about all types of testing, and how to keep the customers’ point of view.
Risks of Losing the “Big Picture”
We use “feature” in this article to mean some business capability, perhaps an epic or theme in Scrum. One of the biggest problems we’ve seen on many agile teams is forgetting the real business value of the feature they are developing. We call this risk “forgetting the big picture”. Teams break up a feature into tiny stories and then make sure they test the functionality on each individual story. Even with all the testing done for each story, the team may deliver a feature that has outstanding issues, or does not meet the customer’s expectations. We have to balance the fast feedback of working in small increments and iterations with ensuring that the overall feature delivers adequate business value.
User stories should generally be small enough to complete in two or three days. During an iteration, the team focuses on their current stories, making decisions about acceptance tests and code design. However, these stories represent the tip of the iceberg – there’s probably a big feature lurking just out of view. In the process of slicing a feature into manageable stories, it’s easy to leave some gaps. We have to find ways to keep the end goal -- the purpose of the overall feature -- in mind.
Paradoxically, it’s hard to learn how to think in small chunks and thin slices when it comes to breaking up features and stories. Janet recently talked to a team that is still struggling to define a release scope. They haven’t gotten the idea of thin slices, delivering small complete pieces, and adding more incrementally until they get something that meets their needs. When you try to deliver a feature all at once, you’re likely to not finish it at all. But once you do master the art of incremental and iterative development, you must find ways to keep the overall feature visible.
An “Aha” Moment
Janet gained insights into “big picture testing” while on vacation at her family’s country cabin. Here’s her story.
I was relaxing at our cabin and pulled out a jigsaw puzzle. I dumped the fresh puzzle on to the table, looked at the picture on the box – my final goal, the release acceptance test if you like – and tried to decide how to sort the pieces. There is no one correct way to do this and everyone has their own method. The only consistency that I have seen is everyone tries to make sure they get all the outside pieces separated.
As I began sorting puzzle pieces, I found that it was easier than normal even though there wasn’t a lot of difference among the pieces. I realized it was because I was making all the decisions myself, and didn’t have to explain my thinking to anyone else ... and that got me thinking. I started to think of this process as if I were a Product Champion. What was going to be in this release? My piles of pieces were pretty generic with little understanding of what the details were. I believe this is why I found it helpful to do it alone – I had no real idea of what I was doing, I was only starting to understand the bigger picture.
Once I got all the pieces into my initial six piles, I was able was ready to start collaborating with others to get more ideas in play. Was my thinking correct? Did they understand my ideas and why I sorted them into those piles? Could I explain my vision so that others could help me put it together?
Since I was alone, I started by framing the puzzle, putting together the outside pieces. Of course, it did not work the first time. I desperately wanted someone to challenge my thinking – where did I go wrong? Instead, I got up, walked away and came back a bit later to see where my issues were. All the pieces were there, just not quite in the right places. This is what I like to see in release planning sessions – looking at the big picture, where are the holes, what is missing.
Once the frame was done, I looked at the other five piles trying to decide what the most important thing was. To me, the most important part of a puzzle is the “core”, what makes the picture.
In this puzzle, I chose a simple well-defined area to start with. I started with the simplest “story”, the mirror. It was then easy to continue and add complexity. There were some that didn’t belong to this feature, so I put them into a ‘backlog’ to be grabbed later when I found somewhere they belonged.
As I was going through this process, it dawned on me that this might be an easy way to think about creating stories. Don’t try to look at the whole picture at once, but tackle each section a bit at a time. Keep breaking it up smaller and smaller. It becomes much easier to deal with. Eventually, it gets put together and you have your big picture. It is important to keep the big picture in view at all times, but work on small chunks ... one piece at a time.
Identifying the “Big Picture”
These are various levels of precision: release (or project) / feature / story. We need to consider various tools to represent the levels. For example, we can use a context diagram to look at the interaction with other components or human interfaces at the project or feature level.
At the feature level, we need to understand what problem the customer is trying to solve. Ask your stakeholders how they will measure the success of the feature once it’s delivered to production. What are the hoped-for outcomes? How do we know when the feature is “DONE”? Turn these outcomes or examples into acceptance tests. At the story level, ATDD (Acceptance Test Driven Development), BDD (Behavioural Driven Development) or Specification by Example are effective ways to define detailed business-facing tests so that developers can design the code. We can use a similar approach to define feature-level acceptance tests.
As testers, we sometimes want to dig into details right away, especially those smelly areas of the code where problems wait to be discovered. But we have to consider the context of each small increment of functionality that we test. Do break features into small stories, but don’t lose sight of the overall goal.
Defining “Big Picture” Tests
In specification or story elaboration workshops, we start with a feature, decompose it into stories, and write customer-facing acceptance tests to drive coding on each story. Too often, we lose or forget to keep that feature in mind when testing. What if we created acceptance tests – both desired and undesired behaviour – at the feature level? These give us a way to test the “big picture”.
Let’s go a step further. When decomposing a feature into stories, try creating an extra story to “Test Feature A,” which should include the corresponding feature acceptance tests. In our experience, the idea of creating a “Feature DONE” definition is powerful. We can apply many tests that do not make sense at the story level, but do apply to the feature.
The “Test Feature” story is prioritized after all the individual stories are “done”. Tasks for this story might include: Test browser compatibility, Perform load test, Automate GUI tests, Complete user documentation, and Perform UAT (User Acceptance Test). Testing at the feature level enables us to run these tests at the appropriate time. End users can be given the chance to test the complete feature and give timely feedback.
Adding acceptance tests to the feature and defining “Feature DONE” to include the tasks and tests that make sense at this higher level help teams to consider the big picture and the business problem that they are trying to solve.
Summary
When you start to test your next story, step back and think “big picture”. Consider not only the feature that it is part of, but the system as a whole. What are the system impacts, the business workflows or scenarios? Think about who or what, is using this feature and what other pieces is it interacting with, or what data it uses. As your team, including your customers, plans upcoming features and user stories, work together to identify tests that show the desired value is delivered for each. There are many simple tools like mind mapping, drawing flow diagrams of scenarios on the whiteboard, or story mapping that help teams explore ideas and business needs. Use all the tools in your toolkit to help you remember to look beyond the story.
References
- http://www.janetgregory.blogspot.com
- http://www.lisacrispin.com
- Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testing and Agile Team, Addison-Wesley, 2009
- Context Diagrams
- Gottesdiener, Ellen and Mary Gorman. “Slicing Requirements for Agile Success”. Better Software, July/August 2010. Available at: http://www.ebgconsulting.com/Pubs/Articles/
- Adzic, Gojko. Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications, 2011.
- http://www.agileproductdesign.com/presentations/user_story_mapping/index.html