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 test je de eventuele bugfixes en nieuwe functionaliteit(en) die geïntroduceerd zijn in de nieuwe release en uiteindelijk voer je een regressie test uit.

Smoke test

De Smoke test wordt altijd uitgevoerd direct nadat de release is geïnstalleerd op de test -of acceptatieomgeving van de retailer. 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 gecontroleerd of 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.
    1. In het eerste geval zal de leverancier de installatie over moeten doen waarna nogmaals de Smoke test wordt uitgevoerd.
    2. In het tweede geval moet de bevinding direct worden gemeld aan de leverancier 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.

Bug fixes

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 optreed 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 worden tegengehouden of kan de release wel worden gedistribueerd naar de filialen.

  • 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.

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.

Als de nieuwe functionaliteit niet zo groot en complex is en er dus geen behoefte is aan een PRA,  dan wordt er een set aan logische testgevallen opgesteld die door de business wordt goedgekeurd. Vervolgens worden deze fysiek gemaakt en wordt de functionele test uitgevoerd.

Product Risico Analyse

Als er wel behoefte is aan een Product Risico Analyse dan wordt het volgende stappenplan toegepast:

  1. Voorbereiden;
  2. Uitvoeren;
  3. 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 worden opgenomen in de Product Risico Analyse. Dit kunnen dus ook deelfunctionaliteiten zijn als er maar 1 of 2 nieuwe functionaliteiten zijn toegevoegd aan de nieuwe release. In een kassa vervangingstraject zullen dit vaak meerdere nieuwe functionaliteiten zijn in één release.

Deze test-items worden in de sessie gescoord op Faalkans en Impact. Dit leidt tot een risicoclassificatie zoals in onderstaande tabel.

Vervolgens wordt er een groepssessie georganiseerd met de betrokken stakeholders. Deze groepssessie wordt gestart met een introductie inclusief doelstelling en wordt de werkwijze van de PRA-sessie uitgelegd. Vervolgens wordt bepaald welke test-items we gaan scoren. Zijn we compleet? Zijn we niet iets vergeten? Zo ja, dan is dit de tijd om deze toe te lichten en toe te voegen aan de lijst met test-items.

Vervolgens wordt de risicotabel per test-item gevuld: 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 wordt zo veel mogelijk vastgelegd wat later gebruikt wordt om de teststrategie te bepalen.

Als je de tabel hierboven plot in een grafiek met 2 kwadranten krijg je een 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.

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
Er wordt een conceptrapport opgesteld met een totaaloverzicht van de risicoklasse per test-item. Na eventuele aanpassingen wordt er een definitieve rapport opgeleverd. 

Geen Product Risico Analyse 

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.

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 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.

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.

Stappen
De volgens stappen worden genomen:

  1. Identificeren van testsituaties;
  2. Opstellen Logische testgevallen;
  3. Opstellen fysieke testgevallen;
  4. Vaststellen uitgangssituatie.

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

Factor Testgeval 1 Testgeval 2 Testgeval 3 Testgeval 4
Artikel Type Los artikel Verkoopset Los artikel Verkoopset
Korting Nee Vaste klanten korting Personeelskorting 2e artijkel 50%
Betaalwijze Cash Pin Credit Card Cash
Type klant Anoniem Vaste klant Personeel Anoniem

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, Leeftijdscontrole, Statiegeld, etc.


Classificatieboom bij het voorbeeld

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


Ingevulde boom voor het voorbeeld

De volgende 4 logische testgevallen worden gedefinieerd:

  1. Een anonieme klant koopt een los artikel zonder korting en betaald met cash geld;
  2. Een vaste klant koopt een verkoopset met vaste klanten korting en betaald met pin;
  3. Een personeelslid koopt een los artikel met personeelskorting en betaald met credit card;
  4. Een anonieme klant koopt twee verkoopsets waarbij het 2e artikel voor de helft van de prijs is en betaald met cash geld.

Stap 3: Opstellen fysieke testgevallen

Voor elk logisch testgeval wordt één of meerdere fysieke testgevallen gedefinieerd. Het fysieke maken van een logisch testgeval wordt gedaan door daadwerkelijke testdata vast te leggen die gebruikt kan worden bij de uitvoer van het testgeval.

  1. Het eerste logische testgeval kan fysiek worden gemaakt door een artikelnummer te bepalen van een los artikel met de gewenste prijs, want er hoeft geen klantnummer te worden bepaald en er wordt ook geen korting verleend.
  2. Het tweede 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.
  3. Het derde logische testgeval kan fysiek worden gemaakt door een personeelsnummer te selecteren die gebruikt wordt voor deze test en door een artikelnummer te selecteren van een los artikel waarvoor personeelskorting is toegestaan en ook een artikelnummer te selecteren van een los artikel waarvoor de personeelskorting niet is toegestaan.
  4. Het vierde logische testgeval kan fysiek worden gemaakt door een artikelnummer te selecteren van een verkoopset waarvoor een promotie actief is waarbij het tweede artikel 50% korting krijgt. Een ander fysiek testgeval zou zijn om maar 1 artikel te verkopen zodat de promotie niet mag afgaan.

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.

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 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 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 activiteiten zijn bedoeld om inzicht te krijgen in het risico dat de retailer loopt door een nieuwe release naar de filialen te sturen.

 

