Graphic Recording of Awareness Session at Agile Testing Days

I attended Rob Lambert’s session “Do agile teams have wider awareness fields” at Agile Testing Days in Potsdam, Germany in November this year. The ‘doodle’ I have included in this blog is from that session. I learned about this medium from ImageThink who recorded all the keynotes at the Oredev conference in Malmo Sweden, and gave a session on how to do it. I don’t hope to compare my scribbles to theirs, but I did find it an interesting practice. My test was to leave my book alone for 2 weeks and then go back and see what I could understand. Here’s my takeaways from Rob’s session.



To broaden one’s awareness, we need to widen our choices, and surround ourselves with different types of thinkers. Too often, we concentrate or focus on an idea too narrowly and then are constantly surprised by the outcome. Rob suggested creating a learning time line – what do you want to learn, and then set yourself some ideas about how to get there. That way you can slowly move items from the “Can’t Do” list to the “Can Do” list. The first step is awareness. Only when you can see choices, can you begin to accept. Start with yourself, and then start raising awareness to the team, and so on. In my classes, I talk about scope of control, and Rob pointed out when you think about concentric circles in your scope of control, you see that when you widen your awareness, you can widen your influence. Of course, there can be a downside of too much awareness – information overload.

I think I need to keep practicing with this medium, but I found I remembered most of it. If you follow the Rob's link, you can find the slides there.

Testing the Big Picture

One of the top seven success factors that Lisa Crispin and I 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". 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.


This means understanding what problem the customer is trying to solve with each new feature. One practice I have been coaching teams to try, is defining acceptance tests at the feature level (or theme / epic if you are practicing Scrum). ATDD (Acceptance Test Driven Development), BDD (Behavioural Driven Development) or Specification by Example all talk about defining tests at the story level. We often forget about the feature level – the bigger picture. How do we know when the feature is “DONE”?

In specification workshops, we start with a feature, decompose it into stories, and often lose or forget to keep that feature in mind when testing. Now, if we created acceptance tests – both desired and undesired behaviour – at the feature level, then have something to test.

When we decompose the feature into stories, I suggest creating a story to “Test Feature A”, with the corresponding acceptance tests. I have found the idea of creating a “Feature DONE” definition to be very powerful. There are many tests that do not make sense to do at the story level, but apply to the feature. Many of the Quadrant 4 (technical facing tests that critique the product) fall into this category. Some examples are load tests, usability, and browser compatibility.

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, Create user documentation, and Perform UAT (User Acceptance Test). Testing at the feature level enables us to run these tests when it makes the most sense. End users can be given the chance to test the complete feature and give feedback as soon as it is complete.

Adding acceptance tests to the feature, defining Feature DONE to include the tasks and tests that make sense at this level helps teams to consider the big picture and the business problem that they are trying to solve

Choosing Functional Test Tools for Large Organizations

In one of my tutorials at StarWest 2011, someone asked the question about choosing tools – specifically functional automation tools. I do believe teams should chose the tools that work best for their application, but sometimes we have to think beyond our immediate project team.


As large organizations adopt agile, many are running into a common issue where each team wants to choose their own tool – after all, they are supposed to be self-organizing? I think this might be a bit short sighted.

One of the premises of eXtreme Programming is shared code ownership, and if you ask any programmers working on one product, they will all be using the same tool for their unit tests. For example, jUnit if they are coding Java. They may use different IDEs (editors) but the unit testing framework remains the same. We need to apply some of those ideas to choosing our functional test tools.

If we think about an extended team, say one that included the support or operational folks, would we still want each individual project team selecting a different tool? If multiple teams are working on the same product, can we really support the automated regression suite mixed and matched arbitrarily?

One suggestion I have for organizations facing these problems is to define a class of tools for teams to select from. For example, for API level tests, you can choose from FitNesse or Cucumber or for tests through the GUI, Selenium or Ruby and Watir. One way to determine these selections is to have product teams experiment with several tools, and then compare pros and cons, and select one for each type of testing they want to perform.

It is important to understand who will using them, and the teams they impact.

I am a member of the Community of Thinkers

Jean Tabaka, Liz Keogh and others devised this statement and to me, it expresses the power behind a community of like thinkers. Patrick Wilson-Welsh mentions the idea of Network Weaving on his blog, and I like that idea as well; that also resonatated with me.

Thank you Jean, Liz, Eric, and others for sharing.

--------------------------------------------------------------------------------

A Community of Thinkers

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders. 

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

--------------------------------------------------------------------------------

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Jigsaw Puzzles & Small Chunks - The Ending

