7 Software Test Principes

Dit artikel introduceert de zeven basis test principes van Software Testing die naast de project manager iedere professionele software tester en QA professional moet weten.

Achtergrond van software test principes

Het is belangrijk dat we met het software testen optimale testresultaten behalen zonder af te wijken van het testdoel. Maar hoe bepalen we of we de juiste teststrategie volgen? Hiervoor moeten we een aantal basis test principes volgen.

Om dit te begrijpen denk je bijvoorbeeld aan een testscenario waarin we een bestand van map A naar map B moeten verplaatsen.

Bedenk alle mogelijke zaken die we daarvoor zouden moeten testen. Afgezien van het goed lopende testscenario kunnen we ook de volgende voorwaarden testen:

• Probeer het bestand te verplaatsen terwijl het geopend is.
• Poog het bestand te verplaatsen terwijl je geen toegangsrechten hebt om het bestand in map B te plakken.
• Probeer het bestand te verplaatsen terwijl map B is op een gedeelde drive komt die vol is.
• Probeer het bestand te verplaatsen terwijl map B al een bestand heeft met dezelfde naam.

Er is een eindeloze lijst met dit soort testen te verzinnen, alleen al voor dit simpele geval.

Of denk aan een scherm met 15 invoervelden met elk 5 mogelijke waarden, het aantal te testen combinaties is 5 tot de 15 macht. Test test test…

Als we alle mogelijke combinaties van een SaaS applicatie moesten testen, zouden de tijd en de kosten hiervoor exponentieel stijgen. Daarom hebben we bepaalde uitgangspunten en strategieën nodig om het aantal testen te optimaliseren.

Dit zijn de 7 test principes:

1. Test, test, test, uitputtend testen is niet mogelijk

Uitputtend testen is dus niet mogelijk, zeker voor SaaS niet. In plaats daarvan gaan we op zoek naar het optimale aantal tests dat nodig is op basis van de risico-analyse van de applicatie.

Met welke test zal de systeemsoftware waarschijnlijk de fout in gaan? De meeste mensen zullen gokken op de kans dat 10 verschillende gebruikers de applicaties op hetzelfde moment openen. Dus als we een SaaS applicatie moeten testen zullen de meeste defecten waarschijnlijk in de multitasking-activiteiten voorkomen en dit moeten we dus grondig testen.

2. Defect Clustering

Defect Clustering gaat er van uit dat een klein aantal modules de meeste defecten bevat. Dit is de toepassing van het Pareto-principe op software testen: ongeveer 80% van de problemen komt voor in 20% van de modules.

Alleen door ervaring kunnen we dergelijke risicovolle modules identificeren. Vaak zijn er modules waarin stambestanden worden bijgehouden of enkelvoudige mutaties worden opgevoerd. Daar lopen we geen groot risico mee. Er zijn echter steevast 1 of 2 modules waar in het echte werk plaatsvindt. Alle data komt daar samen en wordt verwerkt tot nieuwe informatie. Of er zijn koppelingen met andere systemen. Denk bijvoorbeeld aan de factureringsmodule met een koppeling naar het boekhoudsysteem. Dit soort modules bevatten het grootste risico op fouten.

3. Pesticide Paradox

Als we dezelfde testen keer op keer herhalen, zullen we met dezelfde testgevallen geen nieuwe bugs meer vinden.

Veelvuldig gebruik van dezelfde landbouwgif om insecten uit te roeien in de landbouw zal er na verloop van tijd toe leiden dat de insecten een resistentie tegen het pesticide ontwikkelen. Daardoor is het niet langer doeltreffend op die insecten. Hetzelfde geldt voor software testen. Als we dezelfde reeks tests herhaaldelijk uitvoeren, is de software test methode nutteloos voor het ontdekken van nieuwe defecten.

Om dit te overwinnen, moeten we de testgevallen regelmatig herzien. Nieuwe en andere testcases toevoegen aan de testset helpt bij het vinden van meer defecten.

Testers mogen niet blijven hangen bij van bestaande testtechnieken. Zij moeten constant kijken of ze de bestaande methodes kunnen verbeteren om zo het testen effectiever te maken. Maar zelfs na de zwaarste testinspanningen kunnen we nooit beweren dat de applicatie foutloos is.

Denk je niet dat een bedrijf als Microsoft, hun besturingssysteem niet grondig zou hebben getest alleen om hun OS te laten crashen tijdens de publieke lancering? Dit is wel daadwerkelijk met Windows 98 gebeurd!

4. Testen bewijst dat er defecten in de software zitten

Testen zegt iets over de aanwezigheid van fouten in de software en niet over de afwezigheid er van. Daar mee verminderen we met Software Testing de kans op onopgeloste defecten in de software. Maar zelfs als er geen defecten zijn gevonden, is dat geen bewijs van correctheid. Er zijn bepaalde testtechnieken waarbij programmeurs met opzet een aantal fouten in de software aanbrengen. Bijvoorbeeld 5. Als de testers er dan 4 vinden kunnen we zeggen dat de software voor 80% in orde is.

5. Afwezigheid van fouten

Er is een kans dat software voor 99% foutloos is maar onbruikbaar voor de organisatie. Dit kan bijvoorbeeld gebeuren als we de applicatie grondig testen maar op de verkeerde requirements. Software testen is dus niet alleen het vinden van fouten, maar ook om vast te stellen of de software goed in de zakelijke behoeften voorziet. Het vinden en repareren van defecten helpt niet als het gebouwde systeem onbruikbaar is en niet voldoet aan de behoeften en requirements van de gebruiker. Dit is natuurlijk de grootste nachtmerrie van iedere projectleider.

6. Early Test in het software proces

Vroege testen – Het projectplan moet voorzien in het zo vroeg mogelijk starten van testen in het Software ontwikkelproces. Als dat lukt kunnen we eventuele tekortkomingen in de requirements of het ontwerp vroegtijdig vinden. Het is namelijk veel goedkoper om een defect in vroege testfasen op te lossen. Maar hoe vroeg moeten we beginnen met testen? De projectleider zou graag zien dat we alle bugs al vinden op het moment dat we de requirements opschrijven. Het requirementsrapport en de ontwerpen daarna moeten we dus goed controleren. Plan de reviews daarom tijdig in.

7. Testen is context afhankelijk

Testen is contextafhankelijk, wat in principe betekent dat de manier waarop we een webshop testen, anders is dan het testen van een Windows applicatie. Alle ontwikkelde software is verschillende. Voor het maken van de software kan er gebruik gemaakt zijn van een andere aanpak, andere methodologieën en andere technieken. Het soort test wat we moeten uitvoeren is afhankelijk van het type applicatie. Het testen van PIN betalingen aan de kassa in een winkel is bijvoorbeeld iets anders dan het testen van een SaaS COTS applicatie.

Samenvatting van de zeven test principes

1. Testen toont aan dat er defecten zijn.
2. Uitputtend testen is onmogelijk.
3. Early Testing, vroeg in het ontwikkelproces.
4. Defect Clustering, zoek het op gevoelige plekken.
5. Pesticide Paradox, blijf niet telkens dezelfde test herhalen.
6. Testen is contextafhankelijk.
7. De afwezigheid van fouten hoeft niet goed te zijn.

Discussieer mee op LinkedIn.