Crests and troughs in the bdd journey
•Download as PPTX, PDF•
3 likes•873 views
This talk was given at Agile Testing and Test Automation Summit, Melbourne on 10/12/2015. Behaviour Driven Development aka BDD tests have come a long way. From being a buzzword at the conferences to becoming the de-facto way of writing tests. BDD tests act as a living documentation and provide tremendous value when done right. However, they can also become a significant bottleneck in smooth delivery of the software system if some of the anti patterns are allowed to creep in. Thus, as part of this talk we re-iterated the core principles of BDD and the best practices surrounding them. At the same time, we discussed the common anti-patterns that are usually found in the BDD ecosystem, and more importantly how can we abstain from falling in those troughs.
Recommended
More Related Content
Similar to Crests and troughs in the bdd journey
Similar to Crests and troughs in the bdd journey (20)
Recently uploaded
Recently uploaded (20)
Crests and troughs in the bdd journey
- 1. Crests and Troughs in the BDD journey Priyanka Bhasin @priyanka23 Jatin Bhasin @jatin_bhasin
- 2. Who are you? 1. Test automation? 2. Heard about BDD? 3. Practiced BDD?
- 3. Tester
- 5. Individuals and interactions over processes and tools
- 6. The agile umbrella Lean Kanban Scrum XP Crystal Lean Startup
- 7. eXtreme Programming (XP) • Pair Programming • Continuous Integration • Small releases • Simple design • Sustainable pace • Refactoring • Test Driven Development (TDD)
- 8. TDD
- 10. TDD vs BDD TDD building thing right BDD building the right thing
- 11. Behaviour Driven Development Behaviour-driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders”
- 13. Core principles
- 14. It’s all about behaviour
- 15. It’s all about behaviour
- 16. It’s all about behaviour
- 17. Where is the business value
- 18. Where is the business value
- 19. Where is the business value
- 21. The three amigos Business Analyst / Product Owner Tester Developer
- 22. AntiPatterns
- 23. AntiPattern.. what? …an antipattern was something that seems like a good idea when you begin, but leads you into trouble. Martin Fowler
- 24. BDD is a silver bullet The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
- 26. 3 amigos do not build it
- 30. Higher level scripting Language
- 31. Higher level scripting Language
- 32. And I wait for 10 seconds
- 34. Clients not interested • Clients don’t care about testing • Clients don’t write specification on their own
- 35. The more the merrier
- 36. Or this
- 37. Or maybe this
- 38. Benefits
- 39. Shared Knowledge
- 40. Reduced waste
- 43. …those who learned to collaborate and improvise most effectively have prevailed.” Charles Darwin
Editor's Notes
- Good afternoon all I am Jatin and I am Priyanka We both work at MYOB as part of different product teams and we are both passionate about the software quality And we also strongly believe that every possible effort should be made to bake quality in instead of trying to find out defects later. Behavior driven development which is popularly known as BDD has definitely proved helpful in our attempt of trying to build a quality product However we have also seen BDD making things worse for teams and that primarily happens if you overlook its core principles and fall into the traps of some of its anti patterns So as part of this talk we would like to reiterate the core principles of BDD and some of the common anti patterns that should be avoided.
- Before we begin we would like to know a bit about you Please raise your hand if Who here has done test automation – no matter which tool or platform Who here has heard or read about BDD – may be at a conference or read a blog post Who here has practiced BDD – the tool doesn’t matter Great, so it seems we have a good mix of attendees here and hopefully you will find this talk relevant.
- Let me start with the story of a very familiar guy here. Not very long ago this guy on the project team often used to miss the bus. He was none other than the tester on the team. He used to get involved very late in the project, and wont get enough time for testing, forget about automation. He used to get the product in his hands towards the end of development cycle. May be this was the first time in 2 years of development process that he got a chance to look at it. And now he was supposed to find out anything and everything that could have possibly gone wrong with it. Last minute deadlines Testing comes in the end No emphasis on collaboration Everyone work in silos Feedback comes in the end
- Testers in the end Working in silos Automation in the end of the cycle
- Thankfully we are well over with that, and now testing goes hand in hand with development One of the key values that agile manifesto proposed was Individuals and interactions over processes and tools With that in mind the workflow has changed a bit
- Yes there is a lot of collaboration and the delivery pace is now faster but even then the rate at which stuff is delivered varies from teams to teams. Even though all these teams are now following agile they are following different flavours of agile, they are following the one that suits them
- One of these agile flavours is XP No I am not talking about the Microsoft’s operating system. XP stands for Extreme Programming It is an Agile methodology that gives a lot of emphasis on the dev practices so that the overall software quality can be improved. As part of XP, you would have frequent releases and short development cycles. XP came up with a lot of new practices such as pair programming, continuous integration, refactoring and Test Driven Development or TDD TDD has played an important role in enabling teams to achieve short development cycles
- As part of TDD – first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
- Now BDD takes this pratice of writing test first to a new level altogether. BDD focuses on tests that define behavior, rather than tests which test a unit of implementation. So you are now trying to write an acceptance test even before the functionality exists. And therefore your tests will initially fail but once you have the functionality ready, the tests should go green
- So lets make it clear, TDD is not same as BDD TDD helps us building the thing right Whereas BDD helps in building the right thing
- Who is this guy, well that’s Dan North, the guy who coined the term BDD As per him, BDD is nothing but the approach that allows us to define the behaviour of an application from perspective of its stakeholders
- Now there are numerous tools to implement BDD in your project. Some of them are more popular then others but in reality the tools do not matter. What matters is that you follow the key principles of BDD, so that you get the desired benefit of this approach.
- Now let us look at the core principles of BDD
- Dan North suggested a template for writing test scenarios or the acceptance criteria in the plain english language. Since the test scenarios are no longer in terms of code every person on the team can understand them well.
- Typically an applications can be thought of as set of features, within each feature you may have multiple scenarios A scenario is described using a sequence of Given When Then statements.
- So as an example, if we were working on a project similar to amazon from where users can search and buy books online Some of the features relevant in this case could be – online search, ability to purchase books, manage user profile etc.. The search feature may look like this Its written entirely from an end user’s perspective So as a user on this particular webstore if I want to search a book, I will go to the search page, enter the book title and try to look for that book in the search results These way of writing test scenarios in plain english language is called gherkin, under the hood each line in the test scenario is implemented using the step definitions and that’s where the actual code comes in, that’s where you interact with the controls on your application.
- The next important principle is keeping the business value in mind It is very important to ensure whatever tests or scenarios we are adding what business value do they provide If there is a scenario which is not of importance to a business user then you should not automate it at a BDD level. Looking again at the webstore example
- It is important to notice at what’s happening in the first line here
- The first line in this feature describes the business value that the website users will get out of this feature They will be able to find books quickly So in summary As part of the feature what you are writing is: In order to gain business value As a role I want to perform an action And as part of scenario Given the context When an action is performed Then you should see a certain outcome
- The third principle is about following a Ubiquitous language. This term was coined by Eric Evans in his book Domain Driven Design What it means is the practice of building up a common language between developers and users. The idea is to get rid of all the ambiguity that surrounds software development. For example if a particular control in the application is called a calendar widget, the DBA on the project should name the related table with the same name and not something as db_numeric_gregorian_calendar
- However following the first 3 principles is not sufficient. Even if you are writing behavioural scenarios, following a ubiquitous language, keeping the business value in mind, bugs can still happen and that is where the people aspect of BDD comes into the picture. It is important for teams following BDD to get together as 3 amigos which is forum where the 3 different stake holders of the project get together and bring to the table their perspective of looking at the same piece software. Now they define the expected behaviour together They have a really focussed conversation about a story or series of stories that will be worked upon in coming days or weeks. This gives an opportunity to the programmers to think through about the card being picked up In a larger scheme of things Some people refer to it as Example Workshop or Discovery workshop, again the name doesn’t matter as long as the conversation is happening regularly and the right kind if scenarios are getting written. Now we have a fair amount of idea of what BDD means and what are the core principles around it, Priyanka will now talk about the anti patterns that often emerge along side BDD and how can we mitigate them.
- Now as we all know what BDD is all bout and what are its core principles, let's take a look at some of the Anti Patterns
- What is an anti pattern, Martin Fowler has explained this in a very simple way in one of his blogs. Quote so we will have a look what are the cases when BDD incorporated in a project has turned out to be ineffective.
- Another common anti pattern is many consider BDD to be a silver bullet. There is a famous an interesting quote of Bill Gates: QUOTE The important bit here is the second part – magnifying the inefficiency. People need to understand BDD is not a silver bullet. Often teams just incorporate BDD thinking it will magically solve all their problems. They will decide on a BDD tool to be used and assign it to one person within the team to implement it. But Just bringing in a tool that supports BDD will not make it work if the essence of BDD is not being followed. If you have some process problems you must resolve them before. Otherwise bringing in a tool to support BDD while not actually changing the processes will only make the whole situation worse. So introducing a BDD tool is not enough. Team needs to resolve their process issues and follow BDD as a practice, coming together to discuss business scenarios with examples so that all business aspects are covered.
- The first and a very common antipattern is treating Automation over Conversation.This usually occurs with teams where BDD is actually considered just a tool for automation. There is this friend of mine, who is not surprisingly a tester and he writes real good BDD scenarios but he writes them alone and the reason for writing them is automation. He is trying to give good automation coverage so writing BDD scenarios from a tester's perspective. So I had a question for him, why does he need BDD for automation. To this his response was , it is ecause of the tool he is using and more importantly it will provide a living documentation to anyone who reads it.Then I asked, who except the testers developing this automation suite tend to actually read it. He didn’t have an answer to that Now my last question for him was , if there are instances in their project when they had to rewrite the scenarios as they actually misunderstood the requirement or it was implemented in a wrong way, for which not surprisingly he said Yes many a times. So here we are, practicing BDD but not getting any benefits out of it. This discussion of our made him wonder if he is doing BDD right. So the issue here is that BDD is being considered as a tool for automation whereas BDD is not about any tool or automation, it is actually all about collaboration and tools exist to support this collaboration and enabling conversation. The right approach here is even if you are writing scenarios on your own, the conversation need to happen and they need to happen at the beginning not after the software has been built. Till the time you have those conversations, you will not identify an misunderstood requirement or any assumptions made.
- Now 3 amigos is one of the core principes of BDD, but what if 3 amigos meet at the start of iteration before development begins and still do not build BDD scenarios. Consider a case where you have fully functional Agile team where BAs, QAs and Devs meet for a kick off before any development activity begins but what they close on is an Acceptance criteria and not BDD scenarios with examples. Thus, it is either Devs or QAs who in the end actually invent BDD scenarios out of those acceptance criteria with no involvement of business. This is the lack of collaboration which again results in functionality written under assumptions. and thus an anti pattern making BDD fail. As the outcome of this is that invalid assumptions are made and functionality invariable needs to be redeveloped when reviewed by the customer. So what is the solution, 3 amigos session's outcome should be scenarios with examples as writing them will result in conversations and thus reducing any chances of missed requirements or any communication gaps.If this can not be achieved in a kick off meeting, there should be a follow up example workshop, where those acceptance criterias are refined to form scenarios with examples.
- The scenario here - does it clarify the intent of the feature? It does not communicate clearly what the business outcome is aimed at. If you see the first line and third line, they both mention users but what kind of users that is not clear here. This might make a reader feel the same user who wants to buy latest books will also upload them. It does nor clearly state what kind of user is driving the need here. it is actually setting a wrong scene here. Now look at another version of the same scenario.
- This gives me a clear picture of what kind of user or stakeholder is driving this scenario. I should be able to know from looking at the first line what type of user this guy is.Thus the intention and the context of the scenario is more explicit in this, which is what BDD is intended to accomplish – Clarity and Unambiguous Requirements. Now I know there can be different kind of users who can drive the business flows of my system. This might open more conversation around parts of the system we take for granted where user state might not have entered the conversations before. Thus We should always try not to be generic and rather be as specific as possible. so that there is no scope of assumptions and business users when reading the scenario can directly relate to it.
- This particular anti pattern I believe probably emerged because scenarios are added after implementing the features and it related more to automation process than conversation. So if you see the way it is written, specifying the UI objects in scenarios, it actually looks like higher level scripting language. But what is the harm in that, we all can understand this, we all are technical enough to understand the purpose of this scenario. What about non-technical people, our business stakeholders, will they be able to understand the intent of these scenarios without any help. By adding these implementation details, we are hindering the open communication. What is the solution
- This is the better version of the same scenario. It's actually paramount to write the BDD in the domain language of your business, and you should never see any reference to specific DOM elements in your features. Your features should always be written in the domain language of the business to ensure clarity of intent and that both technical and non-technical stakeholders are able to fully understand them.
- This one is about adding wait times to your features Some features you're testing might rely on third-party systems with an unstable network latency, or there might be javascript-heavy pages which exhibit delays in moving from one state to another preventing further steps from carried out. e.g. you might have to wait on an AJAX call to complete before a 'continue' button is enabled. A common anti-pattern often used to obviate this, and related to the scripting anti-pattern above, is to add a timeout to the feature. The main problem with this is that while it's written in something which is near to domain language, it's unlikely that wait time can be an actual requirement. Your client is very unlikely to actually want their user to wait for ten seconds while some unrelated action occurs, so steps like these which actually exist to ensure that non-functional technical issues don't stop functional tests from executing should not appear in feature files. To avoid these situations, such kind of steps should be rolled up into implementation level that is page element contexts, thus hiding the details of these workarounds.
- well there have been instances when I have heard people saying that they can not implement BDD right as their clients are just not interested in this. Now let’s break down these complaints and look at them .
- Slide 'Clients don’t care about testing' We all must have observed at one point or another that as a discussion on testing starts, somehow it seems to give business people the green light to tune out their attention and it appears that they really not care about testing. But wait a second,why are we talking about tests here, we should be talking about behavior driven development, and it has nothing to do with testing. Testing is something you can't do until the software exists. BDD is a design activity where you build pieces of functionality incrementally guided by the expected behavior. In BDD we step away from a test-centric perspective and go into a behaviour-centric perspective, meaning that this complaint actually was born misplaced. Slide 'Clients don't write specifications on their own. This is the second most used complaint Whoever complains about this is assuming that the client is expected to propose a solution of all the problems. Client writing specifications on its own will not benefit anyone. Rather we’ll lose the biggest value of BDD – continuous feedback and communication. The benefit will only come when group of people with heterogenous roles will come together to write this. For instance, while writing a scenario, he might need the advice of engineers that know the technical aspects of the problem that he wants to solve. He might also needs a QA to spot edge cases that no one else noticed. Else, he may come up with a solution that is much more complex than it needs to be and might end up in a similar situation where customers provided us with requirements written in a word document or some other tool What the client really needs to do is to provide to the team information about the problem that he wants to solve and together they come up with concrete examples to lead the development process.
- Look at this code snapshot, this is a simple scenario for registration. This looks pretty fine, it is not high level scripting language, and it clearly depicts the business value.
- Now what about this, it looks more concise, easy to read and well structured. So does this not look better than before. Ok before discussing what was wrong with first scenario, lets take a look at another version of it. This one also signifies the clear intent of the scenario and is in domain language.
- Now what is the difference among 3, they all say the same thing but shows different levels of abstraction. If you have noted the first one tends to be real long providing a lot of details than required. Focussing on so many details actually dilutes the business value of the scenario and the business might just find it boring to read and can actually miss requirements. The other two code snippets are more concrete and can easily lead to coversations without confusing the people reading it as the focus more on the scenario itself. The only difference is that in the second snippet the data is hidden at implementation level. Now none of the other two scenarios are wrong, you can use them based on how you want to keep details of data being used. At time you might want to be explicit while at other times you don't want those details at scenario level.
- what needs to be taken care of when trying to do BDD right. Now let's have a look on what benefits can be achieved if BDD is done right.
- BDD emphasizes on collaboration and conversations. With 3 amigos sessions, when teams get together to discuss the problem statement they will be working on, they eliminate the chances of any assumptions thus the team gets to a state where they all understand the behaviour in the same way.
- As the code team develops validates the tests which in turn satisfies the behavioral scenarios The effort of the team is focused in the right direction The team actually implements what is required by business. Thus eliminating any waste in terms of defects or rework because of wrong implementation.
- Agile has killed the notion of “fully-specified, completely-detailed-out requirements upfront.” It is a well accepted fact that we won’t be able to figure out all the requirements when we are starting off with a project. BDD, at its very crux, embraces the fact of evolving product understanding It thus allow easy adaptation to requirement changes With BDD, all the features have tests which show how the code is used and thus it becomes easier to understand and maintain code as traceability is relatively easy.
- Reality is people come and go in every team. But with BDD your documentation is a part of your code which runs with the pipelines. Thus, onboarding becomes a lot easier as the wealth of information that is available is always up to date. Moreover as it is written in plain English language, it is easily understood by all.
- This is an interesting quote by Charles Darwin, he says…. I will leave you all to ponder upon with this quote and will conclude by saying The essence of BDD lies in collaboration. Thank you
- BDD when done right is a step in the direction for delivering software that matters