I went to a "Startup Drinks" event tonight and met some interesting entrepreneurs with lots of great ideas. One thing I discovered (about myself) is that I'm going to need to get on Twitter in the near future. ;-)
One person mentioned a tweet that he posted yesterday from the "Monday Morning Memo" about advertising. The tweet was about the topic "Why Most Ads Don't Work" (by Roy Williams, author of the book "The Wizard of Ads") and is summed up in the nine secret words: "The Risk of Insult is the Price of Clarity."
This was an interesting phrase. I instantly thought about the feedback that we, as testers, give about the products we test. You know what I'm talking about.. the Ugly Baby Syndrome. Sometimes we have to be the bearer of bad news. Hopefully, we can find a nice way to say it, but ultimately, I believe that the risk of insult is the price of clarity.
Thinking about my motto "ubi dubium, ibi opportunitas" (where there is doubt, there is opportunity), we often exploit the vague, unclear areas of products and applications.. because there will usually be lots of bugs there. The bugs we report are about more than just little typos and minor UI issues, though. If we do our jobs well, bug reports can be the catalyst to help bring clarity to features/requirements/implementations and consensus among the stakeholders about the app/system under test.
When I test, I report every bug. It's all information. I can't judge when something will be worthwhile (to report) and when something won't. You won't recognise that your baby is ugly because it has thousands of little things wrong with it if you don't report the thousands of little things. It's not often that you'll test a system where you find a "nose" in the completely wrong place, or an "ear" where an "eye" should be (to continue the 'baby' analogy). Those moments are easy - you *have* to risk the insult or risk completely failing to meet the customers' (and other stakeholders') needs.
If you test, and report bugs, in a way so as to "not offend" (i.e. by watering down the message, not testing certain features too hard, or choosing not to report certain bugs) are you really providing a helpful service?
What are you willing to risk to ensure clarity on your projects? What do you think?
Hi,
ReplyDeleteInteresting post. Hopefully, we're all professionals in the development cycle (my utopian wish...), so handing over the status and facts as observed shouldn't be taken as anything more than that.
The receiver/s might not like the observations but they can work with you to try and make some meaning of the data (if it's looking at what got missed, why a certain fault appeared or whatever).
This analysis should be seen as a two-way communication. It's good feedback to help future design and it helps the testers learning process about the product/system under test (maybe prompting new test ideas or follow-up activities.)
BTW, I like your motto - very good to have in mind when reading specs before even getting near the product.