Testverbetering als 1 organisatie

Stel je werkt voor een bedrijf met meer dan 1 ontwikkelteam. En elk team test anders. Andere tools, andere processen. Je organisatie wil dat veranderen. Allemaal dezelfde tools, allemaal een zelfde manier van werken. En jij krijgt de opdracht dit voor het testen als geheel of voor een testonderwerp te regelen. Hoe pak je dit aan? Maar vooral: hoe pak je dit niet aan? Om dit goed aan te pakken, wil ik eerst een vooroordeel de wereld uit helpen. Bedrijven willen vaak gezien worden als 1 organisatie en niet als een organisatie, bestaande uit verschillende teams. De veel gevolgde manier om dit te bereiken is gelijktrekken van tools, processen en taalgebruik. Er is niets mis met gelijktrekken van tools, processen en taalgebruik. Dit kan zorgen voor betere samenwerking tussen teams, meer vrijheid in het indelen van teams, kostenbesparing en een algehele verbetering in efficiëntie, effectiviteit en kwaliteit. Maar wat het niet doet, is losse teams omvormen tot 1 organisatie. Helaas is dit wel een voorwaarde om het gelijktrekken te bereiken. Je kan iemand dwingen een proces te volgen en zolang je dat tot in detail controleert, zullen ze het volhouden. Maar als ze er zelf niet achterstaan, zelf niet in geloven, dan zal dit veranderen zodra jij deze tijd niet meer kan vrijmaken. Bij het eerste de beste obstakel zal gezegd worden "We zeiden het toch: Dit werkt niet bij ons". 1 organisatie is niet een organisatie, die hetzelfde werkt. 1 organisatie is een organisatie, die hetzelfde wil werken. Hoe bereik je dit? Om dit duidelijk te maken, zal ik gebruik maken van een onderwerp waar ik zelf veel kennis van heb, vooral van het invoeren: testautomatisering. Stel je organisatie heeft 10 teams. Nu heb jij de opdracht om testautomatisering in alle teams in te voeren. Een veel gevolgde aanpak: pak het probleem per team aan. Doe eerst team 1, dan team 2, dan team 3. Deze aanpak verkleint je kans op slagen enorm, als dit ook inhoudt dat alle andere teams geen enkele betrokkenheid hebben bij de testautomatisering, totdat zij aan de beurt zijn. Ik weet niet of jij ooit iemand heb gesproken, die jou precies verteld hoe je moet gaan werken en wat je moet veranderen, terwijl die persoon nog nooit eerder enige interesse in jou of je team heeft getoond. In de meeste gevallen is dan de eerste reactie: "Wie denk je wel niet dat je bent?". Wat zich later vertaalt in "Dit gaat voor ons niet werken, want wij zijn anders.". Het is belangrijk dat elk team vanaf het begin betrokken wordt bij de verbetering. Daarom is het in de "ontwerp" fase van belang dat elk team zijn input kan geven en dat deze input ook zichtbaar is in het eindresultaat. De "ontwerp" fase is de fase waar bepaalt wordt in welke stappen de verbetering ingevoerd wordt, maar ook met welke tools gebruikt gaan worden en welke processen gaan veranderen. Zorg ervoor dat elk team de gelegenheid heeft de volgende vraag te beantwoorden "Gaat dit werken voor mijn team?". En als het antwoord is: "Nee, want...", neem die problemen serieus. Neem die problemen op in je plan. Noem ze minimaal als risico. Maar als het mogelijk is: geef aan hoe je het probleem op wil lossen. Dan komt het invoeren. Hoewel de neiging groot zal zijn om je te richten op 1 team, is dit niet verstandig. De verbetering wordt voor de andere teams dan "een verhaal van een andere wereld". Tegen de tijd dat een ander team aan de beurt is, ben je de bij de "ontwerp" fase gecreëerde betrokkenheid en draagvlak alweer kwijt. Het is zeker niet erg om 1 team de meeste tijd te geven, maar vergeet de andere teams niet. Zorg ervoor dat er bij elk team gewerkt wordt aan een obstakel, dat de verbetering in de weg staat. Dit zal ik aan de hand van de testautomatisering wat duidelijker maken. Testautomatisering is meer dan starten met het maken van automatische testen. Maar dit is vaak wel de grootste klus, waar mensen veel hulp en ondersteuning bij nodig hebben. Maar er moet ook een goede, stabiele testomgeving zijn. Men moet in staat zijn goede regressietesten te schrijven. De testdata moet op orde zijn. Gevonden bugs moeten snel opgelost worden. Bevindingen moeten goed en snel worden geanalyseerd en beschreven worden.Enz. Enz. Enz. Veel van deze verbeteringen zijn ook verbeteringen, die handmatig testen ten goede komen. Maar ze vragen zeker niet allemaal evenveel tijd en begeleiding. Zorg ervoor dat elk team bezig is met een verbetering, die nodig is voor een goede testautomatisering. Om ervoor te zorgen, dat dit je niet veel tijd kost, kan je de teams zelf laten kiezen welke verbetering voor hun het belangrijkste is. Als zij mogen werken aan de verbetering, waarin zij de meeste resultaten zien, zal er nauwelijks controle nodig zijn. De motivatie om door te zetten zal bijna automatisch aanwezig zijn. Je hoeft er alleen voor te zorgen, dat je beschikbaar bent voor problemen, waar de teams zelf niet uitkomen. Bijvoorbeeld omdat ze de kennis nog niet hebben of omdat ze geld, tijd of mensen nodig hebben. En als laatste de communicatie. Goede communicatie over verbeteringen is belangrijk. Als je meetings houdt of informatie rond stuurt, houdt je dan altijd aan de volgende regels: * Zorg ervoor dat je van elk team een succes noemt * Zorg ervoor dat je voor elk team de veranderingen op korte termijn voor dat betreffende team noemt Dit geeft het laatste steuntje in de rug. Je laat merken, dat je niet alleen met mensen praat, maar dat je ook echt naar ze luistert. Dat wat zij vinden belangrijk voor je is. En dat wat er met ze gebeurt belangrijk voor je is. Dat jij ze deel vindt van die ene organisatie. Testverbetering door verschillende teams heen bereik je door alle teams bij de testverbetering te betrekken. Door ze te betrekken bij het opstellen van het plan over de testverbetering. Door ze in een vroeg stadium te laten meewerken in de testverbetering. En door te laten merken, dat ze belangrijk voor je zijn. Hun kennis telt, hun mening telt en zij tellen zelf zeker ook!