De Smoke test wordt altijd uitgevoerd direct nadat de release is geïnstalleerd op de test -of acceptatieomgeving van de retailer. 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 gecontroleerd of 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.
    1. In het eerste geval zal de leverancier de installatie over moeten doen waarna nogmaals de Smoke test wordt uitgevoerd.
    2. In het tweede geval moet de bevinding direct worden gemeld aan de leverancier 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.

Bug fixes

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 optreed 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 worden tegengehouden of kan de release wel worden gedistribueerd naar de filialen.

  • 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.

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.

Als de nieuwe functionaliteit niet zo groot en complex is en er dus geen behoefte is aan een PRA,  dan wordt er een set aan logische testgevallen opgesteld die door de business wordt goedgekeurd. Vervolgens worden deze fysiek gemaakt en wordt de functionele test uitgevoerd.

Product Risico Analyse

Als er wel behoefte is aan een Product Risico Analyse dan wordt het volgende stappenplan toegepast:

  1. Voorbereiden;
  2. Uitvoeren;
  3. 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 worden opgenomen in de Product Risico Analyse. Dit kunnen dus ook deelfunctionaliteiten zijn als er maar 1 of 2 nieuwe functionaliteiten zijn toegevoegd aan de nieuwe release. In een kassa vervangingstraject zullen dit vaak meerdere nieuwe functionaliteiten zijn in één release.

Deze test-items worden in de sessie gescoord op Faalkans en Impact. Dit leidt tot een risicoclassificatie zoals in onderstaande tabel.

Vervolgens wordt er een groepssessie georganiseerd met de betrokken stakeholders. Deze groepssessie wordt gestart met een introductie inclusief doelstelling en wordt de werkwijze van de PRA-sessie uitgelegd. Vervolgens wordt bepaald welke test-items we gaan scoren. Zijn we compleet? Zijn we niet iets vergeten? Zo ja, dan is dit de tijd om deze toe te lichten en toe te voegen aan de lijst met test-items.

Vervolgens wordt de risicotabel per test-item gevuld: 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 wordt zo veel mogelijk vastgelegd wat later gebruikt wordt om de teststrategie te bepalen.

Als je de tabel hierboven plot in een grafiek met 2 kwadranten krijg je een 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.

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
Er wordt een conceptrapport opgesteld met een totaaloverzicht van de risicoklasse per test-item. Na eventuele aanpassingen wordt er een definitieve rapport opgeleverd. 

Geen Product Risico Analyse 

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.

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 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.

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.

Stappen
De volgens stappen worden genomen:

  1. Identificeren van testsituaties;
  2. Opstellen Logische testgevallen;
  3. Opstellen fysieke testgevallen;
  4. Vaststellen uitgangssituatie.

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

Factor Testgeval 1 Testgeval 2 Testgeval 3 Testgeval 4
Artikel Type Los artikel Verkoopset Los artikel Verkoopset
Korting Nee Vaste klanten korting Personeelskorting 2e artijkel 50%
Betaalwijze Cash Pin Credit Card Cash
Type klant Anoniem Vaste klant Personeel Anoniem

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, Leeftijdscontrole, Statiegeld, etc.


Classificatieboom bij het voorbeeld

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


Ingevulde boom voor het voorbeeld

De volgende 4 logische testgevallen worden gedefinieerd:

  1. Een anonieme klant koopt een los artikel zonder korting en betaald met cash geld;
  2. Een vaste klant koopt een verkoopset met vaste klanten korting en betaald met pin;
  3. Een personeelslid koopt een los artikel met personeelskorting en betaald met credit card;
  4. Een anonieme klant koopt twee verkoopsets waarbij het 2e artikel voor de helft van de prijs is en betaald met cash geld.

Stap 3: Opstellen fysieke testgevallen

Voor elk logisch testgeval wordt één of meerdere fysieke testgevallen gedefinieerd. Het fysieke maken van een logisch testgeval wordt gedaan door daadwerkelijke testdata vast te leggen die gebruikt kan worden bij de uitvoer van het testgeval.

  1. Het eerste logische testgeval kan fysiek worden gemaakt door een artikelnummer te bepalen van een los artikel met de gewenste prijs, want er hoeft geen klantnummer te worden bepaald en er wordt ook geen korting verleend.
  2. Het tweede 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.
  3. Het derde logische testgeval kan fysiek worden gemaakt door een personeelsnummer te selecteren die gebruikt wordt voor deze test en door een artikelnummer te selecteren van een los artikel waarvoor personeelskorting is toegestaan en ook een artikelnummer te selecteren van een los artikel waarvoor de personeelskorting niet is toegestaan.
  4. Het vierde logische testgeval kan fysiek worden gemaakt door een artikelnummer te selecteren van een verkoopset waarvoor een promotie actief is waarbij het tweede artikel 50% korting krijgt. Een ander fysiek testgeval zou zijn om maar 1 artikel te verkopen zodat de promotie niet mag afgaan.

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.

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 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 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 activiteiten zijn bedoeld om inzicht te krijgen in het risico dat de retailer loopt door een nieuwe release naar de filialen te sturen.