Helaas zie ik nog maar al te vaak 'draken' van testontwerpen voorbij komen in mijn vak. Zo’n testontwerp is vaak ontstaan door grote delen uit een functioneel ontwerp middels een testtechniek anders op te schrijven in logische testgevallen.
Hierna wordt er met behulp van de aangemaakte fysieke data een fysiek testontwerp gemaakt dat beschrijft in welk veld op het scherm welke waarde dient te staan uit de verzameling testdata, welke knoppen er ingedrukt moeten worden en/of welke jobs er gestart moeten worden. Dit levert enorme testontwerpen op waarvoor urenlang wordt gespecificeerd. Daaropvolgend is er nog het onderhoud, want bij wijzigingen in bijvoorbeeld het datamodel, de schermopbouw, de functionaliteit, et cetera moet het testontwerp aangepast worden. En dat terwijl de testuitvoering vaak in slechts een fractie van de tijd is volbracht.
Gestructureerd testen
Het zo uitgebreid opschrijven van datgene wat je zou willen gaan testen en controleren, wordt helaas vaak verward met gestructureerd testen. De definitie van gestructureerd testen: ‘Gestructureerd testen onderscheidt zich van de normale testomschrijving door een planmatige aanpak en het gebruik maken van informatie die gaandeweg het proces beschikbaar komt ten behoeve van de optimalisatie van het eigenlijke testproces.’ Er wordt dus met geen woord gerept over hoe, hoeveel en hoe uitgebreid de testgevallen vastgelegd dienen te worden. En het gebruik maken van informatie die tijdens het proces beschikbaar komt, is juist met zo’n uitgebreide beschrijving een erg tijdrovende activiteit.
Een van de argumenten of soms zelfs uitgangspunten om een en ander zo uitgebreid te noteren is dat ‘je zo iemand van de straat moet kunnen plukken die de testgevallen dan ook moet kunnen uitvoeren.’ Waarom? Waarom zouden we dan minimaal hbo-geschoold personeel vragen als testers? En wanneer gaan we dan daadwerkelijk eens iemand van de straat plukken?
Overdraagbaarheid
Een andere veel gehoorde reden voor deze uitgebreide notatiewijze is de behoefte aan overdraagbaarheid. Stel dat je op een dag als tester een dergelijk mooi volledig uitgeschreven testontwerp van collega Harry op schoot krijgt met het verzoek de testen uit te voeren. Want Harry is daadwerkelijk voor de spreekwoordelijke bus gekomen en zal een paar weken afwezig zijn. Je begint vol goede moed met het uitvoeren van de tests en al snel dient zich het eerste verschil aan tussen de resultaten op je scherm en Harry’s resultaatvoorspelling. Een bevinding aanmaken dan maar? Na nog een aantal van dergelijke constateringen heb je alle tests uitgevoerd. Dan nu de hamvraag, is dit stuk software van goede kwaliteit?
Stel dat u van iemand een uitgebreid stappenplan zou ontvangen hoe een auto te bouwen. U heeft verder nauwelijks kennis van auto’s, maar gaat vol enthousiasme aan de slag. Na een lange periode van noeste arbeid is de auto klaar. En asjemenou, het lijkt ook daadwerkelijk op een auto. Daarna vraagt iemand of de auto ook rijdt… En remt… En een topsnelheid van 185 km/h heeft… Wat zijn de antwoorden? Hierover valt uiteraard niets te zeggen, omdat de kennis van auto’s bouwen (hopelijk) zit bij degene die u de beschrijving heeft gegeven.
Hoe dan wel?
De wens is uiteraard duidelijk en logisch. Het is prettig als testers werk van elkaar kunnen overnemen. En niet alleen in verband met busongelukken, maar in het algemeen ten faveure van de flexibiliteit van het testteam en het in kunnen spelen op veranderingen in planning en werkaanbod. De sleutel hiertoe is kennis. Kennis van het gehele systeem ofwel een groot deel daarvan, globaal en vervolgens ook in detail. Zodoende kun je als tester direct of met een korte duik in de details een te testen component oppakken zonder een uitgebreid testontwerp tot je beschikking te hebben en daarnaast ook daadwerkelijk een gerichte uitspraak over de kwaliteit te doen aan het einde van de test. Omdat je kennis hebt. Omdat je weet wat die component moet doen, omdat je weet wat er belangrijk is, waar de input vandaan komt en waar de output naartoe gaat. Omdat je weet op welke plekken het ontwerp wellicht onvolledig of onjuist is, of wanneer een bevinding wellicht onterecht is. En indien niet, wat de zwaarte en prioriteit van die bevinding is.
Tijdswinst
Er is een heleboel tijdswinst te behalen met het minderen van het uitwerken van de testgevallen. Geen fysiek testontwerp, of wellicht een zeer beknopte versie met alleen de relevante gegevens. Of verzoeken of de ontwerper bijvoorbeeld standaard een dataflow aanlevert. Of vooraf schrijf je niets op en gaat aan de slag zodra de software is opgeleverd met het ontwerp op schoot en je legt vast wat je doet, of gebruikt tooling om je test op te laten nemen. Bedenk dat het beknopter en efficiënter vastleggen van je testgevallen ook bespaart op het onderhoud en voorkomt dat je testontwerpen hebt met achterstallig onderhoud vanwege tijdgebrek.
De geboekte tijdswinst laat je door testers gebruiken om het systeem te leren kennen. Het lezen van use cases, functionele ontwerpen, globale ontwerpen, interfacebeschrijvingen, handleidingen, gesprekken met gebruikers en functioneel beheerders en het datamodel zijn nuttige exercities. Hierdoor neemt de kennis van het systeem in zeer hoog tempo toe, worden daaropvolgende tests kwalitatief beter, de overdraagbaarheid hoger en de toegevoegde waarde van testers in het ontwikkelteam vergroot.