De wereld van complimenten en de gevaren hiervan

Een tijd geleden maakte ik een persoon mee, die complimenten promootte. Maar op een manier waarop ik totaal niet achterstond. Nu ben je als tester snel aan het oordelen, omdat je bepaalt wat goed en fout is. En daarmee ook indirect kan zeggen of suggereren wie zijn werk goed en wie zijn werk niet goed doet. Weten hoe de wereld van complimenten en de wereld van kritiek werkt, vind ik daarom een belangrijk onderwerp voor testers.

De wereld van kritiek is vaak besproken, maar naar aanleiding van deze ervaring kwam ik tot de vraag: hoe steekt de wereld van de complimenten in elkaar? Wat maakte deze promotor van complimenten in mijn ogen nou zo verkeerd? Ik ben zeker niet tegen complimenten. Maar wat mij tegenstond, was de sfeer, die eromheen ontstond. Het idee was om voor een bepaalde periode je alleen maar te concentreren op complimenten. Even geen kritiek op elkaar of op jezelf, maar kijken naar het positieve.

Klinkt misschien goed, maar ik zag ongewenste bijeffecten. Want ik zag twee dingen gebeuren. Ten eerste is ook complimenten geven iets wat je moet oefenen. Daarom is het verstandig om niet meteen te vragen wat iemand fantastisch, perfect, ideaal, uitstekend o.i.d. heeft gedaan. Nee, vraag gewoon wat iemand goed heeft gedaan. Dat maakt het veel makkelijker een compliment te geven. Het kan dan ook iets kleins zijn. En het hoeft niet eens perfect gegaan te zijn. Puur het feit dat iemand zijn best deed, is dan al voldoende. Dat maakt het zowel voor de gever van het compliment makkelijker te geven, als voor de ontvanger makkelijker om te ontvangen. De eisen en verwachtingen liggen niet zo hoog. Tijdens het beschreven evenement werden te vaak de varianten op "ontzettend goed" gebruikt. En ik zag dat als een blokkerende factor voor mensen, die complimenten geven en complimenten ontvangen toch al niet vaak doen.

 En daarmee maak ik meteen een sprong naar mijn tweede probleem. Het was niet mogelijk om hier opmerkingen op te maken. Hier opmerkingen op maken, was tenslotte geen complimenten geven. Puur de opmerking, dat ik niet achter de opzet stond, leek al bijna te suggereren, dat ik niet achter complimenten geven stond. En, jammer genoeg niet tot mijn verbazing, is het voorstanders van complimenten wel bijna altijd toegestaan om scherpe kritiek te geven op personen, die complimenten lijken tegen te werken. Terechte opmerkingen, die op dat moment hadden kunnen leiden tot verbeteringen en daarmee tot meer complimenten, waren niet welkom. Ik heb niets tegen personen, die complimenten promoten. Wel tegen personen, die dit als reden gebruik om niet te luisteren naar anderen en direct over te gaan op zelf kritiek leveren. Dat die kritiek is tegen het hebben van kritiek, maakt het in mijn ogen geen betere kritiek.

Mijn eigen ervaringen in de wereld van complimenten zijn natuurlijk vooral gebaseerd op mijn ervaringen als tester. En het eerste wat je moet beseffen is: wat een compliment is voor de een, kan kritiek zijn voor de ander. Als ik trots vertel, tijdens het testen in korte tijd heel veel fouten zijn gevonden, suggereer ik tegelijkertijd dat minimaal 1 ontwikkelaar zeer waarschijnlijk heel slecht werk heeft opgeleverd. Een ander voorbeeld: Als een ontwikkelaar trots vertelt, dat hij echt de tijd heeft genomen om goed te programmeren, kan dat mij eraan herinneren, dat er juist hierdoor te weinig tijd is overgebleven om goed te testen. Zo kan ook de opmerking, dat je als tester weinig tot geen fouten hebt gevonden, bij ontwikkelaars tot de conclusie leiden, dat je als tester je werk slecht doet. Want een vorige tester, andere tester of klant vond tenslotte wel fouten.

Waar het op neer komt: verplaats je in de ander en probeer te beseffen hoe die naar de situatie kijkt. Is de ander ook zo blij met de situatie als jij? Wat kan helpen verkeerde conclusies te voorkomen, is om een vergelijking of de oorzaak in je compliment op te nemen. Er zijn meer fouten gevonden, omdat er een nieuwe testtechniek is toegepast. De ontwikkelaar heeft meer tijd genomen, omdat de vorige keer zoveel fouten waren gevonden. En je hebt, vergeleken bij het vorige opgeleverde werk, veel minder fouten gevonden, dus de kwaliteit van het werk is verbeterd. Door de vergelijking en/of door de genoemde oorzaak is het moeilijker voor de toehoorder eigen conclusies te trekken.

