Workshop about Specifications and Testing.

At the end of February we got to the Copenhagen Context Conference, I would like to write some posts about how it went.

Workshop about Specifications and Testing.

The first day of the conference we went to a tutorial by James Bach & Pradeep Soundararajan.
Jon Bach also showed up, since he was just arriving and hadn't seen his brother for a while.

Since the ideas that we talked about are still thundering in my mind, I am going to use a story as backup.

This is a story about a Panda named Po, who would like to learn Kung-Fu.

It's also the story of Tai Lung, a cruel and skilled white tiger, who would like to be the Dragon Warrior. After all, he went through many years of hard training to get such title and he believes he deserves such right. Then there is Master Shifu, He did train Tai Lung 20 years ago, but he feel sad because his student went evil, and now he has to train Po.

In this tutorial we talked about specifications, about how they can get complex to write, because you need to find out the explicit and the implicit knowledge, and write it in a way that developers and testers will have the same understanding that you have.

Writing requirements is a discipline hard to master.

In order to experiment, we did three exercises, we tested three apps.
First getting the requirements first, and then the software.
Second getting requirements and software at the same time.
Lastly, getting the software first, test it and then get the requirements for it.

Po gets the title of being The Dragon Warrior almost by accident, and then, he starts to train and learn Kung-Fu, because having only the title won't be enough to defeat his enemy.
The action goes around an item called The Dragon Scroll, which contains the secret to become the true Dragon Warrior. 
Tai Lung will use violence to get the scroll and learn the secret, Po will train to become the Dragon Warrior and at one point Master Shifu will give him the Dragon Scroll.

What do you think was the best experience? well, if we follow the rule that says that you should have your test cases first, the first one should have been the most successful tested app.

But since testing is a performance, it happens that when you do not tie yourself to a script, you get freedom to experiment things, and since we are looking for unexpected behaviour at the app, those are not going to happen if we only execute the expected actions, and we found more and better bugs on the second and third exercises.

The point was, that when you review the specifications you can focus on:
- What are the obvious specifications, understand them and move on.
- What are the non obvious specifications, those are important, since the developers might have a different interpretation out of these.
- How are you going to test this feature. You need to think in what tools will you need to use, what understanding will you require to have.
- Do you understand each one of the phrases in the requirements? read them slowly, and focus in one phrase at the time, make questions and get answers.
- Focus on the critical information you don't want to forget when you will be testing, mindmaps are great for this.

Just, don't write test cases at this point, but prepare your learning, your testing ideas and your tools. You can create your testing cases once you got the software in front of you, once you are able to explore and learn, and question the software, instead of the specifications.

At the end, when Tai Lung finally takes the scroll, he gets disappointed and stunned when he discovers that it is blank. 
Po, tells him that it's okay, since he didn't get it the first time either. Tai Lung is still confused, so Po explains to him that "there is no secret ingredient; it's just you."

Users will use your software without test cases, so, what if I tell you that you don't need test cases to test your software, but you need to be a skilled tester to test it right.

There are some slides from James Bach about test cases you might want to check is you have done this far.