Showing posts with label Lessons learned. Show all posts
Showing posts with label Lessons learned. Show all posts

Wednesday, January 19, 2011

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.

Tuesday, July 27, 2010

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.

Tuesday, July 20, 2010

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.

Friday, May 7, 2010

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.