Aanpak testen nieuwe kassarelease

In een ideale wereld weet u wanneer u een nieuwe versie van uw kassasoftware opgeleverd krijgt. Hierdoor heeft u genoeg tijd om de deployment naar uw test of acceptatie omgeving voor te bereiden. Ook heeft u genoeg tijd de test die u wilt uitvoeren om te controleren of deze nieuwe release voldoet aan de verwachtingen uit te voeren.

Toch?

Helaas weet u niet altijd exact wanneer de volgende release wordt opgeleverd of heeft u het zo druk met de dagelijkse business dat u de aankondiging van de volgende release niet helemaal in het vizier hebt. Hoe moet dat dan met het testen van deze release? Is het niet handiger dat u hiervoor tijdelijk iemand inhuurt die weet hoe hij deze release kan testen?

Ik wil en kan u daar graag bij helpen.

Maar hoe pak je dat dan aan? Vrij simpel. Om een nieuwe release te testen, van eender welke software, start je over het algemeen met een smoke test, vervolgens voer je je regressie test uit en uiteindelijk test je de nieuwe functionaliteit(en) die geïntroduceerd zijn in de nieuwe release.

Smoke test

De Smoke test wordt altijd uitgevoerd direct nadat de release is geïnstalleerd op de test of acceptatie omgeving. Tijdens de Smoke test wordt gecontroleerd of alle basale functionaliteiten (zoals inloggen, verkopen en pinnen in 1 kassatransactie) het nog doen en of er niks is omgevallen (soort van mini regressie test). Vervolgens controleer je of de nieuwe functionaliteit die deze release speciaal voor jullie is toegevoegd (als dit het geval is) het überhaupt doet in de happy flow. Eigenlijk controleer je dus “of er geen rook uit komt”, vandaar de term “Smoke test”.

Als de Smoke test niet succesvol is kan dat meerdere oorzaken hebben. Of de nieuwe release is niet correct geïnstalleerd óf er zit een bug in de nieuwe release. In het eerste geval zal de leverancier de installatie over moeten doen waarna nogmaals de Smoke test wordt uitgevoerd. In het tweede geval moet de bevinding direct worden gemeld aan de leverancier zodat deze dit zo snel mogelijk moet oplossen door middel van een patch of door middel van een volledige nieuwe release. Alle testwerkzaamheden zullen dan per direct worden gestaakt.

Als de Smoke test succesvol is start je pas met het uitvoeren van de regressie test.

Regressie test

Definitie: Met regressietesten wordt gecontroleerd of de niet aangepaste onderdelen van een applicatie nog steeds juist werken.

Om een regressie test uit te voeren is het noodzakelijk om eerst een regressie test set samen te stellen (als deze nog niet beschikbaar is). Idealiter is er een set van testgevallen beschikbaar uit het project toen de nieuwe kassa werd geïmplementeerd. Als deze set er is, dan wil ik deze set graag eerst reviewen en samen met een key-user bepalen waarom er ooit gekozen voor deze testgevallen en vervolgens bepalen welke testgevallen we gaan gebruiken als regressie test set.

Als er geen testscripts of testgevallen beschikbaar zijn dan wil ik aan de hand van een datacombinatietest bepalen welke testgevallen er opgenomen gaan worden in de regressie test set. Het doel is om met zo min mogelijk testgevallen zo veel mogelijk situaties af te dekken, die ogenschijnlijk niks met elkaar te maken hebben. Bij de datacombinatietest maak ik gebruik van een classificatieboom die lijkt op een beslissingsboom.

Stappen

Stap 1: identificeren van testsituaties
Er zijn gegevens nodig om een beslissingsboom te kunnen maken. Hieronder staat een voorbeeld van kassatransacties die gebruikt zal worden voor een boom.

FactorTestgeval 1Testgeval 2Testgeval 3Testgeval 4
Artikel TypeLos artikelVerkoopsetLos artikelVerkoopset
KortingNeeVaste klanten kortingPersoneelskorting2e artijkel 50%
BetaalwijzeCashPinCredit CardCash
Type klantAnoniemVaste klantPersoneelAnoniem

Deze tabel wordt vertaald naar de koppen van de boom hier onder. Ten behoeve van dit voorbeeld wordt hier maar een kleine subset van de factoren weergegeven die in een echte regressie test ook moeten worden opgenomen. Denk hierbij aan BTW classificatie, Omzetgroepen, Vouchers, Retouren, etc.


Classificatieboom bij het voorbeeld

Stap 2: Opstellen Logische testgevallen
Nadat de koppen van een boom zijn gemaakt, kan de boom ingevuld worden. Vooraf moet bepaald worden welke factoren volledig getest moeten worden. In deze boom moeten alle factoren getest worden. Dit wordt vertaald naar de boom hier onder.


Ingevulde boom voor het voorbeeld

