Een Agile aanpak voor een teststrategie

Als je kijkt naar een teststrategie of soortgelijke documenten, loop je tegen een standaard Agile probleem aan. Een veel gehoorde Agile klacht is: "We werken nu Agile, maar we worden nog steeds nergens bij betrokken". En een andere veel gehoorde Agile klacht is: "We hebben sinds de invoering van Agile veel te veel meetings. Ik wil meer tijd om gewoon mijn werk te doen." Beiden komen regelmatig uit dezelfde monden. Hoe ga je hiermee om bij een onderwerp als de teststrategie? Mensen zijn vaak nauwelijks bereid hier veel tijd in te steken, maar zeer bereid om te laten weten, dat zij het anders wilden.

Om dit te bespreken, moet ik eerst een misverstand uit de weg helpen. Ik heb bijna geen invoering van Agile of Scrum meegemaakt, zonder dat mensen gingen klagen over het aantal meetings. En de meest getrokken conclusie naar aanleiding van die klachten, is dat mensen niet betrokken willen zijn. Die conclusie is in de meeste gevallen te snel. Vaak willen mensen wel degelijk betrokken zijn. Maar niet bij alles. Ze willen niet gedwongen worden om tijd te besteden aan zaken waar ze geen kennis van hebben en geen interesse in hebben. Meetings, waar ze vooral luisterend tijd doorbrengen. Als ze het al de moeite vinden om te luisteren. Wanneer je het voor elkaar krijgt een meeting te organiseren op het gebied van hun kennis of hun interesse, zal je niet snel horen klagen over "te veel meetings". Dat in het achterhoofd houdend, is het zeer goed mogelijk om tot een Agile teststrategie te komen.

Maar er is nog een probleem. Een teststrategie kan niet 100% democratisch bepaald worden. Er is namelijk een langere termijn opgelegd doel. Dit kan zijn opgelegd door hoger management, maar dit kan ook een doel zijn, dat je zelf wil bereiken. Dit doel kan niet zomaar aan de kant worden geschoven, al zou het hele team tegen zijn. Er zijn dus grenzen. En die grenzen moeten, hoe Agile de aanpak ook is, wel bewaakt worden.

Alternatieven

Een van de meest logische wijze om inspraak te geven, is om mensen de mogelijkheid geven met een alternatief plan te komen. Juist door het bovenstaand beschreven probleem rond het lange termijn doel, lijkt dit geen handige aanpak. Maar ongeacht of je dit officieel vraagt of niet, juist als je echt Agile wil samenwerken, moet je altijd open staan voor een ander idee. Juist binnen een teststrategie kan er sprake zijn van experts op een bepaald gebied, zoals testautomatisering en performance. Maar ook een testspecialist in een bepaalde applicatie kan inzichten hebben, die jij niet hebt. Bijvoorbeeld waar de grootste kwaliteitsrisico's liggen.

Meestal zullen de geboden alternatieven afgewezen worden. Ze bereiken namelijk niet het doel, dat je voor ogen hebt. Niet zo vreemd, want het alternatief is namelijk niet bedoeld om jouw doel te bereiken. Het is bedoeld om het doel van de indiener te bereiken. Juist daarom kunnen afwijzingen van een alternatief zo'n groot effect hebben. Voor je het weet, is de indiener ervan overtuigd, dat zijn of haar probleem voor jou dus niet belangrijk is. Ongeacht of dit waar is of niet.

Om de samenwerking en de betrokkenheid goed te houden, zijn goede alternatieven van de mensen om je heen van groot belang. Door hun specialisaties, die doorklinkt in hun alternatieven, wordt jouw strategie al snel beter, als je dit weet te gebruiken. Maar om bovenstaande situatie te voorkomen, is het wel jouw taak anderen een eerlijke kans te geven met hun alternatief. En dat doe je door niet alleen de oplossing te vertellen, maar ook het probleem.

Zorg dat alle betrokkenen op de hoogte zijn van de doelen, die jij dit jaar met je teststrategie wil bereiken. En vermeldt hierin welke problemen je hiermee hoopt op te lossen of te verminderen. Vooral het laatste is ook van groot belang. Het kan je doel zijn om meer de facturatie te testen. Maar als je hier niet bij vermeldt, dat je het aantal door de klanten gevonden fouten in de factuurbedragen wil terugbrengen? Dan hebben anderen veel sneller niet genoeg informatie om tot een goed alternatief te komen. Want "Meer facturatie testen" kan bijvoorbeeld ook om een performance probleem gaan. Of om layout problemen.

Je mag dan wel verwachten dat mensen, die een alternatief aanbieden, hierbij aansluiten bij de genoemde doelen en ook de genoemde problemen willen oplossen. Maar daarnaast zullen ze ook hun eigen problemen tot een oplossing willen brengen. Dit maakt het alternatief niet opeens standaard bruikbaar. Maar zelfs bij een afwijzing, is het makkelijker om het probleem van de ander te verwerken in het eindresultaat. Omdat beide voorstellen al dichter bij elkaar liggen.

Overleggen

Samenwerken is overleggen, daar is niets aan te veranderen. De meest logische Agile aanpak voor een teststrategie, is dan ook een meeting beleggen met alle betrokkenen. En omdat er veel te bespreken valt, een lange meeting beleggen. Zo een, waar veel mensen al door de lengte geen zin in zullen hebben.

Samenwerken door overleggen kan echter ook op andere manieren. Je kan thema overleggen doen, bijvoorbeeld een losse meeting voor de testautomatisering, een losse meeting voor testtools, enz. En bij deze meetings alleen de direct betrokken van deze onderwerpen uitnodigen.

Daarnaast kan je ervoor zorgen, dat alleen de mensen die willen aanwezig zijn. Dit lijkt misschien niet netjes en verstandig. Maar mensen, die verplicht zijn te komen en er niet willen zijn, zullen meestal geen bijdrage leveren aan de meeting. Dus ze de gelegenheid geven niet te komen, heeft voor beide partijen alleen maar voordelen.

Let wel op, dat het niet komen hun keuze is. Dit doel kan heel eenvoudig bereikt worden door mensen voor een vergadering optioneel uit te nodigen. Maar je kan er ook voor kiezen, dit van tevoren mondeling te bespreken. Het tweede is natuurlijk meer tijdrovend, maar geeft wel de optie om de ander ervan te overtuigen dat zijn of haar kennis in de meeting zeer waardevol zal zijn.

Daarnaast hoeft overleggen niet in een groep. Een op een meetings kosten in basis meer tijd, maar de waardering voor zo'n meeting van de ander is vaak groter. Juist door de een op een aandacht, zal de ander zich niet snel niet serieus genomen voelen. Het is makkelijker om de onderwerpen op de ander af te stemmen. En de ander zal ook sneller zijn of haar mening geven. Zeker in een omgeving waar het vertrouwen in Agile of de organisatie laag is en er in meetings weinig input is, kan juist een meeting een op een de doorbraak geven. Maar houdt wel een belangrijk nadeel in je achterhoofd: er is geen wisselwerking tussen de verschillende betrokkenen qua ideeën. Daardoor kan de kwaliteit lager zijn.

Als het vertrouwen in Agile en in de organisatie wel aanwezig is, kan je er ook voor kiezen om geen echt overleg te hebben, maar te overleggen per e-mail. Dit kan door een concreet voorstel te sturen of door vragen rond te sturen. Waarbij mensen de kans krijgen via e-mail, al dan niet aan een hele groep, te reageren. Een goed alternatief, als men wel wil overleggen, maar geen tijd heeft. Maar hierbij moet je wel iets zeker weten: iedereen aan wie je de e-mail stuurt, moet in staat zijn om het met je oneens te zijn, En wel openlijk. Als iemand nooit tegen jou heeft gezegd, dat je iets verkeerd hebt gedaan. Of dat je iets beter had kunnen doen, is dit niet de persoon om via e-mail mee te overleggen. Ongeacht de situatie, zal je eerst mondeling de samenwerking moeten verbeteren.

Het eind- of tussenresultaat

Het belangrijkste voor een goede Agile aanpak, is dat mensen zich vrij blijven voelen opmerkingen en ideeën in te brengen. En daarvoor is het van belang, dat mensen het gevoel hebben serieus genomen te worden. Maar een teststrategie is keuzes maken. Je kan niet alle problemen nu oplossen. En je kan je tijd maar 1 keer besteden. Dus regelmatig zal niet iedereen blij zijn met je voorstel of je eindproduct, hoe vaak je ook overlegd. Of nog erger, juist door de overleggen, omdat je verwachtingen hebt geschept, enkel door naar hun problemen te luisteren. De verwachting, dat je iets met hun input gaat doen. Hoe onbelangrijk het misschien ook lijkt voor een teststrategie, juist hier moet je ook aandacht aan besteden.

