Conversation

Tester: This does not work with the latest software version.

Developer: Weird, did you use chromium version 5.0?

Tester: No, because it also should work with the latest version of chrome.

Developer: Of course it should work with the latest version, but try chromium if you like.

Tester: But why?

Developer: Then it might work.

Tester: ????

Developer: We had some problems before with chrome and with versions of chromium and with this version of chromium it did work, so we decided that on our machines that chromium 5.0 will be installed. So no other versions or browsers need to work.

Tester: But what if someone finds a blocking bug in chromium 5.0 and we need to upgrade?

Developer: That are problems for later.

Tester: Ok, I will try it with version 5.0

…..

Tester: Here I am again. With version 5.0 it also doesn’t work.

Developer: Shit.

Kickoff QA Forum

Recently we had a meeting with a few people about the quality of our software. We did call it QA forum, but the name does not matter for me. The intension of this meetings was very clear. We have to increase the quality of our software. These meetings well be done to brainstorm and to make some action plans. This above all our projects. Because we do have several projects with more or less the same code base.

This first meeting was a brainstorm meeting. First question that came in our mind was:

What are the needs?

To increase quality, we should know what we are missing at the moment. So we should answer questions like:

  • What is the value of testing?
  • Why do we test X and not Y?
  • What do we expect from our testing?
  • When do we automate, when not?
  • What are we going to automate?

To give some answers to some questions, a kind of risk analysis is needed. The outcome of the risk analysis will answer what we are going to test for example.

Let’s hope that this was not the first and last meeting about the subject, because I already have been there. But this time, we are getting an audit by an external company. They are going to analyse our way of working and give some tips what can be changed.  After that audit, we can continue to improve.

Parrondo’s paradox

Recently I found a nice article on Wikipedia. It is about Parrondo’s paradox. This is a mathematical paradox that can be applied in games. Suppose that you have 2 games. You play it many, many times. But in the end you will loose the game. This paradox is stating that if you combine such 2 games, it might happen that you can win eventually.

How does this work? It is kind of complicated to explain, so I will give an example. Like I already told, we have 2 games:

  1. If you play this game, you will always loose 1 Euro.
  2. If you play this game, you will loose 5 Euro if the money you have at this moment is an odd number. If it is an even number, you earn 3 Euro.

Very simple rules in those 2 games. If I start with 100 Euro, I will loose it all in 100 times if I am playing only game 1. If I am playing only game 2, I also will loose all my money after 100 games.

What happens if I combine these two games?

Suppose I start with game 1, after that I play game 2, then again game 1 and so on. I will again loose all my money, because I first loose 1 euro, then I will loose 5 Euros, so I end with 94 Euros, then again 1 euro, again 5, and so on until I got an empty wallet.

Now I will try to start with game 2 and then game 1, game 2 and so on. Then I first earn 3 Euro. So I have now 103 Euro. Then I loose 1 euro, so I end with 102 Euro. But then I again earn 3 Euro.

Because I always end before starting with game 2 on an even number, I always earn more money than I loose. So I am a happy person now.

That is the paradox. You can gain by combinations of different games. In fact, by changing the order, I manipulated the outcome. Is that not what we as testers are supposed to do? Try to search for combinations that reveals problems in testing product.

Like Elisabeth Hendrickson tells it in her book  Explore It!, we should try to search for hidden bears. This paradox is one of them.

Being prominent or not?

The project is too late, lets put some extra people in the scrum team. Then it will get fixed by time. Is it as simple as managers think?

In prehistoric times, the start of mankind. The common man is living in a group of other people. He prefers to live in solitude, but he has to. Surviving in such a cruel world is not easy, so If the common man wants to reproduce, he must live in a group. Here he is getting protection from animals that otherwise tries to eat him.

Better to be a living grey mouse than a white dead one.

Suppose an enormous lion is attacking a person. Where is he save? In loneliness or in a group? At present times, with fish, we also see that some fish stick together because it is safer for shark that wants to eat them. The group gives them protection. The fish that are the weakest are eaten first, but also the fish that are on the outside of the group. They are noticed by the predators. This is also so in prehistoric times, the rule was simple. Get out of sight of the danger.

Also in present times, this behaviour is still in our genes. If you are at a concert of a famous singer. He yells: “Do you want more?“. The audience yells back, “yeeeees“. But then the singer yells again: “I do not hear you, do you want more?” At his time the audience yells back again, but many many louder as before.

