Testen van een nieuwe kassarelease

Het testen van een nieuwe kassarelease van een kassasysteem die al gebruikt wordt door meerdere filialen heeft inhoudelijk voor het testproces andere uitdagingen dan het testen van een backoffice systeem zoals bijvoorbeeld een ERP of een CRM. De impact van het niet goed testen heel groot kan zijn. Het kan direct vele winkels, medewerkers en klanten treffen terwijl dit voorkomen had kunnen worden. In dit artikel leg ik uit hoe het testen van een nieuwe kassarelease het beste kan worden aangepakt.

Uitgangssituatie

Een grote nationale retailer is al meer dan een jaar over op een nieuw kassasysteem en elke 2 maanden wordt er door de kassaleverancier een nieuwe versie opgeleverd van de kassasoftware, waarin bugfixes en nieuwe functionaliteiten worden opgeleverd.

Het kassasysteem heeft een centrale applicatie en een kassa applicatie die via een aparte deployment geïnstalleerd wordt. Er wordt dus nog niet in de cloud gewerkt.

De afspraak is dat er maximaal 2 versies mogen worden overgeslagen, omdat de retailer anders achter gaat lopen qua versies en de kassaleverancier dan niet de gewenste service kan bieden.

De retailer heeft de beschikking over een testomgeving, een acceptatieomgeving en een productieomgeving.

Vanuit de kassaleverancier wordt een nieuwe release aangeboden ter installatie inclusief release notes.

Testplan

Voor het testen van een nieuwe kassarelease begin je met het analyseren van de release notes. Uit de release notes blijkt dat er een aantal bevindingen zijn opgelost en dat er nieuwe functionaliteit speciaal voor deze retailer is opgeleverd.

• Per bevinding ga je analyseren hoe de kassaleverancier de bevinding heeft opgelost en hoe je deze bevinding gaat hertesten. Hiervoor kan je aparte testscripts maken maar dat is niet noodzakelijk. Als het goed is staat in de originele bevinding een stappenplan hoe de originele bevinding gereproduceerd kan worden zodat de kassaleverancier het kan naspelen op hun ontwikkelomgeving om de bevinding te begrijpen en op te lossen. Dit stappenplan kan ook gebruikt worden als startpunt voor de hertest.
• Voor de nieuwe functionaliteit is er als het goed is een functioneel ontwerp beschikbaar die door de kassaleverancier gebruikt is om een technisch ontwerp te maken. Met behulp van deze twee documenten (mits beschikbaar) kan een software tester logische en fysieke testgevallen definiëren eventueel op basis van een Product Risico Analyse.
• Uit de release notes blijkt ook dat er enkele database verbeteringen zijn toegepast en dat er nieuwe services zijn toegevoegd voor andere klanten waar deze retailer nog geen gebruik van maakt. Dit kan niet functioneel getest worden door de retailer maar zal impliciet getest moeten worden tijdens de regressie test.

Release en teststrategie

Aangezien het kassasysteem een centrale applicatie en een kassa applicatie heeft en je niet in één keer alle kassa’s in het land wil upgraden naar de nieuwe versie is het verstandig om er voor te zorgen dat je getest hebt dat het volledige systeem ook nog goed functioneert in de volgende 3 scenario’s:

1. Centrale applicatie op de nieuwe versie en alle kassa’s op de huidige versie
2. Zowel de centrale applicatie en de kassa’s van 1 pilot winkel op de nieuwe versie en de kassa’s van alle andere filialen op de huidige versie
3. Zowel de centrale applicatie en de kassa’s van alle andere filialen op de nieuwe versie

Om dit te bereiken zal je er voor moeten zorgen dat er een duidelijke release strategie beschikbaar is waarmee alle drie de scenario’s afgedekt worden. Door deze strategie te volgen zorg je er dus voor dat je uiteindelijk zo min mogelijk risico loopt dat er issues in productie optreden.

Issues tijdens testen

Als er tijdens het testen van een nieuwe kassarelease toch issues optreden dan zullen die één voor één geanalyseerd moeten worden en zal er moeten worden bepaald of het issue blokkerend is voor de release of niet.

• Als het issue blokkerend is:
  • Aanmaken nieuwe bevinding(en) en terug naar de kassaleverancier en een nieuwe versie regelen.
    • Dit betekent het einde van het testproces en bij de oplevering van de nieuwe versie zal het proces van voren af aan opnieuw getest worden
• Als het issue niet blokkerend is:
  • Aanmaken bevinding(en) naar de kassaleverancier die in een volgende release wordt meegenomen
    • Door naar de volgende stap in het testproces.

Conclusie

Door het testen van een nieuwe kassarelease gecontroleerd en gefaseerd uit te voeren, zoals beschreven in dit artikel, zorg je er voor dat het uiteindelijke doel wordt bereikt. Het doel is het risico op blokkerende issues in de winkel te verlagen zodat de klant ongestoord zijn inkopen kan doen en het winkelpersoneel ongestoord hun werkzaamheden kunnen verrichten.

Berry van der Rijk – Retail Software Tester

Berry van der Rijk (1977) is een Retail Software Tester met jarenlange ervaring in de software test wereld en heeft zich gespecialiseerd in het testen van Retail software systemen, zoals Point of Sales, Mobiele Kassa’s, SAP (Retail, MM, SD, FiCo, BW, POS DM, PI), Backoffices, etc.

Hij heeft onder andere bij DetailResult (van de Dirk en de Dekamarkt), Vomar en bij COOP een duidelijke release strategie geïmplementeerd en kan ook uw testproces analyseren en als nodig optimaliseren.