A BDD lesson from my past - Part One

So, a few years ago I was involved in an agile transformation.

I was part of the consultancy brought in to work with a client.

As part of our learning through trial and error, we decided to try Behaviour Driven Development.

I wanted to learn from what we went through and share it with others.

I also wanted to learn what some of the people on the client site learned.

I worked with two separate people and we came up with 2 talks.

We worked with the same theme but taking their different experiences and personalities we created different talks.

It worked quite well.

Thanks to @andrewjutton and @brightoniant for joining me on this exercise and also being willing to go through their first presentation experience with me.

Recently @friendlytester wrote a post which reminded me of that time.

His post prompted me to write this post.

Are you sitting comfortably? Good. Then we'll begin.

Many moons ago, a few people came across SpecFlow and this lead them to Behaviour Driven Development.

We didn't spend time thinking through exactly what we wanted to achieve, or how we'd know if we were getting there.

SpecFlow, however, was shiny and new and we were still working on how exactly we were going to use automation in testing. 

We were lucky that people with the business knowledge were available.

We were unlucky in that the people with business knowledge were offsite most of the time.

We decided to trial BDD, which was driven by the tool and by the 'Software makers', which at the time did not include anybody from the business.

This (now) seems wrong and didn't work as effectively as it could have.

I have no evidence to back this up, but I believe that having the business suggest the idea of BDD would change the approach completely. 

BDD is about focusing on collaboration, not focusing on a tool.

You can work with BDD without ever using automation and receive plenty of value.

In-some cases you'll be better off as you won't get lost in the tool and focus on the collaboration.

Collaboration is the key and point.

So, there we were; Giving it, Whening it and Thening like mad.

Mostly written (solely) by the Business Analysts and therefore bypassing a shared understanding and attempting to share one person's understanding.

Here's an example:

Scenario: Display ‘Insurer Selection’ screen

Given that Insurer selection screen has been invoked
When the Insurer selection UI is rendered
Then the ‘Insurer Selection’ page is displayed
And the ‘Risk Variation Name’ field is displayed
And the ‘Risk Variation Name’ field is selected
And the ‘Customer Name’ is displayed
And only breadcrumb ‘Select Insurer’ is displayed
And all insurers setup in the system for the policy type are displayed
And all insurers setup in the system for the policy type are not selected
And the ‘Next’ button is disabled

We were learning.

We hadn't quite grasped yet that the how wasn't important, it's the what that is important.

What is actually trying to be completed?

End of part one.

Blast from the past: BDD Lessons Learned

Collected blog posts - #ltgw2013

I've gathered up a list of blog posts related to the London #TesterGathering Workshops 2013.
I'll keep adding as I come across any but If I've missed any please let me know.

Pre:
Carlos Ble - London Tester Gathering Workshops

@webcowgirl - The Cheater's Guide to Levelling Up

Post:
Stephen Janaway - London Tester Gathering Workshops 2013

Simon Knight - Focussed Awareness

conferize - Attend any conference online.

R B's Prezi

Dan Ashby - Lessons from the Black Ops Testing LTG Workshop!

Three talks - One #TesterGathering

So at the October London #TesterGathering we had three talks.

David Parker talked about Test Estimation - My main take away is that it's not easy.

Mark Smith talked about a experiment he is trying with making BDD examples easier to write and automate.
I've linked to his template (for want of a better word).
He is looking for feedback so get in touch with him.


Steve Green talked the need for Testers to be unreasonable, to be more insistent. - My main take away is that we need to make people aware of the risks of not having the right kit. For example only testing with emulators.

A huge thanks to the sponsors of the evening:

Random photos:

BDD Lessons Learned - Skillsmatter skillscast

Recently I presented a talk with my colleague Ant on some lessons learned around working with BDD.

The podcast is here



A discussion on what can cause some issues when implementing BDD taken from personal experience.

Things like, in no particular order:

