Wednesday, November 13, 2013

Moved Blog to new location

Hello folks - For those visiting here - please visit instead. I have incorporated my blog into my website.

Friday, August 30, 2013

MOVED my blog


Hi folks - I have moved my blog to work with my website. Please visit me there at  . I hope you enjoy the new look and feel.

Sunday, December 30, 2012

Book Reviews: Discover to Deliver and Impact Mapping

I recently read two new books:  Impact Mapping by Gojko Adzic, and Discover to Deliver by Ellen Gottesdiener and  Mary Gorman.

I have posted both my reviews below, but I wanted to add a few words about the synergy I felt between them.  I believe that if delivery teams use both techniques – Impact Mapping to get a really good idea of what we want to build, and then take lessons from Discover to Deliver to consider different dimensions of what we are building, then teams can really learn to delight their customers.  Software development ideas do not stand still, and these books show that we should continue to explore new ways to always improve.

Impact Mapping – Gojko Adzic
Easy to read, but powerful concepts presented.  The first thing I tried after I finished reading Impact Mapping,  was to try it out on one of my own exercises.  I found it fascinating how differently I thought of what I wanted to accomplish. By creating a simple map of a real situation, I learned so many things that I hadn’t even considered. I do recommend trying to draw an impact map on something concrete to cement the ideas. 

I have used mind maps to get clients to think about areas that might be affected by new features, but impact maps go one step further. They give us concrete ways to consider how measurable goals are supported by stakeholders (actors), and how those actors are impacted (negatively or positively changed behavior) before we even think about the deliverables.

I believe this is what many teams are missing in their development cycle, answering the question “ Are they really building something that matters”.  In Impact Mapping, Gojko Adzic has brought together many ideas from different sources.  Simplicity at its finest – complex ideas presented in an easy to read manner.

Discover to Deliver – Ellen Gottesdiener and  Mary Gorman
When I was reading Ellen Gottesdiener and Mary Gorman’s Discover to Deliver – Agile Product Planning and Analysis,  I had my highlighter, pencil and my sticky notes ready and I’m happy to say that I have many little pink stickers pulling me back to areas of interest, along with the notes I made as I was going through it.  My library is filled with paperbacks (I’m not a fan electronic reference books), but I think this is one of my favourites as far as the feel of the book and the turning of pages.

There are so many very positive things about the book in general – besides the content. I liked the graphics at the top of the page so you could constantly see where you were in relation to the rest of the book.  I also liked the use of pictures to continually remind us of what we were focusing on.
There is a lot of theory for people who are new to analysis, but Ellen and Mary use case studies and practical examples to demonstrate exactly what they mean. For example, their example of a structured conversation walks through a very typical team conversation showing how complex a very “simple” story can be if the right questions are asked. They examine ways to look at the feature to bring out the important factors the team needs to consider.
Many software teams are good at creating software, but I see many of those same teams still struggle with creating the right value. Discover to Deliver helps with this aspect of software delivery. 
Many of the tools and techniques (summarized into one great section) should feel familiar to testers since they are many of the same ones we use to create tests. This book demonstrates how testers can add value by using those tools early to prevent defects or missing requirements.  If testers bring their testing mindset to the early structured conversations that Ellen and Mary describe, the results can be amazing.
Discover to Deliver is not focused on one delivery method but how to adapt to the one you are using. So much depends on your context and perspective, and I think Ellen and Mary have done a tremendous job of giving techniques and tips on how to adapt to the one you are in. I recommend this book to all team members to read. I’m sure each one will get something different out of it.

Sunday, December 2, 2012

View into test planning at the release level

View into test planning at the release level

One of the common pitfalls of agile teams is “Forgetting the big picture”.  Lisa Crispin and I wrote an  article for informIT in May 2012 .  Teams tend to focus on individual stories, and often don’t think about the feature or the system until the end game when they get ready to release to the customer or put it into production.              
Using a tool such as a test matrix at the release level gives the team a different viewpoint into the testing needed.   After the release planning meeting, the team usually has a fairly good idea of what will be included in the release. Plan a workshop for the testers, domain experts, in fact anyone who is interested.  The outcome of this collaboration workshop is a high level testing matrix. Start the workshop with a listing all the features  down the left side of a spreadsheet. Then add possible test conditions across the top.  Sometimes I suggest starting with a testing mind map to generate test ideas (see ). 

Leave open columns for adding extra test ideas, as well as rows for new features, and be prepared to cross off features that may be lowered in priority and moved to a later release.  Once the spreadsheet has been created, gray out the cells that are non-applicable. It gives an easy reference for what we want to think about when testing.  Here is an example with 3 features and some possible test ideas.
I find that this collaborative process is helpful in getting everyone involved and getting different ideas for testing.  The value for me is the planning effort. At this point, the team could put it on the wall and use it as reference, reviewing it with programmers or other team members.  However, I have found that there is another use for this test matrix.
Project managers find it a very useful tool to see progress at a high level if we color code the cells as the testing is completed. It is more of a “gut feel” or approximation than an absolute indicator.  The colors I have used in the past are:

If we look at the example matrix again, it might look something like the following once development has begun.

You can see at a glance that most of the testing for “Save customer information” has been completed, but we may want to visit security a bit more. There is also a major issue in currency for “Update shipping charges”.
I have used this tool in many of the projects I have worked in and had success with all. I suggest to all the teams I work with to find something simple to show visibility of testing at the project release level.  This is only one alternative.

Sunday, July 29, 2012

Upcoming public courses and talks

I’m getting ready to go on a 2 month road trip through Europe and South Africa. I thought I’d put my schedule up here so folks can join me at the place closest to them.

Aug 14-15th: Webinar: Automation on agile projects

Whole Team Approach to Agile Testing Course - Europe
August 27–29: Gothenburg, Sweden
     Sponsored by House of Test  (first time taught in Sweden)

Sept 11 – 14:  Oslo, Norway
     Sponsored by Program Utvikling

Sept 17 – 19: Copenhagen, Denmark
    Sponsored by Ative

User Group talks - Ireland:
     Sept. 25, 6:00 p.m.:  Dublin, Ireland
           AOL Global Operations Limited
           The Brunel Building, Block 7A
           Heuston South Quarter, Dublin 8
      Sept. 24, 12:00 p.m. (noon): Belfast,
           Holiday Inn Belfast,
           22 Ormeau Avenue Belfast,
           BT2 8HS, Belfast, Ireland

Whole Team Approach to Agile Testing Course – South Africa
     South Africa: sponsored by Growing Agile

     October 2-4: Johannesburg
    October 16-18: Cape Town

Monday, November 28, 2011

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.

Friday, October 21, 2011

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