Growing bananas

This week I attended a presentation Exploratory Test Automation:Investment Modeling as an Example given by Cem Kaner in the Netherlands as part of the Cem Kaner week

One of the statements he made is avoid commodity. This triggered me to reflect on how I see software testing.

To my opinion Cem Kaner tried to explain to use why commodity is good for those who feel happy to be a tester who have and can use standardized skills and knowledge. Who accepting to be replaced easily and who’s expertise can be cheaply outsourced. Those testers are as valuable for the client as all other testers. The other side is that there are testers who are willing to become better; they want to become valuable for the client. The client experiences the value. I think for this you have to express yourselves, keep learning, and adapting to the environment and work hard for it.

What does this have to do with growing bananas?
As C. Kaner mentioned about commodities:
There are green bananas
and ripe bananas
and rotten bananas
and big bananas
and little bananas.
But by and large,
a banana is a banana.


If you look at the phrase above and replace "bananas" with "testers" then testers are in general commodity testers. Unless they choose not to be a commodity tester. If the choice is made then you have to become aware of yourselves, what do you value?

As with a banana, the shell can be used, only the inside is eaten. Based on that taste the banana is valued.

This made me think a bit further. In general if people are thinking about bananas they visualize the banana including the shell and sometimes with a small piece of the inner stuff visible. People are visualizing a banana eatable when the shell is removed. There is more to imagine. the structure of the inside of the banana is also a result of the outside structure, how it is grown, how fast, with which means and under which conditions.

The same can be the situation for testers, they might be thought under certain conditions. This might not definitely lead to wrong results. They remain testers. I can imagine that for certain test certification might be useful to gain some basic fundamentals about testing. It might be right, it might be wrong. At least a direction can be defined. It is up to the tester if he/she becomes a commodity tester or able to add other specific value to the client. There are more roads which leads to Rome.

If testers are tending to become commodity testers and they might be identified as bananas. As said, bananas shouldn't be judged and testers also not; just because their believe in methods and approaches is different. I think it counts more what a tester is doing to become of more specific value.

Serving the method

In a discussion with a fellow tester we talked about testing effort. The situation was deliverance of certain request for changes. It contained functionality of which the persons who wrote the functional designs claimed it hadn't that much impact. The users who were involved also claimed it can be tested intensively spending several days or just the main things accepting risks.

There were also users involved which had their own history with the system. They wanted to test the system based on their experience from the past.
The fellow tester admits there might be more options to test which the others didn’t think about. He based that idea on the method he has been thought. From theory, he might be right. He also used the arguments based on the method. One of the main arguments was: the quality must be right and optimal. To claim this we should spend a lot of test effort.

In the discussion it was not about who has right and who is wrong it was about the effort needed and if it was valid to use a test method as argument for the direction.

When people are discussing, there are several views. As the fellow tester doesn’t blog I can only present my view.

In my opinion the following points were important
- No discussion was needed as the changes were important, it was forced by top management;
- End date was fixed due to management decision;
- Resources for test execution was available because of importance;
- Resources and quality of documentation to derive test cases using test techniques was not sufficient available;
- System was available;
- Support from development and business was sufficient;
- Solutions would be delivered in time and on time, just before the deadline;
- Time was left to follow phases from TMap, no time left to identify and cover all risks;
- Knowledge of application managers and business was more important to select test cases then the documentation and test techniques;
- Cost of not delivering was larger the solving after implementing on production.

When looking to a method like TMap, it wouldn't be possible to implement a solution on productive system as not enough proven information was provided about the risks. No defined and measured coverage was made visible. Requirements were too poor. No test techniques were selected and used which were mentioned in the method. Still we made it to deliver successfully to productive system.