Testdesign: een essentiële QA-vaardigheid
Een van de belangrijkste misvattingen in het huidige testlandschap is dat testen in productie slechts drie vaardigheden vereist: procesexpertise, kennis van geautomatiseerde testtools en capaciteiten op het gebied van incidentbeheer. Deze zijn belangrijk, maar wat opvallend ontbreekt—niet alleen in deze lijst, maar ook in de gedachten van personeelsmanagers—is iets waarvan je zou denken dat het het meest fundamentele zou zijn:
Het vermogen om een praktische test voor productieomgevingen te ontwerpen.
Het zou komisch zijn als het niet zo verontrustend was dat bijna geen enkele organisatie expertise op het gebied van belangrijke QA-vaardigheden prioriteit geeft bij het implementeren van strategieën voor testen in productie.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Of een test nu handmatig of via automatisering wordt uitgevoerd in een live productiesysteem, je moet eerst weten hoe je er een ontwerpt die bruikbare inzichten oplevert zonder de gebruikerservaring te verstoren, toch?
Het zou komisch zijn als het niet zo verontrustend was dat bijna geen enkele organisatie expertise op het gebied van testontwerp prioriteit geeft bij het implementeren van strategieën voor testen in productie. Of een test nu handmatig in een gecontroleerde omgeving of geautomatiseerd in een live productiesysteem wordt uitgevoerd, je moet eerst weten hoe je er een ontwerpt die bruikbare inzichten oplevert zonder de gebruikerservaring te verstoren, toch?
Er is één duidelijk probleem met het uitsluiten van expertise op het gebied van testontwerp uit je aanpak voor testen in productie:
Is het niet essentieel om te weten dat de persoon die tests in je productieomgeving implementeert, begrijpt wat een betekenisvolle test inhoudt?
Want door slecht ontworpen tests in productie te automatiseren, krijg je sneller onbetrouwbare gegevens en creëer je onnodige risico's? En "agile" zijn tijdens het incompetent testen in productie lijkt mij geen echte verbetering, behalve misschien voor de scrummaster.
Het belang en de discipline van testontwerp, vooral voor scenario's waarin in productie wordt getest, zijn al veel te lang aan heropleving toe. Beschouw dit als mijn bijdrage aan die inspanning.
Wat is essentieel voor effectief testen in productie?
De eerste stap naar het beheersen van testen in productie is het maken van enkele essentiële onderscheidingen die de meeste QA-professionals intuïtief ongetwijfeld al bekend zijn, maar die zelden systematisch worden gepresenteerd in contexten waarin in productie wordt getest.
Laten we deze fundamentele concepten verkennen die je aanpak voor testen in productie zullen transformeren.
Expliciete versus impliciete functionaliteit in productieomgevingen
Laten we beginnen met het cruciale onderscheid tussen expliciete en impliciete functionaliteit bij het testen in productie.
Het eerste is wat de meesten van ons beschouwen als "functionaliteit". Het verwijst naar functies en mogelijkheden die formeel zijn gespecificeerd door Product en waarvan de formele specificatie de implementatie ervan binnen Engineering aanstuurt. Bij het testen in productie vormen deze expliciete functies doorgaans de focus van monitoring- en observeerbaarheidstools.
Daarom lijkt het testen van expliciete functionaliteit in productie misschien eenvoudig, maar zelfs bij goed gedefinieerde functies is dat niet het geval, zoals we later zullen zien. In ieder geval maakt het specificiteitsniveau van expliciete functionaliteit het gemakkelijker om er een raamwerk van productietests omheen te bouwen (of de illusie van zo'n raamwerk).
Impliciete functionaliteit in een productieomgeving is iets heel anders.
Deze bestaat uit gedragingen en reacties op gebruikers- of omgevingsinvoer die niet formeel zijn gedefinieerd of voorzien. Het niet adequaat ontwerpen van tests voor deze impliciete functionaliteit in productie is veruit de bron van de meeste kritieke bugs die worden ontdekt nadat het product is uitgerold (de andere bron is ontoereikend testen in omgevingen met afwijkende hardware/software/apparaten).
Met andere woorden:
Het testen van impliciete functionaliteit in productie vereist aanzienlijke vindingrijkheid en verbeeldingskracht. Het is het werkelijk creatieve onderdeel van productieteststrategieën.
Het testen van impliciete functionaliteit in productieomgevingen vereist een zekere mate van duivelse slimheid om er goed in te worden, en helaas kan dat niet worden aangeleerd via standaard QA-processen.
Geen enkele agile methodologie of geautomatiseerd testframework leert je hoe je impliciete functionaliteit in productie effectief test, maar goed testontwerp kan dit wel stimuleren.
Dus hoe definieer je een testontwerpstrategie voor impliciete functionaliteit in je productieomgeving? Gelukkig kan het. Maar voordat we rechtstreeks op die vraag ingaan, verkennen we eerst nog enkele verdere relevante onderscheidingen die cruciaal zijn voor effectief testen in productie.
Positief versus negatief testen
Belangrijkste punt: Bij het testen in productie vereisen zowel positief als negatief testen speciale overwegingen die verder gaan dan traditionele QA-benaderingen.
De meeste mensen die in QA werken begrijpen het basisverschil tussen deze twee testtypen:
- Positief testen in productie: Valideren dat functies werken zoals ontworpen in liveomgevingen
- Negatief testen in productie: Strategisch testen hoe je systeem reageert op onverwachte invoer zonder echte gebruikers te verstoren
Waarom testen in productie anders is
Hoewel deze onderscheidingen conceptueel duidelijk zijn, brengt testen in productie unieke uitdagingen met zich mee:
- Grotere belangen: Randgevallen hebben gevolgen voor echte klanten en bedrijfsactiviteiten
- Complexiteit uit de echte wereld: Gebruikersgedrag volgt zelden voorspelbare patronen
- Bedrijfscontinuïteit: Testen mag de normale bedrijfsvoering niet verstoren
Verder kijken dan de specificatie
Specificaties bieden zelden alles wat nodig is om effectief te testen in productie:
Als je te afhankelijk bent van de specificatie—of die nu afkomstig is van Product of Engineering—beperkt dat je manier van denken. Dit is vooral problematisch bij het testen in productie, waar gebruikspatronen uit de echte wereld vaak afwijken van specificaties.
Dit illustreert wat ik "de empirische drogreden" noem: wachten tot iets je expliciet vertelt wat je moet doen voordat je het kunt begrijpen.
Een succesvol testontwerp voor productieomgevingen vereist:
- Een juiste parametrisering van functionaliteit
- Logisch nadenken over wat mogelijk is
- Aandacht voor interacties tussen zowel gebruikers als hun omgeving
Voorbeeld uit de echte wereld: onverwacht gedrag
In het Krijt van de softwarewereld (oftewel de jaren 80) testte ik software voor documentconversie en ontdekte ik verrassende mogelijkheden:
Afbeelding weergeven
Klassiek voorbeeld: In WordPerfect kon je midden in een alinea een opdracht voor regelafstand invoegen die alleen van invloed was op de daaropvolgende regels, waardoor alinea's ontstonden met twee verschillende waarden voor de regelafstand.
Moderne equivalenten bij het testen in productie:
- Onverwachte combinaties van gebruikersrechten in cloudapplicaties
- Onvoorziene reeksen API-aanvragen in microservicearchitecturen
- Racecondities in omgevingen met hoge gelijktijdigheid
Laten we nu de drie belangrijkste parameters verkennen die je aanpak voor productietests zullen aanscherpen:
1. Testen van de reikwijdte van functies
Definitie: Vaststellen hoe gebruikers functies kunnen inzetten in contexten of op manieren die tijdens het ontwerp nooit zijn bedacht.
Waarom dit belangrijk is voor het testen
Niet alle beperkingen worden tijdens de ontwikkeling voorzien. In productieomgevingen kan dit gebrek ernstige gevolgen hebben.
Verder kijken dan eenvoudige validatie
Houd bij het testen in productie rekening met deze grenzen:
Onthoud: Een functie valideren in productie betekent niet alleen bevestigen dat deze werkt zoals ontworpen, maar ook controleren dat de functie niet op onbedoelde manieren kan worden gebruikt die de stabiliteit of beveiliging van het systeem kunnen beïnvloeden.
2. Testen van workflowonderbrekingen in live systemen
Waarschuwing: Deze aanpak gaat ervan uit dat je al gedefinieerde workflows in productie test. Zo niet, pak dan eerst die basis aan!
Verder kijken dan het "standaardpad"
Verken bij het testen in productie deze kritieke workflowonderbrekingen:
✅ Onderbroken workflows: Proces gestart maar nooit voltooid
✅ Geannuleerde bewerkingen: Gebruiker annuleert het proces halverwege expliciet
✅ Opnieuw gestarte processen: Gebruiker probeert dezelfde actie meerdere keren uit te voeren
✅ Teruggaan: Gebruiker keert terug naar eerdere stappen met andere invoer
Implementatietips voor testen in productie
Gebruik technieken zoals functievlaggen om de blootstelling aan deze tests in productieomgevingen veilig te regelen.
Toepassingen uit de echte wereld
Tip van een expert: Deze scenario's worden zelden in specificaties vastgelegd, maar vertegenwoordigen wel echt gebruikersgedrag in productie.
3. Sequentieel karakter bij productietests
De uitdaging: In productiesystemen met meerdere gelijktijdige processen kan de volgorde van bewerkingen leiden tot onverwachte fouten die moeilijk te reproduceren zijn in testomgevingen.
Twee kritieke patronen in sequentieel gedrag
Voorafgaande bijdragende omstandigheden
Afbeelding weergeven
- Definitie: Gebeurtenissen die moeten plaatsvinden voordat een proces faalt
- Kenmerken: Komen mogelijk pas aan het licht na specifieke reeksen die zich onder natuurlijke omstandigheden pas na dagen voordoen
- Voorbeeld in productie: Gebruikersrechten gewijzigd → cache verloopt → specifieke API aangeroepen
Daaropvolgende bijdragende omstandigheden
- Definitie: Fouten die pas tijdens latere interacties aan het licht komen
- Manifestatie: De fout blijft verborgen totdat een latere bewerking plaatsvindt
- Voorbeeld in productie: Gegevens raken stilzwijgend beschadigd totdat een rapport wordt gegenereerd
Waarom is dit zo uitdagend?
Het bepalen van de reikwijdte van sequentiviteitstests in productie vereist:
- Intieme kennis van systeeminteracties
- Modellering van statusovergangen voor complexe processen
- Inzicht in zowel bedoelde als onbedoelde statuscombinaties
"Net als die dubbele regelafstandwaarden in één alinea kunnen deze onverwachte statussen grote problemen veroorzaken in productieomgevingen."
Essentiële hulpmiddelen voor sequentiviteitstests in productie
- Chaosengineering om bewust gecontroleerde fouten te introduceren
- Hulpmiddelen voor observeerbaarheid om statuswijzigingen in verschillende systemen te volgen
- Gedistribueerde tracering om aanvraagpaden door microservices te volgen
Kortom: Problemen met sequentieel gedrag vormen een van de rijkste bronnen van ernstige bugs in moderne productiesystemen. Geef dit aspect prioriteit in je teststrategie.
De kern
Functievlaggen veranderen testen in productie van een risicovolle praktijk in een gecontroleerd, datagestuurd proces. Doordat ze implementatie loskoppelen van vrijgave en directe mogelijkheden voor terugdraaien bieden, creëren ze een vangnet waarmee teams software onder reële omstandigheden kunnen valideren zonder de gebruikerservaring of systeemstabiliteit in gevaar te brengen.
Platformen voor functiebeheer bij productietests
Platformen voor functiebeheer hebben testen in productie veranderd van een risicovolle onderneming in een gecontroleerd, systematisch proces. Toch slagen veel organisaties er niet in deze hulpmiddelen effectief te benutten binnen hun strategie voor testontwerp.
De evolutie van risicobeheer in productie
Traditionele benaderingen van testen in productie gingen uit van binaire beslissingen: een functie was óf voor iedereen actief óf voor niemand. Platformen voor functiebeheer veranderen dit paradigma fundamenteel:
- Gedetailleerde controle: Test functies met specifieke gebruikerssegmenten in plaats van implementaties die alles-of-niets zijn
- Direct herstel: Schakel problematische functies uit zonder code-implementaties of terugdraaiacties
- Geleidelijke blootstelling: Vergroot de blootstelling aan gebruikers geleidelijk op basis van realtime prestatiegegevens
Verder dan eenvoudige functievlaggen
Hoewel eenvoudige functievlaggen al jaren bestaan, bieden moderne platformen voor functiebeheer cruciale mogelijkheden die productietests transformeren:
Wanneer ze goed in je strategie voor testontwerp worden geïntegreerd, maken platformen voor functiebeheer het volgende mogelijk:
- Gerichte risicobeheersing - Beperk de blootstelling aan nieuwe functies tot specifieke gebruikerssegmenten
- Validatie door echte gebruikers - Test met echte gebruikers in plaats van synthetische testgegevens
- Direct herstel - Pak problemen aan zonder noodimplementaties of terugdraaiacties
Integratie met hulpmiddelen voor observeerbaarheid
De ware kracht van platformen voor functiebeheer komt naar voren wanneer ze worden geïntegreerd met systemen voor observeerbaarheid en monitoring:
Traditionele aanpak:
- Problemen detecteren na volledige implementatie
- Handmatige verificatie van testresultaten
- Analyse achteraf na incidenten
Integratie van featurebeheer:
- Featureactivering correleren met systeemstatistieken
- Geautomatiseerde prestatiemonitoring per functievlag
- Realtime inzicht in de impact van functies
Impact in de praktijk: productietests transformeren
Organisaties die platforms voor featurebeheer implementeren, rapporteren aanzienlijke voordelen:
- Verminderde ernst van incidenten: "We kunnen functies al ruim vóór een marketinglancering in productie testen. En als een functie op de dag van de lancering problemen veroorzaakt, kunnen we deze gewoon uitschakelen met een noodschakelaar—zonder terugdraaiingen." — Chris Guidry, VP of Engineering, O'Reilly Media.
- Versnelde releasecycli: Teams bij IBM, TrueCar en andere toonaangevende bedrijven maken gebruik van featurebeheer voor tests in productie en profiteren van wat zij omschrijven als "veilige, onceremoniële releases".
- Uitgebreidere testdekking: Functievlaggen brengen randgevallen aan het licht die onmogelijk in gecontroleerde omgevingen kunnen worden gesimuleerd.
Praktische implementatie in testontwerp
Om platforms voor featurebeheer effectief op te nemen in je strategie voor testontwerp:
- Ontwerp verificatiepunten die aansluiten op overgangen van functievlaggen
- Maak terugvalscenario's voor elk onderdeel met een functievlag
- Stel prestatiedrempels vast die automatische uitschakeling van functies activeren
- Definieer segmentspecifieke testgevallen om gedrag in verschillende gebruikerspopulaties te valideren
- Documenteer afhankelijkheden tussen functievlaggen om ketenstoringen te voorkomen
Platforms voor featurebeheer vervangen doordacht testontwerp niet—ze versterken het. De kwaliteit van je productietests blijft fundamenteel afhangen van de mate waarin je je tests goed hebt ontworpen.
Veelvoorkomende valkuilen die je moet vermijden
Zelfs met robuust featurebeheer blijven er verschillende uitdagingen bestaan:
- Vlaggenachterstand - Verlaten of vergeten functievlaggen die technische schuld veroorzaken
- Onvoldoende monitoring - Er niet in slagen de status van functievlaggen te correleren met de systeemprestaties
- Overmoed - Productietests voortijdig verminderen
- Onderlinge afhankelijkheden tussen functievlaggen - Complexe relaties creëren die moeilijk op te lossen zijn
De kern
Platforms voor featurebeheer bieden krachtige mogelijkheden voor tests in productie, maar ze moeten zorgvuldig worden geïntegreerd in je algemene strategie voor testontwerp. De organisaties die de meeste waarde behalen, implementeren deze tools niet alleen—ze heroverwegen fundamenteel hoe testontwerp werkt in een omgeving met functievlaggen.
Wanneer featurebeheer correct wordt geïmplementeerd als onderdeel van een uitgebreide aanpak voor testontwerp, verandert het productietests van een noodzakelijk kwaad in een concurrentievoordeel.
Hulpmiddelen voor tests in productie: implementatie-uitdagingen
Hoewel functievlaggen en beheerplatforms de basis vormen voor tests in productie, brengt het bredere ecosysteem van hulpmiddelen zijn eigen implementatie-uitdagingen met zich mee. Het selecteren en configureren van de juiste hulpmiddelen vereist een zorgvuldige afweging van de capaciteiten van het team, de systeemarchitectuur en de behoeften van de organisatie.
Hulpmiddelen voor monitoring en observeerbaarheid
Effectieve tests in productie zijn afhankelijk van volledig inzicht in het systeemgedrag:
- Monitoring van applicatieprestaties (APM)
Voordelen: Biedt gedetailleerd inzicht in de prestaties van de volledige applicatiestack.
Uitdagingen: Vereist vaak aanzienlijke instrumentatie en kan te veel gegevens genereren, waardoor kleinere teams worden overspoeld. - Systemen voor logbeheer
Voordelen: Essentieel voor foutopsporing en forensische analyse tijdens productietests.
Uitdagingen: Kunnen overweldigende hoeveelheden gegevens genereren zonder de juiste strategieën voor filtering en indexering. - Gedistribueerde tracering
Voordelen: Biedt inzicht van begin tot eind in microservicearchitecturen.
Uitdagingen: De complexiteit van de implementatie neemt dramatisch toe in heterogene omgevingen met meerdere technologiestacks.
Systemen voor waarschuwingsbeheer
Een goede configuratie van waarschuwingen is cruciaal bij het testen van nieuwe functies in productie:
- Platformen voor waarschuwingaggregatie
Voordelen: Meldingen van meerdere bewakingssystemen consolideren.
Uitdagingen: Uitstekend voor incidentbeheer, maar kunnen storend zijn als ze niet zorgvuldig worden geconfigureerd om meldingsmoeheid te voorkomen. - Systemen voor incidentrespons
Voordelen: Communicatie tijdens productie-incidenten stroomlijnen.
Uitdagingen: Vereisen goed gedefinieerde draaiboeken en integratiepunten om effectief te zijn; kunnen extra overhead creëren voor eenvoudige implementaties.
Aandachtspunten voor de implementatie
Bij het implementeren van tools voor testen in productie moeten teams het volgende beoordelen:
- Schaalbaarheidsvereisten - Kan de tool uw verkeersvolumes en datagroei verwerken?
- Integratiemogelijkheden - Hoe eenvoudig kan de tool verbinding maken met uw bestaande toolketen?
- Resourceverbruik - Welke overhead introduceert de tool zelf?
- Expertise van het team - Beschikt u over de vaardigheden die nodig zijn om de waarde van de tool optimaal te benutten?
- Signaal-ruisverhouding - Kunt u betekenisvolle inzichten verkrijgen zonder te verdrinken in gegevens?
Veelvoorkomende valkuilen bij de implementatie
- Wildgroei aan tools - Het opstapelen van te veel overlappende oplossingen
- Onvolledige instrumentatie - Het missen van kritieke bewakingspunten
- Meldingsmoeheid - Het genereren van buitensporig veel meldingen die teams uiteindelijk negeren
- Onvoldoende context - Er niet in slagen statistieken te correleren met de impact op gebruikers
- Datasilo's - Geïsoleerde bewakingssystemen creëren die geen informatie delen
De juiste balans vinden
De meest succesvolle implementaties van testen in productie vinden een balans tussen:
- Uitgebreide bewaking versus beheersbare complexiteit
- Gedetailleerde inzichten versus een overvloed aan informatie
- Geautomatiseerde reacties versus menselijke beslismomenten
Begin bij het implementeren van testtools in productieomgevingen klein met gerichte doelstellingen en breid de dekking vervolgens geleidelijk uit naarmate uw team expertise ontwikkelt in zowel de tools als het interpreteren van de daaruit voortvloeiende gegevens.
Belasting, complexiteit, vertraging
Houd bij het ontwerpen van uw tests rekening met de macrofactoren belasting, complexiteit en vertraging. Deze kunnen van invloed zijn op de uitvoering of voltooiing van een verzoek, proces, of gebeurtenis.
De relevantie van systeembelasting zou duidelijk moeten zijn. Verzoeken of transacties die worden verwerkt tijdens perioden van hoge belastingstress van het systeem kunnen mislukken (in elke fase van het transactieproces).
Dit zou standaard onderdeel moeten zijn van uw testplanning. Zoals we allemaal weten, kan belasting ook worden gegenereerd als gevolg van het verzoek zelf—bijvoorbeeld een gegevensquery die de verwerking en verzending van enorme hoeveelheden gegevens activeert.
Complexiteit verwijst hier voornamelijk naar de complexiteit van verzoeken die aan een systeem worden voorgelegd. Deze complexiteit kan bestaan uit het aantal opgegeven voorwaarden (en de uitsluitingen en uitzonderingen daarop), het aantal databases (virtueel of anderszins) dat bij de verzoeken betrokken is, of de verwerkingstopologie van het systeem zelf.
In de context van deze bespreking gebruik ik vertraging om het optreden van tijdsintervallen in het verzoekproces aan te duiden, wat niet de gebruikelijke betekenis ervan is. Ik doel hier op gebruikersvertraging, niet op de responstijd van het systeem zelf.
Met andere woorden: hoe gedraagt de functie of mogelijkheid zich als de gebruiker bij een specifieke stap in het proces komt en daar vervolgens blijft wachten zonder iets te doen? Verloopt de systeemaanvraag na verloop van tijd (waarschijnlijk zou dat moeten)? Moet het systeem de gebruiker een melding tonen? Moet het in die toestand blijven tot het einde der tijden?
De antwoorden op deze vragen kunnen in de specificatie staan, maar het product dat wordt getest gedraagt zich mogelijk niet op die manier, en daarom testen we überhaupt.
Gebruikersrollen
Natuurlijk kunnen eindgebruikers op verschillende manieren met softwaresystemen communiceren. Dezelfde gebruiker kan afhankelijk van zijn handelingen verschillende rollen binnen het systeem aannemen.
Processen en diensten kunnen echter ook verschillende rollen en bijbehorende rechten hebben. Zorg er in beide gevallen voor dat uw testontwerp en planning, of het nu om functies of mogelijkheden gaat, alle mogelijke roltoestanden in overweging neemt en test.
Wat nu?
Op zoek naar meer tips voor testontwerp? En wil je je SaaS-groei en leiderschapsvaardigheden versterken?
Schrijf je in voor onze nieuwsbrief voor de nieuwste inzichten van CTO's en toekomstige technologieleiders.
We helpen je slimmer op te schalen en sterker leiding te geven met handleidingen, hulpmiddelen en strategieën van toonaangevende experts!
