Wouldn’t it be nice if I had the definitive answer! Well certainly do have an answer, but whether it is something you agree with I shall leave up to you to decide, here are my thoughts on it anyway:
I believe that the key to successful test automation begins not with thinking about “how” to automate but instead concentrating on “what” to automate.
Do not start by thinking about the tools you are going to use, whether it be Selenium, WatiN, WebAii, Project White, <InsertYourFavouriteTestToolHere>, but focus more the input into the automation process. You have to look to the start of the development process, the requirements capture, and ensure that your approach to this provides you with a solid foundation for the creation of automated tests. If you are already on an existing project and you are looking to implement automation try not to be overwhelmed by the sheer scale of the task. You can very easily be “scared off” of implementing automation because it just looks too big but as with anything in Agile by taking small iterative steps and learning from your mistakes you can start to make a dent and let’s face it any automation (done right) must be better than no automation?
You do not need to commit to automating everything straight away but you can start to make your requirements more automatable. Avoiding the ‘overwhelm’ of automation is an important part of making the first steps into reducing your technical debt.
How do I make requirements more automatable?
There are numerous theories on how this can be done but the theory I prefer is to use Behaviour Driven Development (BDD) and it is something I truly believe can help to bridge the communication gap, reduce time spent maintaining requirement specs and increase the team’s overall understanding of the business requirements and therefore lead to a better implemented product.
Now I do not profess to be an expert in BDD in anyway but this is my general understanding of the concepts:
“Software delivery is about writing software to achieve business outcomes” – Dan North
Dan North is generally considered to be the father of BDD and a simple Google search on his name will reveal numerous articles on the subject and I would encourage any reader of this article to take a look at his blog and specifically introducing BDD. The concept behind BDD is that is takes the idea that you “can” turn an idea for a requirement into implemented, tested, production-ready code simply and effectively and in order to achieve this any requirement needs to be specific enough so that “everyone” knows what is going on. The overall goal of BDD is to achieve a common definition of “Done” in order to avoid “that’s not what I asked for” or “I forgot to tell you about this other thing”.
BDD takes the general Agile concept of User Stories and looks to extend them with acceptance criteria that is defined in the form of scenarios, a typical BDD user story is defined as follows:
Title (One line describing the story)
Narrative:
In order to [benefit]
As a [role]
I want [feature]
Scenario 1: Title
Given [context]
And [some more context]
When [event]
Then [outcome]
And [some other outcome]
Scenario 2: …
By working together to define a user story and all of it’s associated scenarios the team gains more knowledge of the requirement and they have one place (the user story) that can form the focal point for the definition of the feature. Any new scenarios that are thought of at any point prior or during the iteration should be added to the user story at the very least as a Scenario title that can be expanded at implementation time.
Who writes the user story?
This seems to be a common question especially amongst new Agile teams and I believe the answer is that everyone writes the user story. That is not to say that everyone writes the story at the same time but that the story will evolve over time and become more detailed as it touches on each discipline within the development team.
- Product Owner communicates with the Stakeholders and help them to frame the narrative i.e. what is the high level feature?, and capture salient elements of that story in an informal way – the stakeholder does not always want or need to get bogged down in the language used to formally define a user story and scenarios
- Testers help to further define the scope of the story and extract acceptance criteria by determining which scenarios matter and which are less useful
- Developers may provide alternative approaches to delivering the story which in turn may influence the structure and focus of the story
More complex stories should involve whiteboard discussions to ensure that each member of the team has a common understanding of the story. Whether the story is elicited from end to end in a single meeting or over numerous time boxed iterative reviews the key to delivering a successful user story is communicating with the stakeholder to ensure that what you intend to deliver is what they expect you to deliver. Obviously in order to achieve this giving the team as much access to the stakeholder as possible would be ideal but where this is not possible then the Product Owner should take responsibility for ensuring that the stakeholder is kept up to date with any changes to the story definition.
Elaborating and formalising the story
The output from the story elicitation meetings will generally be in the form of a fairly loosely defined story with some informal concepts and ideas that capture the essence of the story and promote discussion about the key areas of the feature. The next phase is to begin taking those ideas and formalising them into well defined scenarios using a Given, When, Then (GWT) notation.
The goal of using GWT steps is to achieve a common language to describe the domain in which the feature exists. Having a structured common language makes automation far more achievable because it begins to make each team member talk using the same business terms and it defines steps that may apply to numerous test steps and aids the longer term maintainability of the specifications. By defining the feature in business terms and not being implementation specific you can achieve scenarios that are robust on top of an ever changing system – the goal of the feature should not have to change even if the application is re-written from a web app to a WPF app. “How” you prove that the system still meets the expected behaviour may change but the definition of “What” the system should do should remain fairly consistent and this should be a design goal when creating scenarios for your user stories. This blog post is a useful read to clarify the domain of a specification who's domain is it anyway.
Summary
Getting a handle on your requirements will play a major role in your ability to automate your acceptance tests and start on the road to reducing your technical debt, but once you have laid the foundations you will begin to see the opportunities to automate open up and become apparent in ways that you never thought would be possible.
Next Steps
Why not take either a new requirement or a relatively simple existing requirement and focus some energy to make the requirement more automatable, can you apply the ideas promoted by BDD to your user stories? Have a play with different ways of expressing your scenarios in the Given, When, Then format and then start to capture user stories in this format in your next elicitation or elaboration sessions.
In my next post I’ll discuss some practices to help getting automation done within the time scales of an iteration.
No comments:
Post a Comment