• Don’t rush into automation
• Don’t spend hours arguing about the correct language to use
• See what others are doing
• Write scenarios as a team
• Have the conversation
• Don’t add implementation details in scenarios
• Add tests to continuous integration process as early as possible
• Use your scenarios
• Include the SME (Subject Matter Expert)
• domain expert and customer
• Keep scenarios precise
• Use examples to reinforce the scenario
• Every scenario is negotiable and is subject to change at any time
• Your scenarios are your living documentation
• Make things visual
• Sign off scenarios
• Just do it.

Reasons to come to Agile Dev Practices

Program Overview

1. I'll be there.
2. Good mix of sessions.
3. Good mix of tutorials.
4. Good range of subjects.
5. Did I mention I'll be there?
6. Good range of workshops.
7. My colleague Ant will be there.
8. 25% off with code ATDC4P_025.
9. Potsdam/Berlin is great.
10. Markus can sign 'ATDD by Example: A Practical Guide to Acceptance Test-Driven Development' for you.  
11. You can talk to Gaspar Nagay, main contributor of the open-source .NET BDD tool, SpecFlow. 
12. Ellen can sign one of her books for you.
13. You can talk to Chris Matts and Olav Masssen.
14. Díaz & Hilterscheid have put on a great event.
15. You can talk to people who make software from all over the world, share your stories. 
16. You can teach.
17. You can learn. 

There are more reasons, what am I missing?

It doesn't make sense.

I stole this, I changed two words:

People work with one set of ideas about how the software is. Everything they do, be it experimental or theoretical work, is informed by, and framed within, that set of ideas. There will be some evidence that doesn't fit, however. At first, that evidence will be ignored or sabotaged. Eventually, though, the anomalies will pile up so high they simply cannot be ignored or sabotaged any longer. Then comes crisis.
13 Things That Don't Make Sense - Michael Brooks.

To me, this is a pretty good explanation of software development, although of course, not in all cases of software development.

It's also a pretty good reason why things like agile, devops, devs, bdd, etc have come about.

We do approach things with a set of ideas and we do frame things with that set of ideas in mind.

We stick to our own ideas, even though some of our ideas have been born out of others' ideas and thoughts and words and we've blindly made them our ideas and thoughts.
- For more on this train of thought refer to Leprechauns of Software Development or various kinds of certification.

When we have ideas that we have actually conceived it can be a good thing because we all have different experiences, we all have different thoughts, we can all add something.

I think the problems occur when we don't let go of theses ideas (when beneficial) and learn from others experiences and listen to others ideas.

A lot of time we don't conceive ideas together for something we are supposed to be working on together.

What's wrong with us?

Doesn't make sense to me.

Make sense to you?

Continuing with the excerpts from 13 Things That Don't Make Sense The next paragraph starts with the sentence:

Crisis, Kuhn said, is soon followed by the paradigm shift in which everyone gains a radically new way of looking at the world.

Does it? Not for software development, not as much as needed.

In the context of software development the sentence would read:

Crisis, Kuhn said, is soon followed by a attempt to throw more people at, work longer hours to stem and follow the procedures that caused the crisis in the first place until the next crisis arrives.

What's wrong with us?

I spoke at CukesUp!

Andrew Jutton and I spoke at CukesUp! 2012 about issues with 'rolling out' BDD.

Learning from mistakes with BDD

View more presentations from tonybruce.

Most if not all the other talks are also available.
Definitely worth checking out.

Re-Regression Checks + Regression testing = Regression testing?!

Sharath recently wrote a blog post to which I decided to write my own post in response.
Sharath's post is here.

Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.

I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.

ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios

What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc.  That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.

Back to Sharath's blog.

One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever. 
As well as automating any useful information gained from the ET.

I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.

What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation.  Had slightly more success with that.

If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.

I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).

There is really no one answer, is a case of finding what works for you with the people you have.

Agile Practitioners meetup - 'In Theory and in Practice'

