Software QA FYI - SQAFYI

Testing the Big Picture on Agile Teams

By: Janet Gregory and Lisa Crispin

One of the biggest problems on many agile teams is forgetting the real business value of the feature they are developing. 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. This article covers how to balance the fast feedback of working in small increments and iterations with ensuring that the overall feature delivers adequate business value.

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.

Full article...


Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/

Testing the Big Picture on Agile Teams