Het VNSG Magazine, het vakblad voor alle SAP gebruikers in Nederland en Vlaanderen, verschijnt 5 keer per jaar. PTWEE geeft in iedere editie een praktische tip over testen in een SAP omgeving. Deze tip gaat over het het onderscheid maken tussen logische en fysieke testcases.
Voor de snelheid en de kwaliteit van het testen is het van groot belang om duidelijk onderscheid te maken tussen logische en fysieke testcases. Logische testcases beschrijven de situaties die getest moeten worden. Fysieke testcases zijn de uitwerking van logische testcases in gedetailleerde stappen met indien nodig testdata. Iedere stap bevat een actie en een bijbehorend verwacht resultaat.
Voorbeelden van logische testcases zijn:
- TC1: Bestel precies één artikel waarbij het orderbedrag beneden de drempelwaarde ligt
- TC2: Bestel meerdere artikelen waarbij het orderbedrag boven de drempelwaarde ligt
Uitwerking van testcase 1 (TC1) in een fysieke testcase:
Het maken en onderhouden van fysieke testcases is erg tijdrovend. Doe dit daarom heel selectief. Enkele redenen om testcases fysiek uit te werken zijn:
- degene die de test moet uitvoeren heeft weinig kennis van het te testen systeem;
- de functionaliteit die getest moet worden valt in een hoge risicoklasse (zie ook de tip over risk-based testen in VNSG magazine van december 2011);
- de functionaliteit die getest moet worden is zeer complex waardoor een uitwerking in stappen noodzakelijk is;
- de test wordt (op termijn) omgezet naar een geautomatiseerd testscript.
Om de test te kunnen automatiseren is een fysieke uitwerking in stappen, inclusief testdata, noodzakelijk. Het is van groot belang dat er concrete afspraken worden gemaakt over het al dan niet uitwerken van logische testcases in fysieke testcases. Overigens worden er ook logische testcases opgenomen in de regressie testset zodat deze in de toekomst kunnen worden hergebruikt.
Specificatietechnieken
Voor het opstellen van logische testcases kan gebruik worden gemaakt van zogenoemde testspecificatietechnieken. Daarmee is het mogelijk om op basis van een bepaalde testbasis (bijvoorbeeld een functioneel ontwerp of een procesflow) alle mogelijke logische testcases te bepalen. Zo wordt voorkomen dat er testsituaties over het hoofd worden gezien.
Een techniek die zeer geschikt is om door de business (functioneel beheer) te worden gebruikt is de ‘proces cyclus test’. Met deze techniek worden aan de hand van een procesflow zinvolle testpaden gedefinieerd.
In het volgende voorbeeld muteert een HR Service Center persoonsgegevens die worden aangeleverd door de HR adviseurs en de medewerkers van het bedrijf.
De mutaties komen op verschillende manieren binnen: via de mail, via de telefoon en via formulieren. Algemene persoonsgegevens kunnen zonder handtekening gemuteerd worden, maar voor de overige zaken is een handtekening nodig van de HR adviseur of van de leidinggevende. Indien handtekening niet aanwezig is, wordt de mutatie teruggezonden via de interne post met een motivatie en/of vraag erbij.
Eerst worden nummers in de proces flow gezet. Alle startpunten van het proces krijgen een nummer en vervolgens steeds na de beslispunten in het proces.
Daarna worden alleen alle zinvolle paden genoteerd. Een voorbeeld van een niet zinvol testpad is ‘3- 5-6’. Een mutatie die wordt doorgegeven via de telefoon kan namelijk geen handtekening bevatten. De testpaden kunnen vervolgens worden uitgeschreven in logische testcases en indien nodig fysiek uitgewerkt.
Helder onderscheid tussen logische en fysieke testcases vergroot de kwaliteit van de uit te voeren tests en kan tijdwinst opleveren. Daarnaast draagt het bij aan het opbouwen van een regressie testset voor de toekomst die goed te onderhouden is.
