Wat je in een sandbox test voordat je live gaat

Een checklist voor voordat je live gaat. De negatieve gevallen zijn degene die echte problemen vinden.

Een checklist voor voordat je live gaat. De negatieve gevallen zijn degene die echte problemen vinden.

Test eerst het negatieve geval

Iedereen controleert of het ding dat hij bouwde nu gebeurt. Veel minder mensen controleren of het níét gebeurt bij tickets die het niet hoort te raken, en daar zit de schade.

Voor elke regel: één ticket dat zou moeten passen, één dat dat niet zou moeten.

De checklist

1. Gaat hij af wanneer het hoort? Het voor de hand liggende geval.
2. Laat hij al het andere met rust? Het belangrijke.
3. En een ticket zonder waarde in het veld dat hij leest? Meestal de grootste groep.
4. Wat gebeurt er bij de tweede bijwerking? Triggers kunnen opnieuw afgaan en een loop vormen.
5. Waar staat hij in de volgorde? Een eerdere regel kan het ticket al hebben gewijzigd.
6. Wie krijgt er een e-mail? Tel de meldingen, ook die aan agents.

Lege velden zijn de klassieker

Een voorwaarde op een veld dat op een vijfde van de tickets is ingevuld, gedraagt zich anders op de andere vier vijfde. Alleen testen met een ingevuld veld test het minderheidsgeval.

Let op loops

Een trigger die een ticket bijwerkt kan een trigger laten afgaan, zichzelf inbegrepen. In een sandbox is dat een curiositeit; in productie zijn het duizenden meldingen.

Laat iemand anders het proberen

Jij test het pad dat je hebt gebouwd. Een collega doet het ding waar je niet op had gerekend, en dat is precies de bedoeling.

Schrijf op wat je hebt getest

Dan is het herhaalbaar de volgende keer dat je aan hetzelfde gebied komt, en het is bewijs als iemand vraagt of dit is gecontroleerd.

Zie ook

• Een inrichting van de ene omgeving naar de andere uitrollen
• Wat een sandbox is en waar hij voor is
• De volgorde van triggers en waarom die uitmaakt