De belangrijkste wijze is een goed begin van je document. Beschrijf nogmaals de doelen van de teststrategie en de problemen die je hiermee wil oplossen. Als je bepaalde problemen van anderen hebt overgenomen, benoem deze dan ook. Laat al aan het begin van het document merken, dat je die problemen ook belangrijk hebt gevonden.

Besteed daarnaast aandacht aan de langere termijn. Als je teststrategie voor een jaar is, beschrijf dan ook de teststrategie voor een flink aantal jaren meer. Dit mag natuurlijk op hoofdlijnen. Niet alleen geef je hiermee belangrijke informatie aan de lezer. Je kan dit ook gebruiken om onderwerpen, waar je nu geen tijd voor hebt, alsnog te benoemen. Te laten merken dat je ze wel degelijk belangrijk vindt. Probeer ook uit te leggen waarom je dit jaar niet hebt gekozen voor deze onderwerpen, dat maakt de kans op acceptatie groter.

Pas hierbij wel op, dat je geen verwachtingen schept, die je niet waar kan maken. Iemands probleem schriftelijk erkennen is een goede stap, zelfs als je niets oplost. Maar jaar na jaar na jaar schriftelijk laten weten dat er belangrijkere problemen zijn, kan vertrouwen juist om zeep helpen.

De Agile aanpak samengevat

Er is dus een manier om op een Agile wijze tot een teststrategie te komen.

• Laat duidelijk weten wat je doelen zijn en welke problemen je op wil lossen, zodat andere makkelijker waardevolle input kunnen geven
• Plan overleggen met personen, die echt willen. Als de situatie dit toestaat of zelfs aanraad, kan dit met een op een meetings of via e-mail
• Laat in je uiteindelijke teststrategie of een voorstel hiervoor duidelijk de problemen van de ander terugkomen, als je deze inderdaad wil oplossen. Een middel hiervoor is een beschrijving van de doelen, die gaat over een langere periode dan de periode van de teststrategie.

Hoe verminder je testspecialisaties bij Scrum?

Specialisaties is een algemeen probleem bij Scrum. Het streven om als team altijd onafhankelijk te kunnen werken, wordt steeds moeilijker naarmate er meer teamleden zijn met specialisaties. Of er steeds meer specialisten buiten het team komen. Zolang je bedrijf alleen testers heeft, is het een probleem van iemand anders. Maar juist binnen testen komen steeds vaker specialisaties voor: performance tester, testautomatiseerder, security tester, noem maar op.

Juist bij een onderwerp, waar een bedrijf en de testers in de Scrum teams niet zo bekend mee zijn, ontstaat er snel een specialist. Een tester in een Scrum team, die de tijd neemt of krijgt, om een nieuw onderwerp te leren. Of iemand buiten het team, al of niet ingehuurd, die al ervaring heeft met het onderwerp. Deze specialist zal, geheel tegen de Scrum goals in, door de teams gedeeld worden. De kennis is vaak nodig in alle teams, niet in slechts 1 team. Het belangrijkste is wel: probeer dit als een tijdelijke situatie te zien, met als doel zo snel mogelijk zo veel mogelijk zonder de specialist te kunnen werken. En ga dit niet als de gewenste situatie zien.

Nu gaat het werk overnemen van een specialist meestal niet in een keer. Die tijd is er vaak niet. En het is ook wat veel voor de persoon, die de nieuwe stof moet leren. Het overnemen kan echter ook in kleinere stappen gebeuren. De stappen, die je kan zetten om de zelfstandigheid weer terug te krijgen, zijn bijvoorbeeld de volgende:

Testuitvoering

1. Leer het resultaat lezen. Is de test geslaagd of gefaald?
2. Leer het resultaat beoordelen. Welke test is gefaald? En wat test deze test?
3. Indien mogelijk: leer de test handmatig herhalen
4. Leer de test uitvoeren. Hoe start je hem op? En hoe start je, indien van toepassing, een deel op?
5. Leer het resultaat analyseren. Hoe bepaal je bij een gefaalde test wat er fout gaat?

In veel gevallen is het slim om het analyseren na het opnieuw uitvoeren te doen. Dit is, omdat vaak het zien van de test veel informatie geeft over wat er fout gaat. Het kan daarom handig zijn, dat je zelf in staat bent de test verschillende keren te herhalen, waarbij je bijvoorbeeld kleine verschillen in de data hebt of de omgeving iets hebt aangepast.

Testaanpassing

1. Leer bestaande testen aanpassen, als deze door een wijziging in de applicatie falen
2. Leer nieuwe testen maken op basis van bestaande testen, bijvoorbeeld een andere invoer, maar wel dezelfde controles
3. Leer nieuwe testen maken zonder gebruik te maken van bestaande testen

Het allerbelangrijkste blijft: beschouw een specialist, al of niet in je eigen Scrum team, niet als het eindstation. Zet een traject in werking om in ieder geval de testuitvoering te kunnen binnen het team. En bij voorkeur ook de bestaande testcases aanpassen. Meer kan eventueel buiten het team. Dat is niet ideaal, maar brengt de Scrum principes niet meer gevaar.

Veel leerplezier!

De Ja-Nee-Ja-Nee-Ja-Nee testtechniek

Als je mijn blog regelmatig leest, weet je dat ik het belangrijk vind om invoervelden met verschillende waarden te testen. Maar soms heb je maar twee mogelijke waardes: Ja en Nee. En op je scherm staan misschien zelfs meerdere van dit soort invoervelden. Hoe test je nu of deze waardes goed werken?

Stel je hebt 5 velden met de keuze Ja/Nee. Om deze goed te testen heb je 2 X 2 X 2 X 2 X 2 = 32 testcases nodig. Alleen dan weet je zeker, dat elke mogelijkheid werkt. En als je de tijd hebt, moet je deze 32 testcases zeker allemaal testen. Als je de tijd niet hebt, kan je al heel veel met slechts 2 testcases.

Veel fouten rond Ja/Nee invoervelden ontstaan door kopiëren van bestaande code of elementen. De ontwikkelaar neemt het dichtstbijzijnde bestaande invoerveld en kopieert het element en/of de code. Deze wordt dan vervolgens aangepast voor het nieuwe invoerveld. Door de velden, die dicht bij elkaar staan, nu andere waardes te geven, test je of deze velden ook werkelijk hun eigen waarde gebruiken. En niet die van hun mogelijke "oorsprong". Maar naast dit kopieer argument is het ook handig om ingevoerde waardes snel te kunnen controleren. Een bepaald patroon in de invoer maakt dit makkelijker.

Hoewel ik deze testtechniek nergens heb kunnen vinden, ben ik daarom in de loop van de tijd dit soort velden met de Ja-Nee-Ja-Nee-Ja-Nee techniek gaan testen. Het eerste veld zet ik op Ja, het tweede op Nee, het derde op Ja, enz. En voor de tweede testcase zet ik het eerste veld op Nee, het tweede op Ja, de derde op Nee, enz. Dit heeft dus drie duidelijke voordelen: elk veld wordt zeker getest met beide waardes, ik kan de door mij gekozen invoer eenvoudig onthouden en, zeker niet onbelangrijk, er is een flink grotere kans dat kopieerfouten ontdekt worden.

Een hele eenvoudige, snelle techniek met een vaak goed resultaat. Probeer hem eens zelf uit!

Problemen bij Scrum en Automatisch testen - Ze bestaan echt

Scrum en automatisch testen worden vaak als perfect koppel gezien. Dus hoeveel problemen kan je tegenkomen, als je deze twee combineert? Een heleboel! Hoe komt dit?

Automatisch testen werkt het beste als deze op de ideale wijze uitgevoerd kan worden. Dit houdt in dat er per Scrum team een stabiele omgeving is, waar op een afgesproken tijd opgeleverd wordt. Deze afgesproken tijd is afgestemd op de automatische testen, zodat de automatische test tegen een voorspelbare applicatie draait. Onderhoud aan de automatische testscripts wordt binnen de teams zelf afgehandeld als onderdeel van de story. Bugs worden opgelost bij het team, waar de bug vastgesteld wordt. De perfecte omgeving. Een perfecte omgeving, die er dus niet altijd is.