This behaviour is exact the same as our prehistoric man. People do not want to be noticed. Scientists examined this in 1979. They saw that people are less productive if they are in group. Their effort is higher if they are alone.

The problem I think is that this is also on our work. Also in agile teams. And it is stronger if the team is bigger. People do not want to be noticed, so they are vanishing in the crowd. And they do less, because if they are doing to much, more as the average team member, they are getting noticed.

This is where we should be aware of. Do not make teams to big, or productivity will decrease. That is the reason why it is not as simple as just putting extra man power to a project that is already too late. These extra man could be the threshold so that productivity will dramatically decrease.

Werken werken werken

Het is een algemeen geweten. Het is eigenlijk niet echt nodig van in een scrum team over te werken. Dat is niet echt een goed idee. Toch wordt het vaker gedaan dan we denken. Het process is zo gemaakt dat je zelf je target zet, elke 2 of 3 weken, afhankelijk van hoe lang de sprint duurt. De belangrijkste zaken staan bovenaan de takenlijst of backlog. Daarom als het project zonder budget of tijd zou vallen, zijn de belangrijkste zaken van het project toch af.

Toch als men ziet dat het project begint te vertragen, wordt er door sommige teamleden overgegaan naar een overdrive mode, en beginnen ze thuis ook zaken te doen. En dit enkel en alleen maar om die target te halen.

Het zou niet mogen zijn. Het team zou als iets dreigt niet af te geraken, moeten proberen te begrijpen waarom het niet afgeraakt is. Daarvoor zijn de retrospectives belangrijk. En de reden waarom iets niet afgeraakt kan vele oorzaken hebben. Dat is dus aan de teamleden om dat uit te zoeken, en om er oplossingen voor te vinden.

Overwerken, want na de uren nog blijven doorgaan is overwerken, leidt tot vermindering van kwaliteit. Men begint moe te worden, en begint daardoor snellere oplossingen te bedenken die later toch slecht blijken te zijn. Daardoor worden er weer extra bugs geïntroduceerd. Waardoor dan de deadline weer niet gehaald wordt, en uiteindelijk, …..  is een burn-out niet ver meer af.

Het is nog voor een andere reden geen goed idee. Voor de sfeer in het team. Als er anderen zijn die merken dat enkele teamleden aan het overwerken zijn, dan krijgen ze misschien wel schuldgevoelens. En het gevolg gaat zijn dat het team in groepjes verdeeld wordt. Dat mag niet de bedoeling zijn, want als de moraal naar beneden gaat, dan daalt ook de kwaliteit. En als de kwaliteit naar beneden gaat, voelen de mensen zich niet meer gelukkig.

En is dat net nu wat de meeste bedrijven proberen te doen. Hun werknemers gelukkig maken tijdens hun arbeidstijd. Great Place To Work is dat concept.

Moeten testers gemeen zijn?

April 1961, een groep van 1400 bannelingen van Cuba was bij het Amerikaanse leger gegaan om de dictator die in Cuba aan de macht was, van de troon te stoten. Ze waren geen professionelen, en Amerika stuurden hun om Cuba binnen te vallen. Een paar dagen later echter, waren de grote overwinnaars niet de Verenigde Staten, maar wel het Cubaanse leger. Dit was een zeer domme zet van Amerika. Nadien is men gaan bekijken hoe het komt dat men zo een dom plan heeft kunnen uitvoeren.

Groepsdenken is een fenomeen, waarbij een groep zodanig wordt beïnvloed door groepsprocessen, dat de kwaliteit van groepsbesluiten vermindert.

De oorzaak was groepsdenken.Door dit process gaat de kwaliteit en besluiten van hetgeen een groep beslist drastisch naar beneden. Hoe komt dat toch? Het valt voor in groepen waarbij de mensen nauw met elkaar samenwerken. Als de groep dan veel belang hecht aan een unanieme mening, kan deze belangrijker worden zodat de groepsleden vergeten kritisch en ook rationeel te denken.

Dit komt zelfs meer voor als er een persoon in de groep zit met macht. Macht om iemand te ontslaan of te evalueren elk jaar is zulk een macht. Als deze “baas” dan aanwezig is, dan is iedereen wat nerveus. Men begint onbewust de andere leden van de groep te observeren. Zijn er mensen bij die tegen de mening van de leider durven in te gaan? Ja? Dan is het veilig om dit ook te doen. Elk lid doet dit onbewust. Als dan iedereen op zich beslist dat het een slecht idee is om tegen de leider in te gaan, omdat ze dan misschien hun werk verliezen, dan komt er een consensus waar zelfs de meerderheid van de groep tegen is. En niemand doet daar iets aan.

