Changing roads to follow: start exploring

A new day started for me like almost every day starts at this time of the year. The sun is rising
while I drove in my car with music on the radio. I turned on the navigation system and selected a destination from my Favourites called “Work”. You might wonder why is work my favourite, well, at work, I’m involved with software testing and that is one of my favourite things to do.

Every day I follow the same route, actually I don’t need to use my navigation tool as I know where I’m going and which other options there are. Somehow I got used to it getting information which is sometimes valuable for me under certain conditions: the expected time of arrival. That information is also just valuable for a short period. On arrival only the arrival time remains and sometimes arguments for delay.

While driving along the route peeking at the navigation tool what the ETA could be. Also at my
dashboard of the car which is telling me that I’m not driving the maximum allowed speed. Triggered by this information I look with different eyes to the traffic in front of me. Although, different? The only observation I made at that moment was the same as I do in previous days following the same route. I confirmed what I already now: at this time the chance becoming part of traffic jams is obvious. So why bother, just enter the queue and lower your speed and accept
the conditions. Why bother for other information.

This day could be same as any other day. Following the route you already known, look at predefined” behaviour and at the end of the trip: report for duty. Only, this day was not the same as others. I observed that the traffic jam started earlier on the route then occasionally. At that moment I consulted my mobile app and got information about the length of the traffic jam, which was exceptional. I could accept the expected delay and use my navigation tool to monitor the ETA. The chance it would change beyond the boundary of 9 o’clock which would force me to escalate.

I could do what I supposed to do; follow a predefined path and collect information I already
could know. No new information collecting besides there was some disturbance which could cause delay. Making the comparison with scripted testing. Only collecting information about a certain path in the system (landscape) neglecting there are other ways to fulfil my trip. The obvious checks can be made:
- traffic jam = check
- delay within boundaries = Issue (assumption: queue is to long compared to speed and distance)
- option to enter the queue = check
- predefined route accessible = check
- predicted delay = actual delay = Issue (probably)
- accept delay = check
- predefined route followed = check

Again: following this route will provide me information about the accessibility of the route and the time it cost. It doesn’t provide me more information about possible routes which can be followed.

This day was different; I decided to take another route. I already had some information about one route which threatened the ETA: The Traffic Jam on the High Way. I changed my route. At first my navigation system told be to turn around and follow the initial route and based on this info calculating a new ETA. It took some denial of turn-message to get a new route to follow. Fortunately I new a bit of the area.

It seems like ignoring the original route. I see it more as finding a new way to reach my goal.
Immediately I noticed my new ETA was not increasing. It stayed as predicted. This can be translated that the new way to follow was not used at that point by others creating delay.
I cheered too early. Just after a while I noticed another traffic jam. This meant that other drivers
had made a similar observation. Based on my early experience I valued that this route would not bring me the expected result, being early, on time. Instead of adding the queue here I challenged myself by choosing other paths. This time I new just a bibt about the environment. I accepted that decisions I would made now need more information then just experience. It need focussed observations.

I still used my navigator in combination with the environment and my experience. As my
navigator tried to push me back on the high way I tried to ignore it and follow the road signs. A new information source was added to my journey. Just after a few minutes I relied on that new source of information, road signs in combination with small knowledge of the environment I followed and made a short stop. I did not feel good to go this direction.

My feeling and understanding about North, South, West and East I was travelling the correct
way, though I was forced to got directed to the road with the initial traffic jam. I made a bold step, ignore tools, ignore road signs with directions, I used my understanding of the position I needed to go to and the position I was at. At this moment I gathered new information: following this route could bring me back using another path.

I think it was this moment I got aware what I was doing. I was touring around, gathering all kinds
of information which normally would neglected. This seems to me the strength of exploratory testing, reject predefined paths, following your own, while doing reflecting the information you can collect.

I accepted that I can make decisions how to follow my way to destination point. I collected some
interesting information continuing.

- I came again on a road I know. It was also crowded by slow speed queued cars. The chance was that this queue caused the 2nd traffic jam I avoided. My mobile app told me that this queue was also huge.
- based on this information I choose another road combined with the position of the sun. The
ETA was still beyond borders. I saw a detour information board. I neglected it as it seems there might be other ways too. I interpreted it as a detour for other routes.
- A few kilometres ahead I saw traffic signs with places on it, this helped me define another road
which seemed to be more valuable while the navigator was telling me different. Somehow I could not rely on that tool as it wanted to direct me in opposite direction I was heading to.
- While driving I noticed I made some wrong decisions, followed the turn about by 180 degrees.
- I passed another detour which can cause delay
- I noticed it seemed I was lost in space and focussed on different ways, no longer the primary goal to get to the destination point, instead getting back on track again.
- trusting the road signs no longer heading for one known place I drove to a direction where any
place in the direction of my goal. I ignored feeling of being lost. I accepted there are multiple ways to get to destination as I was still in the right area.
- I came closer and got stopped by traffic lights. A new source of information normally neglected
by certain context. I placed it in future context. New knowledge was gained for future tours in this direction. I learned something new about areas.
- Finally I entered the town from a different view and could follow the last kilometres of the original tour. I did arrived within allowed time and learn more then I expected when I started

Lessons learned:
- Following pre-defined routes can make you blind for other information
- Starting to explore you need some bravery and embrace uncertainty
- Coping with uncertainty you need moments to defocus and to focus
- It can help if you don’t value information immediately, try to find the context and
challenge that context against another
- Exploration can bring you different information on different levels; perhaps it is not bad
and not good, if might even not useful after all
- Context can change; be aware and take time to allow it or not
- There is no wrong path, all paths provide new insight, it depends how to value it and
use it. Perhaps not immediately valuable, it might be in the future
- The meaning of situations causing delay change over time
- When exploring you can use more skills in different areas. Trust on yourselves and continue.
- Continuing parts of the original route is not falling back to it; it is addition of your
exploration.
- Even in daily live there are examples which can help you to understand exploring.

This day started good, normally I would complain about the traffic jams, now I got excited by the
lessons learned. I did something which was valuable for me. I was in control and learned. I made the decisions instead the predefined path in some kind of scripted route.

No space for innovation?

This time a smaller note then usual. It came to my mind that in times of trouble we stick to what
we know. In history there were other cases when the world was in trouble leaders gave trust to those who got ideas which might fail or might succeed. For instance the war machine during the WWII provided in a very short time different innovations. (Technology during World WarII)

Perhaps the reason lies with the lack of procedures, methods and controlling processes.
After the war improvements were made which seemed to be successful for that time. People still using those methods and methodologies like PRINCE2, ITIL, BISL, TMAP, Six Sigma, etc. It helped managers to give them a feeling being in control.

Sometimes they still work for them. I’m wondering if there is still room for other approaches then people are looking for certainty and good practices are not yet given it to them. Is there still space in projects to approach uncertainty with Agile approaches? Can we SCRUM and accept the skills of dealing with that uncertainty and adapt earlier to get better results? Is a context driven approach in software testing explainable when managers are focussing on methods which are
know to them, instead of learning and adapting to the actual need?

