In het kort: Op 8 september 2026 verstoorde een softwarefout met een venster van ongeveer één milliseconde het Britse luchtverkeer. Zo’n zeldzame situatie aan de rand van wat een systeem verwacht, heet een edge case. Met edge cases testen zoek je die situaties bewust op, voordat productie ze voor je vindt.

Op dinsdag 8 september zorgde een fout in het Britse luchtverkeersleidingssysteem voor urenlange beperkingen in het hele Britse luchtruim. De Britse luchtvaartautoriteit CAA telt meer dan 2.000 vluchten die vertraagd, geannuleerd of omgeleid werden. Tien dagen later publiceerde luchtverkeersleider NATS een eerste rapport. De oorzaak: een softwarefout in een klein deel van het systeem, die zich alleen kon voordoen binnen ongeveer één milliseconde.

Dat is een schoolvoorbeeld van een edge case, en de lessen gelden voor elk team met software waar mensen op rekenen.

Wat gebeurde er op 8 september?

Volgens NATS zat de fout in een klein onderdeel van het National Airspace System. Dat onderdeel verwerkt verzoeken om vliegtuigen een identificatiecode te geven, waarmee verkeersleiders vluchten op de radar herkennen. Tijdens zo’n verzoek werd het systeem onderbroken door een bericht met een hogere prioriteit. Na dat bericht pakte het de gepauzeerde taak niet goed weer op. Het venster waarin dit mis kon gaan, was ongeveer één milliseconde. Alleen vluchten van het London Area Control-centrum werden geraakt, vooral vluchten op grote hoogte. Toch golden er in heel het Verenigd Koninkrijk beperkingen, zodat het systeem veilig opnieuw kon worden opgestart. Die beperkingen duurden ongeveer zes uur, en het wegwerken van de achterstand kostte meer dan twee dagen. NATS vond geen aanwijzing voor een cyberaanval en zegt dat de storing niets te maken heeft met die van 2023. Er is een tijdelijke maatregel, terwijl een definitieve oplossing op veiligheid wordt getest.

De CAA is een onafhankelijk onderzoek gestart. Dat kijkt naar hoe NATS zijn kritieke systemen vernieuwt, hoe eerdere aanbevelingen zijn opgevolgd en hoe goed de CAA zelf toezicht houdt. Een eerste rapport komt uiterlijk eind januari 2027, het eindrapport uiterlijk 8 maart 2027. Het rapport van NATS zegt niets over hoe de fout langs het testen kwam, dus daar speculeren we niet over.

Wat is een edge case bij testen?

Een edge case is een situatie aan de rand van wat een systeem verwacht. Hij is zeldzaam, maar hij kan voorkomen. Bij testen gaat het om een combinatie van invoer, timing of omstandigheden die bij normaal gebruik bijna nooit ontstaat. Sommige edge cases zitten op een grens, zoals het hoogste bedrag dat een formulier accepteert, of de laatste seconde voor middernacht. Andere zitten in de timing, zoals twee gebruikers die hetzelfde record op hetzelfde moment opslaan, of een taak die halverwege wordt onderbroken. De fout bij NATS hoort bij die tweede groep: een onderbreking op één precies moment. Edge cases worden makkelijk gemist, omdat de gewone testroute er nooit komt. Een tester klikt door het normale pad, waar alles netjes op volgorde binnenkomt. Het systeem in productie verwerkt duizenden gebeurtenissen, en een paar daarvan komen op het verkeerde moment.

Waarom glippen timingfouten door gewone tests heen?

Timingfouten glippen erdoor omdat de meeste tests stap voor stap draaien, netjes op volgorde, op een rustig systeem. Een test stuurt een verzoek, wacht op het antwoord en controleert het. Daartussen gebeurt niets. In productie gaat het anders. Berichten komen tegelijk binnen, dringend werk gaat voor en taken worden gepauzeerd en later weer opgepakt. Een fout die alleen optreedt als een gebeurtenis precies binnen één milliseconde valt, kan duizenden testruns doorstaan zonder zich te laten zien. Dezelfde test nog eens draaien laat de fout ook zelden terugkomen. Daarom kan een team terecht zeggen dat het getest heeft, terwijl de fout er toch nog in zit. Om zulke fouten te vinden, heb je tests nodig die drukke, rommelige omstandigheden bewust nabootsen. Je hebt ook runs nodig die vaak genoeg herhalen om het zeldzame moment te raken.