Meer Scrum teams is niet altijd meer testomgevingen
De meeste problemen ontstaan als er meerdere Scrum teams in een bedrijf aanwezig zijn. Bij het toevoegen van Scrum teams, zal er niet altijd sprake zijn van het toevoegen van testomgevingen. En zeker niet van testomgevingen, die stabiel genoeg zijn voor een automatische test. Hierdoor zal de automatische test draaien op een omgeving, waarin de code van meer dan 1 team wordt opgeleverd.

Dat maakt analyse noodzakelijk bij het falen van de test. Niet alleen moet worden nagegaan of er echt sprake is van een fout, maar ook moet worden nagegaan welk team deze veroorzaakt heeft. Als je tenminste het streven wilt vasthouden, dat er alles aan gedaan moet worden om de story's met de beste kwaliteit mogelijk op te leveren. Het eindproduct van een sprint moet tenslotte geschikt zijn voor productie. En dat is zeker niet het geval, als je weet dat er nog een fout in zit.

Tijdstip afstemmen op de oplevering
Elke wijziging, die opgeleverd is, moet een keer automatisch getest zijn. In de meest ideale situatie vindt er daarom na elke oplevering van een story een volledige automatische test plaats. Maar als dit (nog) niet mogelijk is, moet er meer afstemming plaats vinden. De automatische test kan als eindcontrole gebruikt worden aan het eind van een sprint. Dit is het meest eenvoudig, maar maakt de afstand tussen oplevering van de story en de automatische test wel erg groot.

Ook kan de automatische test met een vaste, korte frequentie draaien. Maar het heeft geen zin om de automatische test dagelijks te draaien, als je de story's pas 1 keer in de week op een stabiele omgeving neerzet. Deze oplossing kan dus pas als de story's ook minimaal 1 keer per dag opgeleverd worden naar een stabiele omgeving, die geschikt is voor de automatische test.

Onderhoud van de testscripts
Testautomatisering begint vaak als een los project, buiten de bestaande Scrum teams op. Regelmatig vraagt het kennis, die in de teams nog niet beschikbaar zijn. En tijd, die binnen het team niet vrijgemaakt kan worden. Om onderhoud van de testscripts onder te brengen in de Scrum teams is als gevolg daarvan een uitdaging. En zeker op korte termijn met regelmaat (nog) niet haalbaar.

Dit staat dan nog los van de verantwoordelijkheid van de testscripts. Het meest eenvoudig is om een Scrum team verantwoordelijk te maken voor de testscripts, die "hun" applicaties of modules raken. Maar wat als twee Scrum teams werken aan dezelfde applicatie, zelfs aan dezelfde schermen? Beide onderhouden hun eigen wijzigingen? Wie voegt deze wijzigingen dan weer samen en controleert het geheel?

Niet vreemd dat onderhoud van de testscripts bij testautomatisering nog wel eens wordt losgetrokken van de Scrum teams. Maar in dat geval zal je wel afspraken moeten maken over het melden van de benodigde wijzigingen. Hoe weet de testautomatiseerder welke functionaliteit wijzigt? Waar velden worden toegevoegd of gewijzigd? En waar controles worden aangepast?

Toch doen!
Laat deze problemen je er niet van weerhouden om met testautomatisering te starten. Afspraken zijn te maken en problemen zijn op te lossen. Het kan alleen handig zijn om er van tevoren alvast bij stil te staan. Dat maakt de kans op het slagen van testautomatisering alleen maar groter!

Test op "veel gebruikt" of test op "risicovol"?

Een van de grootste uitdagingen van een tester is: wat test je wel en wat test je niet? Zeker als de tijd om te testen beperkter is. De basiskeuze hiervoor is, naar mijn ervaring, de volgende: test je vooral datgene wat veelgebruikt is of test je datgene wat het grootste risico heeft om fout te gaan?

Het verschil

Maar wat maakt het eigenlijk uit welke keuze je maakt? Komt beiden niet grotendeels op hetzelfde neer?

Stel je hebt een personeelsadministratie applicatie bij een bedrijf waar de meeste personeelsleden tussen de 20 en de 30 zijn. En ongeveer 75% is man. Het bedrijf ligt dicht bij de grens met Duitsland, maar de meeste werknemers wonen in Nederland. Dit bedrijf geeft personeelsleden boven de 50 twee extra vakantiedagen.

De gegevens, die waarschijnlijk het meest ingevoerd worden, zijn die van een man tussen de 20 en 30, die woont in Nederland. Alleen: man is de standaard waarde bij het invoeren van nieuwe werknemers. En datzelfde geldt voor de landkeuze "Nederland". Zelfs als er een fout zit in het opslaan van de gegevens (als je het geslacht of land wijzigt, wordt deze niet opgeslagen), zal je deze niet testen. De standaard waarde wordt vaak toch wel opgeslagen. Daarnaast is de kans zeer groot dat de ontwikkelaar al getest heeft met de waarde "Man" en de waarde "Nederland". Dat is tenslotte de meest eenvoudige invoer. En vergeet niet de extra situatie: het kan ook zeker interessant zijn om te kijken of die twee extra dagen toegevoegd worden.

De keuze

Stel, je hebt maar tijd voor 1 testcase. Kies je dan de man tussen de 20 en 30, die woont in Nederland? Of kies je de vrouw boven de 50, die woont in Duitsland? De tweede heeft een veel groter risico om fouten te vinden: in de opslag, in het tonen van het adres en in het berekenen van de vakantiedagen. En je test bijna alle functionaliteit, die de eerste testcase ook zou testen, uitgezonderd de berekening van het aantal vakantiedagen. Dus je test meer en de kans is groter dat je fouten vind. In mijn ogen geen moeilijke keuze.

In de praktijk heb je gelukkig wel meer tijd dan 1 testcase. En de keuze is niet altijd zo simpel, als hierboven beschreven. Om het risico te bepalen, moet je weten welke functionaliteit geraakt wordt en bij welke criteria uitzonderingen van toepassing zijn. Daarnaast kan het handig zijn om te weten waar in het verleden veel fouten zijn gevonden. Dit is echter informatie, die je niet altijd tot je beschikking hebt.

En laat ik volledig en eerlijk blijven: de veelgebruikte optie heeft ook voordelen. Je test of de applicatie voor de meeste werknemers goed zal werken. En niet of de applicatie goed werkt voor een kleinere uitzonderingsgroep.

Over het algemeen is het verstandig beide groepen aandacht te geven in je test. Test de meestgebruikte situaties. Maar kijk ook, voor zover mogelijk, naar de uitzonderingen

Wijk af van de standaard waardes

Met twee testcases kan deze voorwaarde vaak al afgedekt zijn. Veel tijd is dus niet nodig.

Test business rules uitgebreider

Als er business rules bekend zijn, test dan verschillende mogelijkheden van een business rule. De verschillende mogelijkheden kan je, als je moet kiezen, weer afwegen op basis van hoeveelheid gebruik of verschil in uitkomst van de businessrule. Om de tweede afwegingsoptie iets te verduidelijken: als je denkt aan het bovenstaande voorbeeld, dan heb je de invoer "onder de 50" en "50 jaar en ouder" voor de uitkomsten "Standaard vakantiedagen" en "Standaard vakantiedagen + 2". Een werknemer van 20 jaar en 30 jaar zullen dan ook precies dezelfde functionaliteit testen. Een werknemer van 20 jaar en 60 jaar niet.

Vraag naar fouten in het verleden

Veel ontwikkelaars, functioneel ontwerpers, business analisten en andere bijdragers aan de applicatie hebben al veel bugs langs zien komen. Ze kunnen je dan ook waarschijnlijk wel vertellen wat voor soort fouten zich in het verleden in dit onderdeel, in soortgelijke onderdelen of in de applicatie in het algemeen hebben voorgedaan. Andere testers in je bedrijf hebben mogelijk ook informatie hierover. Dit is, hoe kort je tijd ook is, belangrijk om mee te nemen in je test.

De collectie testcases

Verdeel je testtijd tussen "Veel gebruikt" en "Risicovol". Een 50%-50% verdeling tussen deze twee is zeker geen onverstandige keuze. En besef dat, zelfs bij beperkte kennis, testen op "Risicovol" wel degelijk tot de mogelijkheden behoort. Test dus op beide, hoe beperkt je tijd ook is.

Als testen meer is dan testen

Deze blog is ooit mede ontstaan als een kijk op een wereld, die vaak wordt ontkent. De testwereld, waarin niet alles perfect geregeld is qua geld, tijd, proces, mensen en/of middelen.. Een wereld, waarin je als tester een keuze hebt: je laat jouw testen bepalen door jouw testwereld of je laat jouw testen steeds opnieuw jouw testwereld uitdagen om te veranderen. Uitleggen welke keuze ik heb gemaakt, is denk ik niet nodig. Maar waar loop je dan tegenaan? Waar ben ik tegenaan gelopen?