I might be wrong, implementing methods can be useful, mostly I saw implementations of it where it became an objective on its own and no longer for adding value to business. Somehow I have the feeling that in times of trouble like we are now as in the economic crisis people tending to get proof that the method is working for them and make decisions to reveal that is not delivering the value by blaming it after all on the economic situation.

Is there space to use approaches like Agile approaches or Rapid Software Testing? Are there managers who dare to face uncertainty and learn from it, become stronger and more skilled? Search innovation in the way of thinking and working?

I hope so, as technology is still changing which mean that the way we have to face our new world might be different as we know. Although I’m uncertain about that too. :-) To maintain innovative we have to provide space for those new ideas also. Let us give and get some space for new ideas and try-outs

Issue solving in the cloud

This time not a story which I did a bit of research. This time not a long story, at least the intention is not to write one. This time about a thought I want to share with you.

The trigger for this thought was the failure of internet. As often I didn’t had the phone number available to call some service desk. Therefore I used my mobile and twitter account to express some #fail moment using a #service from some #provider

Within 10 minutes I got response from a service desk who noticed my call and asked for more info over twitter. Wow, I was taken serious, even more serious then providers took me before. They came to me to help me instead I asked them to help.

I provided some info with the idea: “We will see, perhaps it might work for me.”
Approximate 15 minutes later they came with the information that there was some kind of capacity shortage and they are working on it and asked me to have some patient.

Wow, not only they contacted me, they also shared information with me. How powerful twitter can be.
I shouted in the cloud and got help from some kind of desk. This made me think about the concept: “Issue solving in the cloud.”

Imagine that all apps, information, data etc are in the cloud. As user the chance of identification the service who can help me might even more challenging then solving the problem. Nowadays if we have an issue, we make a ticket or call someone to make a ticket and we have to wait and see. If I don’t know who to contact, why not make the provider responsible to monitor. We just need some rules, or perhaps even not. Who will tell.

Assume the following
- I want help
- I don’t know exactly who should help me
- apps are every where and nowhere, at least I don’t know were
- I have a tool which I can use to communicate

If there are a huge number of applications, you can do several things, use several issue tracking systems, (how can I monitor all?) Buy some service who does this for you (why do I need to pay more for something I don’t control?) or just communicate about it and use only those apps of organizations who also care.

Perhaps this can twitter also be for us. In this example I know what was not working for me I used the identifier #fail and a #provider name. Surprisingly, someone cared and responded; and informed me.

Perhaps this is the new way of issue solving, not writing huge reports what went wrong (only 140 characters) get help by interaction (question within time) taken seriously as a customer (provide service). No issue tracking list about metrics, no waste of time by spending more attention how to get the numbers right for management instead use that same time to investigate, learn, question and adapt.

I know this might be far away from the future how to deal with issues and provide service in the cloud. In my opinion if cloud is a new way of serving then also problem solving must be adapted to the this new way of working. Let change the roles. As we placed the apps in the cloud, the data in the cloud and the people in the cloud. The not store the issues on the ground and use the processes for solving as we do know. It might not fit. So let look fore other solutions out side the box into the cloud.

Just a few thoughts about issue solving in the cloud to share with you.

Navigation by blindness

Let me start again with a phrase: a few weeks ago.... some how I got triggered by the navigation system I own. I drove back from work towards the place I call home. I push automatically the “home” button and the navigation system calculated the optimal trip home without asking me for any questions if I prefer another way to follow.

Normally I would consider this normal behaviour and follow the advice route or ignore it. This time I got aware of “it”. “It” gained is this situation a new context. “It” turned from an accepted situation of which the rules did not matter into a situation with several conditions. “It” turned into a predefined path into an path which could be overruled with made decisions which I controlled.

You might think, this is nothing strange, you always follow the route which is calculated, or you also overrule the calculated route.
If so, are you able to make the connection with software testing? Do you even wonder if there are connections?

At that moment driving back at home there were several things I thought of:
- Why do I ask for a defined route calculation although I know were I am, were to go and how to drive?
- Why did I still continue to add the destination?
- Why was I curious about the ETA, I had a watch and I know how long it would take approximately and somehow it was not higher maths?
- Why did this remind me of some moments in regression testing? Performing the same actions although you know the outcome?
- Why did it give me a bad feeling that using a tool did not provide me any additional value?
- Why did it feel as false trust to rely on a tool although I could use my own knowledge, skills and senses?
- Why did it look like I was in control and in testing using standard regressions test or standard automated tests provide same feeling of control?

So why do I bother at all to write about such a simple action. That is “Why”.

While driving I deliberately ignore the advice as I know another route, not faster, not slower, a route which worked for me. I ignore the tool, the navigator, and followed my route. I used a who-cares-factor.
So who cares?
I cared because:
- I got aware that I was able to overrule the system
- I got triggered to ask me the question why to ignore the system
- I added new value to the meaning of the route, as I was curious about some parts of the area
- It made me also challenge the tool I was asking for information. I compared the initial prediction of ETA combined with KM’s to drive with the newly forecasted information
- It made me able to listen to my car under other conditions, instead of driving 80 km/h driving the care with 120 km/h. somehow certain speed at certain moments gave some other thrills.
- I got aware of a situation were things seems so obvious you have to change focus to learn new things and redefine old behaviour.

That evening I learned more about not following blind advises provided by people or systems. I learned to play with the context, instead of accepting the situation I got new insights about the way I behave, think and act. I learned that I and perhaps others using tools out of familiarity instead of certain purpose which value has changed.
I learned that if you don’t change the situation or circumstances then the value will be minimized. This remembered me of a lessons I read somewhere sometime that if you don’t change your regression tests then they are worthless, they don’t add anything. So why do it, spend time, and valuable skills if you skilled testers?

I think we should avoid navigate with certain blindness by relying on tools and defined routes. Instead we should change our test cases and not rely on our “old” regressions tests or other tests we scripted in the past.

Geocaching and software testing

Introduction
A few months ago I was introduced by a friend of mine with the phenomenon called Geocaching. Looking at the title of the Geocaching site "The Official Global GPS Cache Hunt Site" you notice the word "Hunt". To me this seems a bit like testing; as testers we are hunting for bugs instead of caches. Below you will find a short introduction to GeoCaching, for more information check out one of the links.

A short introduction to GeoCaching
The definition about geocaching on the main site is: "Geocaching is a high-tech treasure hunting game played throughout the world by adventure seekers equipped with GPS devices. The basic idea is to locate hidden containers, called geocaches, outdoors and then share your experiences online"

I highlighted a few words which have some similarities also with software testing:

High-tech treasure hunting <> in an high tech environment searching for bugs
adventure seekers <> passionate testers
equipped <> with tools and skills
locate hidden containers <> identify issues
share experiences <> share value of the tester/system

You might find more similarities in this definition or you might believe these are not the similarities. You might by right. In my opinion are more relations between testing which goes further then just looking at the definition.

Recently you see testers I value bringing up all kinds of challenges. Challenges to make the tester think. Most of the time those are directly related to testing like the missions in http://weekendtesting.com/.