Hoe test je edge cases die je niet kunt voorspellen?

Je kunt niet elke edge case vooraf bedenken. Wel kun je de kans vergroten dat hij eerst in een test opduikt. Begin met de edge cases die je kunt benoemen. Boots daarna de drukke, rommelige omstandigheden van productie bewust na, en laat geautomatiseerde runs vaak genoeg herhalen om het zeldzame moment te raken. Vijf technieken helpen daarbij:

• Grenswaarden: test net onder, op en net boven elke grens. Het ISTQB noemt dit grenswaardenanalyse.
• Onderbrekingen: pauzeer lange taken voor dringend werk en controleer of ze goed verdergaan.
• Belasting: stuur veel verzoeken tegelijk, met dringende berichten ertussen.
• Storingen veroorzaken: vertraag een dienst, verbreek een verbinding of herstart een onderdeel halverwege een taak.
• Herhaling: laat geautomatiseerde tests elke nacht draaien, met wisselende data en timing, zodat de zeldzame combinatie duizenden kansen krijgt.

Voor de Blankenburgverbinding, de tunnel bij Rotterdam, testten we in een speciaal gebouwde testfaciliteit die productie zo goed mogelijk nabootste. Daar simuleerden we storingen aan apparatuur, noodsituaties in de tunnel en echte verkeerssituaties.

Waarom test je ook het herstel?

Elk systeem faalt een keer, en het herstel bepaalt hoeveel die storing kost. Bij NATS duurde de fout een milliseconde en de beperkingen ongeveer zes uur. De meeste schade ontstond na de fout: veilig stoppen, opnieuw opstarten en de achterstand wegwerken. Dat geldt ook voor een webwinkel, een bank of een logistiek platform. Test daarom de herstart zelf. Hoe lang duurt die? Wat gebeurt er met transacties die halverwege waren? Wie besluit dat alles weer aan mag? Is een herstelprocedure nooit geoefend, dan weet niemand hoe lang hij duurt. Oefen hem regelmatig in een testomgeving, en klok de tijd. Bij de Blankenburgverbinding bevestigden uitgebreide failover-tests dat de back-upsystemen direct en zonder onderbreking inschakelden.

Wat betekent dit voor je team?

Kies één proces waar een storing echt pijn doet. Schrijf de grenzen op, de lange taken en de momenten waarop het kan worden onderbroken. Maak voor elk daarvan een test, en zet die in je geautomatiseerde regressietest, zodat ze elke nacht draaien. Oefen daarna één keer het herstel, met een stopwatch erbij.

Nekst bouwt en draait deze tests samen met je team. Met Test Automation as a Service draait je regressietest, inclusief edge cases, elke nacht, en wij houden hem draaiend. Voor kritieke systemen in infrastructuur en industrie test ons team van Smart Industry Solutions besturingssoftware onder realistische omstandigheden.

Veelgestelde vragen

Wat is een edge case bij testen?

Een edge case is een zeldzame situatie aan de rand van wat een systeem verwacht. Denk aan een maximale waarde, twee acties op hetzelfde moment of een onderbreking halverwege een taak. Bij het testen van edge cases breng je die situaties bewust tot stand om te zien hoe het systeem reageert.

Wat zijn voorbeelden van edge cases?

Een bestelling van precies het maximale bedrag. Een datum in de nacht dat de klok verzet wordt. Twee gebruikers die tegelijk hetzelfde record wijzigen. Een taak die wordt onderbroken en daarna verder moet. De fout bij NATS op 8 september was een onderbreking op één precies moment.

Wat is het verschil tussen een use case en een edge case?

Een use case beschrijft hoe mensen een systeem normaal gebruiken, zoals een bestelling plaatsen. Een edge case is een zeldzame variant aan de rand daarvan, zoals een bestelling plaatsen terwijl de betaaldienst herstart. Je hebt ze allebei nodig: use cases voor de hoofdroute, edge cases voor wat daaromheen mis kan gaan.