Daarnaast vind ik het volgende heel belangrijk: leer complimenten geven op het geven van kritiek, ongeacht de vorm. Complimenten geven is heel belangrijk, maar je hebt kritiek nodig om te groeien. En daarmee heb je mensen nodig, die altijd bereid zijn je te vertellen wat er fout gaat. Dit zijn niet altijd de mensen met het meest subtiele woordgebruik. Maar als je werkelijk wilt leren complimenten te geven, moet je leren verschil te zien tussen het gewenste doel en het werkelijk bereikte doel. Deze kritiek, hoe slecht ook gebracht, wordt bijna altijd gebracht met het doel iemand iets te leren. Om iemand de ogen te openen voor het onbekende, niet geziene. Door meespelende emoties, teleurstellingen uit het verleden of vele andere oorzaken wordt hiervoor wel vaak de botte hamer, of in dit geval de botte woorden, toegepast. Maar bot zijn is niet het doel, bot zijn is op zijn hoogst een verkeerd gekozen middel en soms zelfs een ongewenst bijeffect. Als je hier onderscheid in kan maken, kan je iemand complimenteren voor het willen verbeteren van de situatie. En dan ben je in staat om werkelijk iedereen, optimist of pessimist, zodra je dat wil te bedelven onder complimenten. 

En dan heb je nog de "Maar dat is toch niet zo bijzonder?" complimenten. Kort geleden kreeg ik zelf een compliment voor het vinden van een probleem. De standaard waarden in een scherm leverde verderop in het proces een ongewenste situatie op. Het werd knap gevonden, dat ik dat had gevonden. Maar voor mij was het meer "Hoe had ik die nou ooit kunnen missen?". Ik wijzigde niets, ging door met het proces en zag een hele duidelijke ongewenste situatie. Het compliment was oprecht. Toch klopte het in mijn ogen niet. Ik had niets bijzonders gedaan. Ik had gedaan, wat ik altijd doe, wat ik zelfs al jaren doe.

Waarom het toch een terecht compliment was: als het echt zo simpel was, waarom was dit probleem nog nooit eerder door een tester gemeld? Waar je werkelijk goed in ben, zie je vaak zelf niet meer als een prestatie. Het hoort bij de dagelijkse gang van zaken, het normale. Je zou niet anders kunnen. Maar als het iets is, wat anderen niet doen of wat anderen niet kunnen, is het wel degelijk een compliment waard. Dat moet je als ontvanger leren zien. En als gever leren beschrijven. Waarom is dit voor jou wel zo bijzonder, dat het een compliment waard is?

Complimenten geven vraagt erom je te verplaatsen in een ander. Hoe kijkt de ander naar de situatie? Maar het vraagt ook om een goede onderbouwing: waarom is dit zo goed? Trek ook vooral niet te snel de conclusie dat de anderen slecht is in het geven of ontvangen van complimenten. Doe gerust eens een poging te achterhalen waarom het compliment niet overkomt of zelfs het omgekeerde effect heeft. En zeker nooit vergeten: gebruik jouw streven naar complimenten nooit als toestemming om kritiek te hebben op anderen.

Testen in een team in overlevingsstand

Stel je voor, je bent tester. Je wilt kwaliteit. Maar als je bugs ontdekt, krijg je ze niet opgelost. En dan hebben we het niet over een spelfout in een stukje tekst. Nee, we hebben het over critical bugs. En als je pech hebt zelfs blocking bugs. Hoe dat komt: je development of scrum team is in overlevingsstand.

Hoe herken je een overlegevingsstand?

Bugs horen als basis geprioriteerd te worden op de ernst: is een bug blocking, critical, major of minor. En deze prioritering hoort gedaan te worden door onpartijdige personen binnen de organisatie. Natuurlijk zijn er uitzonderingen, bijvoorbeeld een belangrijke deadline, maar deze uitzonderingen komen slechts zelden voor. En ook deze uitzonderingen worden bewaakt door onpartijdige personen in de organisatie.

Dus herken je aan het omgekeerde de overlevingsstand. Er wordt zeer regelmatig gewerkt aan minor bugs, terwijl je weet, dat er critical bugs nog op de lijst staan. De persoon, die de prioriteiten bepaalt, mag of wil dit niet onpartijdig doen, maar kiest de kant van de manager, de klant, het project, enz. En beide situaties zijn dus geen uitzonderingen. Nee, het is standaard. Het is soms zelfs helemaal ingeprogrammeerd in de hersens van het team en/of van andere betrokkenen. Hierop wijzen wordt misschien zelfs gezien als iets raars of ongewenst.

Hoe ontstaat een overlevingsstand?

Het volgende lijstje is gebaseerd op mijn ervaringen. Mogelijk zijn er meer oorzaken, maar dit is wat ik in al mijn jaren testervaring ben tegengekomen. En vaak is het een combinatie van meerdere factoren.

Ernstige ondercapaciteit
Het team is niet groot genoeg om de werkvoorraad goed bij te houden. Nu gebeurt het al snel, dat een team meer werk krijgt, dan het aankan. Maar dan is er nog niet altijd sprake van ernstige ondercapaciteit. Ernstige ondercapaciteit merk je aan de "creatie-datum" van het werk dat opgepakt wordt. En de "creatie-datum" is de datum waarop de bug of wens voor een wijziging voor het eerst in de organisatie is gemeld. Als je team meer dan 75% werkt aan bugs of wijzigingen, die minder dan een maand oud zijn, dan is er sprake van ernstige ondercapaciteit. Je werkt te vaak aan nieuwe zaken en kan daardoor niet goed structureel andere problemen oppakken.