Geocaching brings you also this challenge, only not just behind the pc, it takes you in the world outside, the caches are most of the time outdoors (Yes, there are some also located behind doors when you search for example in the centre of Amsterdam on caches)

Besides the official geocaching site you can also take a look at the wiki page: http://en.wikipedia.org/wiki/Geocaching

Type of caches
There are several types of caches with all their own purpose and symbols (depending on site and/or tool). Below you see a selection of
Traditional: The basic cache type, a traditional cache must include a log book of some sort
Multi-cache: This variation consists of multiple discoveries of one or more intermediate points containing the coordinates for the next stage; the final stage contains the log book and trade items
Mystery/puzzle: This cache requires one to discover information or solve a puzzle to find the cache
Virtual: Caches of this nature are coordinates for a location that does not contain the traditional box, log book, or trade items
Earthcache: A type of virtual-cache which is maintained by the Geological Society of America. The cacher usually has to perform a task which teaches him/her an educational lesson about the earth science of the cache area
Event Cache: This is a gathering organized and attended by geocachers.

Types of containers
There are several types of containers which contain the logrol. They are from magnetic to nano. from mini to ammo-boxes. Depending on size the purpose is defined and value can be added.
Example of a nano-container

Example of a ammo-box

Example of a re-using containers (foto-container)

An example of a cache hidden behind a location you normaly wont look

A great example of a container can be watched
http://www.youtube.com/watch?v=Lu7IysgaZf8

Coins and travel bugs
When you found a cache, depending on the size it might contain valuable. For some the valuables are trackable like geocoins and travelbugs. For others they are just playable valuables (kids like those stuff, we don't value any more, thought kids have a new toy to play with)

Travelbugs and geocoins have the behaviour to travel around. Sometimes with a preset goal and sometimes just with the goal to travel as much as possible.

There are several ways of selecting your caches.

Some similarities in caching/testing
Similarity 1: Save environment
I started with selecting caches in the neighbourhood. It feels save when you are in your own environment. Like testing you try to start testing in an environment you know, which gives you a save feeling.
Example of caches in my environment at a certain time

Similarity 2: Learn from environment
During my search in my environment I noticed the different levels of difficulty, terrain and also types of caches. Initially the traditionals were easy, then we started to act as a team (family) and walked a multi-cache in our neighbourhood. We joined our effort and watched and learned during the walk.
During testing you have to look further then just your cases. learn from your system/environment.

Similarity 3: Remember patterns/hide outs
While finding traditionals and exploring multi-caches we trained ourselves to identify the types of containers which contains information or the actual caches. In testing you will also learn about the hide-outs of bugs. For example: This can be based on the technology which is used or the process which is involved. You recognize situations.

Example cache hidden in fence. notice that it is under a lit, (you have to look beyond the black box-vision)


Similarity 4: Touring
While I was already active for some weeks I made some trips to my assignment and also to family. before I went to those location I planned my tripped, reserved some additional time to enable myself to search some caches. Sometimes it were short tours picking up just one cache during the route. Other times it were large tours, planning multiple pick-ups during the travel to the north. For this I used the map from geocaching.com to identify possible caches.
Like in testing, you plan and schedule you tour within a certain context.

Example of a map of a long tour (Defocusing)

Similarity 5: Challenges
Like said before, there also mystery caches. These involves some homework. Before you are able to find the cache you have to solve puzzles to calculate the coordinates. You have these also in different types of difficulties. Sometimes you can use the internet for it searching for answers. Sometimes you have to try to think different. This can be challenging, you have to focus and defocus finding the answers. Sometimes you are not able to find an approach to start. Either you leave this cache and continue with another or you ask for help. In testing we also facing challenges which we are not able to solve immediately. it is from these mysteries you learn the most.

Example of a mystery to solve


Example of another mystery to solve

Similarity 6: Pair caching
Recently I cached with a friend of mine. We scheduled a route to pick up as much as caches within a certain time frame. The preparation consisted out a list of caches we wanted to find and some spare caches. We created a tour plan and drove away. With 2 navigation and 2 GPS devices and internet connection we started the day. While caching we noticed that we could be more productive if we split up tasks. Instead of single logging caches etc we came up with an approach where drove the car, while driving he entered the new coordinates and made some pre-work. At the location we both searched for the cache. When it took more then 10 minutes we used both GPS devices. when found, the friend logged the cache in our administration and I on the cachelog. While hiding he entered the next coordinates and we drove of. We managed to adapt our way of working during our mission.
Like in testing we can benefit from pairing up.

Example Preparing a short tour with several types which fits in time frame

Similarity 7: Collecting information and Registration
There are several things to register and collect. I started to print out all the caches I hunted for. On those printouts I wrote down the date, time and nr of cache found. Just for administrative purposes. When needed I also add answers to questions in the cache or the newly calculated coordinates. This is fine when you are acting in small numbers. Now I learned that storing that information takes space, it takes time and sometimes it is not valuable at all. For instance the caches which are just for picking up. Why store that information also offline while it is online available also. it is available on the spot you found out about the cache: geocaching.com

Example of using other techniques

As learned in testing, I learned that registration should be of some value. Sometimes information is needed for an undefined period, sometimes you can delete it when it is used. For example: when a cache is found and no one needs my information, why keep collecting it.
At least I register the found and the not found on the official geocaching site.
There is some value in collecting information when you solved a puzzle and the way you solved it can be usable for other mysteries in the future.
In testing we do the same: we collect information and we register information. And we also do this too much. A lesson I learned again is to collect just information which contributes to the value of the object/system/person

Similarity 8: Find and learn about new spots in the environment
One thing I like about caching is learning about new locations, I was often surprised about the beautiful nature just around the corner. I get a broader vision about my environment were I live in. Also I identify suspicious bricks etc. on locations it is not their nature. Sometimes you see them everywhere. Currently for me there might be caches behind it when I am aware of a possible location in that area. There is the thin border about known known's and the unknown unknowns. You can explore and take the effort to look below the suspicious brick. You also can save the energy.
In testing it is the same: while testing you learn about new spots in the system. You might see suspicious actions in the system. Sometime you focus on them or you leave them as is.
Example of a cache hide-out in a tree


Similarity 9: Valuing your findings
As mentioned before, caches can contain some values like travelbugs or geocoins. You can select caches based on the probably chance of containing those items as mentioned on the website. You know it is there if you spot it in the cache. Sometimes some other person already found it and took it with him.
When you found an item you can decide if you take it with you and register it as taken, or you leave it and register it as discovered. When you decide to take it, be aware that those items might have their own goal, and sometimes that goal is attached to the item, sometimes you have to read it on the website. be careful to take it when you didn't check the goal, you might disturb the purpose of the item and disrespect the owner.

I found this also in testing. Sometimes you check the existence of value in a system based on some information you have. Sometimes you spot items which you were not aware of. you have to be careful if you call it a bug or an issue. Sometimes you were looking for it and sometimes it is not reproducible.

Similarity 10: Addictive
Geocaching is addictive. I enjoy solving puzzles, walking in other environments, spot those caches. Learn other techniques.
This is what I also gain from testing. I like to test, learn about applications, learn from other people. I want to keep testing.

Conclusion
There are similarities in testing and geocaching, in both you tour around an environment where you gain knowledge if you are open for it. You get pleasure if you enjoy it. You have to approach systems/environments and people with respect.
There are always other approaches which you can learn even after asking for help which guides you kin the future.
One of the valuable lessons here is that you have to spend time and energy to make it your own. (often registration is free and there are no certification programs)

What to learn from puzzles

Here a brief posting to express my thoughts what skills can be learned from playing with puzzles. Michel Kraaij triggered me to share my thoughts about this using twitter were he is involved with a discussion with James Bach. Somehow there is a 140 character restriction and also for him this posting.

As I'm no part of their discussion I will not summarize their ideas. The main idea to trigger Michel is to tell him about my idea "ppl become better in solving the puzzle, only they got trained in other skills which helps them solve." http://twitter.com/JeroenRo/status/19645539452

With this statement I intended to express my thoughts that there are other things people learn from playing with puzzles and even repeating them. It is not only the notion of remembering the position of certain pieces.

In my opinion the following things can be learned:
- position of pieces
- shape of pieces
- how does pieces of for instance jigsaws fit Initially

You can also extend the perception of puzzles. Initially I would think also in terms of jig-saws, this might be disadvantage of my native language (in the Netherlands I was trained to call jigsaw puzzles and forgot about not all puzzles are jigsaws)

So what else can be learned from playing with puzzles? To understand this you can look at the outcome: "A puzzle is solved or is not solved."

Not solving is not a failure; even in the process playing with the puzzle you might have learned things.
What can be learned?
- new approaches to solve a puzzle
- new languages
- other visions
- different approaches.
- looking in patterns to jigsaws
- identify differences between the puzzle which is being solved in comparison with puzzles previously solved
- awareness you have gained new information
- ability to use that new information to use in different approaches
- new attitude to approach things like under time pressure, too less information etc

Perhaps the main result of playing with puzzles is the creation of awareness of the persons capability/ability to identify differences in environments and to use different ways to approach "complex" situations with the available knowledge. The person might teach himselve about the sufficiency of information/skills to perform the task or the need more training/guidance/information. If a person learns when to ask for help, a valuable lesson is learned.

The main idea is that there is more to learn from puzzles then repetition.

@Michel, perhaps we should meet each other again to evolve our thinking about this.

Failure is also human behaviour

Did you ever wonder if a failure could be avoided if skilled people were participating in your project? Did someone ever doubt the developer not able to deliver good code and the tester to provide well executed test scripts? Was the team you were working in a highly motivated team and bugs were delivered real time? Was the trust and believe missing towards the application and the people although everyone did a good job, was motivated, made and kept their promises followed the process and still issues were found on a system which should be reliable?

Perhaps you have not been in a situation like that.

How often did you sit down in the lunchroom of your company? Do you sit down your own seat? Was the seat in a particular corner of the room? Or did you sat on all chairs during the years?

I have been in such a place for over 2 years. There are perhaps over 100 seats and most and during the years I sat on almost every one of them. Here is the trick; I’m not able to tell for sure as I have my favourite spots. It doesn’t matter. The issue here is that I perhaps missed some chairs or perhaps not as result of my behaviour. It is in human behaviour to find the safest spots. For some people this is near a window, near an escape door, some people like to sit with their back against the wall. Some people are not aware of the options and others don’t care.

I’m sure there are other behaviours on this. In my opinion it is important to acknowledge that human behaviour influence the outcome. Often the reason behind that behaviour is not noticed or measured. I think it is not mandatory to measure everything. Though it is important for a tester to be aware of differences in human behaviour and learn to defocus to see better which relations are created between human and its environment.

Failures are not only technical, therefore the tester needs more skills.

Thinking about testing and learning

A passionate tester
I’m not a scientist, I’m not a historian, I’m not religious follower and I’m not a native English speaker (bare with me and educate me if I’m wrong). What I am? I am a passionate tester and see in other disciplines lessons we can learn for testing.

So I come this posting. Yesterday I watched a documentary about the beginning of life. This documentary made me think about the discussion which is recently going on in my world of software testing.

Some references contributing the discussion:
Stuart Reid: Keynote 3: When Passion Obscures The Facts: The Case for Evidence-Based Testing
Cem Kaner: A new brand of snake oil for software testing
James Bach: Stuart Reid’s Bizarre Plea
Jon Bach: The Truth about Testing?
Nathalie Roosenboom de Vries- van Delft A lot on my mind…

The documentary
While watching the documentary on discovery channel I was captured by the example how John Needham (10 September 1713 – 30 December 1781 was an English biologist and Roman Catholic priest) performed an experiment to "proof" that live can be created in an "closed" environment. Based on his experiment he believed that a concept of "Vital Atoms" exists. This concept deals about the escape of atoms into the soil and are again taken up by plants. You might see this experiment of adding water in a sealed bottle and after a while life was growing in the bottle. As there was nothing and it was sealed, there must be something which is smaller and is created by parts of atoms.

If I'm correct he had quite some followers and the concept of "Vital Atoms" became a hype. People seemed to believe what he told based on his proof.

Fortunately Louis Pasteur (December 27, 1822 – September 28, 1895) was a French chemist and microbiologist born in Dole.) proofed with his experiment that a mistake was made. The obvious sealed bottle was not sealing the bottle completely from the outer world. Bacteria were able to enter the "isolated room".

