“Testen, dat is toch op knoppen drukken en kijken of je verwachting overeenkomt met wat er gebeurt? En kijken of je in een systeem kan komen? Of kijken of je iets kan laten stoppen met werken als dat niet zou moeten kunnen?”
Op het internet lees ik het volgende:
“Testing consists of verification, validation and exploration activities that provide information about the quality and the related risks, to establish the level of confidence that a test object will be able to deliver the pursued business value.”
Maar wat houdt dat dan precies in?
Bij Prime Vision, waar ik ben ingezet, wordt het ook wel Quality Assurance genoemd. Als QA-engineer ben je verantwoordelijk voor het bewaken van de kwaliteit van de software die wordt opgeleverd. Dit gaat verder dan alleen testen bedenken en uitvoeren.
Je dient ten eerste de ins en outs van je project te kennen. Wat zijn de eisen waaraan je software moet voldoen? Hierbij kijk je niet alleen naar de functionele kant (doet de applicatie wat het moet doen) maar bijvoorbeeld ook naar performance, integriteit, security en vele andere aspecten. Tijdens onze refinement-sessies zorg ik ervoor dat er duidelijke acceptatiecriteria voor de user stories worden vast gesteld. Kortom, aan welke eisen moet deze iteratie voldoen om geaccepteerd te worden.
Informatie verzamelen
Daarnaast is het cruciaal dat je goed communiceert met de stakeholder van het project. Zij zijn een bron aan informatie die jij nodig hebt om je tests op te zetten. Deze meetings zijn voor mij het leukste deel van het werk! Meestal vraag ik aan de developers of ze mij een demo kunnen geven van het nieuwe stuk software dat ze hebben gemaakt. Tijdens deze sessies vraag ik hen het hemd van het lijf, zodat ik weet of de gemaakte software voldoet aan de vastgestelde acceptatiecriteria. Meestal check ik eerst zelf of de besproken functionaliteiten aanwezig zijn in de software. Dit noemt men ‘exploratory testing’. Vervolgens schrijf ik testcases waarbij ik de grenzen van de software opzoek. Natuurlijk probeer ik ook deze grens over te komen. Zo houden we het een beetje spannend! Als ik fouten tegenkom, onderzoek ik de mogelijke oorzaak en rapporteer dit aan het team.
100.000 verzoeken per uur verwerken? Programmeren is je redmiddel
Ons systeem werkt in de cloud en moet 100.000 verzoeken per uur kunnen verwerken. Voor ons is het daarom enorm van belang om te testen of alles werkt en tegelijkertijd voldoet aan de eisen. Eisen kunnen bijvoorbeeld zijn: hoe snel moet een verzoek verwerkt worden? En hoeveel procent van de verzoeken moet minimaal verwerkt worden om geaccepteerd te worden?
Om handmatig honderdduizend verzoeken in een uurtje te versturen is natuurlijk onmogelijk. Gelukkig komt mijn opgedane kennis van programmeren hier goed bij van pas! Zo heb ik een programma geschreven wat verzoeken automatisch naar de cloud stuurt. Best een uitdaging om te maken, maar onmisbaar voor mijn werk, waardoor ik best wel trots ben op het resultaat!
Veelzijdig is het zeker!
Zoals je merkt is het een functie met een groot palet aan activiteiten waarin je op heel veel stukken verantwoordelijkheid krijgt over de kwaliteit van de software. Ook komt er nog een stukje kostenanalyse bij kijken. Want wegen de kosten wel op tegen de risico’s die de mogelijke fout met zich meebrengt?
Wil je meer weten over de rol van tester binnen een DevOps team of ben je benieuwd naar mijn ervaringen binnen Calco? Stuur me dan een berichtje via LinkedIn en misschien ben jij binnenkort ook wel een Calcollega!