Stakeholder or Steakholder

Become a visible tester
I was triggered to re-think about stakeholders after re-reading the presentation: "The Most Important Stakeholder -- YOU" by Adam Goucher. This is a presentation which was given on CAST2009. mr Goucher explains that you as a person/ tester are also an important stakeholder. The article it selves is more about how to become visible. How visibility can strengthen you.

This will reflect on you as person. Therefore it will also reflect on the project you are in. You participation in project might change.

To make a difference in project you first have to identify if you are a stakeholder or not. Start with the question: “What is a stakeholder?”

What is a stakeholder?
Stakeholders are often described as important. In wikipedia Project stakeholder is explained as:
Project stakeholders are those entities within or outside an organization which:
a) Sponsor a project or,
b) Have an interest or a gain upon a successful completion of a project.
c) May have a positive or negative influence in the Project Completion.

Examples of stakeholders are:
- End users
- Developers
- Marketing Department
- Helpdesk
- Resource Managers
- and more

Often Testers are also mentioned as stakeholder. They might be stakeholders of the project. There are also people who are claiming testers are not stakeholders of a project.

The right arguments?
Did you ever talked about projects with other fellow testers? Did you ever attend an intake? Did they ask you how large the project was? How many people you managed? It seems to be more impressive you managed a test project consisting of 20 persons instead you managed to deliver a system on time with 3 very good persons. Numbers count, not result!

I always believe it is not the number of people you guided/coached/managed, it is how you managed to serve your stakeholders. It seems so obvious. And you might think this has nothing to do with stakeholders.

Mr Goucher wrote that it is important to become visible as tester. As far I as take his words it is to learn and keep learning. Not to make you more important, it is to gain respect from others.

I hope that respect is not based on how well you are to talk to 20 people, it is how good you are to deliver value to the stakeholders.

Judgement by numbers? Are typos easily made? Do you management by numbers and therefore your team becomes just meat which turns you into a steakholder>

As it is mentioned in The Seven Basic Principles of the Context-Driven School Illustrates: "Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives. "

And a bit further on: "Test artifacts are worthwhile to the degree that they satisfy their stakeholders' relevant requirements"
It seems to be important.

This has nothing to do with the number of people you are able to manage. This is how you perform to supply information to stakeholders about how the software satisfies the stakeholder and also how you are able to satisfies the stakeholders. It is showing you are delivering value to them. Plain numbers just cost them. You have to show them you are able to deliver in an optimal way.

Other arguments
On Software Testing Club Ainars Galvans posted a nice blog called Different test reports for different stakeholders? I like the picture he is using. It shows how things are presented on different levels with different products. Important is that you present only that information which is important because it delivers value.

It shows also that people watch from different angels. indeed, this seems that people are judging you from the number of people you steered. It is good to be aware you are able to have some kind of span-of-control. Only don't make that too important. You shouldn't be judged by the numbers. Typos easily made. So: "Do you manage by numbers and therefore your team becomes just meat which turns you into a steakholder?" Or are you able to serve yourselves as you are your own stakeholder present and tell what you can, who you are. And deliver your stakeholders the value they asked?

Steakholder?
Like just said, a typo is easily made. You coached 2 people and were successful or it were 20. I hope the results counted and not how many people. There are testers who still claim I was successful managing 20 persons. It is more important to ask: what value did you deliver. A person who presents their selves in numbers are counting in meat instead of value. They are more steakholders instead of becoming their own stakeholder or value stakeholders.

Free pie for everyone or just an issue?

My son has his birthday very soon so we tried to order some cakes and pies online. We loved the cakes and pies from that certain store and never had problems. now it seems to become a very cheap birthday. While placing the order it seems that nothing was charged.
It was tempting to add more items to the chart, though we didn't do it. The first screen was already an issue. Items were selected and nothing charged. (This is a Dutch site so here some translations so you all can learn some Dutch from this site also
aantal = number
personen = persons
per stuk = per piece
prijs = price
totaal = total
)
The first issue see below: I assume that since it is counting the quantity of persons and persons are not charged, the total amount to pay is also zero.

