A few posts back, I talked about misheard lyrics and how they can apply to assuming our customers’ needs. After a conversation with a friend, I realised I had missed another aspect. What if we had a non-English speaker mishearing English lyrics? This could change the meaning of the song in a whole different way.
I think this works much like people with different skill sets in a team. So, we have the developer who mishears the lyrics and a tester, whose first language is not English, hearing something else. Possibly, we get test cases assuming one thing and software that does something completely different. Sometimes we even get people hearing something they like and ignoring anything else. Paul Simon summed this up nicely in his song, The Boxer, “A man hears what he wants to hear and disregards the rest”
So how do we fix this?
The answer is Behaviour Driven Development (BDD). So what is BDD?
BDD was created as an evolution of test driven development. It was developed by Dan North as a place to start writing tests. It relates to how the software should work or behave. When a user clicks a button, what exactly will happen, or what does the user expect to happen?
How do we find out these answers? Well, through conversations with business stakeholders and end-users. What BDD allows for is these conversations. It allows developers, testers and business stakeholders to talk before any code is written. This would stop the misunderstanding in the lyrics. It would even allow for all different meanings of the lyrics to be addressed. Everyone gets their view point heard, and all it costs is the price of a conversation.
I’ve seen it save hours of waste in misunderstood requirements. Once the conversation has been had, then acceptance test driven development can start, and everyone is on the same page. Don’t believe me? Try it for yourself! Start small, then tell me all about the results.