Stap 3: Opstellen fysieke testgevallen
Iedere regel in de boom is een logisch testgeval. Deze worden fysiek gemaakt door iedere bullet op de regel in te vullen door een waarde. Dus in bijvoorbeeld het eerste fysieke testgeval wordt zowel “los artikel”, “geen korting”, “cash” en een “anonieme klant” getest.

Stap 4: Vaststellen uitgangssituatie
Het vaststellen van de uitgangssituatie is nadenken over wat er klaar moet staan om te kunnen testen. In dit voorbeeld is het een testkassa met daarop de artikelen, betaalwijzen en promoties beschikbaar. Ook wordt per testgeval bepaald of reeds bestaande artikelen worden gebruikt of dat er een nieuw artikel voor wordt aangelegd (kan ook op worden genomen in de boom). Dit kan verstandig zijn om de gehele integratie in de keten te testen in combinatie met een nieuwe kassa release.

Nieuwe functionaliteit(en)

Als de nieuwe kassa release speciaal voor u nieuwe functionaliteiten heeft toegevoegd dan is het verstandig dat u deze zelf onderwerpt aan een functionele acceptatie test. Uw leverancier heeft deze functionaliteit ook getest maar dan op hun eigen testomgeving en niet op uw integrale (keten) test omgeving. Ook dit kan ik voor u uitvoeren.

Aan de hand van de beschikbare documentatie (dit kan een lijst met requirements zijn of een volledig gereviewde en goedgekeurd functioneel ontwerp inclusief acceptatiecriteria) kan ik samen met de operatie bepalen of er behoefte is aan een product risico analyse (zodat we aan de hand van de bepaalde product risico’s een teststrategie kunnen opstellen) of als de nieuwe functionaliteit niet zo groot en complex is dan doe ik een voorstel voor een set aan logische testgevallen.

Product Risico Analyse
Als er behoefte is aan een Product Risico Analyse dan pas ik het volgende stappenplan toe: Voorbereiden, Uitvoeren, Rapporteren.

Voorbereiden
We starten met het maken van afspraken met de betrokkenen ten behoeve van informatievergaring. Vervolgens gaan we verder met het vergaren en bestuderen van de relevante documentatie, zoals de eerder genoemde lijst met requirements of een volledig gereviewde en goedgekeurd functioneel ontwerp inclusief acceptatiecriteria. Ook testresultaten van vorige releases kunnen hierin worden meegenomen. Simultaan starten we de voorbereiding met betrekking tot de interviews en de gezamenlijke PRA-sessie.

Uitvoeren
Het bepalen van de exacte scope van de Product Risico Analyse, dus welke test-items nemen we op in de Product Risico Analyse. Deze test-items gaan we in de sessie scoren op Faalkans en Impact. Dit leidt tot een risicoclassificatie zoals in onderstaande tabel.

Vervolgens organiseer ik een groepssessie met de betrokken stakeholders. In deze groepssessie doe ik een introductie met doelstelling en leg ik de werkwijze van de PRA-sessie uit. Vervolgens bepalen we test-items die we gaan scoren. Zijn we compleet? Zijn we niet iets vergeten? Dan is dit de tijd om het nog toe te lichten en toe te voegen aan de lijst.

Vervolgens vullen we de risicotabel per test-item: Schade inschatting per test-item en Faalkans inschatting per test-item. Dit leidt tot de risicoklasse per test-item zoals in het voorbeeld hieronder. De kolommen “Wat testen?” en “Opmerkingen teststrategie” worden tijdens de sessie gevuld vanuit de opmerkingen die in de sessie worden gemaakt over de desbetreffende test-items. Op deze manier leggen we zo veel mogelijk vast wat we later willen gebruiken om de teststrategie te bepalen.

Als je het tabel hierboven plot in een tabel krijg je onderstaand totaaloverzicht met test-items en risicoklassen. 

Na afloop van de groepssessie is de basis voor de teststrategie gelegd. Duidelijk is dat Test items 2, 6 en 8 een Risicoclassificatie Hoog hebben gekregen en deze zullen dan ook het zwaarst getest gaan worden tijdens de testuitvoer. Test items 3 en 5 zijn geclassificeerd als Laag en zullen bij tijdgebrek niet worden getest en als ze al worden getest zal er niet heel diepgaand getest gaan worden.

Rapporteren
Ik stel een conceptrapport op met een totaaloverzicht van de risicoklasse per test-item. Na eventuele aanpassingen lever ik het definitieve rapport aan u op. 

Geen Product Risico Analyse 
Als er geen behoefte is aan een Product Risico Analyse (bij kleine wijzigingen of bij voorbaat al duidelijk wat de risico’s zijn) dan stel ik een lijst op met logische testgevallen welke we gaan testen als de nieuwe release beschikbaar is. Deze logische testgevallen laat ik valideren door de key-user(s) en als akkoord dan gaan we deze fysiek maken (mits er voldoende voorbereidingstijd beschikbaar is).