Begin bij regels die altijd moeten blijven gelden.
Maak eerst de gewenste uitkomst concreet. “De voorraad werkt” is niet toetsbaar. “Een herhaalde bevestiging verbruikt dezelfde reservering niet opnieuw” wel. Zulke afspraken worden ook invarianten genoemd: eigenschappen die bij alle toegestane handelingen behouden moeten blijven.
Stel de regels samen met de operatie op. Denk aan een geblokkeerde partij die niet beschikbaar mag komen voor picking, een deelzending die de rest van de order openlaat en een herdruk die bij dezelfde logistieke eenheid hoort. Maak uitzonderingen expliciet. Als een bevoegde medewerker tekorten mag toestaan, vraagt dat een andere test dan een systeem dat negatieve beschikbaarheid volledig verbiedt.
Gebruik kleine, begrijpelijke datasets. Met tien stuks op één locatie kun je een reserveringsconflict vaak duidelijker verklaren dan met een kopie van een groot magazijn. Voeg daarna de relevante complexiteit toe: een tweede eigenaar, partijen, eenheidsomrekening of voorraad onderweg.
Test iedere afspraak op de plek waar zij wordt bewaakt.
| Soort test | Wat toets je? | Logistiek voorbeeld |
|---|---|---|
| Procesregeltest | De beslissing op basis van concrete invoer. | Een geblokkeerde partij wordt niet aan een pick toegewezen. |
| Databasetest | Opslag, transacties en gelijktijdige wijzigingen. | Twee aanvragen kunnen de laatste voorraad niet allebei claimen. |
| Contracttest | De afgesproken berichten tussen toepassingen. | Hoeveelheid, eenheid en foutantwoord worden door beide kanten begrepen. |
| Ketentest | Een volledige route langs de betrokken onderdelen. | Van orderimport tot pickbevestiging en verzendstatus. |
| Praktijktest | Bediening en apparatuur in de beoogde werkomgeving. | Een picker kan met handschoenen een afwijking afhandelen. |
Deze tests vullen elkaar aan. Een snelle test van een reserveringsregel vindt veel fouten zonder een complete gebruikersinterface te openen. De echte database is nodig om uitspraken over transacties en gelijktijdigheid te toetsen. Een werkend softwarebericht bewijst nog niet dat een label goed leesbaar uit de printer komt.
Houd de tests gekoppeld aan gedrag dat ertoe doet. Een controle die alleen bevestigt dat een interne functie is aangeroepen kan groen blijven terwijl de voorraad verkeerd wordt geboekt. Controleer het zichtbare resultaat en de relevante toestand na de handeling.
Een contracttest is geen bewijs van de hele boeking.
Een contracttest controleert of verzender en ontvanger dezelfde verwachtingen hebben over een aanvraag of antwoord. Dat helpt wanneer een ERP-koppeling een veld wijzigt of een nieuwe status toevoegt. De test laat bijvoorbeeld zien of de ontvanger de verpakkingseenheid begrijpt en of de afnemer een afgesproken foutantwoord kan verwerken.
Zo'n test bewijst op zichzelf niet dat de ontvanger de juiste voorraadmutatie heeft opgeslagen. Daarvoor is een functionele test van de verwerking nodig. Ook een lokale nep-API, of mock, bewijst alleen dat je software met het nagebouwde gedrag omgaat. Als het echte pakket anders reageert, blijft die test mogelijk gewoon slagen.
Toets daarom waar mogelijk het contract ook tegen de echte aanbieder in een geschikte testomgeving. Als die samenwerking of omgeving niet beschikbaar is, leg die beperking vast en organiseer een gerichte aansluitproef. Houd voorbeeldantwoorden actueel bij wijzigingen; oude voorbeelden mogen niet ongemerkt de enige waarheid worden.
Onderbreek het proces op het lastige moment.
Een verbinding verbreken vóór het werk begint is eenvoudiger te begrijpen dan een verloren antwoord ná een boeking. Test juist die tweede situatie. De toepassing moet het resultaat kunnen controleren of dezelfde handeling veilig opnieuw kunnen aanbieden. De technische voorwaarden staan in onze gids over API-koppelingen.
Een fictieve testreeks voor een reservering kan er zo uitzien:
- Zet tien beschikbare stuks klaar en start twee aanvragen voor zeven stuks gelijktijdig.
- Controleer dat maximaal één volledige reservering slaagt als deeltoewijzing niet is toegestaan.
- Herhaal de geslaagde aanvraag met dezelfde handeling-ID; controleer dat de claim niet groeit.
- Annuleer een deel en controleer dat alleen dat deel weer beschikbaar komt.
- Laat een pick en het verlopen van dezelfde reservering samenlopen; controleer welke toegestane uitkomst is gekozen.
Gebruik bij zulke tests gerichte synchronisatie om aanvragen echt te laten overlappen. Willekeurig even wachten maakt een timingfout moeilijk reproduceerbaar. Controleer na afloop ook de mutaties en openstaande taken, niet alleen het antwoord aan de aanvrager. Lees voor het model achter deze test voorraad veilig reserveren.
Breng software en werkvloer bij elkaar.
Werk met representatieve labels, scanners, printers en netwerkcondities. Een barcode die met een toetsenbord wordt ingevoerd, toetst niet hoe een terminal scaninformatie aan de app aanbiedt. Een afdrukvoorbeeld op een scherm toont evenmin de werkelijke printkwaliteit. Laat medewerkers normale taken én herstelwerk uitvoeren.
Beproef daarnaast de belasting die jouw operatie kenmerkt. Denk aan veel scans tegelijk, een grote orderimport en rapportages rond hetzelfde tijdstip. Meet responstijd, achterstand en foutafhandeling. Een test met alleen een hoge hoeveelheid eenvoudige leesvragen zegt weinig over concurrerende voorraadboekingen.
Gebruik afgesproken testomgevingen en fictieve of passend voorbereide gegevens. Voorkom dat een ketentest werkelijk transport bestelt, een klant bericht of productievoorraad aanpast. Leg vast welke externe stappen zijn nagebootst en welke met de betrokken partij zijn beproefd. Dat maakt de uitkomst bruikbaar zonder meer zekerheid te suggereren dan de test levert.
Maak controle onderdeel van iedere wijziging.
Automatiseer de belangrijke procesregels en contracten zodat ze bij wijzigingen opnieuw worden gecontroleerd. Voeg bij een gevonden fout een gerichte test toe die het probleem zichtbaar maakt. Een verzameling tests geeft vooral vertrouwen als zij de risico’s van het systeem raakt en als fouten begrijpelijk terugkomen bij de makers.
Plan daarnaast controles die niet iedere keer volledig automatisch kunnen: werken met de beoogde apparatuur, een proefmigratie en een herstel- of terugvalscenario. Bij een databasewijziging kan terugrollen ingewikkelder zijn dan een vorige applicatieversie starten. Controleer daarom ook of oude en nieuwe software de gegevens tijdens de overgang kunnen verwerken.
Test de zichtbaarheid na ingebruikname mee. Komt een vastgelopen opdracht in de juiste werklijst? Wordt de achterstand na herstel kleiner? De gids over monitoring maakt deze dagelijkse controle concreet.
Blade neemt ontwerp, bouwen, testen en ingebruikname samen mee in maatwerksoftware. Bespreek een proces dat bij wijzigingen kwetsbaar is. Met één normale opdracht en een paar lastige uitzonderingen kunnen we bepalen welke werking de software aantoonbaar moet bewaken.