Druk
De prioritering of hoeveelheid te besteden tijd wordt niet bepaalt door kwaliteit of kans op falen, maar door een deadline, een manager, een klant, een afdeling, een collega, enz. Deze kwam je al tegen bij de beschrijving van de overlevingsstand. Dat komt, omdat dit een van de meest eenvoudige is om te herkennen. En deze is bijna altijd van toepassing, als een team in overlevingsstand is. De bugs worden voornamelijk geprioriteerd op grootte van klant, deadline van het project, afwijken van een standaard, enz. Het grote gevaar is, dat dit vaak niet raar wordt gevonden. Want moet je met die zaken dan geen rekening houden? Natuurlijk wel. Het verschil is tussen reactief en preventief bugs oplossen. Bij reactief oplossen gebeurt het oplossen van bugs grotendeels in opdracht van iemand, die eigenlijk qua functie niet verantwoordelijk is voor de prioritering. Je bent dan meestal mensen tevreden aan het stellen of crisissen aan het bezweren. Bij preventief bugs oplossen, los je bugs op op basis van de prioriteit, zoals bepaalt door de persoon of personen, die in zijn functie heeft staan "Bepaal de prioriteiten van het op te pakken werk". En deze persoon maakt  of deze personen maken wel gebruik van anderen, maar is of zijn vrij om de mening van ieder ander naast zich neer te leggen. En ze doen dat ook. Als je vraagt: "Waarom pakken we dit op", is het antwoord dan ook bijna nooit "Omdat X dit wil". Dit geeft rust en geeft daarnaast ook weer de tijd om goed structureel andere problemen op te pakken.

Kennisgebrek
Men wil wel, maar men kan niet. De kennis van de applicatie is zo weinig geworden, dat bugs fixen of wijzigingen inbouwen ongeveer gelijk is aan schieten in het donker. Het is duimen, dat er niets vergeten wordt of er geen nieuwe bugs ontstaan. Dit is de meest ingewikkelde om te herkennen, want niemand kent de hele applicatie uit zijn hoofd. Maar ikzelf herken hem aan het aantal keren waarop de code het antwoord moet geven op functionele vragen. Natuurlijk, als ik een heel gedetailleerdere vraag stel: "Wat gebeurt er als ik eerst X doe, dan Y en dan Z?", verwacht ik niet dat iemand direct het antwoord weet. Maar als ik vraag "Op hoeveel plaatsen kunnen we een klant invoeren?" of "Hier werkt het op manier A en daar op manier B, wat is correct?", zou het antwoord meestal eenvoudig te geven moeten zijn. En zeker geen uur code analyse moeten vragen. Helemaal duidelijk wordt het, als mensen je vragen verkeerd beantwoorden en ze het zelf niet doorhebben. Natuurlijk, beide situaties kunnen een keer gebeuren, maar als dit (bijna) de standaard is, wordt bijna elke bouwklus aan je applicatie gevaarlijk. En kan daardoor leiden tot ondercapaciteit, doordat bij bouwklussen te regelmatig nieuw werk ontstaat. Of het leidt tot druk, omdat anderen de problemen van het bouwresultaat moeten ontdekken.

Hoe ga je er als tester mee om?

Het allerbelangrijkste advies aan testers bij een team in overlevingsstand? Ga zelf niet in overlevingsstand. Natuurlijk, je werkt wordt erdoor beïnvloedt. Je kan niet genoeg testen, de bugs, die je vindt, worden niet voldoende opgelost of je hebt te weinig informatie voor een betrouwbare test. Maar blijf zelf in ieder geval goed prioriteren. En het belangrijkste advies: prioriteer zelf! Prioriteer zelf je testwerk: wat moet het eerst getest worden, wat het tweede, wat het derde. En bepaal ook van deze taken het testbelang: welke testtaken zijn must haves, omdat ze blocking bugs voorkomen en welke zijn would haves, omdat ze trivial bugs voorkomen. Prioriteer ook zelf de bugs: welke zijn critical, welke major, enz. Leg die prioriteiten vast en leg ze zo vast, dat je ze later terug kan vinden.

En als laatste: gebruik deze prioriteiten om feedback te geven op de situatie. Geef deze feedback minimaal aan je manager en aan je team. En blijf deze feedback geven, ook als het geen effect heeft. Blijf melden, als je belangrijke testtaken niet uitgevoerd krijgt of als ernstige bugs niet opgelost worden. Maar (en dit geldt niet altijd, maar wel bij een team in overlevingsstand) meldt niets als je al je must have taken hebt kunnen uitvoeren en je alle bugs hoger dan major zijn opgelost. Dit laatste is om over te komen als iemand, die zich inzet voor belangrijke zaken. En niet als iemand, die altijd wel iets te klagen heeft. Juist in een team in overlevingsstand is hoe je overkomt heel belangrijk. Je omgeving moet begrijpen waar je voor staat. En bij voorkeur hier respect voor hebben, ook als ze je mening niet delen. Serieus genomen worden is je enige kans op verbetering.

Manieren om aan namen, adressen en andere gegevens te komen voor testdata

De beruchte adrescheck. Je moet een postcode invoeren, die werkelijk in Nederland bestaat. En het liefst nog in combinatie met een huisnummer ook. De oplossing: iedere tester heeft zijn eigen postcode en huisnummer, die steeds weer opnieuw gebruikt wordt. Elke test opnieuw. Want hoe kom je elke keer op een nieuw adres? Zeker in een tijd, waarin je ook nog eens geen werkelijke gegevens mag gebruiken? Eigenlijk weet toch iedere tester, dat elke keer dezelfde gegevens gebruiken je testen niet betrouwbaarder maakt?

