Hoe testen we een nieuwe release van je kassa. Kassasystemen zijn er in vele soorten en maten. Er is één ding wat ze allemaal gemeen hebben: ze worden (bijna) allemaal ontwikkeld door een softwareleverancier en ze worden (bijna) allemaal gebruikt door retailers. De reden dat weinig retailers dit zelf gaan ontwikkelen is heel simpel: “Schoenmaker blijf bij je leest“.
Iedereen moet dus doen waar hij goed in is, echter er komt een moment dat de softwareleverancier het ontwikkelde product graag wil implementeren bij de klant (de retailer) en dan wilt u als klant graag zekerheid dat wat de softwareleverancier zegt dat het systeem doet, het systeem ook daadwerkelijk doet en niet alleen de zogenaamde “happy flow”.
U wilt als klant zekerheid hebben dat u alle soorten en typen transacties kunt uitvoeren met alle gedefinieerde betaalwijzen tijdens het dagelijkse werk en dat het systeem stabiel is en snel genoeg is.
Maar hoe kunt u dat nu zeker weten?
- vertrouwt u er op dat de softwareleverancier alles goed heeft getest?
- vertrouwt u er op dat de softwareleverancier ook uw configuratie goed heeft getest?
- of gaat u er maar van uit dat het wel goed zit?
Ik ga er van uit dat u graag zelf wilt controleren dat de opgeleverde release voldoet aan uw verwachtingen. Maar hoe pakt u dat aan? Om een nieuwe release te testen, van eender welke software, voer je over het algemeen de volgende 4 test soorten uit:
- Je start met een smoke test;
- Vervolgens test je de eventuele bugfixes in de release;
- Dan test je de nieuwe functionaliteit(en) die geïntroduceerd zijn in de release;
- Als laatste voer je een regressie test uit.
Uitvoeren Smoke test
De Smoke test wordt altijd uitgevoerd direct nadat de release is geïnstalleerd op de test -of acceptatie-omgeving van de retailer. Bij voorkeur wordt deze Smoke test uitgevoerd door de leverancier, in het bijzijn van de klant, bijvoorbeeld door middel van een demo.
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 wordt aangetoond dat de nieuwe functionaliteit die deze release speciaal voor de retailer 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 twee oorzaken hebben. Of de nieuwe release is niet correct geïnstalleerd óf er zit een (nieuwe) bug in de release.
- In het eerste geval zal de leverancier de installatie over moeten doen waarna nogmaals de Smoke test wordt uitgevoerd (bij voorkeur in dezelfde sessie).
- In het tweede geval moet de bevinding direct worden gemeld aan de leverancier (als de Smoke test niet door de leverancier wordt uitgevoerd tijdens een demo) zodat deze dit zo snel mogelijk kan 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 testen van de nieuwe functionaliteiten.
Testen van bugfixes
Als de nieuwe kassa release één of meerdere bugfixes bevat dan worden deze (als het goed is) gemeld in de release notes. Lees deze release notes nauwkeurig zodat duidelijk is wat de oplossing is die de softwareleverancier heeft bedacht om de door de retailer opgevoerde bevinding(en) op te lossen.
Vervolgens worden de opgeloste bevindingen hertest door deze te reproduceren:
- Als het reproduceren van de bevinding niet lukt dan heeft de softwareleverancier de desbetreffende bevinding succesvol opgelost. Zorg er dan wel voor dat de bevinding ook op andere factoren wordt getest want het is altijd mogelijk dat bij het oplossen van de ene issue een ander issue wordt geïntroduceerd. Dit noemen we dan een regressie issue.
- Als er een regressie issue optreedt dan kan de originele bevinding worden gesloten en wordt er een nieuwe bevinding opgevoerd. Afhankelijk van de ernst van de nieuwe bevinding kan de release óf worden tegengehouden óf wordt de release wel gedistribueerd naar de winkels.
- Als het reproduceren van de bevinding nog steeds lukt dan heeft de softwareleverancier de desbetreffende bevinding niet opgelost en dan wordt deze teruggestuurd naar de softwareleverancier en mag deze het nog eens proberen op te lossen.
- Zorg er dan voor dat de softwareleverancier meer informatie krijgt in de vorm van logfiles, testdata, screenshots, etc. om er voor te zorgen dat ze het de tweede keer wel “begrijpen” en het wel oplossen.
Testen nieuwe functionaliteit(en)
Als de nieuwe kassa release speciaal voor u nieuwe functionaliteiten bevat dan is het verstandig dat u deze zelf onderwerpt aan een functionele acceptatie test. Uw softwareleverancier heeft deze functionaliteit, als het goed is, ook getest maar dan op hun eigen testomgeving en niet op uw integrale (keten) test omgeving.
Aan de hand van de beschikbare documentatie (dit kan een lijst met requirements zijn of een volledig gereviewd en goedgekeurd functioneel ontwerp inclusief acceptatiecriteria) wordt samen met de business bepaald of er behoefte is aan een Product Risico Analyse (PRA). Aan de hand van de bepaalde product risico’s wordt dan een teststrategie opgesteld en worden de logische en fysieke testgevallen gedefinieerd.
Als er geen behoefte is aan een Product Risico Analyse (bij kleine wijzigingen of bij voorbaat is al duidelijk wat de risico’s zijn) dan wordt er een lijst met logische testgevallen opgesteld die worden getest als de nieuwe release beschikbaar is. Deze logische testgevallen worden gevalideerd door de key-user(s) en als akkoord dan worden deze fysiek gemaakt (mits er voldoende voorbereidingstijd beschikbaar is).
Vervolgens wordt de functionele test uitgevoerd.
Uitvoeren Regressie test
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 is het verstandig deze set eerst te reviewen en samen met een key-user te bepalen waarom er ooit is gekozen voor deze testgevallen en vervolgens wordt bepaald welke testgevallen gebruikt worden als regressie test set. Een regressie test set kan na elke release worden aangevuld met testgevallen van nieuwe functionaliteiten, voor zover deze een hoog risico met zich meebrengen.
Als er geen testscripts of testgevallen beschikbaar zijn dan wordt aan de hand van een datacombinatietest bepaald welke testgevallen er opgenomen 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 wordt gebruik gemaakt van een classificatieboom die lijkt op een beslissingsboom.
Opstellen Regressie Test Set
De volgens stappen worden genomen:
- Identificeren van testsituaties:
- Denk hierbij aan verschillende artikelsoorten, promoties/kortingen, betaalwijzen, klanttypen, BTW classificaties, Omzetgroepen, Vouchers, Retouren, Leeftijdscontrole, Statiegeld, etc.
- Opstellen Logische testgevallen:
- Voorbeeld: Een vaste klant koopt een verkoopset met vaste klanten korting en betaald met pin.
- Opstellen fysieke testgevallen:
- Het logische testgeval kan fysiek worden gemaakt door een klant te selecteren die gebruikt wordt voor deze test en door een artikelnummer te selecteren van een verkoopset waarvoor ook een vaste klantenkorting actief is en een artikelnummer te selecteren van een verkoopset waarvoor de vaste klantenkorting niet actief is. Dit kunnen ook twee losse testgevallen zijn.
- Vaststellen uitgangssituatie.
- Het vaststellen van de uitgangssituatie is nadenken over wat er klaar moet staan om te kunnen testen en dit ook regelen.
Uitvoeren regressie test
Het uitvoeren van een regressie test wordt pas gedaan als zowel de bugfixes als de nieuwe functionaliteiten succesvol zijn getest en er geen blokkerende bevindingen zijn gedaan tijdens de uitvoer hiervan.
- Als er wel blokkerende bevindingen zijn gedaan tijdens het testen dan wordt de release toch niet gedistribueerd naar de filialen dus dan is het uitvoeren van een regressie test zonde van de tijd en moeite.
- Als er geen blokkerende bevindingen zijn gedaan tijdens het testen dan kan de regressie test set worden uitgevoerd op de acceptatie omgeving van de retailer. Deze regressie test wordt bij voorkeur uitgevoerd door de key-users of functioneel applicatie beheerders aangezien zij diegenen zijn die er dagelijks mee werken en dus niet door de professionele testers die de bugfixes en de nieuwe functionaliteiten hebben getest.
Als alle testgevallen zijn uitgevoerd kan bepaald worden of de release niet ergens is “omgevallen” ten opzichte van eerdere releases. Als dit wel het geval is dan wordt de ernst van het issue bepaald en afhankelijk van de ernst wordt bepaald of de release wel of niet gedistribueerd wordt naar de filialen.
Al deze test activiteiten zijn bedoeld om inzicht te krijgen in het risico dat de retailer loopt door een nieuwe release naar de filialen te sturen.
Over de auteur
Met zijn jarenlange ervaring als software tester gecombineerd met zijn uitgebreide kennis van retail processen en kassasystemen kan Berry van der Rijk (www.retailtester.nl) in een korte periode op basis van een product risico analyse uw (kassa) systeem testen en u inzicht geven in de kwaliteit en de openstaande risico’s aan de hand waarvan u kunt bepalen of u de opgeleverde release wel of niet in gebruik wilt gaan nemen.
Bent u geïnteresseerd in de diensten van Berry, neem dan contact op via berry@vanderrijk.nl of bel direct op +31628452551
