Dienst
Structured testing
Een migratie of een nieuwe versie valt of staat bij testen. Niet met wat rondklikken, maar gestructureerd — en op een omgeving die op uw echte situatie lijkt. Wij zetten dat op, en voeren het samen met u uit.
Waarom rondklikken niet volstaat
Wie na een migratie een uur door de toepassing klikt, vindt de luide problemen: een venster dat niet opent, een knop die niets doet. Dat zijn niet de problemen die geld kosten.
De dure fouten geven geen foutmelding. Ze geven een verkeerd bedrag op een factuur, een datum die een maand verschoven is, of een mail die nooit vertrokken is. Die vindt u niet door rond te klikken — alleen door gericht te vergelijken. We schreven er een apart artikel over: wat stilzwijgend breekt bij een 4D-migratie.
Wat een representatieve testomgeving betekent
Testen op een lege database met drie fictieve klanten bewijst niets. Een omgeving is pas representatief wanneer ze lijkt op de plaats waar de toepassing straks echt draait:
- Uw echte gegevens, in hun echte volume. Stille fouten zitten net in de uitzonderingen die een testset niet bevat: de klant met een apostrof in zijn naam, de factuur uit 2009, het dossier met vijfhonderd regels.
- Dezelfde regionale instellingen als uw gebruikers. Getal- en datumnotatie hangt daarvan af, en een testmachine staat zelden goed ingesteld.
- Dezelfde randapparatuur. Printers, scanners en kassa-apparatuur gedragen zich anders dan hun tegenhangers op een ontwikkelmachine.
- Dezelfde koppelingen. Mailserver, boekhoudpakket, webshop. Wat via een testadres of een simulatie loopt, is niet getest.
- Hetzelfde besturingssysteem als dat waar uw mensen straks op werken.
De fouten leven precies in de verschillen tussen uw testomgeving en de werkelijkheid. Hoe kleiner die verschillen, hoe minder verrassingen na de overstap.
Wat gestructureerd testen inhoudt
- Uitgeschreven scenario's in plaats van “eens iets proberen”. Wie hetzelfde pad twee keer volgt, kan resultaten vergelijken.
- Oud en nieuw naast elkaar. Dezelfde handelingen op dezelfde gegevens, in beide versies, en dan de uitvoer regel per regel vergelijken. Dit is de enige methode die stille fouten betrouwbaar aan het licht brengt.
- Vastleggen wat getest is. Niet alleen wat misging, maar ook wat goed ging — anders weet u na de derde ronde niet meer wat al gecontroleerd was.
- Opnieuw testen na elke aanpassing. Een herstelling op de ene plaats breekt geregeld iets op de andere.
Testen is geen fase op het einde. Het is wat bepaalt of u de overstap durft te maken. Een migratie die technisch klaar is maar niet doorgetest, blijft maanden op de plank liggen — en dat kost meer dan het testen zelf.
Waarmee wij u helpen
U hoeft dit niet alleen te doen. Wij nemen het testwerk op ons of begeleiden uw eigen mensen erin — wat het beste past bij uw organisatie:
- De testomgeving opzetten: een werkende kopie van uw gegevens, met de juiste instellingen, randapparatuur en koppelingen.
- Testscenario's opstellen op basis van uw werkelijke processen, niet op basis van wat de software toevallig kan.
- De vergelijking uitvoeren tussen oude en nieuwe versie, en de verschillen uitzoeken tot we weten waar ze vandaan komen.
- Uw mensen begeleiden die de tests doen. Zij kennen het proces; wij kennen de valkuilen.
- Rapporteren: wat is getest, wat is gevonden, wat staat nog open — zodat u op een onderbouwde basis beslist of u overschakelt.
Uw mensen kennen het proces, wij kennen de valkuilen
De beste tests komen van de mensen die er dagelijks mee werken. Zij weten welke uitzonderingen bestaan en welk rapport op de eerste van de maand moet kloppen. Wat vaak ontbreekt is de structuur eromheen: wat testen we, in welke volgorde, en hoe weten we of het antwoord juist is.
Wij vervangen uw mensen niet. We geven hun testwerk een vorm waarin het ook echt iets bewijst.