Fake name generators
Er zijn websites gespecialiseerd in het creëren van valse gegevens. Deze zijn handig voor snelheid, maar hebben vaak nadelen. Zo zullen ze voor telefoonnummers in Nederland vaak 06-nummers tonen. En, als ze als postcode en huisnummer combinaties geven, zullen deze niet altijd in werkelijkheid kloppen.

Voorbeelden:
https://www.fakenamegenerator.com/gen-random-nl-nl.php
https://www.fakeaddressgenerator.com
http://www.naamgenerator.com/

De eerste twee zijn het meest uitgebreid. Ze bevatten namen en adressen en kunnen zelfs internationaal gebruikt worden. De laatste is voor Nederland het beste. Het netnummer klopt en de postcode lijkt te kloppen met het huisnummer. Al komen de namen me niet erg realistisch over. Maar dat is eigenlijk bij alle drie het geval.

Ook voor andere data zijn generatoren te vinden, bijvoorbeeld deze twee voor IBAN en BSN codes:
https://cyberwar.nl/elfproef.html
https://www.mobilefish.com/services/bankaccount_bsn_numbers/bankaccount_bsn_numbers.php?lang=nl

Top X lijsten
Om variatie te hebben in voor- en achternamen, kan je ook gebruik maken van de populaire top X lijsten op het internet. Zoek eens op de 100 populairste voornamen en de 100 populairste achternamen. En je bent zo weer 100 personen verder. Juist omdat dit veelvoorkomende namen zijn, zijn ze vaak realistischer. Maar bijzondere gevallen zal je hierdoor juist weer missen.

Bestaande sites met databanken
Om aan namen of adressen te komen, kan je ook gebruik maken van bestaande databanken. Wel is aan te raden om, als je namen gebruikt, de voornaam van de ene en de achternaam van de andere persoon te nemen. Maar het meest simpel is dit voor adressen. Denk hier aan sites, waar huizen te koop of te huur staan. Denk aan willekeurige zoekacties in Google, bijvoorbeeld "Winkel Haarlem". Wissel hier wel af in bronnen, zeker als je veel testdata gebruikt. Voor namen kan je denken aan zoekacties op nieuwsberichten. Zoek bijvoorbeeld eens op "Directeur" in de nieuwsberichten en combineer een voor- en achternaam van twee verschillende directeuren. Andere mogelijke termen zijn "Manager" of "Dominee". Ook regionale bladen bevatten vaak veel namen. Fantaseer er zelf maar op los voor meer variatie. Het voordeel is, dat je bij bestaande sites eerder een goede verhouding krijgt tussen de verschillende namen en adressen. Het is echter wel meer werk dan de bovenstaande methodes. En je moet meer letten op de anonymisering

Het verband tussen kwaliteit en klantgerichtheid

Testen is een activiteit gericht op het verbeteren van de kwaliteit van het product. Sommige testers zien misschien een groot verband met de uiteindelijke klanten en gebruikers, anderen misschien nauwelijks. Maar het is er wel. Uiteindelijk zijn het de eindgebruikers, en daarmee vaak je klanten, die het definitieve oordeel over de kwaliteit van je product vormen. Maar hoe kan je daar als tester mee om gaan? En hoe moet je er vooral NIET mee omgaan?

De situatie in het algemeen

Een applicatie wordt gebouwd voor klanten en eindgebruikers. Doel is ervoor te zorgen, dat zij tevreden zijn en tevreden blijven. Het eerste kan je nog wel achter komen. Als je klanten en eindgebruikers niet tevreden zijn, krijg je dat via een of ander kanaal vanzelf wel te horen. Tevreden blijven, is waar het probleem zit. Hier gaat het om een moeilijker terrein: hoe gaan nieuwe klanten je applicatie gebruiken en hoe gaan je bestaande klanten in de toekomst je applicatie op een andere manier gebruiken? Juist in deze tweede situatie kan je als tester veel betekenen. Wat zijn de kwaliteitsaspecten voor onze applicatie en welke zijn van belang voor onze klanten?

Wat vindt de klant belangrijk?

Het is van belang te weten wat voor je klant belangrijk is. Over het algemeen wordt bij zogenaamde kantoorapplicaties de layout niet zo belangrijk gevonden. De mogelijkheid om snel en eenvoudig gegevens in te voeren, wordt vaak veel belangrijker gevonden. Liever een snel, dan een mooi scherm. Op websites, waar thuisgebruikers gebruik van maken, is layout en vormgeving daarentegen vaak een van de doorslaggevende factoren. Als je concurrent een betere eerste indruk maakt, zullen veel klanten naar de concurrent gaan. Maar als je wat gebruikssnelheid inlevert voor gebruikersvriendelijkheid, zal daar niet snel over geklaagd worden. Het kan zelfs pluspunten opleveren.

Elke tester moet erbij stil staan welke kwaliteitsaspecten belangrijk zijn voor zijn of haar applicatie. Hoe belangrijk is gebruikersvriendelijkheid, vormgeving, performance, gebruiksgemak, leerbaarheid, enz? Als je klant zou moeten kiezen, welke aspecten zouden blijven en welke zouden overgeslagen worden? Van je testtijd moet zeker 75% besteed worden aan de belangrijkste kwaliteitsaspecten. Als dit niet het geval is, is het tijd om je teststrategie eens onder de loop te nemen. Zeker als je klanten klagen over deze kwaliteitsaspecten.

Betrouwbaarheid

Ongeacht de klant, betrouwbaarheid is altijd belangrijk. Getoonde gegevens moeten correct zijn en ingevoerde gegevens moeten goed opgeslagen worden. Maar uit mijn ervaring als tester weet ik, dat deze betrouwbaarheid vaak ter discussie wordt gesteld. Vaak ten behoeve van klantgerichtheid. Om zowel mogelijk te bouwen wat de HUIDIGE klanten NU willen, wordt alles wat daar niet in valt als minder belangrijk gezien. Als er 10 combinaties mogelijk zijn en er worden er maar 5 gebruikt, hoeven de andere 5 niet goed te werken. Dat komt tenslotte de klantgerichtheid ten goede, toch?