The debate about the origin of life occurred later on triggered by Charles Darwin (12 February 1809 – 19 April 1882 was an English naturalist) who wrote the On the Origin of Species. With this document a new era is started. He didn't write about how life began. He brought biology and chemistry together in explaining how life evolves.
The debate started between a god who created life and life which evolved.

Between the followers that life evolves several experiments, hypothesis and theories were developed to proof that under various circumstances life can evolve and created. For example the combination of oxygen, carbon and other materials combined with some source of energy can result in "life-forms". The Oparin-Haldane Hypothesis by Aleksandr Oparin (in 1924), and John Haldane (in 1929, before Oparin's first book was translated into English), defined such a process. In short I would refer to this process in terms of chemical components which were individual present in the sea and transformed by ultraviolet or lightning into organic components.
Haldane even called it the 'prebiotic soup'.

Stanley Miller came with an experiment called Miller–Urey experiment (conducted in 1952, published in 1953) (re-concucted in 1982) to proof that in an isolated world life can be created. This experiment together with the outcome resulted in "the standard". They believed that it would be so easy to create life.

This concept also supported that life could be created else were but on earth, also called Panspermia. If I remembered well from last night watching the documentary, there is space in found pieces of meteors which are older then the earth resembles the structure of "simple" cells. Combine this with the theory that in isolated spaces also organic components can be created, the change is available to raise life from outer space.

Jeffrey Bada also executed the Miller-Urey experiments (see: Primordial Soup's On: Scientists Repeat Evolution's Most Famous Experiment by Douglas Fox) and continued on it. With the difference looking to the environment of the earth containing amounts of iron and carbonate minerals. He added them to the experiment and came to different outcome.

Other scientist followed their road bringing up hypothesis and research to see about the options creating life under extreme conditions, like near volcanoes, in caves, under water without light etc.

In the documentary I watched more exampled were provided which in my opinion also can be translated to testing.

What to do with testing?
Perhaps you wonder what this has to do with testing. Perhaps you made your own conclusion or picture. What I see is a process where evolution is involved. Not only evolution of the human species. You can see also an evolution of human thinking. Based on the known context John Needham came to his approach and method. He was able to sell it to the crowd and gained followers. Almost hundred years later a new person, Louis Pasteur, came with his conclusion to proof otherwise. I proofed that although the conclusion seems to be valid, the environment was not as what was expected. Based on the knowledge of John, he was right, only due to technique and new understanding; human kind was able to bring up other methods.

In testing I see also people evolve and continue to challenge "experiments" and "methods" and also people who accept certain outcome and become a follower.

Louis Pasteur did not proof how life was created, he just showed what went wrong in that experiment. In the same era Charles Darwin published his view about evolution. This triggered other scientist with other disciplines to continue the search how components evolve.
This evolution triggered me to think how just "zeros and ones" translate in bugs.

I would say that those zeros and ones alone won't do anything. It is the context how the will become visible into functionality and the environment how they can evolve. Even in new functionality or in flaws of evolution.

As testers we have to be open for other disciplines and understanding from those disciplines to continue. We can learn from it and should spend time for investigating those disciplines instead of spending time our approach is the only truth. For learning an open debate and does necessary based on mutual understanding and not solely on the perception own the single truth.

Like Stanley Miller re-conducted his experiment after years we have to be alert and keep learning and questioning our approach. It is mandatory to keep an open mindset. Like Jeffrey Bada did, also perform our own experiments. They might support or adapt visions of others, or even your own vision.

Testers should be able to discuss the possibility of own failure and learn from others if they perform similar experiments. In approaches like the Schools of software testing there must be space to discuss, challenge, disagree and agree with each other to make evolution in software testing possible.

Do you believe?
What I learned from the documentary is that people are followed by others who claim to have found the evidence for their hypothesis and that others are false. To me, it turns out that in history certain failures are often made. In the example above, initially they seemed to be right although time proofed the opposite.

I don't think it should matter who is wrong or who is right, you have to be able to define you own mind and not following people because they claim to have the proof. You might use their thoughts because it helps you. it helps you in your work. It helps you in your own process of learning.

When accepting this, you have to be aware that what you believe in now might be wrong or different later on.

Was John Needham wrong with his assumption? I think not, based on his knowledge and the lack of knowledge of others who lived in his era, he seems to assumable right. Others learned from it. It would be wrong if he deliberately misused situations/ did not present facts or ignore other(s) visions to obtain his proof.

If we follow some school and deliberately ignore others how would this support the evolution of our profession? How different are we then Pope Damasus I who assembled the first books of the bible at the Council of Rome in AD 382? Imagine how different the world would look like when the bible contained other chapters?

I think we should mutual accept each other thoughts and learn from it and adapt. The key word is here mutual. Are you making the step with an open mind and support mutual learning or are you leaving behind?

Additionally to read:
While searching for some background information I stumbled on this book. I believe it is worth reading
Thinking about Life: The History and Philosophy of Biology and Other Sciences By Paul S. Agutter, Denys N. Wheatley preview this book

Rorschach, the power of visualization and software testing?

Introduction
I blogged about my experience in Weekendtesting were I used Astra Site Manager creating a map WTANZ02: Same Language, different sites and places. In that post Shrini Kulkarni challenged me to expand on how to use this as test strategy.

When you look at the images posted there, you might notice that the images look a bit like spots/stains.

Rorschach test
When thinking about spots/stains and deriving information from it reminds me immediately on the Rorschach test.


From Wikipedia: Rorschach test: "also known as the Rorschach inkblot test or simply the Inkblot test) is a psychological test in which subjects' perceptions of inkblots are recorded and then analyzed using psychological interpretation, complex scientifically derived algorithms, or both."


Below you see an example of a Rorschach image. Are you able to read this picture? Are you able to assign functionality to areas? Do you see bugs?

Image saved from wikipedia http://en.wikipedia.org/wiki/File:Rorschach_blot_01.jpg

Primarily based on the perception of these spots the user is asked what and how he experience this and why. What does the spot tells you.

Testing spots

Below you see the 2 images I obtained from "testing" the 2 websites as stated in the challenge from WTANZ02: Same Language, different sites and places.

Just tell me: what do you see?

Image 1

Image 2

It depends how you look at the images, you might identify some shapes. Perhaps you only see dots or animals. Perhaps you see bugs.


The strategy
Defining a strategy is a challenge itself. Writing about it and sharing your idea is even more a challenge. Writing about it and trying to come with a Heuristic is more challenging for me as this is quite new to me. So bare with me, support me and make me teach you as I can learn from you.


First steps
I suggest first to define the approach based on patters. Ask what the image itself can tell you and what information do you need to define the approach.


Imaging: Create a map of the website/ functionality to define a certain landscape
Defocus: Don’t approach the image as a system, approach it as a painting, approach it different, what else do you see? Use your imagination.
Interpret: Are you able to tell a story about what you see (colours, lines, drawings, etc.) and argument it?
Density: is there a structure available representing the first impression you had?


Next steps
After you got a main overview about what the system could look like you might play with the following components.


Complexity: Is there some kind of structure? Are there lots of nodes and are you distracted by it?
Number of objects: Are there too much objects visible you are not able to zoom in without missing details?
Environments: Can the map also be used to identify other systems/ secure areas?
Risk Areas: Are you able to point areas of risks in the map based on "important" functionality?
Process: Is there a order available in the structure which also might support any process?


Other steps
Looking to the previous actions, I hope to provide some additional ideas how images from a website structure can support defining an test approach. I believe looking on a different way to images or structures you might come up with other concepts and thoughts which supports your test approach. The next step could be adapting the newly gained view into your test process. Based on this information you can define alternative test cases or perhaps product risks analysis.

It might help to get back some creativity back in testing.

What you can learn from your kids and yourself?

It is so obvious, I knew it and although I search for someone to blame, it is my mistake.
Sure, how easy it is to accuse my little daughter who sat behind my PC playing some games on it. How adorable she was when she laughed and called me for help. How priceless her smile was when she was proud to be allowed playing on my PC.

It doesn't mind at all. It is broke and I didn't do it. So I am not to blame or am I?

Here is the situation:
I have a external disk drive and I used that one as back up facility. So far so good, why not use an additional drive for backup instead those disks. (I have still some 3,5 inch disks with stuff on it and those cannot be used for backup anymore) It seemed reasonable to use an external HD for backup facility.

That hard drive was standing on my tower, and as it is a tiny one it felt down already quite a few times and afterwards it worked every time. Amazing how solid that Freecom HD was. Until last weekend. It felt, and no one told me. And today after some times I needed that nice solid backup facility. Unfortunately, it was not approachable anymore.

An unapproachable device is nothing new. Sometime USB -ports are just mixed up or deactivated due to some stupid installation etc. As I needed the HD I did some checks.
The initial check was turning on the power. He, that is strange, the power was already on, normally the HD would be recognized. Hmmm. I turned the device on and off. no result

I checked the USB cable, I tried another port. I restarted the PC. Checked the USB settings. Shouted a bit loud just to express some kind of frustration. I checked again the HD if the blue lights was glowing. I listened if the HD was running while I restarted it (turn of and turn on)
I actually checked if it was recognized in the "remove safely-dialog". I kept refreshing my explored window. Did this using THE F5 button, The combination with the SHIFT+F5 button. I used the refresh-option in the explorer menu. I even tried the F9 button as in MS Excel this refresh also sometimes the results.

I stood up and connected that external HD to the PC of my daughter. Tried all USB ports on that PC as well. I actually carried the HD to the PC of my son. All with same results.

While I was walking downstairs my daughter asked me about the status of her new PC. And there something happened, I found another victim. I reminded about the situation finding it strange that the HD was lying on the ground. Only didn't suspect anything at that moment.

While I was walking downstairs my daughter asked me about the status of her new PC. And there something happened, I found another victim. I reminded about the situation finding it strange that the HD was laying on the ground. Only didn't suspect anything at that moment.

I asked her if she remembered if the HD felt down from my PC. She looked with glazy eyes wondering what I meant. I asked her again if that grey little box felt on the ground, and she remembered that. Somehow I felt even more frustrated, it came actually in my mind that to tell her I would work on her PC until cure was found. Only, which person can be angry on her little princess. not me, I went downstairs, informed my wife about the situations, made some strange sound to express my frustration and went upstairs back to the PC.

That gray little box, when I shake it I hear some noise. It sounds like something very tiny was broken. As a skilled engineer I tried a way to open the box. OK, I admit, I'm not skilled in those grey little boxes. Somehow I believe I can become skilled opening the item when it is broken. Also when it is not broken I hope I learn.

Looking back at that gray box no screws visible. I questioned myself if it was worth the effort to open the box using brute force? This time I decided not to open the box. Instead I calculated and argument the damage.
I look at the damages in terms of:
- what is lost?
- is losing a lost?
- time taken to collect,
- times of usage,
- emotional value,
- options to recover (from other) resources,
- time it would take to recover,
- time when information was needed,
- what have I done to prevent loss
- what were my intentions to prevent loss
- what did I not do

Evaluating the process
Looking back and thinking what I have learned or could have learned I come up with this blog and the following identifications in the process
- I found an defect
- I made sure it was broken
- I investigated it in several ways
a. Functional
i. What was behaviour
ii. What should behaviour be
iii. Was the drive approachable
b. Technical
i. Was it turned on
ii. Was there power available
iii. Was the power-cable plugged in
iv. Was the power source connected?
c. Hardware
i. Cables working
ii. Light working
iii. Does it make sound
iv. Can it be opened
v. What effort must be used to open it
d. Connections
i. Was there hardware recognition
ii. Did behaviour occur on all other USB-ports
e. Reproducible
i. Own system
ii. Other systems
f. Information
i. What was on it
ii. What is gone
iii. Were are some pieces stored
iv. How old was data
v. What was the value
g. History
i. What did I remember
ii. What did I do with data
- I checked if others were to blame
- I noticed some strange behaviour as result of my fury/frustration
- I found someone only didn’t want to blame
- I noticed that blaming is not solving the problem
- I searched for arguments not start blaming
- I try to evaluate the loss
- I evaluate and wanted to learn from it

Lessons Learned
When looking back at this situation you might noticed that there are some similarities between this situation and testing.
How often did you:
- face issues and became frustrated about it?
- looked at a system in different ways?
- spend time to find the one to blame?
- did you try to look at behaviour of others and yourself?
- did you learn from that situation?
- did you aimed for value instead of spending time for too detailed proof?

When I look back at that situation I see I didn't stick to problem pointing, even problem solving was not the issue. I valued the situation and took actions. This time it was apologizing to my daughter, removing the external HD from my PC to avoid other damage and check some old other storages and made sure that they are approachable. Finally I scheduled some time to check for other hardware and decided it could wait for a month.

I still have the image of her face sitting proudly behind my PC smiling at me. That is priceless. In other terms also valuable. I would say, that is even valuable then the damage/loss.

A valuable lesson I want to give to the reader: Don't take things for granted, if something happened; look what you learn from it and how you can learn from it.

Testing on the other side

How often do you see that others believe it is not their failure, it are the others? How often are you sure it is not because of you, it is because of them? How often do you see that you did everything to prevent failure and others are to blame? How often do we all blame the other side?

Perhaps not that often. Still if it is not happening at our place, then it must be triggered at the other side. If on the other side failures are triggered, created and on our side solved/prevented. Why are we spending time at our side to proof it works here?
Currently we seem to focus to measure that everything is OK on our side. We are not to blame when the failure hits the fan. So it must be elsewhere to be found. The other side!

If we are sure that it is OK on our side, and failure is on the other side, why aren't we adapting our strategy of testing and look on the other side? Sot the approach would be: create tests what we should do. This will proof we are right. Now reverse the test scripts and test other things as we reversed our thoughts to blame others, then they must be blamed by things we didn't found. That leaves us the parts we are not testing, the parts from the other side.

The thought is acting opposite. If right is OK, and wrong should be found, we believe everything is right on our side; then the other side is wrong. We should find the failures on the other side. Finding failures is NOT blaming. Finding failures is in this case helping out the others. This means working with them on the other side. This means joining for example development, become a team.

To be able to help we should force us to think differently. This also means that we should force us to change our minds to create space for other thoughts and ideas. Perhaps adding a new role to testing: “the devil’s advocate-tester”. He/she will try to force the team think in a different way; although controlled. This role might change every week just to force us think beyond boundaries.

This might result in an approach were space is created to think differently and to extend borders within a testing project.

So prepare to test also on the other side, just for fun!?

Patterns in music and software testing

New music
Yesterday I bought a CD from a colleague who plays in a band called Conorach. In the past he already mentioned about this activity and after an announcement of a new CD release I spend time to pay more attention to it and listen to the demo on their site. Somehow I got convinced to learn more about this band. I decided to support them by buying their CD. That CD I obtained yesterday and was able to listen in the car driving back home.

The ride back home was quite a journey; next to learn from their experience I also learnt about how I look/listen at things.

Travelling home
Imagine: you are sitting in a car, driving all alone, it is already dark outside and there are just a few people on the road. You listen to music you were curious about and never heard much about it. It is not that type of cover-band who brings you music of songs you heard somewhere. It is a band with their own sound.

I like to drive in my car when it is quite and dark. It enables me to think more about things I usually don't care/mind/think about. The situation here is that I like different types of music. If I have to define a range it is hard to do as the music cannot be compared. It differs from The Dubbliners to U2 from Bach to Marillion, from Metallica to de Dijk, from the Baseballs to Pink Floyd, from Fats Domino to Rage against the machine. There is no direct similarity between the choices of sound. Though, the knowledge and my experience with these bands shaped my vision and experience with music.

Try to like it
I started to listen to the music which was playing on my radio. Let me call it the "new" music. Somehow I heard sounds which were familiar to me, they were even sounds I like. First thing I noticed is that I started comparing the "new" music with the perception and knowledge I have about my known "old" music. I wondered if it is human nature when you are doing things with an open vision you try to compare it with other similar things you like.
I did. I tried to compare it with music I know and like. I tried to find the best feeling of my knowledge in the "new" music. I did this for every song and noticed that a song as whole item could not be compared with another artist. Parts of it were comparable.

Are there parts I liked?
After a few songs I changed my approach from comparing whole songs with known artists to parts of songs and even usage of instruments to artists and other music. I choose to compare it on a positive way; compare with things I like. I did this on purpose as the trip was not yet to end. It is better to listen in a good mood then in a negative mood. (I assume) Somehow, this approach made me to learn more about the music. I was able to extend my vision. Not only to recognizable sounds of instruments, patterns of music; also combination of instruments compared with voices. I managed to listen how the volume was used and value that experience.

Finally
As trips ends a CD has also an ending. Within the hour I learned some about a “new” sound, how things can be compared, how I compare things, which I had a good feeling about the music, much more to look at and to check. I manage to value this music and willing to spend more time to listen to it. Listening becomes a journey of its own. Therefore alone it must be some good music, at least parts of it.

Relation with testing?
I know there are items written which might support certain ideas, or part of it. Recently I read a blog which is referring to a book from G. Weinberg with respect to holistic thinking and quality assurance. Unfortunately I’m not in the luck yet to read that book/books. To me it doesn’t matter that much. I believe that it values more to a person who is able to come up with own ideas/thoughts then reproducing others; although it is good to support the thoughts with other ideas :)