The image below represents the confirmation screen and were you can check for your details. The title of this window is: "Controle van de gegevens" which is similar to "Check of the information" Here you see that it counting the number of items and presenting the price of the previous screen. Still nothing is charged.


The last screen in the confirmation screen. O how much did we hope we would see the zero here again. Unfortunately we got surprised we had something to pay. Somehow it seems that here something is working well, only we were not able to check if the price was right.

Remark: At the first image you see a certification called "thuiswinkel waarborg" this seems a certification to provide the consumer trust and liability for there online orders.

Lesson learned: when something seems to be free, don't order too much as you have to pay after all.

Another lessons could be: certification doesn't say anything about the functionality. (Imagine how this statement can be transformed to other types of certification )

Test Automation by the book

Previous title was: "How TMap Next is used for automated testing" changed it into a proper title :)

Automate testing is hot. It has been hot since I work in the software testing business. It will be hot for a long time now. Often I hear arguments about automated test tools are shelf ware.

Sometimes I hear automated testing by the book is not possible. I might have formed an opinion that the Test Approach: TMap Next by Sogeti fails when it concerns automated testing.

When I think and talk about automated testing I think how to use tools and not how beautiful tools are. Sometimes you find another usage of items and methods. Recently I found someone using the Test method as written to automate his testing.

As you see, the book contains the method and it is used to automate his testing. Therefore the method is used for automated testing. In this example it was used to support the LSMW (Legacy System Migration Workbench) in SAP. An LSMW is a tool that supports the one-time or periodic transfer of data from a variety of sources without any programming. Only in this example it had to ran multiple times and therefore user interaction was needed to press the Enter button. As you see. The book/method is very useful to support in automated testing.

As you see the book is lying optimal on the "Enter-key". You might consider this as a steady firm tool. As some testers which are familiar with the "old"Tmap approach, we have been told to use it as a tool not as a goal. I think this is a good example to use a method as a tool.

To order this book as a tool you might take a look at: TMap next

Weekend testing EWT05: my first attempt

I read about it, heard about and received the tweets. I was (indirectly) asked to participate. It should be exciting. It must be something new. So I became curious about it.

Initially I started to find excuses not to participate. It is weekend, why testing. I have more important things to do. It is too late or too early. I need to reconfigure my PC. Dinner must be cooked. My batteries are low. I might even thought about starting to write a left-handed course for software testing written by a right handed person. I'm sure when I would have took more time to think about excuses I would have been more creative.

Instead I looked up for the tweets, visited the website http://weekendtesting.com/, send a PT to Markus, downloaded and installed Skype and registered to the site mentioned above. Confirmed the mail for registration and was ready for business. I thought. This time it seems that acting to get things moving was shorter then finding arguments not to do. I was in the race.

For me it was testing multiple applications. not only was I new to the application which was introduced by EWT. I also am new to Skype and needed to find my way again in the mantis database :)

