Serve your Stakeholder

Dr. Cem Kaner describes stakeholder as someone who has a vested interest in the success of the testing effort and/or in the success of the product. Stakeholders could be project managers, marketing managers, product managers, programmers, technical support representative, sales representatives, customers and many others in many different roles. Testing is done on behalf of the stakeholders. Here is a question for you. Have you ever asked who your stakeholder is before you start to test?

On a balmy Monday morning, I visited Weekend Testing site to read previous weekend's session reports. The battle of the URL shorteners lured me.

Mission
You are contracted by three stakeholders to evaluate URL shortening services - http://tinyurl.com, http://bit.ly, http://3.ly, http://is.gd, http://tr.im, http://stnx.at. The stakeholders are:
1. a heavy twitter user tweeting a lot of internet references over the day
2. a university student wanting to share stuff from his homework/courses over the internet with his fellow students
3. an online magazine publisher for referencing further readings on the internet

Experience Report
This time around, I did not jump right away to test and find bugs. This was partly because I did not know what information to provide and how. I explored all 6 URL shorteners and played around with features for a while. I was specifically looking at evaluating URL Shorteners on behalf of the stakeholders. Stakeholders were of 3 types – heavy twitter users, university student and an online magazine publisher. I went about with a small feature list of what I thought was important to the stakeholders. I chose URL Validation, Default Length, Auto-copy to clipboard, Proceed with URL shortening on same page, Custom Names & Validations and Preview. I identified just these as important features and ignored the others. This is where many of us commit mistakes [Remember, Assuming that we are the final stakeholders and claiming that all we say is right is dangerous].

Now that I had played with URL shorteners a while ago, I started exploring each feature and prepared an excel with details as to which shorteners support above features and which do not. In the end, I looked for the URL shorteners which supported most of the features above and concluded that 3.ly and Tr.im were the good ones.

You can read my summarized report HERE. You can also learn from few more reports at Weekend Testing EWT 04 session.

What went right?
1. Exploring URL shorteners one by one without being lost in finding bugs
2. Came up with ideas to test for each stakeholder requirement separately. I would say this was a good start
3. Came up with a feature list to compare the URL shorteners against each other and evaluate. This approach was good
4. Captured test results to the best of my knowledge and provided good enough information to stakeholders or so I thought.

What went wrong?
1. I did not use Google effectively. I could have googled about URL shorteners in general and fetched more information about other important features
2. I did not think deeply about the stakeholders categories. For e.g. what type of users are heavy twitter users – what are the important features that matter to them? What do online magazine publishers emphasize on while using URL shorteners? What features would be helpful to university students? As a result, my test coverage was very restricted and narrow. Rather, my test coverage was restricted and narrow, hence the result. Do you see the difference here?
3. I failed to summarize my findings with respect to each stakeholder. All I did was to prepare a generic report with my findings. I had started out with an intention of testing for each stakeholder differently and separately. Though the approach was good, I got lost somewhere and failed to identify many important features like Twitter integration, Shelf life of generated URLs and others.
4. Poor reporting yet again – one of my most common mistakes in uncommon situations. I did not present the report in a way that each stakeholder would be able to fish out information from. A generic report like this may not even be worth a glance. In short, it did not show anything useful for the stakeholders.
5. If only I had tried to ask each stakeholder what they wanted directly [assuming they would answer back for their own good], it would have been a lot more easier. In this case, asking questions meant I should have listed down what was more important to each stakeholder and tweaked my findings accordingly in the summarized report.
6. My conclusion that 3.ly and Tr.im were good was completely baseless. The conclusion varied for each stakeholder based on what was important to them which I hardly focused on.

Identify your stakeholders
We often ask our immediate bosses, colleagues and other team members about the stakeholders directly or indirectly. Some times, they don't know. Sometimes, they do. Irrespective of this, it is good to identify the targeted stakeholders for the products/applications being tested and come up with features that matter to them the most. After all, we need to find important bugs quickly contrary to finding all bugs which hardly matter to the stakeholders. Ask who the stakeholder is, what is the information they are looking for and what are the risks that they want to mitigate at any given point of time? (taken from Dr.Cem Kaner's article which escapes my memory right now).

Dr.Cem Kaner opines about understanding stakeholders in Weekend Testing session 20 as follows:

To test any product related to drug submission to FDA, SOME TESTER ON THE TEAM SHOULD mandatorily should have knowledge on the drug submission process. No one is responsible for my ignorance of quantitive trading systems but me. In the United States, over half of the stock trades are now driven by automated trading systems rather than by humans. If I want to understand how the market works, I have to understand the trading
system. If I want to test models of the market, I have to understand the range of tradings systems. If I want to test the models underlying a specific trading system (one of the things that distinguishes a high quality trading system from a low quality one is whether it makes money for the people who use it, yes? So assessing the quality of the system requires assessment of its probable value to users, which is often done in highly-detailed simulations)--If I want to understand these, I have to educate myself. If I am unwilling or unable to educate myself about these, I should test something else. If I am more generally unwilling or unable to educate myself about a product domain, its risks, and how to assess a product in that domain, I should give up on testing and do something easier that requires less learning.

Serve your stakeholder diligently,
Parimala Shankaraiah

P.S.
Ever since I created Testing Fiesta and Defects Fiesta sections on this blog, I have only dreamt about growing these 2 gadgets and hence accelerate my learning. My 7 day work weeks screwed it up and continue to do so for many more weeks. If at all, I do get time, I run back home to play with my 3 yo. If at all, my 3 yo sleeps, I go to sleep as well thinking it’s high time I take some rest. All lame excuses! I’ll start blogging regularly from now on. Keep visiting. Thank You.