Een rol groter dan tester

In de eerste plaats kom je als tester in een andere rol terecht, dan mensen van je verwachten. Je wil als tester steeds meer en beter kunnen testen. Misschien zelfs wel de kwaliteit in het algemeen verbeteren. En daarom ga je over zaken praten, die eigenlijk jouw taak niet zijn. Je wil niet alleen een goed testscript, je wil ook goede specificaties. Je wil nieuwe tools en/of omgevingen, waardoor praten met managers van belang wordt. Je wilt dat de processen goed lopen, omdat betere processen vaak ook leiden tot een beter product. Soms wordt dit gewaardeerd. Soms niet, want het zijn jouw zaken niet. Soms is er vooral ongeloof: wat weet jij als tester nu van deze zaken af? Als je werkelijk sterk in je schoenen staat, is het antwoord: ik kom op voor de kwaliteit van het product. En dat is waar ik als tester ook ervaring in heb. Dus ik kan meer, dan jij misschien denk.

Oplossingen uit "de ideale wereld"

Als er een probleem is, wordt er vaak gekeken naar succesverhalen van anderen. Dan vallen er woorden als: Testautomatisering, Scrum, Outsourcing. Er wordt verteld hoe fantastisch dit geholpen heeft. Dit zijn natuurlijk absoluut geen woorden waar ik tegen ben. Ze kunnen in veel situaties een oplossing bieden. Maar ik merk, dat ik me als tester juist tegen dit soort oplossingen sterk moet verzetten. Niet omdat ik een tegenstander ben van de oplossing op zich. Maar omdat men vaak niet bereid en/of niet in staat is om op een realistische manier te kijken naar de obstakels in de huidige organisatie. Heel veel testautomatiseringprojecten falen, omdat men wel de tijd heeft om de testen te maken, maar niet om ze te onderhouden. Als tester helpt Scrum vaak niet, omdat puur deze invoering er niet opeens voor zorgt, dat ontwikkelaars bereid zijn mee te helpen met testen. En dat terwijl je er juist bij Scrum als tester vaker alleen voor staat. Outsourcing van testen kan een heleboel bugs opleveren, maar bij een houding "we kunnen/moeten onze tijd niet aan dit soort bugs besteden", kan het werkelijke effect van deze testen erg klein zijn. Het is dan soms ook moeilijk om een evenwicht te vinden tussen iemand die open staat voor verandering en iemand die kritisch naar oplossingen kijkt.

Vriend en vijand tegelijkertijd

Als je je evenwicht weet te vinden, ben je vriend en vijand tegelijkertijd. Mensen waarderen je inzet, de bugs die je vindt, de problemen die je aankaart, de verbeteringen die je voorstelt. Maar tegelijkertijd wil men het eigenlijk niet horen. Want als de testwereld niet perfect is, zijn er vaak meer problemen. En extra zaken waar tijd naar toe moet, wil men eigenlijk liever niet. Als het je lukt je positie goed neer te zetten, zal je waardering en aandacht vinden. Maar, al of niet humoristisch bedoeld, opmerkingen als: "Oh je, daar heb je hem/haar weer" zal je zeker ook horen. En als je het evenwicht nog niet gevonden hebt, kan het vijand deel ook nog eens de boventoon gaan voeren. Meer zijn dan puur alleen tester is niet altijd makkelijk. Maar als het je lukt, heb je er, ondanks de regelmatige gevoelens van onwil, toch al snel heel veel vrienden bij.

Bepalen van testcases bij testautomatisering

Ik heb al aardig wat testautomatisering gedaan, maar ik blijf het een puzzel vinden: hoe bepaal je de indeling van de testcases bij testautomatisering? Hoe onafhankelijk van elkaar moeten ze zijn? Wat is de maximale tijdsduur van een testcase? En hoe uitgebreid wil je testen in een geautomatiseerde testcase? Wat is belangrijker: meer testen in 1 testcase of de tijdsduur van een testcase korter houden?

Als alle testcases na bouwen probleemloos zouden draaien, zou je ze zo lang kunnen maken als je wil. Maar dan zouden ze tegelijkertijd zinloos zijn. Geautomatiseerde testen zullen falen. Omdat er een fout is ontstaan of omdat de applicatie is aangepast. Daarom gaat het niet alleen om de ideale testcases voor je testuitvoering, maar ook om de onderhoudbaarheid van de geautomatiseerde testset.

Tegelijkertijd wil je meer doen dan alleen maar hele kleine testen uitvoeren. Je wil een keten van handelingen testen. Iets invoeren en daarna weer opvragen. Of weten of je applicatie goed werkt van stap A naar stap B naar stap C. Dat vraagt om langere testcases of misschien zelfs wel op testcases, die elkaar opvolgen.

Maar hoe kom je nu tot een goed evenwicht?

Tijdsduur

Voor de onderhoudbaarheid van een testcase, is het verstandig dat de tijdsduur niet te lang is. Als een testcase faalt, moet je hem opnieuw kunnen draaien en volledig kunnen volgen. En daarna weer opnieuw kunnen draaien en opnieuw en opnieuw en opnieuw. Om dit goed te ondersteunen, is mijn eerste streven altijd om elke testcase uiterlijk rond de 5 minuten te laten duren. Als hierin echt te weinig getest kan worden, heb ik wel de keuze gemaakt om uit te breiden naar 10 minuten. Maar langere testcases zijn niet goed onderhoudbaar, omdat dit te lang duurt om ook je aandacht er goed bij te houden.

Onafhankelijkheid

De ideale situatie is een test, die altijd kan draaien, onafhankelijk van welke testcase dan ook. Maar zeker als je een hele keten wil testen, ga je al snel over de 10 minuten heen. Toch moet het streven blijven om de testcases zo onafhankelijk mogelijk te laten draaien. Ik houd hierbij het volgende streven aan: als er voorbereidende testcases zijn, is het nodig om deze 1 keer uit te voeren. Hierna kan de testcase oneindig herhaalt worden, zonder nieuwe voorbereiding.

Als ik de tijdsduur niet in kan schatten, begin ik met mijn ideaal: alles in 1 testcase. Wanneer de test dan te lang blijkt, ga ik na welke onderdelen ik los kan testen. Zo kan, na het aanmaken van bijvoorbeeld een werknemer, de controle van de werknemer in een andere testcase geplaatst worden. Ook het gebruiken van de werknemer in andere schermen kan in andere, losse testcases.

Als er een keten is, dan kan deze vaak opgesplitst worden per menu-item. Dit klinkt misschien als een vreemde indeling, maar het openen van een ander scherm via een menu-item geeft vaak een duidelijke nieuwe stap in de keten aan. Terwijl de handelingen, die je uitvoert, voordat je het menu weer gebruikt, vaak sterk met elkaar gerelateerd zijn.

Testdekking

Het liefst test ik alle velden van alle schermen in 1 testcase. Maar hoe groter de schermen en hoe meer schermen, des te moeilijker dit wordt. Maar tegelijkertijd wil je niet een ongelofelijke hoeveelheid testcases, waarvan je niet meer weet welke testcases wat test. Daarom heb ik in de loop van de tijd bepaalde standaarden ontwikkeld:

Testen van een groep gegevens
Een testcase kan gericht worden op het opslaan en tonen van alle gegevens in een bepaalde groep op je scherm. Door alle gegevens van een groep in dezelfde testcase te testen, houd je de testcases beter onderhoudbaar.

Testen van onderlinge relaties van gegevens
Bij voorkeur test ik groepen van gegevens samen, als ze een onderlinge relatie hebben. Denk hierbij aan velden, die gevuld worden op basis van ingevoerde gegeven. Of denk aan velden, die verdwijnen en verschijnen n.a.v. bepaalde keuzen. Maar als dit teveel wordt, bijvoorbeeld omdat groepen teveel relaties hebben, splits ik ze op in verschillende testcases. De invoer kan dan beperkt worden tot de gegevens invoer, die effect heeft op een andere groep. Of de in te voeren groepen kunnen beperkt worden tot 2 en de test is volledig gericht op het testen van de relatie tussen deze twee groepen.

Testen gericht op specifieke controles
Bepaalde controles kunnen los getest worden. Neem bijvoorbeeld het wel of niet verschijnen van bepaalde velden. Of de aangeboden keuzes in een selectiedialoog. Als deze controles belangrijk zijn, maar in een scherm aardig wat tijd vragen om te testen, kan je ze lostrekken in een nieuwe testcase. Door deze testcase helemaal op deze controle te richten en ook in andere schermen deze controles in speciale testcases uit te voeren, houd je wel overzicht op je testcases. Je weet altijd wat er in een testcase getest wordt en wat niet, zonder uitgebreide documentatie na te kijken.