Waarom doen mensen dit? Eigenlijk zit dit gedrag in onze genen. Vroeger, als primaten, leefden we ook al in groepen. We hadden dit nodig om te kunnen overleven. Als er een andere groep aankwam om ons aan te vallen, dan moesten we een samenhangende groep zijn. Daar zijn dissidenten niet op hun plaats. Dat is waarom elk lid van de groep dan ook hun leider volgt.

Maar onderzoek heeft ook aangetoond dat als in de groep een dissident zit, en als de groep dat ook toelaat, zonder dat nadien de vriendschap in gevaar komt, dat dan heel het process anders gaat. Dan durven de meeste leden van de groep wel hun visie te uiten. Hierdoor komt er een dynamiek, die de besluitvorming van de groep veel beter maakt. Dit gelt ook als de leider niet aanwezig is.

Daarom, misschien moeten we de volgende keer in een vergadering eens lastig doen, de slechterik spelen. Het komt de besluitvorming zeker ten goede.

Dynamische properties

Python is een leuke taal. Je kan een klasse hebben die dat properties heeft.

Nu zien we dat de width en de height property eigenlijk de zelfde functie is, uitgezonderd van 1 waarde, namelijk de key in de self.fields dictionary. Zou het niet mogelijk zijn om de properties dynamisch aan te maken? Aangezien het python is, is het antwoord positief.

De oplossing ligt ook verborgen in een vorige post. Het gebruik van descriptors die we dynamisch gaan aanmaken kunnen hier voor dienen.

Als er nu een klasse gemaakt wordt die een get heeft en die dat de hardware oproept, en deze dan dynamisch in de Rechthoek klasse wordt aangemaakt, is het probleem opgelost.

De laatste regels code kunnen nog anders geschreven worden, zodat we ook hier geen code wijzigingen meer moeten doen, indien onze fields zouden wijzigen.

Nu is een nieuwe property eenvoudig aangemaakt door enkel de self.fields aan te passen. Eenvoudig en simpel.

Gebruiksvriendelijk of niet ?

Als we denken aan gebruiksvriendelijkheid, dan botsen we al snel op een probleem dat vele projecten hebben. De projecten focussen voornamelijk op functionaliteit. Werkt het systeem wel zoals we verwachten? Dit is goed, maar (er is meestal een maar) focussen we wel op de gebruiker? Voor de gebruiker is duidelijkheid en gebruiksvriendelijkheid van de applicatie minstens even belangrijk.

Je kent het wel, een applicatie die je niet begrijpt, of die zo moeilijk is dat je er eerst een cursus voor moet volgen. Is dat de fout van de gebruiker dat het zo ingewikkeld is gemaakt? Neen, het ligt aan de applicatie. Die is dan gewoon fout gemaakt. En hier kunnen wij als testers meehelpen. Meedragen zodat onze applicatie die we testen wel duidelijk is om te gebruiken. Zodat een gebruiker onze applicatie met plezier gebruikt, dat is ook een van de doelen van een project. Want gelukkige gebruikers of klanten komen terug, is dat niet een van de gouden regels van de verkoop? Waarom kan dat dan niet doorgetrokken worden naar software?

Testen die naar gebruiksvriendelijkheid kijken, worden meestal overgeslagen of zelfs niet eens aan gedacht. We mogen immers geen tijd spenderen aan mindere risico’s. Tijd is immers geld. Maar is klanttevredenheid dat ook niet? Daarom pleitte Peter Roozendaal in zijn presentatie op de voorjaarsconferentie van Testnet om ook naar het gebruikersgemak te kijken. En meer, als er nog niets bestaat in het project, neem dan als tester zelf het initiatief. Neem zelf de verantwoordelijkheid om specificaties te maken voor gebruiksvriendelijkheid. Dat is niet simpel, maar samen met de product owner en de steakholders.

Er is al heel wat geschreven op het internet, gebruik het en zorg ervoor dat de interface waar jij als tester verantwoordelijk voor bent, veel vriendelijker wordt voor de gebruiker. Het loont.