Het vakgebied ‘testen’ is niet meer weg te denken in de huidige ict-wereld. Dat is goed nieuws, we willen immers de beste software aan onze klanten leveren. Er leven wel verschillende gedachten over wat testen eigenlijk is en ook het begrip ‘kwaliteit’ is niet altijd even duidelijk. In dit artikel geef ik mijn mening over de rol die tester moeten hebben bij het bewaken van de kwaliteit.
Vaak wordt ervan uit gegaan dat door te testen de kwaliteit van een softwareproduct verbetert. De vraag: ‘Is het goed getest?’ en het antwoord ‘Ja’ is voor veel organisaties al voldoende om een product aan te schaffen. Daarnaast leeft het idee dat de tester verantwoordelijk is voor de kwaliteit van een softwareproduct. De tester wordt dan gezien als politie agent of douanier die de poort bewaakt naar productie om zo ‘slechte’ producten tegen te houden. Is het echter wel terecht dat de tester verantwoordelijk wordt gemaakt voor de kwaliteit van het softwareproduct?
Kwaliteit is voldoen aan de eisen
Aan ieder systeem worden eisen gesteld en door te testen kan je vaststellen of het product inderdaad voldoet aan deze eisen. In de praktijk zie je vaak dat eisen niet juist blijken te zijn: het is van tevoren niet goed mogelijk om alles te bedenken wat je wilt en een beschrijving van een product op papier kan daardoor anders zijn dan wat er daadwerkelijk gebouwd wordt.
Pas als je het product gebruikt, dan is het duidelijk wat je écht wilde hebben: ‘Deze functionaliteit hadden we tóch anders bedoeld’, is iets wat veel it’ers bekend moet voorkomen. En de testers zijn vaak de eerste die het complete eindproduct zien, dus zij stellen vaak vast dat de requirements onvolledig waren.
Analyseren van eisen (requirements)
Eisen staan aan het begin van een project vaak nog niet in documenten en bevinden zich voornamelijk in de hoofden van mensen in een organisatie. Het onderzoeken of de requirements juist en volledig zijn en of er risico’s zijn bij het implementeren horen dus onder het kopje ‘testen’. Maar wacht even, hoor ik je denken: de requirementsanalyse valt onder businessanalyse en is een geheel andere tak van sport. Hier wordt verschillend over gedacht: SysQa gaf op de Agile Testing Days in Duitsland een presentatie, met de stelling dat de tester en de requirementsanalist dezelfde persoon zou kunnen zijn.
De tester gebruikt immers de systeemrequirements om zijn testgevallen uit te werken, dus een opvolgend proces. Dit betekent dat de requirementsanalist veel werk heeft in het begin en de tester wat minder en visa versa. De tester zorgt voor een vertaalslag van requirements naar testgevallen. Die vertaalslag zou een stuk efficiënter kunnen zijn als de tester ook requirements engineer is.
Op weg naar een kwalitatief product?
Als testers onderzoeken of het systeem aan de requirements voldoet vinden ze bugs en ontdekken ze risico’s. De ontwikkelaar lost de bugs op en de gesignaleerde risico’s worden kunnen worden afgedekt met aanpassingen aan het systeem of andersoortige maatregelen. Dan komen we in de buurt van een product met kwaliteit. Ik schrijf hier ‘in de buurt’, want je hebt altijd nog de impliciete requirements waar niemand aan gedacht heeft, omdat sommige zaken zo vanzelfsprekend zijn: natuurlijk heeft een nieuw kantoorpand ruimte in de muren voor netwerk bedrading. Een voorbeeld van hoe het fout kan gaan staat in het Computable artikel ‘Een niet-zo-slim gebouw…’. Zo natuurlijk is dat blijkbaar niet. Mensen maken fouten en vergeten onderdelen. Het is dus zaak om scherp en alert te blijven en kritisch te blijven nadenken en mogelijke risico’s te signaleren.
Testen is dus het onderzoeken van mogelijke risico’s bij het introduceren van een ict-systeem en hier informatie over leveren. En dit is wat anders dan ‘verbetering van kwaliteit’. Want als testen een onderzoek is wat informatie oplevert, dan ligt de verbetering van de kwaliteit in de acties die hier op volgen.
Onderzoek naar kwaliteit draagt bij aan deze beslissingen en hiermee wordt testen ook ‘Controle op juistheid van de requirements’. Het begrip testen is nu het ‘onderzoekend vinden van mogelijke problemen en risico’s van een product’.
Nu komen we op het daadwerkelijk verbeteren van de kwaliteit. Testers doen onderzoek en controleren of het juiste product is gemaakt. Vervolgens controleren we of er risico’s voor de business ontstaan. Daarna is het de keuze van de business om aan de hand van deze informatie de juiste acties te nemen:
- Gaan we een ander product maken dan eerst de bedoeling was;
- Gaan we de gevonden bugs oplossen of een work-around implementeren;
- Gaan we de gevonden risico’s bewaken binnen het project of gaan we deze accepteren.
En deze keuzes zijn voor de business. De tester kan geen beslissingen nemen om te stoppen of door te gaan, risico’s te accepteren of besluiten nemen om meer of minder te gaan bouwen. Dit ligt altijd bij het management of de opdrachtgever. Het beeld dat de tester verantwoordelijkheid is voor de kwaliteit komt hiermee te vervallen, de tester is verantwoordelijk voor het geven van inzicht in de kwaliteit.
Conclusie
Kwaliteit betekent het leveren van de juiste oplossingen voor problemen aan de juiste groep mensen: ‘Kwaliteit is waarde voor een bepaald persoon die er toe doet’ (Jerry Weinberg, Quality Software Management vol1) Aan testers om uit te zoeken wat belangrijk is voor de organisatie en voor wie we het product maken. En dan aan de hand hiervan het onderzoek in te gaan en de juiste informatie te leveren.
Verantwoordelijkheid voor de kwaliteit en bewaking gebeurt daarmee door (vertegenwoordigers van) management en de business die de verantwoordelijkheid hebben om de juiste acties te nemen op de informatie die men uit testen krijgt.
Rob van Steenbergen, software tester bij Chickenwings Test Consultancy
(met dank aan Jean-Paul Varwijk, Bert Wijgers (Computable-expert) en Jan Jaap Cannegieter)
Bij deze zou ik graag willen reageren op bovenstaande mening. Allereerst vind ik het zeer goed dat het testen al begint bij de requirements. Ik heb echter een probleem bij de beschreven taak van een tester. Ik ben zelf programmeur, en als programmeur kan ik niet 100 procent mijn code testen, omdat ik altijd blind ben voor bepaalde fouten. Ik heb het gevoel dat in het artikel de tester en de analyst in hoge mate de zelfde is en dan krijg ik de vraag of de analyst dan wel zijn eigen tester kan zijn. Het lijkt mij dat een tester heel goed vragen kan stellen rondom de testbaarheid van requirements en ook best kan beredeneren dat requirements implicaties hebben. Eigenlijk is dat ‘een requirements test’ wat de programmeur t.a.v. de analyst ook doet. Hij stelt vragen als hem het een en ander niet duidelijk is. De programmeur is immers de eerste die te maken krijgt met alle kleine praktische detail puntjes die nog niet uitgewerkt zijn. Naar mijn idee kan een tester vast stellen dat het product niet voldoet aan de specificaties maar hij kan nooit vast stellen dat het product niet kwalitatief is. Dat kan hooguit zijn mening zijn.
Mijn mening is dan ook samenvattend; er zijn verschillende disciplines rondom de bouw van software nodig om te waarborgen dat de kwaliteit hoog blijft en deze verschillende disciplines zijn nu eenmaal nodig om dat we mensen zijn en zaken over het hoofd zien of zaken ons pas realiseren als we het gebruiken.