A good story tells not only what has been done/achieved, but it also tells you WHY. How could you rate the solution (what), if you don’t know the problem (why)?
I have some examples where a short explanation of why saves time and adds so much more.
Writing test cases
Have you ever followed test cases step by step, not thinking what you do, just checking if the system meets the expected result to the letter? Were you happy with that? If yes, please stop reading.
Have you ever tried to learn something from a detailed pre-scripted test set, that explains only what to do in every detail?
“Change the string Test1234_-%$ to Test1234 _-%$”. OK, what? Let’s check the expected result. “An error message should occur.” or better “Saving should not be possible.” Now that explains everything.
A short explanation that spaces are not allowed in that string, but alphanumeric and some special characters are, would have helped to understand the what. And in this special, but real, case you create one set of test data with the same string per every execution of that step. If someone tells you, what you have to do and why you do that, you can easily come up with your own examples of test data. And maybe even find new bugs.
With one good why, you can save so many test steps and make the test case insensible to changes which would lead to a lot of non-testing time going through piles of old test cases and test steps and finding all the little adaptions that need to be made. Or having some trained monkey come to you every other minute telling you that this button is either not there anymore or the label has changed, and if that’s a bug? If you then ask, “Why me?”, because you/someone should have added a “why”.
In my experience it is much easier to write a test case, that can also be executed from someone else, when you explain more detailed why you do the following steps. OK, that someone has to have a brain and be able to use it. Rare, but possible… (sorry, it’s Friday night, I’m in the mood)
Imagine, a year from now, you have long left the project, someone tries to follow your detailed steps, but there have been some minor changes to the system, not much really. A button was added, a string has changed, there are now three options instead of two. What would you hope for? That someone explained why this test case or step has to be done. In case some changes were made the chances are high that the tester knows what to do.
When taking notes, what do you put down? I am a lazy note taker. I tend to write down IDs of test data sets, maybe changes I made and some results. Maybe some hints, more a kind of insider. Same for you?
I don’t know about you, but a short why would help me understand that note in a couple of weeks, without much thinking and trying to reconstruct.
More important when you fill your notes of a test session, that will be reviewed or debriefed. A short “why you did that” shows quick what you were thinking about and gives the debriefer a fast idea if that meets his expectations or if you might have missed something. In case of the test notes it might even help others to learn from your written thoughts, when they read them in a couple of month.
Shmuel Gershon said in his EuroStar webinar about note-taking, always add the why. And I have to agree, really it helps. No, I have to admit, it would help, if I would not be too lazy taking good notes.
Someone has given you a task, what to do. Do you always ask “why”? Just think a bit about using “why” in your daily doing. You do so many things without asking. A short thinking about “why” might help you better understand the task. Here we come back to, understanding the problem first, then create the solution.
If you are the one giving out tasks, do you add the problem to be solved, the “why” someone has to do “something”. Of course not, you’re the boss, everybody has to do what you say.
If you want someone to learn from your test cases or you want to remember next year what brought you to write it in this or that way, always add the WHY. If you want to know if the time you will spend to fulfill a task is spend right, ask “why” first. If you want a solution to your problem from someone else, add the “why”.