Looking back to this experience I believe that in software testing we can experience similar situations.
- compare projects as whole vs compare projects as parts
- compare it with one method vs use more models as comparison
- try to find the best of a situation vs wasting energy to worse part
- try to challenge your thoughts vs sticking to traditional ideas
- see it as a tour of experience vs focus on safe processes
- start with open mind vs use best practices to define approach

Personal lesson
From just listening to new music I learned something about myself. I was triggered to be careful to when using best practices. Knowing methods is good, having experience might count. It only count when it is used justified. My thoughts might be fallible, even my first impressions. I believe in the strength of teaching myself and sharing these thoughts with you will be valuable.
It is good for people to be aware of the pitfall to step in old behaviour and come up with “old conclusions”.

Another thing I liked about this was the awareness you can learn from everything if you open your eyes, ears and mind and try to find relationships. What seems to be different is not definitely wrong. Changes focus from negative perception towards positive attitude might result in new energy which leads to new areas to explore.

As patterns can be recognized based on the view you have, you might be aware of patterns. If patterns are in music in this example, patterns are in testing. If you don’t see a pattern, then spend time to focus and defocus.

Awareness can grow if you are open for it and support skills and craft.

Model Based Testing using your mind

Model Based Testing seems one of the trends which is living nowadays in "the land of the testers"
You will find more often information about this on topic on the internet, seminars, conferences, webinars, blogs, magazines. So it must be interesting, it must be new as lot of people are speaking about it.