Tijdsbesparing

Er zijn twee keuzes, die je kan maken, om de testcases korter te maken. Deze hebben nadelen en daarom is het verstandig de voor- en nadelen goed te overwegen.

Gebruik van data in een database

Om een volledige keten te testen, maar tegelijkertijd je testen kort en onafhankelijk te houden, kan je ervoor kiezen de "tussenproducten" van een keten alvast beschikbaar te maken in een database. Dit heeft zelfs als extra voordeel, dat je test of de aanpassing ook met bestaande data werkt. Maar een belangrijk nadeel is: je test niet de volledige keten van het begin tot het eind in 1 keer.

Verschillende situaties in 1 test

Als je toch in 4 testcases de medewerkersgegevens invoert, kan je deze meteen gebruiken om wat verschillende situaties te testen: een naam met en een naam zonder tussenvoegsel; een man en een vrouw; een adres in het buitenland en een adres in Nederland. Dit heeft twee risico's: je moet goed weten welke situatie je in welke testcase toevoegt. Dit vraagt om documentatie, al of niet in de code. En daar moet je tijd voor vrijmaken. En als tweede nadeel: als de test faalt, weet je dan nog waardoor? Als een medewerker niet goed wordt opgeslagen en de melding "Het adres is niet correct" verschijnt, komt dit dan door het buitenlandse adres? Of komt dit doordat je een huisnummer toevoeging hebt ingevoerd? Meer situaties in een test kan meer analysetijd tot gevolg hebben, als je test faalt.

En nu van start

Testautomatisering testcases bepalen is een kwestie van oefenen, uitproberen en later aanpassen. Houd vooral de tijdsduur van een testcase in de gaten. Naar mijn mening gaat de tijdsduur boven de onafhankelijkheid. Maar houd bij voorkeur je testcase zo, dat deze achter elkaar meerdere keren uitgevoerd kan worden. Bepaal een goede indeling van je testcases qua testdekking. En houd deze over al je testen aan. Eventueel kan je je testcases gebruik laten maken van bestaande data in de database. En ook het testen van meerdere situaties in een testcase is een optie.

Maar ga vooral gerust aan de gang. Als je testcases te groot zijn, kan je ze kleiner maken. En als het er teveel zijn, kan je ze samenvoegen. Ook de indeling van je automatische test is niet gegoten in beton!

De kwaliteit van testen gemeten met de bugs van klanten

Een acceptatietest door een klant is een geaccepteerde en professionele stap in je testproces. Maar het wordt een ander verhaal als je de acceptatietest gaat gebruiken om de echte kwaliteit van het interne testproces te verbergen: "Dit soort fouten zijn aan onze klanten om te vinden". Hoe voorkom je dit? Beoordeel je testproces aan de hand van de bugs, die je klanten terug melden. En kijk zowel naar de bugs uit de acceptatietest, als naar de bugs, die gevonden worden in productie.

Basis indeling

Er zijn drie belangrijke factoren, waaraan je kan zien hoe goed je testproces is, als je naar bugs kijkt:

1. Waar is de bug gevonden?
   Is de bug in de schermen, die de gebruiker (bijna) dagelijks gebruikt? Of is de bug in de schermen, die minder vaak gebruikt worden?
2. Hoe uitzonderlijk is de invoer?
   Is de ingevoerde combinatie van gegevens om de bug te reproduceren iets wat nauwelijks voorkomt? Of is het een combinatie, die (bijna) elke dag opnieuw gebruikt wordt? Let hier wel op: als je 500 producten hebt en het product waarmee je reproduceert is product 371, blijf eerlijk. Als de bug inderdaad op slechts 1 product reproduceerbaar is, is de invoer misschien zeer uitzonderlijk. Maar als je dezelfde bug ook kan reproduceren met 99 andere producten, is de reproduceerbaarheid toch echt een stuk hoger.
3. Hoe eenvoudig is de bug te reproduceren?
   Is de bug reproduceerbaar door gewoon willekeurige gegevens in te voeren? Of moet je bepaalde keuzes maken, om de bug te kunnen reproduceren, zoals een "Ja" kiezen in een combobox of een instelling in een ander instellingen scherm wijzigen?

 Let wel op dat ik hierbij bewust van een bug spreek. Een bug is iets wat niet goed werkt, waarvan iedereen zal zeggen: "Dit is gewoon fout". Dus situaties als "Dit veld hoort eigenlijk voor dat veld" of "De tab volgorde klopt niet" wordt binnen deze blog niet als bug gezien. Natuurlijk verdient dit ook aandacht en zegt het ook wat over je testkwaliteit. Maar als dit de belangrijkste problemen zijn, dan ben je echt al vrij hoog in de testkwaliteit.

Komen tot een tussenoordeel

Op basis van deze drie factoren kan een kwaliteitsschema worden opgesteld. 

Komen tot een eindoordeel

Wat hieronder staat, is mijn voorstel. Maar voel je vrij je eigen indeling te maken.

Kwaliteitsniveau 1Bijna bij elke RFC of story heeft een klantbug, die valt in minimaal 2 categorieën "Laag".

Kwaliteitsniveau 2
Bijna bij elke RFC of story heeft een klantbug, die valt in 1 categorie "Laag".

Kwaliteitsniveau 3
Bijna elke RFC of story heeft een klantbug, die valt in minimaal twee categorieën "Matig".

Kwaliteitsniveau 4
Bijna elke RFC of story heeft een klantbug, die valt in 1 categorie "Matig".


Kwaliteitsniveau 5
Bijna geen RFC of story heeft een klantbug in de categorie "Laag"

Kwaliteitsnviveau 6Bijna geen RFC of story heeft een klantbug in de categorie "Matig"

De kritische punten

De overlap
Ik besef dat de categorieën soms overlap hebben. Als een gegevenscombinatie dagelijks wordt ingevoerd, zal dit bijna altijd zijn in een scherm dat dagelijks gebruikt wordt. Dit kan misschien niet eerlijk lijken. Maar juist de schermen, die zo vaak gebruikt worden en waarin steeds dezelfde gegevenscombinaties ingevoerd worden, moeten ook minimaal op deze wijze getest worden. Als je in de meest gebruikte schermen niet de meest gebruikte gegevenscombinaties test, dan heb je echt je testproces niet op orde. En dat geldt ook voor andere overlap, die je kan bedenken. Juist dit zijn testen, die gewoon standaard uitgevoerd moeten worden.

Dit is toch niet nodig?
Er zijn al zoveel manieren om het kwaliteitsniveau te meten. Waarom zou je zoveel tijd steken in het meten op basis van bugs van klanten? Het zou ook niet nodig moeten zijn. Maar ik heb te vaak meegemaakt dat de kwaliteit van het product afgeschoven wordt op de klanten: "Dat moet de klant testen" of nog erger "Had de klant maar beter moeten testen, voor we naar productie gingen". Meestal gaat dit gepaard met ontevreden klanten, een slechte samenwerking met de klant en weinig vertrouwen van de klant in het bedrijf en product. Tenzij dit is wat je wil, kan het zeer verstandig zijn om bij bovenstaande beweringen eens goed na te gaan of je van je klant niet teveel testwerk verwacht.

In het kort

Het belangrjjkste is goed te kijken naar de bugs, die klanten melden. Hoe simpel was het om deze in een test te vinden. De volgende criteria kunnen hierbij een houvast zijn:

1. Waar is de bug gevonden?
2. Hoe uitzonderlijk is de invoer?
3. Hoe eenvoudig is de bug te reproduceren?

Hoe makkelijker en vaker de bugs voorkomen, hoe slechter de kwaliteit van je testproces. Gebeurt dit regelmatig, dan kan het zeer verstandig zijn een kwaliteitsschema op te stellen als hierboven, om de kwaliteit te controleren en te verbeteren. Maak gerust je eigen schema. Het belangrijkste doel is tenslotte: je interne testproces moet zo goed zijn, dat je klant tevreden is over de kwaliteit. Maar niet slechts de eindkwaliteit. Nee, ook de kwaliteit van het eerste product, dat de klant zal testen.

Het verschil tussen het testen van specificaties en het testen van kwaliteit

De software voldoet aan de vastgestelde specificaties. Maar toch zijn de klanten ontevreden. Niet omdat ze wat anders hadden gewenst, dat is een ander onderwerp. Nee, omdat de software gewoon niet goed werkt. De kwaliteit is niet voldoende. Misschien kent niet elke tester deze situatie, maar hij komt zeker voor. De situatie van een test die 100% slaagt, maar de werkelijke kwaliteit niet kan constateren.