Nee! Klantgerichtheid gaat naast snel opleveren van gewenste wijzigingen en fixes, ook om het voorkomen van wensen voor wijzigen en fixes. De meest tevreden klant is vaak de klant die weinig te wensen heeft, omdat de applicatie aan zijn wensen voldoet en volledig naar wens werkt. Het voorkomen van wijzigingen is niet het terrein van de tester. Het voorkomen van fixes natuurlijk wel. Als er 10 combinaties mogelijk zijn, moeten ze alle 10 werken. Zodat nieuwe klanten, die een nieuwe combinatie gaan gebruiken, niet eerst een wijzigingstraject in moet, om de aangeboden functionaliteit ook werkelijk te kunnen gebruiken. En zodat bestaande klanten, die besluiten een andere combinatie te gebruiken, niet eerst contact hoeven op te nemen met een helpdesk.

Waar het op neerkomt:wat je aanbiedt, moet goed werken. En zorg er anders voor, dat je het niet aanbiedt.

Kwaliteit en deadlines

Het halen van deadlines is een van de belangrijkste aspecten van klantgerichtheid. Om deze reden wordt vaak gekeken of de applicatie niet met wat minder kwaliteit opgeleverd kan worden, om een deadline te halen. Hoe vervelend je dit als tester ook mag vinden, in veel gevallen moet je hiervoor open staan.

Maar ook hier moet je je wel in de klant blijven verplaatsen. Hoe blij een klant ook is met een product, dat op tijd opgeleverd is, die blijheid kan snel afnemen. Bijvoorbeeld als de klant vervolgens een ontzettend lang testtraject heeft, omdat de applicatie heel veel fouten heeft. Of als de gebruikers gaan klagen, omdat de applicatie duidelijke fouten heeft of langzamer werkt. Er kunnen talloze redenen zijn, waarom het halen van een deadline uiteindelijk in je nadeel kan gaan werken.

Ook hier is het van belang om te weten wat voor je klanten belangrijk is. Wat zijn ze bereid in te leveren om de deadline te halen? Minder functionaliteit, mindere vormgeving, minder performance? En daarbijhorend: wat zijn ze NIET bereid in te leveren om de deadline te halen? Soms is het verstandiger om de klant om meer tijd te vragen, dan om een product op te leveren waar ze niet blij van worden.

Mijn eigen richtlijn: elk product dat opgeleverd wordt moet een betere kwaliteit hebben dan het product ervoor. Het kan dus zijn dat het product kwalitatief beter is, door de toevoeging van nieuwe functionaliteit. Maar er iets op achteruit gaat, omdat een bestaand scherm wat foutjes bevat. In dit geval zal de kwaliteit van het product over het algemeen als hoger worden beoordeeld. Maar als de kwaliteit toeneemt, doordat een kleine, nieuwe functie is toegevoegd, terwijl je 10 bugs hebt geïntroduceerd, is het de vraag of een oplevering wel een verstandige keuze is.

Dus hoe kijk je naar kwaliteit?

Kwaliteit wordt bepaald door je klanten, voornamelijk je huidige klanten in hun huidige situatie. Maar een eerste indruk bij nieuwe klanten moet zeker niet vergeten worden. En je huidige klanten moeten zonder veel problemen hun gebruik van de applicatie kunnen wijzigen. Van belang is daarom meer te kijken naar de kwaliteitsaspecten, die belangrijk zijn, dan naar bepaalde veel gebruikte functies of invoercombinaties, die belangrijk zijn.

Waar het om gaat, ook onder tijdsdruk, is dat elke nieuwe versie van een product beter is dan de vorige. Beter in de ogen van klant. Maar natuurlijk moet het algehele kwaliteitsoordeel daarmee niet uit het oog worden verloren. Dus gebruik dit niet als excuus om eenmaal opgeleverde fouten niet op te lossen. Voor de korte termijn strategie kan opleveren met een bekende problemen verstandig zijn. Op de lange termijn moet gewoon je hele product een goede kwaliteit hebben, om weer terug te komen in de gewenste situatie. Hoe een klant je applicatie ook gebruikt, je applicatie moet gewoon een goede kwaliteit hebben.

Testen van berekeningen, die niemand meer kent

Misschien ken je de situatie. Berekeningen zijn binnen veel applicaties heel belangrijk. Maar als je vraagt: "Hoe werkt het? Dan kan ik het testen." is het antwoord "Deze berekening is te ingewikkeld. Die testen we niet." Het zou een zeer unieke situatie moeten zijn. Maar ik ben hem verschillende keren bij verschillende bedrijven tegengekomen.

Het probleem is, dat veel uitgebreide berekeningen bestaan uit vele schermen, velden, condities, enz. Velen hebben een deel gebouwd, met als gevolg dat niemand meer alles weet. En als er zoveel mogelijkheden zijn, hoe kan je dan ooit een goede, volledige test doen? Zeker als een groot deel van de kennis niet meer te vinden is?

Misschien zijn er mensen, die nu hopen op een magische formule, die dit mogelijk gaat maken. Om alvast die teleurstelling te voorkomen: die formule heb ik niet. Wat ik wel heb, is een methode, die het testen van dit soort berekeningen kan starten. En ervoor kan zorgen dat, elke keer als je de berekening test, je beter test dan de vorige keer. Testen van dit soort berekeningen is als met vele onderwerpen: je moet gewoon starten met wat je kan. Alles testen is nu een onbereikbaar doel. Maar elke keer meer weten en daardoor beter testen, is zeker de moeite waard. Alles wat je kan testen aan een zeer belangrijk onderdeel van je applicatie is altijd de moeite waard.