I wrote about this topic a bit earlier already just to share my thoughts. 6th june 2009: Model Based Testing was this new?
This time I was triggered by a posting by Ewald Roodenrijs on First model, than build He gives the advice first to model and then to start building. This seems a good advice. Why not use this approach if this helps communication with your team?

A few weeks ago I also attended a session of the European chapter of Weekend Testers. Weekend Testing EWT08: Kept sticking in testing. During this session Michael Bolton also suggested to build a model before start testing. In the perspective of the challenge of weekend testing is was rather building a model in your mind instead formal paper work.

A week later during the session of EWT (European Weekend Testing) I tried to use modelling first instead starting testing. I made up a model about the system how I think the application will be based on the information provided in documentation. to model it I used the heuristic: SF DePOT (Structure, Function, Data, Platform, Operations, and Time)
- http://www.satisfice.com/articles/sfdpo.shtml
- http://www.developsense.com/articles/2005-10-ElementalModels.pdf

For me this worked out well. I learn to think about the software in another way then just functions, test scripts which must pass etc.

If model based testing is based on defining models and use them before you start testing, then I was also doing some model based testing. I only skipped a lot of formal work.
The next step would be translating my thoughts to a user, tester, developer, or who ever is interested. Here a decision can be made: will I use formal model techniques which will fit the model-tools or will I use a heuristic model (hey: also a model!)

