Binnen de scrum methodiek is het gebruikelijk dat zowel testers als andere teamleden verantwoordelijk zijn voor de kwaliteit van het product, dit betekent onder andere dat het voor komt dat een niet tester zich bezig houd met het opstellen en uitvoeren van testen. Dit is de kracht van de scrum methodiek en dit heeft in mijn optiek vele voordelen ten opzichte van de waterval methodiek. (lees mijn eerder blog: Agile / scrum vs waterval wat zijn de verschillen voor de tester ).Het is echter wel belangrijk dat een tester betrokken blijft bij het testen van het product. één van de reden hiervoor zijn ongeschreven verborgen requirements.
In deze blog zal ik wat meer uitleg geven over deze ongeschreven requirements. Ongeschreven requirements zijn in verschillende categorieen in te delen:
Veronderstelde requirements
Veronderstelde requirements zijn requirements die vaak niet terug komen de requirement documentatie omdat verondersteld wordt dat deze duidelijk zijn. Er wordt vaak gezegd: “Assumption is the mother of all fuck-ups” als tester heb je taak om juist deze requirements te testen.
Een voorbeeld van een veronderstelde requirement kan zijn dat in een veld waar je een aantal te bestellen producten invoert het niet mogelijk is om letters of speciale tekens te zetten. Tevens kan een veronderstelde requirement zijn dat het niet mogelijk is om 2,5 of 2.5 producten te bestellen. Om het nog speciefieker wilt maken kan een veronderstelde requirement ook zijn dat er niet meer dan 2,147,483,647 producten kunnen worden besteld (dit is het maximum waarmee de database gevuld kan worden als het veld van het type INT is).
Om deze requirement goed te kunnen testen is algemene test kennis nodig. denk hierbij aan het technieken als grenswaarden controle. Door ervaring in het testvak op te doen wordt je steeds beter in het bepalen van dergelijke requirements.
Don’t break requirement
Een erg extreem voorbeeld van een don’t break requirement kan je tegen komen bij het testen van medische apparatuur. in de requirments van dit soort apparatuur zal iets staan over hoe het moet werken maar er zal hoogstwaarschijnlijk niet in staan dat hij niet kapot mag gaan, of erger nog een patiënt blesseren bij oneigenlijk gebruik. Als tester is het belangrijk om ook dit soort dingen te testen.
Om dit soort requirements goed te kunnen testen is met name domeinkennis van groot belang. Dit haal je mogelijk niet direct uit het boven genoemende voorbeeld maar bij minder extreme gevallen is dit zeker het geval.
Nonfunctionals requirements
Hierbij moet gedacht worden aan usability, performance of consistentie. voorbeelden hiervan kunnen zijn.
Om deze ongeschreven requirements te kunnen testen is het belangrijk dat je bekend bent met de standaarden. Bij het testen van websoftware is het bijvoorbeeld belangrijk om te weten wat de usability standaarden zijn.
Conclusie ongeschreven requirements
Het is als tester van groot belang dat deze ongeschreven requirements te testen. Want deze requirements worden regelmatig over het hoofd gezien tijdens de ontwikkeling (want de ontwikkelaar heeft echter precies gemaakt wat in de requirements staat).
Ik denk dat het erg waardevol is dat naast testers ook andere teamleden helpen met het testproces. Dit heeft een aantal voordelen.
1. Wanneer je samen met een niet tester bepaalde testen uitvoert laat je aan deze persoon zien hoe je dit aanpakt dit zorgt ervoor dat hij in de toekomst de ongeschreven requirements die hij nu gemist heeft volgende keer niet weer zal missen.
2. Een niet tester kan je helpen je eigen test proces / ‘manier van testen’ te verbeteren. een goed voorbeeld hiervan is dat een ontwikkelaar je uit kan leggen hoe je een voor jou functioneel lastig te testen stuk software veel gemakkelijker op een technische manier kunt testen.
Dus laat vooral niet testers helpen met het testen van je te testen product maar help hem waar nodig een betere ‘tester’ te worden. Een tester die rekening houd met de ongeschreven requirements.
