Onze nieuwe klant is nogal een lastig type. Moppert snel, bij de minste of geringste wijziging trekt ie aan de bel. Als we hier bij Techniek een wijziging doorvoeren die de functionaliteit van ons platform verandert, kun je er vanuit gaan dat er iemand moord en brand schreeuwt. En dat is precies waarom we er zo blij mee zijn.

Wie is deze nieuwe klant?

Onze nieuwste klant is RoboKlant v1.0. Opgebouwd uit Python en wat liefde van onze ingenieurs. In minder dan drie minuten test onze RoboKlant duizenden functies van ons platform op verwacht gedrag. Gedraagt een functie zich anders dan eerst, dan hebben we een change verkeerd ingeschat en moeten we terug naar de tekentafel.

De kwaliteit van een systeem verbeteren met behulp van testen is natuurlijk niet nieuw. Er zijn unit testen, performance testen, fuzzy testen, whitebox testen en acceptatietesten. Testen zorgt ervoor dat verwachting en werkelijkheid dichter bij elkaar komen te liggen — meestal door de werkelijkheid aan te passen. Zo gebruiken vrijwel alle hosting providers een applicatie zoals Nagios om het gedrag van hun (lopende) systeem te toetsen. Is een server drukker dan hij zou moeten zijn? Dan gaat er een SMS naar de dienstdoende techneut (bij ons respectvol met Held aangesproken) die de oorzaakt verhelpt, of de test aanpast.

Nagios is echter niet bruikbaar voor het grondig doorlichten van alle functionaliteiten van een systeem. Nagios moet zo vaak mogelijk testen (liefst iedere seconde) zodat er minimale tijd zit tussen incident en notificatie. Maar iedere seconde een volledige testsuite draaien zou al onze systemen platleggen. Nagios kan dus enkel op eenvoudig te verzamelen uiterlijke kenmerken toetsen. Maar toch willen we ook een grondige functionele toets. Met name als we een nieuwe feature uitproberen in een testopstelling, maar niet zeker weten wat het effect zou zijn op echte sites met echte bezoekers.

Wat doet ons nieuwe testsysteem?

Byte Blackbox

Byte Blackbox

De Roboklant is een acceptatie testsuite op basis van het blackbox principe. Het simuleert een klant en benadert zoveel mogelijk de werkelijke omgeving van een klant. Dus we draaien het vanaf een IP bij een andere provider, zodat we specifieke firewall regels uit kunnen sluiten. We schrijven de tests zodat deze representatief zijn voor 99% van de gebruikspatronen. Dus “typisch” gebruik: uploaden van een bestand, versturen van een mail, instellen van een cronjob, het plaatsen van een bestelling op een Magento webwinkel, het resizen van een plaatje met een PHP script.

Testen we daarmee voldoende? Ons platform is een complex systeem met heel veel variabelen. Stel dat het ‘slechts’ 100 variabelen zijn, dan zijn er 100 faculteit mogelijke combinaties. Dit is een getal met 157 nullen. Ik schat dat wij tussen de 50.000 en 100.000 relevante variabelen hebben. De permutatie van al die variabelen levert dus een ontelbare hoeveelheid test situaties. 100% testen is, natuurkundig gezien, onmogelijk. Daar is wel iets op te verzinnen:

  1. Identificeren van de meest gangbare combinaties van variabelen. Zo kun je met relatief weinig testen, veel situaties dekken.
  2. Onderdelen van je systeem isoleren en hier de in- en output afzonderlijk van testen (unittests).

Wij gaan door met het verbeteren en uitbreiden van onze testen op alle niveaus, want er is nog veel verbetering mogelijk. Het zou misschien een goed idee zijn, om de applicatietesten van onze klanten te integreren met onze platform testen. Zodra wij een nieuwe PHP versie hebben, krijg je automatisch een mail als jouw applicatietest daarop faalt. Om maar eens wat te noemen. Ideeën hierover? Zet ze graag in de comments, ik ben erg benieuwd!

Ondertussen hoor ik onze Roboklant pruttelen. Eens kijken wat hij heeft opgespoord.

 

Scan je eigen Magento shop op veiligheidslekken