Over software testen: wat is testen eigenlijk?

Een half jaar geleden ben ik begonnen als Software Tester (bij BlueConic). Zo’n beetje iedereen die niet in de IT werkt en hoort dat ik werk als tester, vraagt zich af wat testen eigenlijk is. Het klinkt zo simpel: testen. Aan de andere kant klinkt het ook als een groot en vaag begrip.

De verantwoordelijkheid van een tester is duidelijker in een andere benaming: Quality Assurance. Als Software Tester krijg je software voor ogen en is het doel om de kwaliteit van de software te bewaken. Dat doel voer je uit door het te testen. Quality Assurance is dus het doel en Testen het middel.

De kwaliteit bewaken klinkt al meer als iets iedereen wel begrijpt. Als tester wil je er zeker van zijn dat de software doet wat het zou moeten doen (“werkt de ‘+’-knop op deze rekenmachine?”), maar zeker ook niet doet wat het niet zou moeten doen (“kan ik inloggen als administrator terwijl ik dat niet ben?”). Beide zijn duidelijk functionele kenmerken, maar er zijn ook genoeg niet-functionele kenmerken te bedenken: of de software snel genoeg is, of de software ook werkt als je hem met meerdere mensen tegelijk gebruikt (2, 10, of misschien wel een miljoen), of de software niet om de havenklap stopt met werken, enzovoort. Uiteindelijk komt het erop neer dat er (impliciet) een aantal karakteristieken zijn vastgesteld waaraan de software moet voldoen, en als tester bewaak je dat de software daar ook daadwerkelijk aan voldoet.

Dat je als tester de ‘software voor ogen krijgt’ klinkt natuurlijk veel simpeler dan het daadwerkelijk is. Binnen elk bedrijf zal dat proces ook verschillen, al is de basis wel hetzelfde. Software ontwikkelen begint met ‘requirements’: de karakteristieken waaraan het moet voldoen. Die requirements staan ergens beschreven, en dat is meestal in een ‘issue tracker’ (zoals Jira), waarin een issue wordt aangemaakt per ‘feature’ en ‘bug’ – simpel gezegd. Per feature worden de requirements vastgesteld, waarna ze omgezet worden tot software doordat developers het programmeren. Als de feature in de software zit, moet het nog bij de tester komen zodat de tester ook daadwerkelijk aan de slag kan. Het kan zijn dat de tester dit zelf regelt, dat de developer nodig is, of dat het automatisch gaat maar even tijd kost. Dat verschilt per situatie en per bedrijf.

Vervolgens kan de tester met de software aan de slag en velt hij uiteindelijk een oordeel. Dit komt neer op: “de test is geslaagd” of “ik heb gevonden dat de feature nog niet helemaal goed werkt, omdat [..]”. Uiteindelijk bepaal je daarna met de developer, de persoon die de requirements heeft gemaakt en/of een manager wat er uiteindelijk met jouw punten gebeurt. Soms moeten ze per se gelijk worden opgelost, maar soms kan er ook worden gezegd dat het voor nu goed is en dat ze later worden opgelost. Mochten er nog punten worden opgelost, zal je als tester weer opnieuw naar de software moeten kijken om zeker te weten dat de kwaliteit nu wel goed is. En misschien vind je dan nog nieuwe punten, waarna je weer in dezelfde cirkel terecht komt. Mocht de kwaliteit nu wel goed genoeg zijn, dan kan de software worden goedgekeurd en uiteindelijk terechtkomen bij de eindgebruiker! En die heeft dan uiteraard een stukje software voor handen met een hele hoge kwaliteit.

Dit bericht is geplaatst in de categorie Beta met de tag . Bookmark de permalink.

Geef een reactie

Jouw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *