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.

Change how you change presentation - Agile Tour London 2013

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!

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.

Explaining testing: 101 Tactics For Revolutionaries

Here are the first 10 to get you started.

Onward to glory!

1. if you’re in charge, do it yourself
2. if you’re not in charge, do it yourself
3. become known as “the guy who…” so when the time is right, everyone knows there’s a guy who…
4. learn to be nice, so people like you
5. realise there are no rules, you can do what you like
6. know that you are as right as you can be for now given what you’ve learnt so far
7. know that this is the same for everybody else
8. stay on the inside of the wrong thing so you can speak with authority on why and how it is wrong
9. know it’s not a race. That you can divide the world into those ahead of you and those behind, and to all those ahead of you, you’re the one behind.
10. be an entrepreneur not a crusader

The rest are here: 101 Tactics For Revolutionaries

No time left at the end of the sprint for proper testing

In the Agile Testing Linkedin Grp the following was posted:

No time left at the end of the sprint for proper testing

Designers tend to add and change code until the end of a sprint, not leaving enough time to do all the agreed testing. At the start of a sprint, we assign rough time estimates to user stories, taking both design and test activities into account. Some tests are automated and run during the night.
However, other tests need manual preparation of data and partly manual execution and result analysis. There is also some amount of exploratory testing involved. During the sprint, there always seems to be a reason not to deliver yet to test: fixes, improvements and design updates. At the end of the sprint, little time is left for manual testing, far too less for running the tests, analyzing and repairing eventual bugs, retest and results logging.
What advise do you have for me, so that I can claim and really use a fair amount of the sprint time for testing?

With a follow up post of:

What I called 'delivery' is not a heavy weight process wall. It is just a oral notification in the team stand up meeting that some story is ready for test. Our way of working is pretty much in line with all points you mention: except for point 5. "Testing is a fair amount of the sprint if done well". I think 1 day left for testing out of a 2 week sprint is not this 'fair' amount. The pattern that I have to cope with is: several user stories are coded in parallel and they tend to be 'ready for test' all at the same time, that is: 1 day before sprint end. The tester is involved in functionality and architectural discussions during the sprint and prepares test data and test scripts, ready to 'push the button' when a story is ready.

My (currently unpublished) comment (with minor changes):

So, based on the info you've provided I'm going to make a bunch of suppositions along with ask a number of questions.

1. Is there a definition of 'done'? Does it include testing? If so, it seems like it's being ignored?
* If it is being ignored are there retrospectives held? What happens when this is brought up?
* Is the issue being recognised by the rest of the team?
* Is it being recognised and cared about?
* Are the powers that be aware?

2. Are the stories broken up into tasks? If so is it possible to test the tasks?

3. If what you are working on is broken up into (small) stories and setting aside the late adjustments there should be a constant stream of stories coming through, if not, has this been looked at? If so, what was the outcome?

4. Is it possible for team members to pair? IE testers and devs, ba's and testers, ba's and devs, etc.

5. Is there a visual representation of story process? Visible by everybody?

6. Is this way of working new to the team/company? Was there help making the transition? If there was, were they any good? Were any new people with more experience in this way of working hired?

7. Are you/the testers prepared to play hard ball? You can't possibly test a sprints worth of work in a day, so don't try.

8. How are the late adjustments getting into the story? They should be judged on value and as a team decided on whether or not they get into the sprint. Failing that then a story/stories can be dropped to allow for changes.

9. Is there a scrum master type role? Is he/she someone who has gone and gotten the CSM or are they experienced?
* Experience is very hard to judge, how is it done?

10. Is there a way to prepare test data through automation?

11. Is there any skill sets lacking in the team in general?

It doesn't seem like you have a testing issue, you have a team/culture/mindset issue.

I'd like to know what I've missed?

 

 

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?

Total awareness of conditioning

How do I free myself from my conditioning of the culture in which I was born? First, I must be aware that I am conditioned; not somebody telling me that I am conditioned. You understand the difference?

If somebody tells me I am hungry, that’s something different from actually being hungry. So I must be aware of my conditioning, which means, I must be aware of it not only superficially, but at the deeper levels. That is, I must be aware totally.

To be so aware, means that I am not trying to go beyond the conditioning, not trying to be free of the conditioning. I must see it as it actually is, not bring in another element, such as wanting to be free of it, because that is an escape from actuality. I must be aware. What does that mean?