I'm sure that there are a lot of advantages with a formal model based testing approach. I personally prefer at this moment using common sense and focus on right questions instead guided by an heuristic approach presented at one of the links mentioned above instead of implementing model based testing with a big bang.

A former teacher told me once: "If you can avoid automation, then do it, once you started there is no way back!" Is this also the case with model based testing?

Another question which just popped up in my mind is: why are we spending so much time in understanding models and creating models and not trying to learn how our own mind is working and how our mind can support us at work? Is this the meaning of learn to learn and continue with it?

Thinking: You have also different types of testers

The initiation
On the 18th of March 2010 I posted an article related to the way people think called Are you a Sequential or a Spatial tester?

Based on that article Shrini Kulkarni Thinking tester replied on that posting with some interesting thoughts. He suggest that the words are chosen incorrectly between sequential and spatial. Perhaps the sources I used are also mixing up the terms. His suggestion is to alternative words like: "Holistic vs Analytical thinking"

On Twitter
On twitter we continued the visions partly triggered by me:
http://twitter.com/JeroenRo/status/10766445585
@shrinik Thanks for inspiring me with your thoughts related to sequential/spatial would you start with getting definitions right or picture?

http://twitter.com/shrinik/status/10767188470
@JeroenRo To get you started: think of "simultaneous/parallel" as complementary to "sequential" as opposed to "spatial". (1/2)
http://twitter.com/shrinik/status/10767230383
@JeroenRo I wonder what would be complementary or opposite to "Spatial". I hope "analytical" is not the right one (2/2)

http://twitter.com/JeroenRo/status/10767725525
@shrinik I don't think analytical is complimentary/opposite to spatial.Analytical might be an opposite characteristic of spatial thinking1/2
http://twitter.com/JeroenRo/status/10767773838
@shrinik in different professions we use the same words with different meanings, it can be used as part of another (2/2)

http://twitter.com/shrinik/status/10767843209
@JeroenRo This whole left-right brain thinking theory (left: looks at parts, right: Looks at wholes) - is a heuristic.
http://twitter.com/shrinik/status/10767881592
@JeroenRo If spatial = holistic then 'analytic; would be a right opposite. This fits well with left brain-right brain - model (heuristic)

Further investigation on terms
Based on the "discussion" (or is this nowadays called tweetcussion?) I had the feeling that we were talking about the same, only the terms are used differently to place the meaning in a different perspective. To understand more I did a short research on analytic vs holistic thinking.

This lead me to two modes of thought by Ulric Neisser, 1963
Here is the reference made that others using the term analytical were U. Neisser is using them term sequential. Seems that more definitions are used.