Somehow I managed to be there on time. "There" was the place somewhere on the Skype-universe. We grouped as a cluster of bugs you sometimes see. Although we seems to be unknown to each other, somehow it felt familiar. Amazing how people with a same goal could be able to communicate with each other. Like bugs, there were some who were introduced on a later moment. They also made a difference in our quest for fun on the European chapter of weekend testers. (you can follow them on twitter by: http://twitter.com/europetesters)

As you might have read on the website of EWT the time frame is short, the tour takes just two hours. Like I wrote, I first started testing the Skype. One lesson here is that under time pressure you focus on the goal: " am I able to use Skype within time without reading manuals ready tom communicate with the people I need to talk to?" I have to say that I succeeded that part. OK, I had to close several windows which might be worth reading after all. I tried to search on the email address for "europetesters" and managed to find a contact in Skype. Yes! I was in business. After a while the crowd came together and formed a group.

The process was quite easy: take the time to get to know each other, spend a bit of that time to be polite and say "hello and welcome" and work on smiley’s when someone says something nice. We used the text-part of Skype as far as I know. This we did until the first assignment was given: install a tool called: Virtual Magnifying Glass 3.3.2

Now I can exaggerate how complex this tool is. Keep in mind that there was just a small period of time to test the application. When going into retrospective mode I might tell that the testing starts when opening the website for downloading. There are immediately a few questions which are risen.
- is this the right site?
- is the tool available
- is there a tool which can be downloaded (like I said I didn’t had that much time, it was somehow a kind of challenge for me.)
- which version to download. I have an Windows operating system, only also a virtual machine which is running a Linux distribution. I had thoughts to download also the Linux version. And left that thought due to time as the application was unknown for me.

Just before downloading I asked myself a question I automatically ask myself every time I download something: where to store the application? Normally it would become part of the directory where I store applications. This time I decided that they are part of this testing project and stored in the project folder. Testing starts not only when the application is running. It starts when you first got aware of questions you ask yourselves about the application.

After I confirmed I was able to download the application I choose not to install it immediately. Installation of an application is also something which can be tested. I placed that item into the scope of my test challenge. so I waited until the first mission was mentioned. it was a very vague mission and soon it was sharpen to more words to leave the statement still nothing more then "Test this"

I heard that testers are willing to neglect such an assignment because it is to vague. I'm sure we would be able to spend a lot of the available time to make the assignment SMART. Weren't time which was left more valuable for us so we started testing. As I did also. In the meantime they send us a link with the location where to submit the issues found. I was glad to see that they used Mantis as I worked with that tool.

As the time for testing was started, I missed some of it by registration of myself to that tool. I lost some valuable time because the CAPTCHA was too small; it was too hard to see whether the O was an "O" or an "0". After 4 attempts and actually considering installing the magnifier to support me on this I managed to get a CAPTCHA without those nasty symbols. Like I said, tested multiple applications. I also tested myself.

I managed to subscribe, even manage to find the proper database if was confused and distracted by the subscription issues that an empty database made me think I was on the wrong place. It turns out that no one yet entered any issues. Perception of expectation was distracted by previous experience and also be pushed by time.

After spending valuable minutes to important things I started my tour using the application of the weekend. When starting an application you can ask several questions like:
- will the executable start an installation script?
- or is the application started because it seems a small application?
- will the application start?
- what can I expect?

After double clicking on the executable I noticed a wizard was started. How beautiful a mind works, at that moment I decided to test the wizard and making screen prints of it to make sure when something goes wrong I can reproduce it without installing it again. again I was confronted with lack of good preparation, were was that good screen capture tool I used in the past? On my old PC of course which left me with the plain good old CTRL+ALT+PrtSc combination.

The approach of the wizard was quite easy:
- look at the text
- are buttons working
- can I install on selected location
- what about using the back button
- is the application installed
- is the application ready for usage
- what else can I learn from the application

Sometimes you see in the installation wizard references to manuals. While writing this down I missed to check this. Manuals can be a source of information too. Thanks to the screen-print I can confirm that there is no such reference. (I checked the documentation I made)

The application can be started! The first thing I learned from the application is that my key-combination was of no use because it functions mostly on menu-pop-ups. I wished I had that other tool back again. There was no time to lose anymore as while testing communication was also by us, members. You might think that communication was distracting us, sure it was, every time you need to look who was replying now. Also valuable information was provided. like: " just 10 minutes left".

This left me just to recheck some functions I decided to focus on and to open the folder where the application was installed to check what kind of files were stored. I noticed an editable application file, not only the manual, also the "ini-file"! When time is short and you want to learn about the application in a different way: open the "ini-file" and start messing around, change the value, raise the number, check if the values match what you saw in the application like controls set to 0 or 1. Keep restarting the application. Stress the application using the means you have. In this case an text editor can be valuable.

During testing I found several issues which I submitted to the database. While doing this I noticed that the way writing down issues divers sometimes. Initialy I forgot to write about my system (PC and OS and installed language) I also noticed that the expectation was not always mentioned. I remembered to think in front about what to write down and what the audience is for whom Im writing it down. Although I posted some information like:
- what was the behaviour found
- what was the expectation (after 2 issues)
- which actions used
- reference towards screen prints
- when necessary: which data used

Finally the remaining 10 minutes were finished. Now the wrap up for another hour took place. Here we came up with some good lessons learned. I believe that the next time we could be more active on sharing our experience. I had difficulties not to continue testing as the conversation started late :). After a few minutes the structure was there, a strong part was that we listen to each other and hopefully learned. I did.