Last night I attended an Agile Practitioners meetup where Daryn* gave a talked titled 'InTheory and in Practice'.

Here are my notes from last night and the Italics are my thoughts

He took us through a recent project (for a client) to build a Excel plug-in which connected to a third party.

Didn't really go into complexity, wonder if the same approach would work with a larger team.

TDD and BDD were used

BDD details weren't really discussed but it sounded more like acceptance tests were written rather then 'full' BDD.

There were 2 Developers and Daryn acted as a sort of co-ordinator.

The Deverlopers were able to practice pair programming and found having to voice and explain/justify your ideas a little odd at first but found great benefit by doing it.

Teaching/learning and writing better code

Code reviews were carried out by Developers on other projects.

Daryn also talked briefly abou the NUMMI case study, I'm not goint to write anything about that as there is loads of stuff around.

It's a good case study and I've not researched it enough but I wonder about the variables such as if the improvements were partly due to there being nowhere else for people to work and does that matter (in terms of the fact there were huge improvements)

On the project the first thing they talked about was testing, or how much/what could be automated.

They used Specflow for automation and I think Coded UI may have been mentioned as well.

            Were other options explored?

They were given uses stories which contained impementation details and luckily they were trusted enough to re-write the stories and change them to just the what rather than the what and how.  This meant they could look at different ways of implementation and were able to simplify the solutions.

            Were they written with the people who write the original stories?

They were able to decided at the last responsible minute and Daryn shared some pointers:

* Share partially completed designs
* Colloborate
* Develop a sense of how to absorb change

            What did they do to develop that sense? Or how was it handled?

All the stories were based on business value only and nothing had been written for the implentation, frameworks, etc. Essentially all the kind of stuff that becomes tech debt.

This also meant that this work wasn't visible.

            It was mentioned that this wasn't a issue, be interesting to know why this wasn't a issue.

A couple of burn down charts were shown and generally speaking they were pretty smooth and showed improvement.

Excel was used as the overall management and data collection tool

Of high importance was the people side of things, building a good relationship with the PO and the third party.

Daryn shared some general project pointers:

* Don't do too much upfront
* Too large a context change/switch can cause performance hits, ie, work on 1 project, don't work on multiple projects.

Data, information and quotes were resourced from Jerry Weinberg, Lean SoftwareDevelopment*, The New New Product Development Game and various conferences.

*Didn't get Daryn's surname. 

*Not sure which actual book it was.

ATDD is like a fight in the playground.

Does anybody else find that ATDD is like a fight in the school playground?

I've had limited experience with ATDD but from what I've seen you have to be there from story creation (picking a fight) or at least you have to be very nearby (standing near the fighters and therefore at the front of the crowd) otherwise you'll miss it all (because you're stuck at the back of the crowd).

I've found that everybody is willing to get involved with writing the examples but not always together.

If you're not at the front or involved in the fight directly then you have to fight your way through to get involved.

I've found that sometimes before Dev or Test get near a story the AT's are already written. This might be because of a easy to use DSL or having BA's that can code.

Either way it means that the sharing of knowledge and shared understanding of the requirement that happens when people get together to write the AT's is missed out.

It also means there's no discussion. Why would you discuss what is already there and waiting?

It also means that the AT's are written to one person's perception rather than the team.

Which means there is potential for things to be wrong.

I've also found that sometimes Dev's are so eager to code (like kids to candy) that they write the AT's and are off coding and Testers have no idea what's in the AT's and may have to edit and/or add to them.

So how to you handle that? Is there a way? Unless you're monitoring what everybody is doing I don't think there is, all you can try and do is open up communication and ask to be involved in the AT writing and keep asking otherwise you'll be forgotten.

I think ideally the AT's should be written together and Dev's start coding, Test have a longer, deeper think and add more AT's and BA's have a longer, deeper think about whether things are heading the right way.

Sound crazy? What's your experience?