To be aware of my conditioning totally, not partially, means my mind must be highly sensitive, mustn’t it? Otherwise, I can’t be aware.

To be sensitive means to observe everything very, very closely; the colours, the quality of people, all the things around me. I must also be aware of what actually is without any choice. Can you do that?

Not trying to interpret it, not trying to change it, not trying to go beyond it or trying to be free of it; just to be totally aware of it?

Jiddu Krishnamurti - The Awakening of Intelligence

Why would I need excuses?

Recently uTest posted "8 Common Excuses in Software Testing" and within the comments there was a link to "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".

My immediate thought was 'WTF? Why would I need excuses?'.

Reasons, yes, explanations, yes, but excuses? Hell no.

Am I wrong? Do I need excuses?

Or am I getting reasons and excuses mixed up?  Are some people taking them to mean the same thing?

At the end of "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".  There is this sentence 'Well these are not actually excuses. These can be the actual reasons why an application is shipped to client with major bugs.'

The way I understand the two in this context are:

Reasons

1.a basis or cause, as for some belief, action, fact, event, etc.: the reason for declaring war. 

2.a statement presented in justification or explanation of a belief or action.

Excuses

1.to regard or judge with forgiveness or indulgence; pardon or forgive; overlook (a fault, error, etc.): Excuse his bad manners. 

2.to offer an apology for; seek to remove the blame of: He excused his absence by saying that he was ill. 

3.to serve as an apology or justification for; justify: Ignorance of the law excuses no one.

I am not a gate keeper, I am an information provider, I have limited time to provide what information I can.

I will do my best, the people around me will do their best and sometimes we will not be able to investigate everything.

I'm happy to explain things but make up excuses?  I think that will do more harm than good.

There are plenty of reasons why issues end up in production, learn from them, explain, improve how you test and what you test.

Don't make excuses.


28/01/13 Update.
Forgot to add, what and how you are testing and what you are not testing should be communicated and continuously communicated as you delve deeper into the software.

I'm supposed to be negative?

So I've overheard recently  (over the last year or so) things like: 'It gets tiring being negative all the time and pointing mistakes and people flaws.'

And it confused me.

Is that what I'm supposed to be doing?!

Crap!

I've been doing it wrong!

Should I be negative?

Should I be pointing out flaws in peoples work?

Should I be pointing out flaws in peoples ideas?

Should I be stating that people are doing shoddy work?

Am I there to break things?

Am I there to find the breaks?

I thought I was part of a team and we worked together on creating something.

I thought I approached things differently and could add valuable input because of that.

I thought we were solving a problem and approaching it from different angles.

I thought I was there to provide information.

I thought  we evolved together.

Did I think wrong?

Ted talk: Temple Grandin: The world needs all kinds of minds

Book review: Dealing with Difficult People

Dealing with Difficult People: 24 Lessons for Bringing Out the Best In Everyone.

Dr. Rick Kirschner(Author), Dr. Rick Brinkman (Author) 

From the back cover:

In every workplace there are difficult people who, at best, make life stressful and, at worst, can keep you from achieving important goals. But it's within your power to bring out the best behaviour in people who are their worst.

If you are interested in working with people more effectively or work with quirky people and aren't sure how to deal with that this book is good place to start.

The book breaks up what it lists as the 10 most unwanted behaviours:

The Tank

The Sniper

The Grenade

The Know-it-All

The Think-They-Know-it-All

The Yes Person

The Maybe Person

The Nothing Person

The No Person

The Whiner

You can pretty much guess the behaviours of each from what they are called and you probably have already matched some to people you know.

I kind of think we all have a little of all of those within is.

The book starts with some initial general ideas for dealing with all 10. Things like:

Understand that everybody reacts differently to these types of behaviour: The person who's most irritating to you may be perfectly acceptable to someone else.

It then goes into Choosing your approach, then understanding the behaviours and intent.  Four intents are written about:
get it done
get it right
get along
get appreciated

It delves a little deeper into communication and briefly discusses things like blending and redirecting. Pygmalion power is also mentioned.

After that it starts focussing in on the list of 10 and digging in deeper to each one.

I found there were some mixed messages, in some sections there are statments such as 'There's no magic formula; you are the best judge of which choice is right in any particular situation' and in a different section there is the following 'Here is a surefire five-step process to break your Nothing Person's silence'

All in all it's a good starting point if you are interested in this kind of thing.  

Read it, ingest it, think about it.