I was not able to finish the puzzle I described in the previous blog during the week I was at the cabin, but I decided to finish the story. One of the reasons iterative & incremental development is so powerful is that we can deliver the highest priority items first. Although I didn’t finish the puzzle, the pieces that I did get put together were my highest value sections. I decided to show you as much as I completed, along with a copy of the picture as it would have looked. You may not agree with my decisions on what was the most important part of the puzzle, I was happy with what I had completed within my allocated time frame.

Jigsaw Puzzles & Small Chunks

One of the hardest things I find to get people to understand is how to think in small chunks when it comes to breaking up features and stories. One company I was recently talking to is still struggling on defining a release scope. They haven’t gotten the idea of thin slices, delivering small pieces and adding more each time until they get something that meets their needs.

Last week I was at our cabin and pulled out a jigsaw puzzle. I love doing them, but the only time I seem to tackle them is when I am there. This time, I was all alone when I dumped the fresh puzzle on to the board. I looked at the picture – 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. Everyone has their own ideas. The only consistency that I have seen is everyone tries to make sure they get all the outside pieces separated.

As I began sorting, I realized that it was easier than normal even though there wasn’t a lot of definition difference between pieces. I realized it was because I was making all the decisions and didn’t have to explain my thinking, why was I putting that piece in that pile, etc. ... and that got me thinking. I started off with 4 piles – the outside pieces, the ones that were mostly white, the beige coloured ones, and the shaded browns. As I sorted, I added piles because I started to see differences that I hadn’t before – the curtains, and shaded gray pieces. I started to think of this process as if I was a Product Champion. What was going to be in this release – my initial thoughts, and then a bit more detail as I considered options. 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 6 piles, I was able was ready to start collaborating with people, and 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 had extra pieces that didn’t quite fit, and others that were missing pieces. 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. If I am doing a landscape, the buildings or highlights are the most critical. If I don’t finish the sky, I don’t think my puzzle is incomplete – the challenge for me is not trying to fit like colour pieces. It is tedious work that is a ‘try it’, ‘does it fit’ kind of effort. To me, that is low business value and I will happily put the puzzle away without completing a sky.

In this puzzle, I chose a simple well-defined area to start with. These pieces were in the beige coloured pile (my feature). I divided this large pile into 4 smaller piles and started with the simplest “story”, the mirror. It was then easy to continue and add complexity, the rest of the beige pieces which belonged to a couple of picture frames, and the background wall. There were some that didn’t belong to this feature, so I put them into a ‘backlog’ to be grabbed later when I found something useful they belonged with.

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.

The Power of Personas in Exploratory Testing

There are many great articles and books on exploratory testing and I’m not going to try to explain what other people do better. What I do want concentrate on is the power of approaching your exploratory testing from different persona’s point of view. It occurred to me that I haven’t heard people talk much about it lately and decided to raise the awareness of this easy but powerful tool.


Exploratory testing belongs in Quadrant 3 of the Agile Testing Quadrants – Business facing tests that critique the product. You can see more about the quadrants in Brian Marick’s blog “My Agile Testing Project,” http://www.exampler.com/old-blog/2003/08/21/ or in our book “Agile Testing: A Practical Guide for Testers and Agile Teams”.

I guess the first time I heard about it, was at the Canadian Agile Networks workshop in 2005. At that time, I was very interested in the cultural aspect of agile. Jonathan Kohl’s position paper was Exploratory Testing using personas, which can be seen here http://www.kohl.ca/blog/archives/000095.html. Since then, other people have touched on it as well. For example, Elisabeth Hendrickson in her presentation http://www.slideshare.net/codecentric/exploratory-testing-inagileoverviewmeettheexpertselisabethhendrickson


I understood personas much better after listening to people like Jeff Patton and David Hussman. Read up on Jeff Patton’s website- http://www.agileproductdesign.com/blog/agile_product_development.html

Using personas is a great way to help identify requirements but they can also help us test better. When I use personas to help identify test data and test scenarios that I (as a tester) had not thought about before, it helps me get better test coverage. To do this, I need to understand our customers – both internal and external. The marketing folks are often the ones who create the external personas, but sometimes overlook internal customers like administrators.

In agile projects, we encourage testers to help define the requirements by questioning assumptions. Personas are a great way to think differently. In a recent workshop at Quest conference in Boston, Ellen Gottesdiener demonstrated how testers can truly add value by thinking about different dimensions – one being the people. If we carry those thoughts after the code is built, and approach some of our exploratory testing from that perspective, we look at the product differently. For example, if am testing a shopping website as a “hurried working mom” as well as a “senior citizen”, I will be looking at completely different perspectives and may find different types of bugs.

There are many different ways to approach exploratory testing, and I encourage everyone to try lots of different styles.