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.

A recipe for success? Are the requirements clear?

Images above words
How often did you not heard that images tell more then words. Of course we all believe that; as our project manager of also you wants fancy colour charts and dynamic results, deliver real time.
A while ago I planned to make dinner. It is one of the recipes I got from a fellow student, we even named the recipe "Drietdrap" (don't ask me for the explanation) At that time I cooked it for some ladies and they were sold. Although it doesn't look good. I will be honest, it looks awful when you see it the first time, it taste even better. Perhaps that is the deception, it taste better then it looks so therefore it is good.

I have cooked this meal more then often for friends and family, even my children like this meal. Every time I was asked to write down the recipe so they were able to reproduce. When starting this time I noticed that I wrote the recipe already multiple times and depending on the time it was more or less detailed. This made me think about the job I love: testing. Do you taste the similarity already?

Here my story for success. Enjoy your dinner!



Would this be enough information to make create the meal and also test the meal?

Words above images
Another approach to tell the same story with words.

Ingredients for 4 persons (looks like requirements?)
- 500 gram minced meat
- 250 gram mushrooms
- 1 or 2 unions
- 2 pieces of garlic
- spinach
- crème fraiche
- Boursin
- pepper
- salt
- pasta tri-colore

Actions:
Bake the meat, add pepper and salt on taste. Boil the water, chop the union, mushrooms and garlic. Add them to the meat. Heat up the spinach and add the pasta to the water when it is boiling. When it is all done remove the water from the pasta. Add the crème fraiche to the spinach. Add the Boursin to the pasta. And mix all together. now you have a lovely meal.

Are you familiar to the recipe? Do you know when you are done?

Mind mapping dinner
Like every meal I cook, I do it merely using my mind and my sense for taste instead of the actual recipe. To structure the cooking process you can you use some kind of a mind map. perhaps the one below helps you out?

Do you also see and feel it? Do you feel comfortable now there is a bit of structure? is this best of both worlds? An image and some words?

The story so far

Like always, the result you have experienced before never succeed the success you gained now. There are several ways to communicate and there always will be information missing. As tester you have learned never make assumptions. And you now the results only at the end, is it? Sometimes there is a combination between documentation, written words and models. The image below is not a correct way to explain. For me at this moment, it is a story I could have told while cooking.

Context

I provided you a few examples how you could explain cooking this meal. There seems not much a difference between cooking and testing. You have different roads to approach cooking. You have different ways to tell. If you like to cook for profession or a person who likes to cook for fun or a cook who does it because someone has to do it. It is the result which counts. We have to eat for living. Sometimes the looks and the taste don’t care. It is the value of it, is it an in between snack or dinner to survive?

In testing you have these kind of testers also. You have persons who live by the book, you have testers who act on vision and experience. You have those who are creative and willing to try and accepting to fail. As long as they learn from failure and there is time for failure.

in the examples above you will see that information can be brought in different ways. People who are familiar with the recipe or keen on learning perhaps need less detailed information than others. For others detailed information is mandatory. It is also not only the recipes which are counting, also other information related to expectations. Like I started I once start cooking this very successfully, which might be important information as it doesn't add value in preparing the meal, it colours the expectations.

The same is about how old and trustworthy the expectations are. How about I tell you that that nice achievement is about 20 years ago. I cooked over the years more often and was also successful as friends and family were satisfied. Perhaps there is some kind of additional context, designed by memories.

Conclusion

There is not one recipe for success, There are more ways to serve. I hope you learned that we should NOT ask for detailed documentation, we should ask for information needed to add value. In this case the value was when dinner was served and eaten. Less important was the order things happened.

This sounds like testing

Previously compared
This week I already made a posting with a relation between music and testing Patterns in music and software testing. In that post I tried to link it to the way we try to value music towards testing based on identification of certain patterns.

Today I drove in my car to work, normally I listen to the programs on the radio, this time I shared that time. I listened to the radio and again to the band Conorach.

Previously I tried to compare the music with other artist I know. As already spoken I noticed there were some patterns I recognized in the music and based on those I compared it with the others. This time I made also a comparison within the music.

Comparing with numbers
It starts with identification of patterns. If you are aware of patterns you are willing to look at it in different ways. Instead of trusting the known approaches you can search for other relationships.
I think there are certain steps you can make. I'm sure there are books which explain this better than I will do know. Only, books are not available yet/now when the mind is throwing ideas :)

You can listen to music in different ways. Your perception will be defined based on who, how, when, what, why you will listen the music. Are you listening a song you already heard about, listening the whole CD or is it live? Are you in a good mood which fit the music or artist? Do you want to listen since you need to recover from an exhausting testing session? Or, do you need to energy to start with it?
You can listen in different ways, focus might shift/change.

When I was driving in my car I shifted to focus from comparing the music and certain pieces with other artist towards comparing parts between the songs on de CD.

Seems in songs you can use other artists as Oracles, you can also use the songs of that artist as an Oracle. This sounds familiar, don't you think.

Comparing with testing
Imagine you replace artist with system and you replace songs with functionality. This gives the following sentence: "Seems in functionality you can use other systems as Oracles, you can also use the functionality of that system as an Oracle."

To me it seems that music can be used well defining approaches for testing. Perhaps even better then the traditional methods. Ouch, now I might be walking on thin ice. It is not that I am against the traditional project or test methods/approaches. I only experienced too often that maintaining the arguments for using methods is the goal instead of the goal you start using those methods. For me it always helped to change the glasses I was looking to. I tried to look at projects/systems with other point of views. This is necessary as systems are built for humans and organisations. They are also different which result in differences in perception.

Differences in perception is a strength

Music is also different, we all experience songs, music, tunes different, people are different. This leads that perception of music is different. Still we are able to value them within a short period. Some will like the music and some will not. If people have to listen together to music then often is avoided to play music only a small group likes. Imagine you are at work and you play your song and only you like it. Your colleagues might get annoyed by that tune (they wont call if music). This will lead in irritation, lesser performance by them, focus on wrong things. A solution for this is a mutual understanding and knowing that the optimal situation per individual is not obtainable. You have to define a common goal.

Define a common goal

To define a common goal you can use heuristics for it or perhaps use the quality attributes mentioned in ISO-9126. Perhaps this works out. The danger I see is that again best practices become leading instead of first thinking which best practice is the most valuable here. Also, is there a need to learn more best practices first. Learning from music might be a good way.

If a human being is able to value it using their mind and willing to learn from it. Why not use music as a metaphor to help testing software. If people on a work floor can come together about music then it must be valuable to use it also coming together about using systems.

Some instruments are easy to play, especially by experienced people. Some words are better to sing and understand. There might be differences in keeping the tune right. Some can some won't. Compare the guitar sound between songs, artist and time. Even an artist is growing in a direction.

Music is the way
What I'm trying to say is that it might be good if you are following traditional steps to make other moves and learning from music might be such a move. I challenge you to keep learning from situations and don't be distracted by ideas from others like methods etc. Try to listen to the music of the artist I started with: Conorach. I'm curious what you can learn from it. And how you learn from it.

I noticed some riffs from Joe Sattrianni, tunes from the Dubbliners, voices from The Nits, Iron Maiden is also involved and somehow the quietness of Pink Floyd and the piece of Bach. I also noticed other artists I forgot the name. If I try, I can find other songs which seem a bit similar.
I noticed that in a system functionality can be pointed to instruments, some are solid and some are fragile. Some are nice and some are fast. Some are played from paper and some jamming.

If we can come together valuing music would it be able to come together on testing? Accepting the differences in methods/approaches/systems/people?

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.

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.

Investigating details, a waste of time?

I had a great holiday this year. With my family we lived in a tent for 2 weeks. Every day was fun and gives me the opportunity to have some quality time with my family. Of course there were some moments which good be better. It was great because the big picture fits.

When sitting in my chair in front of the tent I had some time of thinking. Clearing my head of thoughts I filled them with news ideas. I needed something to do and made some pictures from close distance. This gave me the idea that although the pictures are nice it doesn't tell the whole story of my holiday. This made me wonder why we are focussing on details in testing. Why we are for example insist on unit tests. one of the reasons is to find issues sooner. Should this be done as in a huge system there might too much details. For example, if I shoot every detail of my holiday I had to spend more time on defining details and making the pictures instead of enjoying the holiday. Because of this I would miss a lot of joy.

Below you find some pictures I shoot. With these examples I will try to explain why focussing on details is not always the right way.

Foot-picture:
My son asked me to make a funny picture of his foot. As you see, you can notice some details. Only is this enough, at least you can check that there are no wounds on it. Ask your self, if there was a wound and it should be nursed, what sense would it make? Is it necessary for the whole picture? The grass behind the foot gives a indication that there is more space behind that foot. Currently the foot is the main object. If I would fade-out it would become part of a bigger picture. In that big picture a lot of other things are happening like children playing, parents sitting, tents standing, trees are growing. As a foot is is part of that bigger picture. I would ask you: If the foot has a wound, what influence would that wound have on the bigger picture? Should it be nursed? Was the time spend on this detail valuable for this bigger picture?




The grass-picture:
Looking behind the foot you see grass growing. When you are on a camping site you have lots of grass growing. When I would make pictures of occurring circumstances which it would certainly result in pictures with some pieces of grass. Is it necessary to investigate every time the details of it? With the picture below I could ask several questions about the colour, the structure. How is the single grass halm growing? Are there different types of grass, is the floor covered well? Are there some dangerous insects living over there? Are there laying pieces of glass lying there which might hurt the children? I wonder is it necessary to ask these questions every time to value the bigger picture? Should I spend in testing all the time effort to similar objects only on different places? Should all details be covered?


The wooden stick-pictures:
Even when there is a need for investigating details, is it done right? In the example below there would be a need to investigate the wooden stick. As you see, the wooden stick can be tested in similar ways on both pictures. Only there is a slight difference between the pictures. So when do you know when you are using the correct view? How can you tell from which angle you should test? I you focus only on the stick, what can you tell about the size? Perhaps it is not a stick, instead a tree. Due to the size it might hurt and have impact on my holiday. As you see, to check the size, you have to focus on other details than the stick. You have to look at the position of the stick with respect to its size and the environment. Focusing on the details of the stick will cost too much time and wrong conclusions might be drawn.




The ash-tray picture:
Sometimes the detailed image looks very dirty you hardly can continue watching at it. For instance the code is very sloppy code. You get distracted from the bigger picture. Perhaps this is a result which supports other issues. In the ash-tray you see a lot of dirt. It is unhealthy etc. Still it is functional. The ash is stored in some kind of a container and can do less harm when there is no wind. If the ash-tray was not there, the output of other habits would be stored else were in an uncontrolled environment. Is it necessary to check in detail how it looks like?



Beer-can picture:
This picture is one I like, it shows some important information from the beer-can in detail. Only I know it is a beer-can as I drank used it. You only see the top of it and can perform some test on it. How would you know if you are sufficient? When are details good enough? If these questions cannot be answered what sense does it make to perform detailed tests.



Food-picture:
Sometimes the details look like a mess; you have to focus more to see what is in it. After focussing you will see objects which can lead to further testing. Would it make sense? The picture below is from a dinner we had, although it looks awful it tasted very good. And it was just to combination which made it taste good. The taste was the main object of the food;it should fulfil one of our needs: dinner and we should be able to eat it while it is hot. For those objectives it was not necessary to have each piece lying in a specific order.




Towel-pictures:
In both pictures of the towels you see details about the structure. The first is made from a larger distance then the second one. How would you know that the detail you look at is sufficient? Wasn't it good enough to know that towels were available and trust the purpose of them, drying your hands? Looking at the towels you also see that the sun is shining. Sun was an important factor of success of our holiday. Do we need this picture the draw this conclusion or should I made another picture with the towels?

Conclusion
With this story I didn't want to tell that spending time at details is not useful or unnecessary. It should make you think if it is useful to look at details any time. Is it mandatory to perform unit tests? Of course people might claim that according the Boehm-law, found issues in an early stage is much cheaper to solve. You have to ask your selves every time, is it needed to find issues in those areas? I hope the examples given above made you think a bit about the meaning of details and focusing on details. Of course I could have made other pictures as well about the holiday and also there the question can be asked, is it detailed enough or not. It is this what should be done: keep asking this questions.

10 Lessons when waiting for a fix

Our dishwasher is broken. It bleeps and light flashes quickly for four times. The water is not pumped away and after trying to reset the machine, it keeps offering water. Don’t do this at home because after a few trials the floor gets wet.

As always, when something breaks the time is never right. With dishwashers, they break when you need them, or not? In this case we noticed it wasn’t working because there were some dishes to clean. When the machine stops, it really stops. To process for a solution might be quite interesting.

When the machine told us there is something wrong I went to the machine and investigate what symptoms there are:
- Water in the machine
- Clean dishes (it stopped at the end of a cycle)
- 4 Short bleeps and blinking light
- Reset button functions
- Restart shows same behaviour after a few minutes
- Water was offered to machine
- No other noises

With this information I went to the internet and performed a search based on the symptoms and brand of the machine. Somehow I didn’t had the information available about the specific type. I found several threads mentioning several options to do:
1. Clean the machine using some special cleaning stuff
2. Hire a mechanic
3. Do it yourself (some “detailed” information how to do this was also offered in terms like: remove screws, check, be careful)

As it was weekend when this behaviour initially started I couldn’t do anything at that moment. This bothered me and made me feel bad since we got used to this delightful machine.

As a good husband I tried to fix it myself the easiest way, telling my wife to clean the machine by buying the tablets which should do the trick. As the machine was still under guarantee she called the store and heard that if the machine is the problem, only the call out charges has to be paid. If the problem is blockage of the filter, then we had to pay also the hourly fee.

After a short discussion with me by wife bought and used the tablets and it worked for a while. Only now it is broken again. Again we tried to clean the machine which didn't work. It seems that the pollution wasn’t the problem after all.
Lesson 1: If the symptoms are gone after trying a solution, this doesn’t mean that it was the proper solution, it can be coincidence.

Together we made a decision to call out for the mechanic. They were responding very quickly, within 3 days, he will come and check under the same conditions. We accepted the risk that it didn't had to do with the machine and we might have to pay also for the hourly fee. We were able to avoid this by calling in a plumber. Only this would also cost money and no solution is guaranteed.
Lesson 2: When making a decision who should help, call in the proper person based on own investigation and others.

Today is the day, the mechanic will come. The waiting is started as the store mentioned that he would here between 8:00 AM and 6:00 PM. "Fortunately" he will give a call in front just 1/2 hour before he would arrive. I have to admit, when the period is there when solutions are entering a certain time window, uncertainty is more annoying when calling in terms of hours then in days. You have to adapt your schedule based on this uncertainty.
Lesson 3: Communicate when an agreement is made on delivering solutions. Time schedules have to become more detailed when the time is right.

While writing, the mechanic called. He will be here within 20 minutes. Now the moment of truth becomes closer, what should we pay after all? And will there be a solution provided? I already prepared myself by being able what I have done to avoid discussion that it is not the machine and that we urgently need a solution for this problem.
Lesson 4: Be prepared when a solution is offered, communication on arguments become more important otherwise you might have to pay for false reasons.

Of course, we have a workaround, doing the dishes manually. Only this is not a proper solution as the dishwasher is using valuable space in the kitchen which will become useless.
Lesson 5: Workarounds should be temporarily, as there are other costs then the usage of missing functionality.

The mechanic just left. As the outcome was not yet clear in the beginning it seems to me important to assist him removing stuff which stood in the way of investigation. I could decide that he can do it himself, only I would spent valuable time from him and since the verdict was not yet made I probably had to pay for it. During the process of investigation and problem solving I was around for assisting and answering questions, trying to avoid not being in the way.
Lesson 6: Provide support which is in your area, avoid discussions and certainly those who area out of your field of expertise.

Within minutes he found the problem. He solved it and also made some adjustments to the "infrastructure" as he couldn't find the cause of it, only noticed that there was something wrong which could be easily fixed which might avoid similar problems in the future.
Lesson 7: If the problem is solved, also take some time for the situation.

After everything was set in the proper place, like the front desk of the dishwasher etc, he performed some small test. he turned on the machine and observed the behaviour. He also listened if it sound right and if the problem actually was gone.
Lesson 8: Let the "problem-shooter" convince himself that the problem is gone. This can be done by demonstration.

Now there was some time to offer him coffee. The mechanic is also human and this was a good opportunity to show respect and recognition. During this few minutes, he was a fast coffee drinker, he explained more about the situation, how it could happen and also a bit about his work.
Lesson 9: Show respect and recognition in a proper way. You perhaps need him again. Don't exaggerate.

At the end, the bill has still to be paid. Fortunately, we had to pay only for the call out charges. The mechanic explained that it felt under the guarantee conditions as he couldn't find the exact cause. He also provided information about situations it wouldn't be part of the guarantee.
Lesson 10: Ask for information about the situation so you are able in the future to narrow your initial decision about what to do.

Whisky or whiskey and testing

Some people call it whisky and some name it whiskey. The notation depends of its origin. In Ireland and the USA they use Whiskey. In Canada and Scotland they name it Whisky.
In the Netherlands we tend to use Whisky.

With this liquor you have differences already in tastes, flavors, ages, colors, experiences. I can imagine that you also have differences in believe and understanding. Most of the people can name at least three different brands of whisky and tell which is better. There are a lesser of them who actually tried that whisky.

You have these kinds of differences also within testing. People think to talk about the same when referring to testing an application only the approach is different. Like with drinking whisky, people have different understanding and believe they talk about the same drink telling it is the best whisky. It is quality. They claim this statement because of their experiences.

If this is true, then quality is just a result of the experience something gives you. This has quite some impact on testing as people tend to get experience by using specific approaches.
For example the view of testing in the USA is a bit different then in Europe (I'm generalizing a bit). In the Netherlands we tend to test according procedures, guides, phases, project plans, steering groups etc like test approaches called TMap and ISTQB. In the USA they tend to test based on technique, their understanding of technique, heuristic methods etc.
Because of these differences the experience will also differ. Therefore the perception of quality will not be equal. As result of this; testing is not equal.

The pitfall here is that we are trying to teach each other about testing, sharing ideas and learn from each other based on different levels of understanding while information might not fit the experience. Wise lessons are misunderstand and misused.

A few days ago I noticed on twitter how a fellow tester was going to enjoy a 16 yr old whisky called Lagavulin. I never heard about this brand and believe him when he claims it is a good, quality whisky. For myself; I like the 18 yr old Highland Park and in certain situations the 12yr and the 15 yr old are also good. It depends on the situation and mood I'm in. This is an example of differences in understanding quality although we both are talking about the same topic, there are differences in experience and understanding. I could try the whisky he is drinking and offer him some of mine to get a better understanding of each other, perhaps when the occasion is there. At this moment I stick to testing.

Knowing about differences in testing I try to understand more about other ways of testing. You can read about it, experience is more valuable. For this I was lucky to visit the Miagi-do of Matthew Heusser as result of my search for a Mentor, Mentor in software testing. During these visits I received a black-belt challenge which I accepted. I will not share the details of this challenge as it will not be a challenge for you any more. That challenge was though. It was a brain teaser and breaker. It was fun to do. I think the strength of the challenge was the capability of Matt to adapt the challenge based on information I gave him.

At the end I earned the brown-belt and I'm proud of it. Not because I got a brown belt, because Matt made me learn more about myself how I approach testing, what differences there are in points of views, were I rely on my own experience and what the pitfalls are when doing this. He also strengthen my idea that there are more views in testing and to understand those I need to learn more. As I knew this already and I am more proud of gaining the brown-belt instead of the black-belt. It makes the brown-belt more valuable because I'm aware of my knowledge, willingness to learn and drive for testing.

Like drinking whisky, testing is also a case of perception. They might differ based on experiences without claiming what is good or bad. For this you have to be able to communicate on proper level of understanding and able to share thoughts and ideas.

Driving a car successfully or driving a successfully car?

You might yourselves the question what you really are doing and what your objectives are.
What do you want: "Driving a car successfully or driving a successfully car?"
Or perhaps successfully driving a (successful) car?

Although this question has nothing to do with testing. It has also everything to do with testing. And no, this is not the metaphor about explicitly mentioning colors, requirements and what car you want. It should make you think how you approach your testing.

Introduction
I'm am aware that there are laws and rules on certain places which states you have to be above a certain age, you need a driving license, you need a car, preferably your own car. I also know that there are different perceptions about what successfully is and what cars are. And yes, they might have some influence on the outcome. And no, I won't consider them in the lines which will follow. Sometimes it is better to leave certain values and restrictions to keep a better picture and stick to a main concept.

Purpose
I believe it is in human nature when they have to do something they start doing their best. They want to be successfully. I think it is also in human nature to give own interpretations to questions, assignments, stories etc. These interpretations are mainly created based on information which is not verbally given. When someone hires you for testing, you assume you should test like you always did. You start using your best practices without checking if that is wanted.

The same can be done with driving a car. A purpose of driving a car which makes sense is to go from point A to point B.

I think here the mistake starts. Based on best practices you can assume that from point A to point B should be done in limited time. Did you check this? Or should it be done in an optimal way. What is an optimal way? The shortest route? The less gasoline consuming route?

Perhaps you even don't look for information and you sit in your car and based on your experience you go beyond the speed limits. Is this asked? Is this allowed?
Are these the right questions?

Driving a car successfully
Imagine you have your car and start driving. Without instructions and the assignment you are willing to go to point B. As you are an experience driver you hit the road. During the trip you rely on your best practices. You were taught to watch the road signs, monitor the gasoline meter, look further then just the car before you, use a kind of mapping device, or map, (or perhaps you know were point B is and you don't use them at all.), etc. You make assumptions based on your interpretation and you take action according your best practices. Your reach point B.

You might think I drove my car successfully as I made it to point B without accidents, within time using the allowed gasoline.

Are you really successful? What about:
- the location of point A?
- is getting from A to B the main purpose? Or can it also be taking some type of luggage in the direction of point B?
- is point B a coordinate on a map or just a reference to a location?
- are you sure that the care must be unharmed?
- was reaching point B the objective? Perhaps it was the task to do everything but avoid point B.

How did your best practices influence your decisions and would it help if you first started with investigating the main purpose and conditions? Don't interpreted this that all requirements should be clear and SMART. Only those who matters.

Do you also start approaching a project as written in TMap or ISTQB? Because your references and best practices are based on these ideas? Or do you investigate and then decide of a method like this can be of some use?

Driving a successfully car
A Porsche is a great car. So are Lamborghini, Ferrari, VW, Skoda and so on. This is what we should believe if we read all the adds, articles, forums, researches. And all can be used for driving. If you believe unconditionally all those stories, adds etc, you are driving a successfully car. At least you believe this. So will everyone have his/her successfully car. Are you willing to drive the car of your boss although it is not your favorite? Be careful how to respond as it is the boss's successfully car. Or is it? Perhaps your boss was also was forced to drive it.

To decide which car is a successful care for you, you interpreted all kinds of information and you based your point of view on it. It helped to built up your experience about driving this car. Somehow it is also in human nature to defend your believe about a successful car, of course it is yours otherwise you wouldn't driving it.

There might be some kind of process behind:
You first bought a car for a purpose; you start some investigation which car suites the best.

You are aware that there are better cars, only you cannot afford them or simply not getting them as they are rare in your region. After a while you start believing that your car is also successful based on your experience. Your car gives you joy and a good feeling. Finally you think you know that your car is the only successful car as you make the assumption that there is a relation between you being successful and your car. You are no longer open for discussion on terms which matters and using the cruise control to drive.

In the world of software testing this is also happening. How much adds, articles etc are not yet written that course like ISTQB, TMap, TMMi, Requirements engineering etc are "promising" that you must have those certifications and work according the written content? Don't you think that those organizations are trying convincing that they are the only successful tool to keep you driving? Do you ask yourselves every time if the conditions which can lead to success is also available and necessary to do your driving job?

Successfully driving a (successful) car
Driving your car under the given conditions reaching the objectives you were given can lead to success. To drive in a car which you prefer and gives you joy might lead to a successful car to support your trip. This seems to be a win-win situation. In this my advice will be also watching the environment you are driving in.

Sometimes you see opportunities which make it worth to stop and shoot some pictures. Sometimes you are challenged to speed up and breaking some rules against speed limit. Although it is not allowed, it can bring you on other thoughts; it helps you to see things in other perspectives. Also slowing down might support your trip and vision. On your trip there are always some kind of unpredicted situations triggered by the "unknown-unknowns" it helps if you change behavior. Perhaps you might not reached your goal within the agreed terms. It can help you to add value to your trip.

In testing it can be the same. If you decided to go on the road with given means and methods take time to judge those and check if they are still given the value needed. Perhaps other value can also be added at that moment. Dare to question your approach and don't rely on the cruise control of your best practices with test methods.

Or just driving?
Another option can be just starting driving. Just see were it brings you. This can be useful and fun. Do something you normally don't do. Don't make it as the daily trip to your job. When opening your mind for circumstances you might find opportunities to help using the means you have.

This is something different then approaching a project with your best practices and methods because there is not yet some direction defined. If you introduce those you will directly have impact on the route the project will go. In this situation it not your skill which will add value to the project; is the method which might define unnecessary conditions towards the project and make it less successful. Sometimes it is better to walk around and see how you can use your skills. Using your skills is not forcing your skills to be used.

Conclusion
Success is not based on methods and best practices, they might help. Written words can be misleading. There is always a context behind a question/assignment. Don't just do what you have been taught to do. Be aware that changing behavior can help to set everything it the proper perspective.

Weather forecast and testing

Testing is like predicting the weather.
Some of the following similarities can be found:
- When it is raining, bugs are hiding, so before start testing first makes the rain stop;
- When it starts raining, look carefully were the bugs are running to. To catch them, tools might be needed to avoid you to destruct their hiding place;
- Based on current values we compare them with historical data and try to predict the next behavior of the next day, days, weeks;
- In both worlds fancy charts are created and only the experienced ones can understand them;
- The next day might differ the prediction, you can tell the weather will be nice, when the moment comes we monitor if the prediction comes out;
- If bad weather is expected we take measurements;
- Even if bad weather is expected, we have to go outside;
- The environmental circumstances can have huge influence on the weather;
- If predictions become valid, enjoy that moment and continue;
- Use the proper tools for the right purpose. A wind meter will not measure the rainfall;
- Gaining weather information can be done manually and also automatically;
- Sometimes it is cheaper and reliable to stick your head outside the window to see what the weather is doing;
- The audience differs, some people are waiting for rain, some for just dry weather and some are interested in the clouds;
- Weather is a concept with different meanings, so is testing.

I'm certain that there are more similarities between weather forecasting and testing. I would say: take nothing for granted and ask yourselves what you would do in certain situations after translating it to weather conditions.

Users as testers

Not every one who reads books wants to write books. Not every one who writes books read books from others. Not every writer is able to write in another genre and specialism. Not every one who wants to write books are good at it.

If this is true, why do we often expect users to start testing applications and trust on their verdict? Why do we rely on that outcome if we know we never told them what testing is and how to test. What we expect them to do?

I think it is because we trust them based on what they have shown. I also think a misperception is made based on wrong behavior. You can say that someone who performs one test is a tester with added value, therefore you can’t say: some user who performs a test is a tester with added value.
Sure, the users know how the system works and are able to tell what they do and how they have done it. Is this enough?

You have readers who are able to re-tell what they have read. There are also readers who are able to write a small review on that book. Still they are not able to write a similar book which attracts the same audience.

There are also writers who are able to write books for their audience. If they are asked to write for a newer audience they have to start learning again.

Can users be good testers? I think they can, only you have to be aware which value you are requesting from them. Don't expect a reader to become a writer in one day. Don't expect a user to be a good tester from the beginning. In both situations you have to guide them.

Also don't expect a tester to be a good user.

Blocking your nurture

What do you do when a person ask you a question? Do you try to answer it immediately or ask an own question to get more information about the purpose?
What do you do when a person explains a problem? Do you try to solve it or ask form more information?

It is in my nature to help people. If a person asks me the time I look at my watch and tells him what is on my watch. If I forgot my watch I look around to check if I see a clock. If no means are available to tell the exact time I try to estimate the time. It is so simple and obvious to respond automatically to triggers we have done before using experience and knowledge we gained before.

The question is: did this help the person? When someone asks for the time and you give the time it seems that the question is answered. Still there might be more behind that question. Perhaps that person used that question to make contact. If you give the time, the chance for further contact is minimized. If that person needed the time to check whether he is late only he is not able to calculate then the question is obviously answered only the person cannot do anything with it. Perhaps he actually wanted to ask if he is late for a certain appointment related to the current time.

The same might happen in testing, when a person tells you that his products is lacking quality you can tell him to test better. Nowadays it normal that in the same sentence we tell them we are able to do that part of testing and inform him that we are able to use methods for this like TMap, ISEB/ISTQB, TestGoal, CDT, SmarTest or whatever. Do to our experience it became our nurture to tell about our skills and experience.

Telling about skills and experience won't help a person. Using them might help. Only it can only help if you know it will fit the problem/ question. Before you start using your skills/experience about methods you first need to check if it is sufficient. It is important to start gaining information first. Then you can decide which solution/method is the best for helping the person.

I think here the tricky part comes: It is in our nurture to start asking questions based on our knowledge and experience. If that knowledge is restricted then the gained information is also restricted. Perhaps it is useful for the method you like to use; the pitfall here is that you might be forced to change customer’s processes and make them accept the disadvantages to make your method work.

I don't know exactly how to resolve this problem. At least I believe sticking to the knowledge/rules of one method is insufficient. Also the knowledge of 2 similar methods like ISTQB and TMap won't work. You will be forced thinking in a certain pattern although this pattern cannot be the answer. It might help you to lead to a solution. Currently I'm reading more beyond these approaches, listening to ideas of others and trying to make up my own ideas. I'm still aware I'm at the beginning of the journey where it helps to start with the statement: Currently no method is useful, let us first see what want to do and what we are currently doing.

Start without a method

I'm the last person who would say that using methods make no sense. As often before, I advise to use them wisely. I can imagine that without any method it might be hard to reach the goal.

You might compare it with getting from point A to point B. In the beginning we didn't had car navigation systems or even paper maps. We started walking, riding, sailing based on our experience. By looking carefully to our environment we adapted the path to go. We even used tools to help us during our journey.

When some trips were made often, wise people drew a map to explain to people with lesser experience how to walk. Even then it was sometimes hard to end up at point B as you needed the skill to read maps, sometimes reading one map type differed from the other.

Currently we are driving our cars, bikes or even walking based on our navigation systems. A tool tells us what to do and when to do what. We stop thinking how to get from A to B. One benefit here is that we have time to other things like watching the environment better, communicating more, etc.

I think the same is now happening in the field of testing; and happened before. Initially we were just testing, finding bugs by pressing the buttons. After a while all kinds of methods were defined like related to testing ISTQB, TMap, TestFrame, TestGoal, TPI, V2M2 etc. Related to development they drew up the different map types like: Waterfall, DSDM, RUP, Agile, etc. They all should help us to get from A to B. And basically, they can work.

Perhaps I'm wrong, what I see happening now is that those methods are also used as tools as they are telling us how to test and when to test. The only difference is here the purpose. Instead of getting from A to B they are to get more free time to enjoy the environment. I suggest that we keep our eyes open to question the environment, use our skills and experience to get from A to B and adapt our routes when we think it is necessary and not because of a method says so or a method forgot to tell you to do.

A method is a good think when it is used as a guideline. Using it as a tool can be done in different ways, you can use it to help you to define your route, it can also be used as goal. When using it is as a goal the focus lies more on implementation of a method instead of using a method.

Collecting evidence

Sometimes it seems testers are just young children, they also want to collect everything, although the reasons are sometimes different.
I can imagine that you, reader, also store your test data for some reason.

Perhaps you can compare it with collecting soccer cards, football card, baseball cards, stamps or what ever. Collecting those items can make you unique; it can give you some additional value. Perhaps you can get money out of it.
Is this the same with test data? Are you just collecting to tell the manager how good you are; how you managed to have everything under control? Or are you collecting to be used as evidence.

Using it as evidence can only help when it is too late and what sense does it make then? Will it help the customer? Perhaps you should ask yourselves in front what to preserve, for what reasons and for how long.

Imagine we define a lifecycle for test data.
We all know these actions:
- preparing
- using
- collecting
- storing
- preserving

What about: destructing?
The initial actions are mostly within a projects lifetime. Destructing should be done when it is no longer necessary. What would you say to start the destruction phase of one project, just after ending the next? This might trigger us to think about what we need to preserve instead saving everything. And it also minimizes the frustration of not finding old data as it is no longer there.

Moments of disbelieve

Sometimes in a lifetime you have some moments when you think: how is that possible. A situation a dealt with just very occasionally is that in the front yard of my house the sun is shining and in the backyard it is raining.

No, I don't have such a big house with a big yard. It just happened. Similar things Moments of disbelieve sometimes also when a product moves from the test environment to production. And in production suddenly it started to rain.

Of course I could have spent time to get the answer why the sun was shining on the other side of my house and it was raining at the backyard. To me it seems some waste of time.

Perhaps we also should deal with certain situations when it happens on productive systems. Instead of searching why it happened, it might be useful to solve the water damage and continue working on the next assignment. Don't let the moment of disbelieve spoil up your resources.

Only when you believe it is not an occasionally thing, you might consider precautions.

Problems and responsibilities

Headache
During a master class SCRUM Jens Østergaard and Bas Vodde gave us the phrase "If a problem gives you a headache then probable it is not your problem."

The idea behind this was that the headache is initiated because you are not able to solve it immediately which made you think without reaching the solution.

Getting headaches is sometimes inevitable in software testing. It is easy to handover the problem to some one else. Will this be the correct way? I think you have to check if it lies in your field of responsibilities and your field of influence.

Responsibility
I always try to think in the number three-approach. Based on this I came to the following classification of problems and responsibilities:
- problems in your area of responsibility, only you don't know how to deal with it
- problems just beyond your area of responsibilities, only it has to do with your field of profession
- problems beyond you area of responsibilities, only you were eager to notice them

In your area
If problems can be assigned directly to activities you are responsible for, then you should not hand over the problem. As you got already the headache, try to find a person who is able to help you. This help can be given in support or advice.

Just beyond your area
If the problem is not related directly to your activities you should check if it is related to your profession. It would help the person you handed the problem needs your support, your expertise and your commitment to help him.

Outside your area
This is an area you have to be careful because you noticed things which should not be your case. Here you have to decide if you are approaching it in a formal way or informal way. Formally could be by escalation or documentation (e.a. e-mail). Informal would be by identifying the person in your field of influence that might be able to guide the information.

Problem solving the headache
To deal with your headache, you might:
- Ignore it, and hope it will go away over a while;
- Take an aspirin;
- Identify your responsibility and take that.

The glass is half full or half empty

Is the glass half empty or half full? is a common expression, used rhetorically to indicate that a particular situation could be a cause for optimism (half full) or pessimism (half empty).



What I'm wondering is how this should be used in projects? Should we be optimistic or pessimistic? I would be too easy to say that we should be neither of both as we are there to measure the "truth about quality". The thing here is that we are also working with people. And people have to be convinced, when you are too optimistic or too pessimistic they won't believe you. If you are neither of both, they probably won’t trust you.

I suggest being honest. Be pessimistic about the things which are going well beyond expectations and be optimistic about parts which unexpectedly are going different.

Don't use the half-filled glass metaphor, be honest and create room for the natural optimistic and pessimistic people.

Shooting with hail or just one test case?

Almost every one wants to setup a controlled test process.

It is if we are playing the song "Proud Mary" by Ike & Tina Turner: "Take the beginning of this song and do it easy. Then we're gonna do the finish rough."

We always start simple with a controlled set of test cases. Often these test cases are based on the outcome of using test techniques. So far so good.

Still we might become lazy over time. If errors are found in production, we re-test the solutions and add the test case to the test set. There is less time to question the system and our test process what went wrong and what can go better.

In manual testing after some short time you will see that keep adding those test cases to the test set will make our process "rough" as we don't have time to execute all test cases or select a common sense set of cases. Business is already relying on us and demanding that all is done.

In automated testing this time pressure is almost minimized. We can keep adding new cases, let the number exceed over the thousands and still continue and deliver.

This reminds me about the phrase: "A bird in the hand is worth two in the bush"
If we accept the meaning of this phrase we are we not able to continue controlling that bird in our hand and instead sewing our own bush?
It is easier to take care of a bird we know then nurse the birds in the bush. If we feel we need another bird, just let the bird free and pick another out of the bush. Not just the first one which fell in your arms, go into the bush and see which sounds the best to your needs.

Keep it simple and easy, enjoy the roughness and prevent to get stucked on numbers. Don't create a process where you are shooting with hail on the system.

Birthday present with too much functions

I'm not that good in buying birthday presents, especially for my mother. Every year I ask what she would like to get for her birthday and this year I expected she would say that it is a present to have me at her birthday and a present wasn't necessary, until this year. She really would like to get a small handheld vacuum cleaner.

This week I went to a shop to buy me such an item. In the store I noticed I didn't have any knowledge of handheld vacuum cleaners so I asked for advice. As a professional tester I noticed the differences between all those different items. I asked questions about the functions and what use they are for. I got explanation about the meaning of difference in power and performance. A demo of usability thought me more about those things.

And here I made the mistake; I bought the best handheld vacuum cleaner which was available in the store for an acceptable price. It had everything on it, easy to use and maintain. Powerful to cleanup even the tiniest dust and it also looked beautiful.
The only disadvantage it had and also the other machines: it was not small.

I'm sure that we do this all the time also in development and testing. We start with the basic needs and requirements and during the project we find out more requirements and also testing them as we need them. We judge them and tell the business if those are working well it can be shipped to production environments. Business will get overwhelmed by those extra nice and really usable functions. Only the main functionality it forgotten: it should be small as the main purpose was for intended usage since the organization has for those heavy jobs a real vacuum cleaner. Perhaps you can compare it with asking for an excel sheet to use as a small database and giving them a web based SQL driven database with fancy windows.

In traditional projects and development methods this is mostly avoided as requirements are fixed and design is available. The system is tested against those requirements. In Agile projects this is in my opinion a risk. The requirements are not always fixed and grow during the project as business involvement is huge. Those change in requirements is not only triggered by their change of thoughts, it is also triggered by the team as they want to give something good and beautiful. They want all the best for the business. I can imagine that functions which initially were nice-to-have becoming must-haves.

This could be avoided by keep asking the right questions: What do you need? Why do you need it? How are you intending to use it? What if you get less and what if you get more? Do you still want it even it has more? Is it acceptable? ....?

Often we think less is bad, I think more is even worse. As a system contains more functionality then needed it will have also impact on the business processes. Procedures has to be adapted, people needs training to use that additional functionality and so on.

Fortunately for me, my mother liked the handheld vacuum cleaner. And she loved it on its initial usage. The initial requirement was basically met and agreed with me that those machines are not that small as in the past as they became better. I know although in the future she will come up with disadvantages she will never telling me that the machine was too big after all. She perhaps will use it lesser then intended.

In this case a sharply priced machine with too many functions which didn't meet the main requirement completely will become a too expensive investment. This makes me think about the situation in our field: Are we responsible to give advice when requirements are not met initially although the user is more than happy? Are we responsible to give information about this during the process? What tools and procedures do we have to maintain this responsibility?