Wat je hier tegenkomt is vaak het verschil tussen het testen van specificaties en het testen van de kwaliteit. Bij het testen van de specificaties is datgene wat letterlijk op papier is gezet ook getest. En dat werkt. De tester heeft het goedgekeurd en de klant heeft het goedgekeurd. Wat niet is getest, is datgene wat niet op papier is gezet. Maar wat achteraf toch van belang blijkt te zijn.

Nu kan je als tester zeggen: "Tja, dan had je het maar in de specificaties moeten opnemen". Maar een echte Agile tester weet dat dit niet terecht is. Het is juist de bedoeling om de hele grote, volledig uitgeschreven documenten terug te brengen. Juist omdat deze uitgebreide documenten misschien wel volledig waren, maar net zo min correct. En zeker niet geschikt om flexibel te wijzigen. Waar dit probleem nu veroorzaakt wordt door iets wat niet in de specificaties stond, werden dit soort problemen daarvoor veroorzaakt doordat informatie anders of zelfs tegenstrijdig in de specificaties stond. Of omdat mondelinge overleggen allang de officiële specificaties hadden gewijzigd, maar die informatie weer niet goed was vastgelegd.

Natuurlijk zijn er grenzen aan wat  je kan testen, als het niet is vastgelegd. Maar naar mijn mening moet je juist als Agile tester (waar iedereen verantwoordelijk is voor het volledige eindproduct) je verantwoordelijk voelen voor de kwaliteit, ongeacht of deze automatisch volgt uit de specificaties of niet.

Wat staat er dan niet in de specificaties?
Specificaties beschrijven meestal minimaal wat de klant of wat het bedrijf zelf wil, gedacht vanuit de verschillen tussen de huidige situatie en de nieuwe, gewenste situatie. Wat staat er dan niet altijd beschreven? Wat maakt het verschil tussen de specificaties en de kwaliteit?

1. Standaard functies
   Knoppen als Nieuw, Opslaan, Verwijderen en Annuleren hebben functionaliteit, die vaak als bekend wordt beschouwd. Ze kunnen dan ook in specificaties afgedaan worden met: De knop X is aanwezig. Als ze al genoemd worden. Maar elk van deze knoppen heeft zijn eigen specifieke testen, om na te gaan of ze goed werken. En dat moet ook getest worden, ongeacht of dit officieel vermeldt staat.
   
2. Foutafhandeling
   Hoe de wijziging moet werken staat meestal wel goed beschreven. Wat de applicatie moet doen, als de gebruiker iets fout doet, niet altijd. Dit is echter ook belangrijk. Het opvangen van foute invoer of verkeerde handelingen, inclusief testen op goede en duidelijke foutmeldingen, kan een heleboel problemen bij de gebruiker voorkomen.
   
3. Andere schermen met dezelfde functionaliteit
   De wijziging wordt vaak beschreven vanuit een bepaald scherm, namelijk het scherm waar de wijziging gewenst is. Maar met grote regelmaat komt dezelfde functionaliteit ook in andere schermen voor. Zo kan het aanmaken van een werknemer bij het invoeren van een contract beschreven worden. Tegelijkertijd wordt een werknemer ook aangemaakt in een algemeen onderhoudsscherm voor werknemers. Als voor het contract bij de werknemer extra gegevens worden toegevoegd, moeten deze ook in het algemene onderhoudsscherm worden toegevoegd. Dus is de vraag: heeft de beschreven wijziging effect op soortgelijke functionaliteit in andere schermen?
   
4. Andere varianten van dezelfde businessrules
   Je businessrules kunnen soms heel ingewikkeld worden. Een beroemd en berucht voorbeeld hiervan is de berekening van een totaalbedrag in de factuur. Er kunnen heel veel varianten zijn om tot een bepaald bedrag te komen, afhankelijk van instellingen en ingevoerde gegevens. Als hier een wijziging wordt voorgesteld, kan dit effect hebben op de andere varianten. Het kan zijn dat een situatie een uitzondering moet zijn op de nieuwe regel. Het kan zelfs zijn dat een andere variant niet meer mogelijk is, door de nieuwe wijziging. En je kan gewoon per ongeluk iets kapot maken in de bestaande situaties, door je huidige aanpassing.
   
5. De wijziging in het gehele bedrijfsproces
   Stel je wijzigt het adres door het adres veld op te splitsen in straat en huisnummer. Dit kan een niet zo'n grote wijziging lijken, totdat je verder het gehele bedrijfsproces bekijkt. Dit adres wordt getoond op heel veel rapporten en vaak ook op andere schermen. Bij elke wijziging is het daarom van belang, zeker als je gegevens wijzigt, na te gaan of deze wijziging ook effect heeft op stappen verderop in het proces.

Ervaren testers kunnen waarschijnlijk nog meer groepen noemen. Maar op basis van mijn ervaring zijn dit de meest belangrijke.

Test kwaliteit, niet specificaties

Probeer altijd als een testers te helpen bij het opleveren van een goed product en kijk daarom niet alleen naar de specificaties. Kijk of de wijziging effect heeft of zou moeten hebben op niet genoemde onderdelen in de applicatie. En kijk of je meer moet testen, dan er letterlijk beschreven staat. Dit zal niet altijd makkelijk zijn, maar enkel al het streven kan een hele grote verbetering zijn.

Testen van een "Kopieer data" functie, niet zo simpel als het lijkt

Snel data invoeren. Met grote regelmaat wordt hier een kopieer functie voor gebruikt. Kopieer een al eerder ingevoerd record. Waarom is dit niet simpel te testen? Technisch blijkt dit vaak vrij ingewikkeld, door alle verschillende koppelingen en tabellen. Maar in de specificaties is het regelmatig 1 zin: "Kopieer alle data in een nieuw record". Zo wordt het vaak niet gebouwd. Door technische beperkingen of door slechte controle door de ontwikkelaar (oh ja, dat veld moet ook). En dat maakt het zo'n lastige functie om te testen. De beschrijving klopt bijna nooit, maar de gevolgen van fouten kunnen wel heel groot zijn.

De basistest

De basis voor het testen van een "Kopieer data" functie is heel simpel: Vul alle velden met een andere waarde, dan de waarde die standaard gekozen wordt. En vul alle tabellen met minimaal twee records. Controleer vervolgens of al deze gegevens goed overkomen bij het kopiëren.

De kwaliteit van de kopie

Hoewel bijna elke "Kopieer data" wordt omschreven als het kopiëren van alle data, maak je hier een gebruiker bijna nooit blij mee. Als je hiermee al niet een onwerkbaar record creëert. En daarnaast geeft het niet goed aan waar je als tester op moet letten. Om dit uit te leggen, val ik in de titels een beetje terug op database termen, maar ik zal elke onderdeel toelichten aan de hand van een voorbeeld gebaseerd op een werknemer.

Primary key

Bijna altijd als je data kopieert, is er sprake van een unieke waarde per record. Bij een werknemer is dit vaak een werknemersnummer. Deze unieke waarde mag NOOIT letterlijk gekopieerd worden. Het mag leeg zijn, tot het moment van opslaan. Het mag opnieuw bepaald zijn. Maar controleer of de waarde in dit veld nog steeds een unieke waarde is en niet gelijk aan de oorspronkelijke kopie. Zeker als het veld ook nog eens niet gewijzigd mag worden, wat vaak het geval zal zijn.

N:N relatie

In bijna elk datarecord kan je data invoeren, die terugkomt in andere soortgelijke datarecords. Denk bijvoorbeeld aan de bedrijfsmiddelen, die een werknemer tot zijn beschikking krijgt. Dit kan een tabel in je scherm zijn, waarin je kan zien dat de betreffende werknemer een telefoon, een laptop en een sleutel tot het kantoorpand heeft gekregen. Maar deze keuzes zullen bij veel andere werknemers ook terugkomen. Ga goed na of deze gekopieerd worden (altijd minimaal 2 rijen in een tabel). En als dit niet het geval is, ga na of dit een bewuste, goed doordachte keuze is.

1:N relatie
Bepaalde data in tabellen is uniek voor dat betreffende datarecord. Er is echt wel meer van deze invoer, maar elke invoer is uniek voor dat datarecord. Denk hierbij aan een contract. Je kan als werknemer aansluitend meerdere contracten hebben. Maar dat contract zal slechts gekoppeld zijn aan 1 werknemer. Over het algemeen is dit data die je niet wil mee kopiëren. De gegevens zijn per werknemer zo verschillend, dat de invoer toch overnieuw moet.

