The last session of software testing clinic focused on how to test requirements. Session conducted by Mark (@2bittester), Dan (@DanAshby04) and Alan (@alan_parkinson).
We discussed how ambiguous requirements could be and the importance of requirements be detailed and transparent. Requirements can be interpreted differently by each individuals experience and views which can result the wrong outcome. Alan hosted a game to illustrate this.
He asked everyone to pair up and then decide who the developer is and who the product owner is. Then all who volunteer as developer sent out where they cannot hear or see the rest. Alan gave the product owners a picture, which more like modern art and a blank paper. He asked us to describe the picture for the developer where they can draw it. Yes, some tried to draw the picture as instructions or prototype but it not allowed. We had given 5 minutes to use words to describe the picture. It was hard. The picture I got seems to be easy to describe compare to some pictures others got!
Then we were sent out with the picture and leaving the notes. Developers came in. They had 5 minutes to draw what described. Well we who were outside could see how confused they are. Then we went in and started comparing the pictures. There were laughter, complains, questions… It was loud. Perfect example to explain why your explanations to be detailed and not let any room for ambiguity or assumptions.
You can see below the original picture, detail description and then the output. Does not matter how much I have described the picture it had not thought from the other person’s point of view resulting confusion and wrong output.
Behaviour driven development (BDD) encourage everyone to reduce the ambiguity as it encourage communication. It is all about collaboration and conversation. There are many ways of understanding the requirements such as,
- Asking questions
- Drawing the solution / user journey on paper /whiteboard
- Asking the value of the requirement
- By generating mind maps , feature files in BDD and also acceptance criteria
- Gather the 3 amigos for formal/informal discussions
Sometimes we do three amigo discussions without realising or enforcing. For an example when a developer have a question and they go to the business analyst to clarify. Test analyst hear the discussion and join in. Sometimes it then taken to the product owner. Alternatively, have a discussion at the watercooler. We all practice it knowingly or unknowingly.
However, always have to remember to,
- Have the conversation
- Capture the conversation
- Implement the conversation
Is the acceptance criteria same as Given/When/Then? It is not! Acceptance criteria is business rules. Business rules could written in,
- High level points
- Given/When/Then format to explain with examples
What we must try is to understand the business rules so the implementation is valid.
Dan asked us to test the following requirement where Mark act as the product owner answering all the questions. He actually did a good job making us feel frustrated with his answers to some questions. So the requirement as follow.
All the questions everyone asked written in mind map format. The groups were What? Where? When? Who? Why? and How?
Then the practical session began. Ioana (@ioanasaysgo) as the mentor she had to come up with a requirement where we have to ask questions to clarify the requirement. Questions were asked What? Where? When? Who? Why? and How? method. The discussion result generating visuals and understanding the requirement is complicated.
We also discussed about clarify assumptions, review requirements before develop and story mapping.
Apart from my train got cancelled half way and resulting me go home late in the night, it was a fantastic day. Until next time…