So this was a "short" description of my first experience. At the end I had fun and sure will attend again. Thanks!

For me I came up with the following quote: "Minds are shaped when guided under pressure in a certain direction trying to maintain vision and control."

Is Agile development/testing also recalled?

The book
Sometimes I heard and read about the “Toyota Way” when reading articles or attending presentations related to Agile Testing/Development. Quite often the Toyota Way of working is mentioned to support the Agile way of working/Thinking. There seems to be a good book which explains this approach. I hoop to obtain this book very soon : The Toyota way – Jeffrey K.Liker ISBN: 0-071392-319>

The source
Even a “wiki-pedia” page is supporting the approach and mentioning it is one of the pillars of lean software development.
From Agile software development: "The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development"

The Assumption
When you follow the news lately you might have noticed that cars are recalled. In this case also Toyota. If I assume correct, then the products of Toyota are also cars, their way of working is like the Toyota Way. Based on that way, cars are produced. If cars are recalled because there is an error in the software. then it seems that people rely too much on that approach. If this approach is fallible, the perhaps the approach which using it as basis is also fallible.

The news
Quoted from Toyota Recalls Reach Prius, Hybrids on Brake Software (Update1): “In Japan, Toyota will call back 223,068 hybrids to repair computers in anti-lock brake systems, according to a notice filed to the Transport Ministry today.
“We will redouble our commitment to quality,” Toyoda, 53, said today in Tokyo. “I would like to apologize again to our customers who are worried about Toyota’s quality and safety.”

From the same article: "49 Lawsuits
“The carmaker faces at least 49 lawsuits filed on behalf of customers in the U.S. and Canada seeking a range of damages in sudden-acceleration cases. It also faces at least 13 lawsuits brought by individuals claiming deaths or injuries.” "

The question
I wonder if an error of a product have such an impact would the approach also be revised or only the products of that approach. If parts of the agile thoughts are based on the Toyota Way, shouldn't the Agile approach also not be recalled for revision? Shouldn't the people who are relying on such an approach be recalled?

Recalling
I don't think Agile should be recalled. Still we can learn and should learn from it. If you rely on an approach, keep questioning that approach. Perhaps the issues could be found if they tested better. Looking to this specific issue I can imagine that this error couldn't be found in normal testing easily. Experience testers can make the difference here. Instead of checking exploring or thinking about "touring" might helped. I wouldn't recall Agile. Instead using an example as this to define other tours might support/help.

The Software Testing Jigsaw....

Tweet and re-tweet

Recently I had a thought that there would be s similarity between a jigsaw and software testing.
I send out a tweet into the world to share this thought.

1. Two of the important pieces of a jigsaw is the first and the last.1 to tell it is started and 1 it is ended. What if testing is a jigsaw?

2. The more jigsaw pieces, the more of the shape is hidden. Would distraction by numbers also count for test cases?

On these thoughts I got the following reactions:
TestSideStory: Testing would be an insolvable jigsaw puzzle: there is no "last piece"
Divinebastard: Of course it's a jig-saw; always aiming for optimum coverage

They made me re-tweet/thought about it:
"Perhaps we start sometimes with the "last piece of the jigsaw", missing some fun in between and losing control on how to start"
"Aiming for optimum coverage: I like it. Since optimum can be reached at several moments and circumstances"

Solving is exploratory
After searching for information to support my thoughts I surprisingly came up with an article from James Bach Exploratory Testing Explained
In that article they compare solving a jigsaw with exploratory testing. It is about learning while solving. Getting to know the shape, color and act on the information you receive. During the solving process you change your strategy.

