Wednesday, 2 November 2011

Given, When, Then


Back in May when I first started blogging about mind maps for software testing I stated that the maps don’t always explicitly state the expected results. As our maps evolved, we started to add in expected results.

Having expected results stated on the map is beneficial. Before I trusted the test team to understand the functionality of performing a given action. We have also started to share our maps with teams outside of organization that take care of testing that we cannot accomplish at our location. To be clear, trust is one of the most important attributes that a manager should have with his or her employees. :)

In August I attended Agile 2011. At a session presented by Elisabeth Hendrickson she taught us a very basic concept that I am sure that some in the room already knew. To me it was a valuable lesson. For the most part, I am a self-taught tester and there are always very cool basic tidbits that I am learning.

When writing Acceptance Tests, a simple and easy to use template is:

Given <a situation>
When <an action is performed>
Then <a certain expected result occurs>

During that session, I was thinking about our maps. I realized, why couldn’t I write the maps in this format as well?

I came back from the conference, created a template map, and shared it with my team. Using Given, When, Then format has improved our maps greatly. It gives the testers focus on what they are writing, and it is easy to expand our tests. What I really like is that each When (or Action) has a one or more expected result. In the past matching steps in test cases to the expected results was sometimes confusing. Different testers have different styles. Some testers would write a test step test cases, with 4 expected results.

Here is the basic template that I came up with. This template gives the testers a common syntax of how to create and update our test maps. In several cases the testers were already writing in this format without realizing this, there were just some fine tuning needed to update them.



What you might notice is that you can easily expand the branches and continue writing tests. Another option for those writing automated tests with tools such as Cucumber mind maps in this fashion would be a great front end for it. From Cucumber syntax I do see more possibility of expanding my template.

I will write more about priority of tests, etc in upcoming posts.  Thank you to everyone for your comments and questions here and on Twitter. Feel free to email me as well.

1 comment:

  1. Hope you could join the discussion on - Differences between Mind-Maps and Trees - in LinkedIn EuroStar group:
    http://lnkd.in/KCdZCz

    As you start going into all these details, it seems to me that you loose Mind Maps greatest advantage of graphical Visibility.
    Reading some of your earlier posts on the subject, shows that mind maps struggle with old limitations of multiple tools usage for result tracking and CM (next you might face wishes for traceability to requirements and bugs...), issues which were long resolved in most ALM tools.
    For Me, I still can't figure out, where Mind-Maps advantages end, and Tree like management begins - I assume it's a matter of amount of details which can no longer be presented graphically.

    ReplyDelete