Maar als het toch meegekopieerd wordt, controleer dan zeer goed of er echt sprake is van nieuw aangemaakte data. En controleer deze extra data op precies dezelfde manier als je het datarecord zelf controleert. Controleer op de primary keys en op de verschillende relaties. En vul ook hier alle velden in en vul alle tabellen met minimaal twee rijen. Als dit soort data meegekopieerd wordt, is dit een plaats waar het vaak misgaat. Omdat juist aan dit deel vaak minder aandacht wordt besteed, dan aan het oorspronkelijke datarecord.

N:1 relaties
Bovenstaande twee relatie beschrijvingen gingen over tabellen. Maar je hebt ook regelmatig comboboxen of andere manieren van selecteren, waarbij je kiest uit een standaard lijst met keuzes. Denk aan de functie van een werknemer of een manager van een werknemer. Het testen hiervan is niet zo moeilijk. Maar bij het testen zal je merken, dat hier regelmatig een veld zal missen. Al of niet om de kopie technischer makkelijk te bouwen. Besteed hier dus wel aandacht aan en vraag na waarom een veld niet gekopieerd wordt.

Speciale situaties

Bij elkaar horende gegevens

Om het kopiëren technisch eenvoudiger te maken, worden vaak besluiten genomen om bepaalde data niet in de kopie op te nemen. Dit kan, maar let wel of het eindresultaat nog genoeg kwaliteit heeft. Het gebeurt regelmatig dat gegevens eigenlijk bij elkaar horen. Als een deel hiervan wel en een deel hiervan niet gekopieerd wordt, kunnen vreemde situaties ontstaan.

Denk bij een werknemer aan de bankgegevens. Het rekeningnummer is eenvoudig gekopieerd en gaat vaak mee. Terwijl elke werknemer eigenlijk een uniek rekeningnummer heeft, dus kopiëren heeft geen waarde. De bank kan echter een combobox zijn, die is overgeslagen. Je krijgt dan de situatie waarin wel het banknummer staat, maar de bank niet wordt ingevoerd. In deze situatie is het verstandiger om alle bankgegevens leeg te laten en niet alleen de bank.

Relatie met zichzelf
Het komt zelden voor, maar het gebeurt wel: bij een van de velden kan je het ingevoerde datarecord zelf invoeren. Een voorbeeld hiervan kan zijn bij de urencontrole. Sommige werknemers mogen hun eigen uren invoeren en bevestigen, anderen moeten hun uren door een ander laten bevestigen. Bij de eerste groep kan dan in het veld "Controleur uren" de werknemer zelf worden ingevoerd.

Hoe weinig dit ook voorkomt, dit zijn heel gevaarlijke velden bij een kopieer test. Want de waarde, die hier staat, is te vaak de waarde van het oorspronkelijke datarecord, waar de kopie op gebaseerd is. Test dit daarom goed. Zo'n veld moet bij het kopiëren leeg zijn of moet al bij het aanmaken naar zichzelf verwijzen. Hier zal je speciaal op moeten testen. Doe dat ook!

Samenvatting

Dus hoe test je een "Kopieer data" functie?

• Voer alle gegevens in en vul alle tabellen met twee rijen
• Controleer goed of de primary key niet wordt gekopieerd en of de gekopieerde relaties de juiste kwaliteit hebben
• Controleer of bij elkaar horende gegevens allemaal wel of allemaal niet gekopieerd worden
• Controleer extra op velden waarin het datarecord zelf als keuze kan worden ingevoerd

Waar het op neer komt, is dat je juist bij een functie als deze niet zozeer controleert of het volgens specificaties is. Maar controleer of de kwaliteit van de gebouwde functie goed is.

Testen in een Agile team: "Vertrouw niemand, maar vertrouw iedereen"

Als tester is het je taak om alles en iedereen te controleren. Er niet vanuit te gaan dat iemand altijd goed werk levert. Als Agile teamlid is het je taak om je team te vertrouwen. Ervan uit te gaan dat iedereen altijd goed werk wil leveren. Hoe werk je binnen deze tegenstrijdigheid? Wanneer vertrouw je iemand en wanneer niet?

Het woord "Vertrouwen" is wel veelgebruikt, maar niet altijd in dezelfde betekenis. Je kan er bijvoorbeeld op vertrouwen, dat iemand altijd voor je klaar staat. Maar tegelijkertijd er niet op vertrouwen, dat deze persoon goede code oplevert. Het belangrijkste vertrouwen van een tester is gericht op het opleveren van goed werk. En dan maakt het niet uit of dit een deel van de applicatie of een document is.

Zelf kom ik tot een lijst van drie manieren van vertrouwen, die voor een tester van belang zijn:

1. Het vertrouwen dat iemand goed werk oplevert
2. Het vertrouwen dat iemand goed werk WIL opleveren
3. Het vertrouwen dat iemand goed werk KAN opleveren

Het vertrouwen dat iemand goed werk oplevert

Wat moet je hierover aan een tester uitleggen? Het werk van een tester is controleren. Controleren of een ontwikkelaar goed werk heeft geleverd. Controleren of de specificaties goed zijn opgeleverd. Dus zelfs als je dit vertrouwen hebt, moet je handelen alsof je het vertrouwen niet hebt.

Het vertrouwen dat iemand goed werk wil opleveren

Een Agile team kan alleen goed werken als de teamleden elkaar vertrouwen. Maar als je er niet op mag vertrouwen, dat iemand goed werk oplevert, waar vertrouw je dan op binnen een team? Simpel: je vertrouwt erop dat iemand goed werk wil opleveren. Dat er niemand in het team als doel wil hebben om een slecht product op te leveren. Dat iedereen in het team er alles aan doet om het product zo goed op te leveren als mogelijk is. Als het niet lukt, vertrouw je erop dat hier redenen voor zijn. Redenen, die in de ogen van de ander goed zijn. Of anders oorzaken, die een ander niet wist bij het maken van het eindproduct. Dit vertrouwen is centraal, zonder dat kan een Agile team geen team zijn. Dus zelfs als je dit vertrouwen niet hebt, moet je doen alsof je het vertouwen wel hebt.

Dit is echter niet zo simpel als bij het vorige onderwerp. Niet alleen is het vaak moeilijk op te brengen, zelfs als je het hebt is het soms moeilijk te bewijzen aan de ander. Want hoe toon je het vertrouwen dat iemand goed werk wil opleveren?

Het antwoord ligt in je woordgebruik. Voorkom zinnen als "Je bent fout", "Je hebt je vergist", "Je hebt slecht werk geleverd". En vervang ze door zinnen als "Ik snap niet waarom", "Kan je me uitleggen waarom". Combineer dit bij voorkeur met een compliment als "Ik zie dit soort fouten anders niet bij je", "Ik weet dat je X ook belangrijk vind", "Ik weet dat je een goede X bent". En daarna: luisteren, doorvragen, luisteren, doorvragen. Net zo lang tot je het besluit begrijpt. Je hoeft het er nog steeds niet mee eens te zijn, maar zorg ervoor dat je het begrijpt. En als je het begrijpt, maar nog niet overtuigd bent, dan is het moment om te vertellen wat jij had gewild. En vergeet dan ook vooral niet te vertellen waarom.

Centraal staat een positieve benadering, waarbij de wil om goed werk te leveren niet ter discussie wordt gesteld. Wat wel ter discussie wordt gesteld is het resultaat en het proces naar het resultaat. Maar het vertrouwen blijft onbesproken en daarmee overeind. Uit eigen ervaring kan ik je vertellen: je zal vaker overtuigd worden, dan je van tevoren verwacht.

Het vertrouwen dat iemand goed werk kan opleveren

Soms wil je wel, maar kan je niet geloven dat iemand goed werk op wil leveren. Want als hij het wil en hij kan het, waarom gebeurt het dan niet? Om het makkelijker te maken, kan het handig zijn om na te gaan of iemand het wel echt kan. Heeft iemand de kennis en vaardigheden om goed werk te leveren? Als je weet dat iemand een junior developer is, is het ook veel logischer als er meer fouten in het opgeleverde werk zitten. En als iemand pas sinds kort aan het product werkt, is het makkelijker te geloven dat deze persoon iets over het hoofd heeft gezien. Maar het gaat hier ook om andere factoren. Wanneer de druk hoog is, bijvoorbeeld door een harde deadline, voelen mensen zich vaak gedwongen stappen over te slaan. Stappen, die de kans op een goed product niet ten goede komen.  Als mensen een opdracht hebben gekregen, die tegenstrijdig is met een goed product, bijvoorbeeld "Doe gewoon wat er staat", kan dit ook de kwaliteit niet ten goede komen.