Achterhaal wat nog wel bekend is
In veel gevallen is er nog aardig wat bekend van de berekening. Denk hierbij niet alleen aan de berekening zelf. Denk ook aan de schermen, waar gegevens voor de berekening worden ingevoerd. Zelfs als men de berekening niet meer weet, weet men vaak nog vrij goed in welke schermen gegevens voor de berekening ingevoerd worden. Zelfs vaak ook welke gegevens gebruikt worden. Dat scheelt al erg.

Oude documentatie, zelfs al is deze niet meer actueel, kan ook helpen te achterhalen welke gegevens gebruikt worden. Natuurlijk: als iemand een deel van de berekening kent of als deze ergens gedocumenteerd is, gebruiken! Maar anders: zo veel mogelijk achterhalen welke gegevens gebruikt worden en waar deze ingevoerd worden, is een hele belangrijke start.

Creëer een lege basissituatie

Wanneer je niet meer informatie over de berekening kan achterhalen, kan de applicatie zelf je de berekening gaan leren. Hiervoor creëer je eerst een lege basissituatie. Wat houdt dit in? Je voert de gegevens zo in, dat de berekening uitkomt op 0. Om van een factuurberekening uit te gaan: aantallen zet je op "0" en bedragen zet je ook op "0". Hier is geen kennis van de berekening van nodig.

Mocht dit je niet lukken, omdat je te weinig gegevens hebt kunnen achterhalen, die de berekening beïnvloeden, start dan zoveel mogelijk vanaf "installatie". Voer alle gegevens in alsof je een nieuwe klant bent, maar voer bij alle getallen de waarde "0" in.

Test de berekeningsonderdelen 1 voor 1
Een uitgebreide berekeningen is vaak onderverdeeld in heel veel verschillende onderdelen. Dit zijn delen van de berekening, die zijn gescheiden door een "+" of een "-" teken. Of methodes, die bepalen of getal A of getal B gekozen wordt. Denk bij dit laatste bijvoorbeeld aan het BTW percentage. Deze is afhankelijk van het gekozen artikel.

In veel gevallen zijn deze onderdelen uit de user-interface te halen. Als je verschillende artikelen aan een factuur kan toevoegen, is de berekening van het artikel waarschijnlijk een lost onderdeel. Wanneer je een onderhoudstabel hebt voor verschillende BTW-percentages, wordt waarschijnlijk ergens bepaalt welke gekozen moet worden.

Ongeacht of je de onderdelen al gedeeltelijk kan raden of niet, de aanpak blijft gelijk. Voer bij een veld, waarvan je weet dat deze voor de berekening gebruikt wordt, een waarde in. Kies voor een waarde, die het eenvoudig maakt te achterhalen hoe de berekening werkt. Bijvoorbeeld "1" voor aantallen of "50" voor percentages. Voer daarna een ander veld in, dat voor de berekening gebruikt wordt. Als je een berekeningsonderdeel weet, kies een ander veld voor dat onderdeel. Als je dit niet weet, kies bij voorkeur een veld op hetzelfde scherm, zo dicht mogelijk in de buurt.

Controleer de berekening en ga net zo lang door, totdat je berekening geen "0" meer als antwoord geeft. Zorg er wel voor, dat elk ingevoerd  veld een unieke waarde heeft. Meestal zal je nu vrij eenvoudig kunnen zien, wat er berekend is. Een optelling of vermenigvuldiging van twee ingevoerde getallen is het meest voorkomend. Anders moet je nog even doorpuzzelen, door weer invoer op "0" te zetten. Als het resultaat van de berekening groter blijft dat 0, blijft dat gegeven "0". Anders voer je weer een waarde in. Waar het om gaat, is dat je een situatie probeert te creëren, waarin zo min mogelijk gegevens de berekening beïnvloeden. Zodat je eenvoudig kan zien, wat de berekening is.

Weet je een berekeningonderdeel, ga dan door tot je alle bekende velden van de deelberekening gehad hebt. Weet je niets, voer de gegevens verder 1 voor 1 in, tot het bedrag wijzigt. En herhaal bovenstaande stappen. Blijf elk veld een unieke waarde geven. Geef desnoods velden weer de waarde "0", om waardes beschikbaar te maken.

Sta tijdens dit hele proces ook bij het volgende stil: "1" is een ideale waarde om de test te starten, maar als je vermenigvuldigd met 1, blijft het antwoord gelijk. Hetzelfde geldt voor "100%" en "1:1". Dit kan dus een goede start zijn, maar wijzig deze waardes op een bepaald moment naar een andere waarde. Mogelijk mis je anders een deel van de berekening.

Niet ideaal, maar beter dan niets
Elke informatie, die je weet te achterhalen, maakt het mogelijk een deel van de berekening te testen. Dus elk gesprek of elk document kan helpen. En door steeds wat meer gegevens in te voeren, kan de applicatie zelf je ook veel leren van de berekening. Besef dat voor zo'n belangrijk onderdeel, als een berekening, betrouwbaarheid vaak zo belangrijk is, dat alle beetjes automatisch waardevol zijn.

Testtools zijn geen doel op zich!

In mijn huidige baan ben ik vooral bezig met testautomatisering. Een baan waar je niet zonder testtool kan. Maar ook buiten de testautomatisering kwam en kom ik regelmatig de behoefte aan testtools tegen. Zeker als testautomatiseerder zou je verwachten dat ik een groot fan ben van het invoeren van testtools. Ik ben het niet. In mijn geval: juist door vele testautomatiseringsprojecten ben ik er alleen maar voorzichtiger mee geworden.

