Of all models a W-model

Last Wednesday I attended a meeting from the Dutch Testing Organization TestNet related to W-models. During this meeting 3 guest speakers: tried to sell their vision about a "W-model".
Of course we all are aware of the V-model. We are also aware of reviewing and how it can contribute gain faster a vision about the quality.

Egbert Bouman: explained his view towards a SmarTEST W-model which represents more the iterative approach of development and the interaction with business
Jan Jaap Cannegieter: informed us about the historical mentioned W-model referring to Paul Herzlich who already spoke about a W-model in 1993 (source: http://gerrardconsulting.com/?q=node/531). He explained why and how reviewing methods adding to the well know V-model created a "W". He is also one of the co-author of a very good book about reviews (Dutch: "Reviews in de praktijk") In his W-model the moments of review results in the "W-model"
Jos van Rooyen: Who referred to his experience from already 15 years ago referring to a similar model where he added the products to be reviewed and/or the roles to perform to a similar W-model and created a "triple V-model"

The outcome of the meeting was to choose for one of the models to be the W-model. Unfortunately history was overruled by reality? The model of Egbert was chosen.

Based on that event I cam up with some questions:

1. I always thought about the V-model as a development model. I might be a misperception from me. In the Dutch testing world we refer to the V-model too often to define and explain the testing process. We even spend time to proof that the V-model fits in other development models. Can this be done to make a development model fit into another? And why also spent this energy?

2. Another thing I wonder is why are we referring to a W-model if we speak about checking the test documentation and other information sources?

3. Do we need a model to refer to the importance of checking documentation?

Some Assumptions

Assume a V-model is a development model like DSDM, RUP, SCRUM, Spiral. If the W-model is created by adding check moments to a V-model. The this W-model cannot always be used as we don't use the V-model always. This means that addding check moments can also be done to those other models. This will results into other presentations of those models too. When doing this there is no specific need to refer to a W-model as in other models you cannot draw the "W".

Assume the V-model is not a development model. It is a representation of a model like de sequential Waterfall model. Then again, if a processes of the sequential model is lifted to create a "V" we can always put them back into position so we got 2 parallel lines. In this case, the "W-model is only usable for other development models which can be supported with the V-model. Basically this can be done. Only it would be hard. Is in this case also worth to spend energy to translate to a W-model.

I would suggest to refer to the W-model to explain how reviews/checks can be embedded in a model. Only not refering to a W-model as model for full implementation.

Some other resources:

W-model from Andreas Spillner: http://squac.iti.upv.es/JTS/JTS2004/docs/Wmodel.pdf
Similar posting of W-models: http://www.testingthefuture.net/2009/09/the-w-model
The Dangerous and Seductive V Model: Nice twist here is the reference towards Morton's butterffy-model: Morton, S. (2001). "The Butterfly Model for Test Development". Sticky Minds website. Accessed 6th October 2008

There is more what it seems

On December 30th 2009 I already wrote I was reading the book from Oliver Sacks: "The man who mistook his wife for a hat: and other clinical tales" The fun of this book is the short stories and from every story you can learn.

For example: A story is called: "The President's speech." It is about a group of people who listening to the speech of the president and start laughing. Those people were living on a aphasia-section of a hospital. It seems that when the symptoms are very strong they are lesser able to understand the meaning of words. In this story they are also explaining that there is more then words in verbal and non-verbal behaviour. There are also the so called "Klangenfarben". Perhaps in English this can be translated to "Colour of sounds". There were people who were affected by every word the president told and convinced in the honesty. Others who had any lack of feeling received the words as they were spoken without context and interpretation.

This story made me think that if this behaviour is human, we all have some kind of thinking. We will be coloured sometimes and sometimes we are able to listen only to the words. I can imagine that it depends if we are interested or not. Imagine if this behaviour is affecting the judgement of the requirements we are reading, hearing and/or writing. What about the test cases we have written. Think what impact it can have if we approach the testing process from a neurological point of view. As we are working with humans, we have to spend time to get known to each other. We might have to learn how we can learn from each other.

Imagine that we are able to write down our requirements and scripts. And we are automating them. How wrong we can be if the written information is coloured in such a way were we didn't pay attention towards the "Klangenfarben"?

As said before, to understand more from testing, also look beyond the borders of the process.

Be careful playing around while testing

As from the beginning, I'm not afraid of applications. I believe this is an attitude which can be healthy and useful when you are working in the software testing business. Over the years I learned that this type of behaviour can help to learn new applications very fast as recently applications are building on common wishes.

I'm not telling that every application is the same. Often there is some basic logic in systems. For example looking at the menu bar, almost every application has a menu which starts with the item: "File" (of course depending on the language.

When I start learning an application I check if the environment I'm want to explore is not a production environment. I also check if I can do some harm it can be restored. One of the things I look for is a person who owns the environment and is that person available.

If I'm sure I can do controlled harm I continue. Based on this attitude I increased my vision about applications, technology and so on. I also learned I have a lot to learn which make things excited. I investigate and played around and continue learning.
And if I do some harm, some people are happy as I was able to help them find some potential bugs. For me, I was happy that there was a person available to restore the system.

Over the years I also noticed that this behaviour most be used carefully. Lately I'm playing with virtual machines, vmware, IP addresses routing of web-servers etc using some open source tools. I found the owner of the system as that was very easy since I was the owner. this time I was not only investigating how the applications were working, I was also busy arrange the systems to make it work.

After a short while I managed to run two websites on different virtual machines approachable from the local network as well the public network. Until this moment I played just a bit around. As I noticed I made it work I continue installing all kinds of modules. Until I made the system crash. as it was getting late I re-installed the VM's and somehow I made some mistakes in my router. Changed some other config files and "renewed" restrictions. I ended up with only 1 machine working approachable from the public net. and both systems approachable from the local net, even using IP-addresses and correct ports.

Until now I am not able to make the second site approachable from the web. Somehow this is frustrating, only how long will it bother me. I learned quite a few things:
1. Investigate the systems under test as it were your own systems;
2. Make sure the owner is able to maintain (I wasn't for the newer technology);
3. Stop investigating when it is getting late, even if you are trained to remember the steps you have taken, it might be obvious that the basic actions are remembered and details forgotten at a certain point;
4. If you cannot find out how it works, start finding other resources where you can obtain information;
5. Continue to focus on other areas instead of that one who stopped you;
6. Be aware when you are changing technology / level of IT you are able to restore to a certain point or rebuild within limited time;
7. Check every time of the goal you are aiming at is worth the possible damage you can cause;
8. Ask yourselves what you have learned from the system and also about yourself;
9. The next day, think about the situation and ask if you should continue or stop.
10. And for fun: if you reached lesson 10, wonder if there are more lessons.

Sure there are more things I might have learned, Certainly I didn't wrote them all down. Of course I could have chosen for another approach. at this moment I learned more from the mistakes I made then from the manuals which were available. I managed to get known of the system within a short time instead of learning how to read a manual and perform the steps written there. The last one is often seems as testing, learning how to read the "test cases" and perform the written steps.

In both cases be careful, with playing around and with reading those manuals.