When we just started to play around
It is not only the software which make you puzzle. It is the entire environment. Imagine how we started with jigsaws. When we were little we used to play with those jigsaws with handles attached to it to function as a tool the guide is with the movements. We learned how to pick up the pieces, identify them and how to recognize the shapes were it should fit into.

After a while we got used to these jigsaws and were able to solve them faster. We made the next step into the puzzles were we have to “solve” the jigsaw using more of our skills. We started with those 10 or 25 pieces jigsaw. We loved to play with them as they were presenting our action heroes in fancy colours.

Introduction of the unknown
Some complexity was introduced by our environment. The shape, size and picture is known, and challenge is created by numbers and the unknown. Unknown as this is the first time we have to decide were to start, how to start. Most of the time we gained instructions to start with the borders. Meanwhile to focus on pieces which might help to solve it (faster)

Introduction of speed and boredom
After a while we raised the speed of solving. It is not intentionally we are doing it. We just got familiar to the jigsaw. At this certain age we were ahead of the environment which provides us with the same jigsaws again and again. Besides the ability to work with agility, we also got introduced to boredom. We finished the jigsaw within optimal speed and sometimes we might got unintentional destructive to certain pieces just to earn newer jigsaws with more challenges.

Challenged by numbers and shapes
At a certain level we were introduced to jigsaws with more pieces we dealt with before. Also the complexity rose due to overlapping colours and pieces with less detail. We had to combine pieces and look more carefully to the shapes of the pieces. This was the first time we got introduced intentionally with the aspect time. We were no longer able to solve a jigsaw within the same period or the same day. We got aware about our ability not to finish within time.

Ownership of space
At a certain moment we were not only confronted with the time aspect. Also the space aspect became important. When we were young we were allowed to leave the jigsaw on those places we felt convenient at. When growing older we learned that other people also needed that table we were working on. We need to find tools and means to store the jigsaw and create the ability to continue. Or we need to gain that supervision to claim that space as our own.

Differences in jigsaws and challenges
Fortunately we maintained our position and kept our joy in solving jigsaws. At this level we earned to position to choose our own jigsaw. We manage to solve different images, sizes, and even shapes (notice the 3D jigsaws etc). I can imagine that we start challenging our selves. We agreed that solving jigsaws is fun, therefore we continued. We tried to make a game of it. Solve within predefined rules like:
- Time: e.a. try to solve on the same day, otherwise clear the table and start over again the next day;
- Order: e.a. border last
- Based on colour/ shape: e.a. order first the colours and continue then or different shapes.
- Together: e.a. with other people
- Fun: find the missing piece (remove one piece from the jigsaw and try to guess which one is missing :) )
- On shape of the pieces: e.a. use the back of the jigsaw and solve it based on the shape of the pieces.
- …..

Teaching our children
At the end we started teaching our children with solving jigsaws. Make it happen that they learn the basics of solving, playing and controlling their sense organs. Learn a bit from the things mentioned above. We start teaching and guiding how to approach jigsaws. For them it seems solving, for us it became approaching.

Similarities with testing
Some similarity with testing is there. Testers start with small assignments; easy steps for teasing the mind and ability to act within a certain environment. At a certain moment testers a learning (the) tricks. A pitfall here is they become bored and not seeking for their own challenges. Other testers try to gain more information and are growing in their behaviour. They become able to find their own way within space, time and culture.

There are also certain rules. We have to define our own questions. If it is a jigsaw or a system. Some challenges are the same. e.a. When will we start, when to end. Is the project size defined on number of cases/ jigsaw pieces? Did we have to start with the first piece of the jigsaw or shall we start with an end-to-end case.
Are we able to tell others what we have done and why we have done it? Are we able to explain why we did it that certain way (e.a. borders first) Are we triggered by colours/details or guided by our own skills and ability to define our route.

Magazine: Softwaretesting Club released their first issue

The Software Testing Club released their first issue of a magazine for testers. You can download it here: Software Testing Club a community magazine



I think this is another good magazine. It is worth to read. Also take your time to subscribe to this forum. It is also worth to read/participate and learn.