Ben ik tegen testtools? Nee, natuurlijk niet. Testtools, of ze nu zijn om bevindingen vast te leggen, test cases vast te leggen, testomgevingen te beheren of, natuurlijk, testen te automatiseren, kunnen heel waardevol zijn. Ze kunnen het werk van de tester verbeteren, versnellen of vereenvoudigen.

Een testtool lost veel problemen niet op
 
Wat is dan het probleem? Het probleem is dat het testtool als de oplossing wordt gezien. Om het voorbeeld bij testautomatisering te houden: testautomatisering wordt vaak als oplossing gezien om beter en sneller de regressietest uit te voeren. In een organisatie met goede, regelmatig uitgevoerde en goed onderhouden handmatige regressietesten is testautomatisering inderdaad een goede stap vooruit. In een organisatie waar de regressietesten van matige kwaliteit zijn, regressietesten bijna nooit worden uitgevoerd of eigenlijk niet worden onderhouden is testautomatisering heel erg moeilijk.

Datzelfde geldt voor het vastleggen van bevindingen of testcases. Een goede bevindingenregistratie kan heel handig zijn. Maar als men nu de tijd niet heeft of de behoefte niet ziet om bevindingen vast te leggen, gaat een invoer van een tool hiervoor niet helpen. Als de bevinding vaak onduidelijk is of moeilijk reproduceerbaar, gaat een testtool dit probleem niet oplossen. Datzelfde geldt voor testcases vastleggen. Testcases hergebruiken kan heel waardevol zijn. Maar als je nu nauwelijks testcases hergebruikt, waarom zou een testtool voor het beheer van testcases dat veranderen?

Elk testtool heeft zijn eigen eisenpakket

En een ander probleem. Testtools kunnen tijd besparen. Maar ze kunnen ook meer tijd kosten op momenten, dat je dat niet wil. Omdat elk testtool zijn eigen eisen heeft. Bevindingenregistraties verplichten je om meer gegevens in te vullen. Gegevens, die daarvoor niet werden ingevoerd. En misschien wel terecht. Als je altijd test op dezelfde testomgeving, is het bijhouden van de testomgeving niet nodig. Als je direct samenwerkt met een ontwikkelaar tijdens het testproces en daarom de bugs direct overlegd, is een omschrijving van de bug, zelfs het aanmaken van de bug, misschien wel onnodige administratie. En zo heeft elk testtool zijn eigen zaken, die je moet uitvoeren, om met het testtool te kunnen werken. Zijn die zaken voor jou wel echt nodig? Wegen ze op tegen de voordelen?

Van doel naar middel

Een testtool is een hulpmiddel bij het oplossen van een testprobleem. En vaak slechts een deel van de oplossing. Toch wordt het al snel een doel, zeker door de manier waarop bedrijven en voorstanders het verkopen. Na de invoering van testtools zal alles beter gaan werken. Wat er nog meer nodig is voor een goede invoering, kunnen of zullen zij je vaak niet vertellen.

Hoe kan je dat zelf controleren. Simpel: testtools verbeteren of versnellen een bestaande testproces stap. Wat ze niet doen: het invoeren van een nieuwe stap in het testproces. Dit kan op detail niveau zijn, zoals het invoeren van bepaalde gegevens bij een bevinding, op wat hoger niveau, zoals het schrijven van een testscript voor een testcase of op een heel hoog niveau, zoals het uitvoeren van regressietesten. Simpel gezegd: alleen als je alle stappen, waar je het testtool in wil zetten, nu al handmatig doet, kan het testtool een doel op zich zijn. Wanneer dit niet het geval is (waarschijnlijk bijna altijd), is je testtool slechts een middel om tot de oplossing te komen.

Een verstandig besluit nemen over de vraag "Wel of geen testtool"

Voordat je over gaat tot invoering van een testtool, is het verstandig om eerst een paar simpele vragen te beantwoorden:

• Welke stappen in het testproces wil ik de testtool laten uitvoeren?
• Bestaan deze stappen nu al? Zo nee, waarom niet?  
• Welke problemen lopen we nu tegenaan bij deze stappen? Gaan deze problemen door de invoering  van het testtool opgelost worden? Of moeten ze opgelost zijn, om invoering zinvol te maken?
• Welke werkzaamheden, die nu al worden uitgevoerd, gaan door de invoering verbeterd of versneld worden? Let op: het gaat dus alleen om werkzaamheden, die je nu al uitvoert, niet om werkzaamheden, die je zou willen gaan uitvoeren.
• Welk extra werk is er nodig, als je gebruik gaat maken van dit testtool? Bijvoorbeeld welke handelingen zijn verplicht om uit te voeren, om dit testtool te kunnen gebruiken of welke extra onderhoudswerkzaamheden zijn nodig om het gebruik zinvol te maken? En is deze tijd ook beschikbaar te maken?

Invoeren van een testtool? Maak de juiste afweging

Een testtool kan een goed middel zijn om een probleem op te lossen. Maar het kan ook uiteindelijk de oplossing niet blijken te zijn. Zeker als je een stap op dit moment handmatig niet uitvoert, moet je je sterk afvragen of het automatiseren van een nu niet bestaande stap, je probleem op gaat lossen. Sta stil bij meer dan alleen de bekende voordelen van een testtool. Sta stil bij de nadelen van een testtool en bij de huidige problemen in je organisatie. Het antwoord op "Invoeren Ja/Nee" kan dan "Ja" of "Nee" worden. Maar als het antwoord "Ja" is, is de kans op succesvolle invoering wel veel hoger. Je weet veel beter waar je aan begint.