Another article which was tweeted (sorry, couldn't find the person who guided me towards this article) GSU Master Teacher Program: On Learning Styles. This article exlpains shortly about Myers-Briggs Type Indicator (MBTI) from the Myers-Briggs foundation

Types:
Extraversion (E) versus Introversion (I)
Sensing (S) versus Intuition (N)
Thinking (T) versus Feeling (F)
Judging (J) versus Perceptive (P)

Based on these differences they classified "The 16 personality types". One important phrase Myers-Briggs Type Indicator (MBTI) page is:
"All types are equal: The goal of knowing about personality type is to understand and appreciate differences between people. As all types are equal, there is no best type."

Other thoughts and resources
Another posting related to differences in thinking is written by Markus Gärtner called Turn off the beamer. He also suggested me to read the book from James Bach about the Secrets of a Buccaneer-Scholar. As far as I understood it supports an different approach then schools are providing now. (I still need to obtain this book real soon!)

If people are thinking differently then it has to infect the way of testing. This should result in different types of testers. The portal for testers called Software Testing Club is providing a free e-book related to Tester Types The E-Book in short different types are explained.


My intentions
With my previous posting I tried to start thinking and make others think that the our hemisphere have influence on our way of working. We should not judge immediately people on their view of testing. Some people tending to think in terms of issues/defects. Others in value to deliver. We have testers who think in test processes and testers who building their thoughts based on images of processes were testing is just a part of.

Like the Myers-Briggs foundation was claiming: there are different types of personalities and they are all equal. If different types exist and we accept that, perhaps we also should spend more time to understand our fellow testers. Try to learn from other visions which might not be yours from the start. We can learn from each other. It can result in acceptance of other ideas or providing arguments for you ideas.

Not always is: thinking in test scripts good. Not always should creating a structured test process be the goal; is Finding issues a primary goal.
I suggest:
- Try to understand your way of thinking;
- Try to learn from others by finding out how they think, see the world;
- Try to see if your ideas are accepted by others when you consider these different kind of thinking
- Learn from each other not in terms what is said, instead what is thought. (see the deeper meaning :))
- Try to look beyond the defined borders of behaviour

Back to initial posting
Referring back to my initial posting Are you a Sequential or a Spatial tester? I might have used words mixed up. After looking backwards, I used the words which are used on those sites which seems to me providing a good resource to support the idea that people think differently in combination what is thought on our schools. I believe that the change knowing testers who think more like spatial/visual/intuitive/holistic is larger then the opposite.

In my experience using familiar words also making us to place the definitions and terms in a certain perspective, we avoid thinking more in detail about them. Perhaps therefore using terms like Spatial/Visual is sometimes better.

You might check the mentioned sites again and see the strengths and differences between ways of thinking. you will notice that certain sequential strengths are good for testers and sometimes the visual strengths . This means that people are complex and testers also. We cannot capture our way of working , our profession in models like ISTQB, TMap, Model based Testing, Test Driven Development or what ever. Let us also approach those models by the personality we are. And stop claiming that this model is the best cure for everything. People are valuable and should be supported to deliver value. In my opinion this cannot be done by teaching them models and force them work accordingly. They should be supported to understand models and approaches and make them fit their way of thinking. As part of a team, testers should try to understand how models can be used by others also. To start with this, try to find out how others think without judging.

I know there is much more to say about this. The different types of thinking and personality made me spend some time to think about it. I hope you, reader, also are triggered to think a bit further and built your own thoughts.

Are you a Sequential or a Spatial tester?

Introduction in a new way of thinking
A few months ago I got introduced to the concept of Spatial thinking. I never was aware about this kind of difference in thinking. Sometime you hear that you have people thinking mainly with their left hemisphere, other with their right hemisphere (Yes, this is an open door so let me state this before reading it comments: and sometimes you meet people who don’t think or start to avoid thinking)

Sometimes you hear people claiming that testers are thinking differently. They need a different mind set. I believe it is not a problem to think different; as long as you are open and aware that the human brain can work different for each person. This shaping their vision and awareness about testing.

Differences in thinking
The difference in thinking is explained on Gifted Development Center: "The left hemisphere is sequential, analytical, and time-oriented. The right hemisphere perceives the whole, synthesizes, and apprehends movement in space. We only have two hemispheres, and we are doing an excellent job teaching one of them."

If this is true then it is probably that our teachers, instructors and coaches also taught us also just to approach out testing knowledge based on sequential, analytical and time-oriented way.

From: Visual-Spatial Thinking

Spatial and sequential thinking are two different mental organisations that affect the way people view the world. Sequential thinking is step by step linear thinking over time, while spatial thinking is an holistic system where all knowledge is interconnected in space.

Strengths and weaknesses of spatial thinking
To understand possibilities of spatial thinking and testing you might need to see what the strengths and weaknesses are of spatial thinking. Below you will find an short listing of possible strengths and weaknesses. Keep in mind that no person is for 100% a visual or spatial thinker.

From Strengths & Weaknesses of Gifted Visual-Spatial Learners Source: Dr Linda Kreger Silverman Ph.D. Director of the Gifted Development Center Denver USA

Differences in Sequential and Spatial thinking
A comparison between the two versions is explained in: Auditory-Sequential vs Visual-Spatial thinking: http://www.gifteddevelopment.com/Visual_Spatial_Learner/vsl.htm Also see image below. When looking at it you might be forced to speak out your preferred choice. You even might suggest that Auditory-Sequential is more appropriate for testers because they are stronger in:
- Has auditory strengths
- Is an analytical thinker
- Has good auditory short-term memory

These are just a few of them. You might check them yourself

From the site Research on the Visual-Spatial Learner a research by Dr. Silverman is published providing the following facts: (I'm not in the position to check these figures and take them as proven results)

We have high confidence (over 80%) that: - At least one-third are strongly visual-spatial - One-fifth are strongly auditory-sequential - The remainder are a balance of both learning styles
Of that remainder (who are not strongly visual-spatial nor strongly auditory-sequential), - Another 30% show a slight preference for visual-spatial learning style - Another 15% show a slight preference for auditory-sequential learning style

This provides the conclusion: "This means that more than 60% of the students in a regular classroom learn best with visual-spatial presentations and the rest learn best with auditory-sequential methods. "

Sequential or Spatial Testers

When looking at the differences, strengths and weaknesses I have the feeling that the way people think has an impact on their approach and skills in testing. A person is not fully left or right thinker. Instead of seeking the disadvantages of this way of thinking we might accept it and see how it can strengthen a test process. If you accept this, you might make the next step, how to use those skills. Before you can do this you have to identify the type of thinker/tester.

Imagine what the possibilities are if you are aware of the way people thinking in communication? How about test scripts/results, requirements? Which tester would be better to prepare an overview and who have strengths in detailed testing.

I see in this topic some opportunities and will take some time to see what this way of thinking can lead me.

For more information you also might check:
In How to spot a spatial by Betty Maxwell, M.A.: "provide some clues to help you recognize those picture thinkers lurking in your environment."
The power of visual thinking by Lesley K Sword, Director, Gifted and Creative Services Australia 2005

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.