Het vertrouwen dat iemand goed werk op kan leveren kan dus terecht zijn, maar er kunnen zaken spelen die je niet weet. Zaken waardoor een persoon nog moet leren hoe je goed werk oplevert, zich gedwongen voelt slechter werk op te leveren of misschien zelfs andere prioriteiten heeft. Deze zaken weten, maakt het makkelijker een persoon te begrijpen. Waar het op neerkomt, is dat je weet hoe je teamleden aankijken tegen organisatie en werk. Hoe lang ze werken in hun functie, in het bedrijf en in het team. En tegen welke problemen ze aanlopen. Hier interesse in tonen geeft anderen al meer het gevoel dat je echt deel van het team wil zijn. Maar daarnaast kan jij ook hopelijk beter begrijpen, wat er speelt, als het werk niet het gewenste niveau heeft. En dat kan flink schelen in emoties, als je onverwachts slecht werk onder ogen krijgt.

Testdata management als al je klanten anders zijn

De testdata beschikbaar in de database is belangrijk. Zowel om je testen betrouwbaar, als om je testen reproduceerbaar te houden. Als je slechts 1 klant heb, kan je de data van deze klant eenvoudig als basis gebruiken. Als je klanten veel overeenkomsten hebben, kan je de deze overeenkomsten als basis gebruiken. Maar wat als al je klanten uniek zijn? Door een applicatie met een oneindig aantal mogelijkheden? Hoe kom je dan tot een basis?

Bepaal de datagroepen

De testdata is te verdelen in vier groepen. Elke groep vraagt een andere aanpak. Het is daarom van belang om eerst goed te beseffen welke data in welke groep hoort.

De gebruikersdata met regelmatig onderhoud
Het aanmaken van opdrachten of het opstellen van een planning. Het zijn werkzaamheden die regelmatig plaatsvinden. Aan de data van deze groep wordt minimaal een keer per week wel data toegevoegd, data gewijzigd en data verwijderd. Ze bevinden zich vaak in de hoofdprocessen van de applicatie, juist door hun regelmatige gebruik. En het is daarom ook van groot belang dat juist deze processen altijd goed blijven werken, ongeacht wat de gebruiker invoert.

De gebruikersdata met incidenteel onderhoud
Voor deze groep is het moeilijker om voorbeelden te geven. Waar het ene bedrijf een vaste groep klanten heeft, waardoor deze nauwelijks onderhouden worden, zal het andere bedrijf elke dag klanten toevoegen, wijzigen of verwijderen. Waar het ene bedrijf een vaste groep producten heeft, zal een ander bedrijf bijna elke week de producten moeten onderhouden. Maar het gaat hier om data die door de gebruikers van de applicatie zelden ingevoerd worden. Mocht er zich een probleem voordoen, is dat zeker lastig, maar een probleem in deze groep zal niet snel blokkerend zijn voor het gebruik van de applicatie.

De systeemmanagementdata met regelmatig onderhoud
Een systeembeheerder, applicatiebeheerder of iemand anders in een soortgelijke functie kan vaak data invoeren, waar andere gebruikers niet zomaar bij kunnen. Hierbij gaat het om zaken als modules, parameters, instellingen en gebruikersrechten. Hoewel ook hier het onderscheid tussen regelmatig en incidenteel van belang is, liggen de periodes wel anders. De data met regelmatig onderhoud in deze groep, kan rustig een keer in de paar maanden zijn. Het is data, die gebruikt wordt om de processen te optimaliseren. Of data die gebruikt wordt om een bedrijf te laten groeien of inkrimpen. Of misschien data, die gebruikt wordt om processen aan de wensen van klanten of andere belangrijke partijen aan de passen. Denk hierbij aan de velden, die je op je scherm ziet. Dit kan voor iedereen slechts eenmalig ingesteld worden. Maar er kan ook behoefte zijn om hierin flexibel te zijn, zodat het scherm niet het werkproces bepaald, maar het werkproces het scherm. En je regelmatig kan kijken of de huidige indeling nog naar tevredenheid is.

De systeemmanagementdata met incidenteel onderhoud
In de meeste gevallen is dit data die na installatie eenmaal wordt ingevoerd en daarna (bijna) nooit meer wordt aangepast. De ingevoerde data is de werkelijkheid en daar kan vaak ook niet van afgeweken worden. Bijvoorbeeld door regels, wetten of voorschriften. Of omdat aanpassingen niet alleen vraagt om een aanpassing in data, maar ook vraagt om een hele andere werkwijze of proces. Of men besluit natuurlijk gewoon dat de huidige situatie voldoet, waardoor er geen behoefte is aan aanpassing. Een typisch voorbeeld hiervan is de modules, die in een applicatie staan ingesteld. Dit wordt vooral bij installatie bepaald en zal daarna nauwelijks meer wijzigen.

Bepaal de data

De gebruikersdata met regelmatig onderhoud
Het onderhouden van deze data is zo belangrijk, dat het verstandig is weinig gebruik te maken van testdata in de database. Juist om zoveel mogelijk varianten in onderhoud te testen, maak je de data zoveel mogelijk keer op keer opnieuw aan. Gebruik makend van je kennis, ervaring of testtechnieken kan je bepalen wat er nodig is. Om tijd te besparen bij handmatig testen of om een automatische test niet te lang te maken, kan het toch verstandig zijn om wat data beschikbaar te hebben. Deze data is dan het gevolg van opgestelde testcases en kan dan ook volgens deze criteria in de database worden opgenomen.

De gebruikersdata met incidenteel onderhoud
Omdat het niet altijd belangrijk is dit in de test mee te nemen, is het wel verstandig hiervoor een goede set in je database te krijgen. Wat hiervoor van belang is, is dat je weet welke data effect heeft op de andere gebruikersdata of hun bijbehorende schermen. Een logische gedachte is een relatie waar instellingen ingevoerd kunnen worden hoe de factuur eruit moet zien. Maar denk ook aan verschillende varianten in namen, zoals wel of geen tussenvoegsels en de keuze tussen Dhr. of Mevr. Als deze belangrijke varianten in je database voorkomen, kan je snel en flexibel testen.

De systeemdata met regelmatig onderhoud
Deze data hoort eigenlijk niet te bepalen hoe de database bepaalt wordt, maar vooral hoeveel testdatabases je eigenlijk tot je beschikking wilt hebben. De redenering rond deze data is eigenlijk gelijk aan de redenering rond gebruikersdata met incidenteel onderhoud. Dus als dit mogelijk is, kies voor verschillende varianten. Maar systeemdata is vaak maar op 1 plek in te stellen, waardoor het niet mogelijk is deze varianten toe te voegen. De varianten zijn echter zo belangrijk, dat je ze uitgebreid mee wil testen, zonder steeds veel tijd aan voorbereiding kwijt te zijn. De meest verstandige keuze is daarom hiervoor meerdere databases te maken. B.v. per belangrijke groep klanten (overheid of particulier) of grootte van de klant (veel of weinig medewerkers). Mocht dit niet mogelijk zijn, zal je geen keus hebben om de voorbereiding toch in je testcases te doen.

De systeemdata met weinig onderhoud
Hier gaat het vooral om het neerzetten van een goede basis. Belangrijke variaties in deze instellingen, zoals de keuze of een veld wel of niet verplicht is, moeten worden opgevangen als aanpassingen/voorbereidingen in je testcases. Maar de basis moet zoveel mogelijk voldoen aan de instellingen van zoveel mogelijk klanten. Noem het de database van de "gemiddelde klant". De instellingen, die het meest gebruikt worden. De waardes, die het meest ingevoerd worden. Dit zorgt ervoor dat, als het werkt, de kans ook het grootste is dat het werkt voor het grootste deel van je klanten.

Het vervolg

Besef dat dit onderwerp altijd aandacht blijft vereisen. Je klanten veranderen, je applicatie verandert, je bedrijf verandert. Dit is dan ook geen eenmalige actie, waarna je er nooit meer bij stil hoeft te staan. Als je je testen uitvoert, blijf dan regelmatig stilstaan of je data nog voldoet. Als de applicatie wordt uitgebreid of aangepast, kijk of de data in de huidige database nog steeds alle groepen goed afdekt. En besef ook dat je de eerste keer vergissingen kan maken, hoe zeer je ook je best doet. Blijf hier aandacht aan besteden en blijf er goed over nadenken. Zodat jouw testdata in de database je optimaal blijven ondersteunen bij je testen.