Stel je voor dat de belangrijkste software van je bedrijf plotseling kapot gaat: wat zou er gebeuren? Bestellingen kunnen verloren gaan, deadlines kunnen worden gemist, maar klanten zouden zeker klagen.
Dit nachtmerriescenario is te vermijden: door een continu en rigoureus testproces te implementeren, dat problemen ondervangt voordat ze chaos veroorzaken. Maar het implementeren van een dergelijk proces in uw organisatie is makkelijker gezegd dan gedaan.
In dit artikel leest u alles waar u aan moet denken als u in uw bedrijf aan de slag gaat met testen, en hoe u op de lange termijn kunt profiteren van testen.
Best practices testen voor productteams
Het eerste deel van dit artikel behandelt het proces van het implementeren van testen in uw workflow.
Implementeer een testcultuur in uw team
Het succesvol introduceren van testen in uw team vereist dat iedereen een gemeenschappelijke mentaliteit deelt en kwaliteit niet als een last ziet, maar als een investering. Dit is een proces dat, net als elke andere culturele verschuiving, tijd en consistentie vereist.
Eén ding dat deze cultuur kan helpen vormgeven zijn regelmatige bijeenkomsten om defecten te bespreken, de impact die ze hadden, waar ze vandaan kwamen en wat er nodig was om ze te verhelpen. Dit helpt om het bewustzijn te creëren waarom het goed is om dergelijke defecten überhaupt te voorkomen.
Het hebben van een toegewijd persoon in het team die de inspanning overziet en aanstuurt, kan de kans op succes sterk vergroten. Iemand die team- of zelfs organisatiebrede richtlijnen definieert, best practices verzamelt en deelt, en pleit voor de inspanningen op alle niveaus.
Een ander nuttig instrument kan zijn om de ondersteunende rol van uw product te roteren. Het verkrijgen van ongefilterde inzichten uit de eerste hand van uw klanten en het leren kennen van de dagelijkse problemen waarmee zij met uw product worden geconfronteerd, kan een waardevolle ervaring zijn voor productmanagers, ontwerpers en ontwikkelaars.
Het doel is dat iedereen in uw team begrijpt dat kwaliteit een kenmerk is, net zo belangrijk als elke andere functionaliteit die u voor uw product bouwt. Zodra iedereen die mentaliteit heeft aangenomen, is het een natuurlijke ontwikkeling om te begrijpen dat tests ook een kenmerk zijn. Omdat tests de kwaliteit van de verzending garanderen.
Een stap voor stap testproces
Zodra er afstemming is tussen de verschillende teams die betrokken zijn bij productontwikkeling, kunt u het bestaan en het gebruik van tests verder formaliseren.
Maak tests onderdeel van de "Definition of Done"
Door tests toe te voegen als functievereiste, geeft u aan dat een functie pas klaar is voor verzending als deze correct en automatisch is getest
Voer regelmatig tests uit
Eenmaal geïmplementeerd kunnen geautomatiseerde tests uw waarborg zijn in elke stap van het ontwikkelingsproces. Ze hebben geen menselijke tussenkomst nodig en kunnen worden uitgevoerd tijdens elke kritieke stap van uw ontwikkelingspijplijn. Bijvoorbeeld:
- Bij elke verplichting.
- Bij elke pull-request.
- Na elke volledige release of omgevingswijziging.
Als u in uw productieomgeving afhankelijk bent van services van derden, kan het zelfs zinvol zijn om uw tests uit te voeren op de productieomgeving om ervoor te zorgen dat API's van derden zich gedragen zoals verwacht.
Definieer en verzamel statistieken
Het definiëren van een reeks statistieken is belangrijk om de effectiviteit van uw tests en de impact van testworkflows op uw bedrijf te meten. Hier volgen enkele voorbeelden van statistieken die u kunt gebruiken:
- Releases per maand : Een hoger aantal releases per maand kan duiden op een flexibeler ontwikkelingsproces. Geautomatiseerd testen speelt hierbij een sleutelrol door ervoor te zorgen dat releases met vertrouwen kunnen doorgaan.
- Bugrapporten : een afnemende trend in bugrapporten kan een positief teken zijn dat uw test- (en ontwikkelingsprocessen) effectief zijn.
- Testdekking : hoewel dit nooit een exacte maatstaf is, kan de dekking een goede indicatie zijn van hoe diep u kritische gebruiksscenario's test.
Houd er rekening mee dat deze statistieken ook worden beïnvloed door andere factoren die deze kunnen vertekenen. Het aantal releases kan bijvoorbeeld tijdens de feestdagen dalen, terwijl de bugrapporten stijgen. Vertrouw dus niet op slechts een paar en zorg ervoor dat u deze kruist met andere gegevens die beschikbaar zijn voor uw team.
Wanneer u deze stappen met uw team succesvol implementeert, zal de gezondheid van uw product op de lange termijn zeker ten goede komen. Maar er is nog meer wat je kunt doen!
Best practices testen voor systeembeheerders
Productteams kunnen niet alleen werken. Ze vertrouwen op de hardware, tools en infrastructuur die door systeembeheerders worden onderhouden. Hoewel systeembeheerders doorgaans niet direct bijdragen aan de productontwikkeling, kunnen ze nog steeds de ontwikkelingsworkflow voorgoed beïnvloeden. Bijvoorbeeld door actief de browserversie te beheren die bepaalde gebruikersgroepen in het bedrijf gebruiken.
In dit tweede deel van het artikel wordt uitgelegd hoe dit werkt, met behulp van de kanalen en het bedrijfsbeleid van Chrome.
Chrome-releasekanalen
Standaard worden Chrome-updates automatisch uitgevoerd om ervoor te zorgen dat elke gebruiker de nieuwste, meest stabiele en veilige versie van Chrome gebruikt, inclusief alle nieuwste functies: de versie van Chrome die op het stabiele kanaal is uitgebracht.
Als bedrijf dat een webgebaseerd product ontwikkelt, wilt u wellicht vóór het stabiele kanaal een browser gebruiken, zodat uw productteams de tijd hebben om uw product aan te passen aan wijzigingen op het webplatform.
Voor dit gebruik biedt Chrome in totaal vier releasekanalen, bedoeld voor verschillende gebruikersgroepen.
In het geval van Chrome zijn er verschillende releasekanalen die u kunt gebruiken om te anticiperen op toekomstige browserwijzigingen en de nieuwste functies te testen voordat ze algemeen beschikbaar zijn:
- Stabiel kanaal : dit is waar de meeste gebruikers zich bevinden. Het stabiele kanaal wordt automatisch bijgewerkt wanneer er een nieuwe Chrome-release is, wat maandelijks gebeurt.
- Bètakanaal : deze versie wordt over vier tot zes weken stabiel, waardoor je de kans krijgt een aankomende stabiele release te bekijken en te testen en je erop voor te bereiden.
- Ontwikkelaarskanaal : dit kanaal krijgt één keer per week een nieuwe versie van Chrome en bevat de nieuwste oplossingen die uiteindelijk naar de bètaversie gaan. Zoals de naam van het kanaal doet vermoeden, is het in ontwikkeling en kan daarom onverwacht kapot gaan, maar het bevat ook de nieuwste functies, soms lang voordat ze hun weg vinden naar stable. Dat maakt het dev-kanaal een geweldig hulpmiddel voor prototyping en geavanceerde ontwikkeling.
- Canarisch kanaal : het meest experimentele kanaal, met alle nieuwste functies, maar zonder veel tests. Minstens dagelijks vrijgegeven.
Als je meer wilt weten over de kanalen van Chrome, bekijk dan de relevante Chrome Concepts-aflevering .
Kanalen inzetten in een voorbeeldorganisatie
De structuur van productteams verschilt per organisatie, omdat er geen one size fits all-aanpak voor softwareontwikkeling bestaat. Als voorbeeld gaan we uit van een team met de volgende rollen: Product Management, UX en UI, Engineering, Operations en Support.
Voor een organisatie als deze kun je denken aan de volgende kanaalverdeling:
- Productbeheer : PM's kunnen zich meestal op het stabiele kanaal bevinden, om dezelfde versie te gebruiken als de meeste gebruikers. Af en toe kunnen ze het bèta- of ontwikkelaarskanaal gebruiken als ze aan een functie werken waarvoor een API vereist is die nog niet is gelanceerd.
- Engineering en UX : Delen van deze teams kunnen zich op het ontwikkelaarskanaal bevinden, om hen toegang te geven tot de nieuwste functies, zoals View Transitions , zelfs voordat ze stabiel zijn.
- Operaties : Kan in bètafase zijn, om te voorzien dat breuk gevolgen heeft voor gebruikers.
- Ondersteuning : Kan op het stabiele kanaal blijven, om ervoor te zorgen dat ze met het product communiceren met dezelfde browser als de meeste van uw klanten.
Gebruik bedrijfsbeleid om kanalen te beheren
In plaats van richtlijnen te geven en de beslissing over te laten welk kanaal te gebruiken, biedt Chrome ook bedrijfs- en beheertools om actief te beheren welk kanaal elke gebruiker uiteindelijk gebruikt. Dit is nuttig omdat hierdoor het testoppervlak onmiddellijk wordt vergroot van een paar individuele gebruikers naar een deterministische groep gebruikers, waardoor breuken zo vroeg mogelijk en op een traceerbare manier kunnen worden geïdentificeerd.
Als u dat controleniveau wilt gebruiken, is hier de configuratie die wij aanbevelen:
- Medewerkers (app-gebruikers) : Om het risico op verstoring te minimaliseren, moeten de meeste medewerkers zich op het stabiele kanaal bevinden, dat volledig is getest door het Chrome-testteam. Bovendien kan een klein percentage gebruikers (van 5 tot 10%) zich op het bètakanaal bevinden. Dit kanaal krijgt een preview van 4 tot 6 weken van Stable en kan beheerders helpen mogelijke problemen met een release te ontdekken, waardoor er meer tijd is om de problemen aan te pakken voordat de release naar alle anderen wordt uitgerold.
- IT-afdeling : Leden van de IT-afdeling, inclusief systeembeheerders zelf, kunnen op het bèta- of ontwikkelaarskanaal zijn om een voorproefje van 4 tot 6 of 9 tot 12 weken te krijgen van wat er naar de stabiele versie van Chrome komt.
Kanalen voor release op lange termijn
De productontwikkeling gaat mogelijk niet zo snel als gepland en de releasefrequentie van Chrome van een maand is mogelijk te hoog. Voor dit gebruik biedt Chrome een uitgebreid stabiel kanaal waarmee u minder vaak functie-updates kunt ontvangen, maar toch beveiligingsoplossingen kunt ontvangen. Dit kanaal wordt elke acht weken bijgewerkt.
Het volgende diagram laat zien hoe verschillende mijlpalen verlopen via de verschillende releasekanalen van Chrome :
- Zowel stable als extended stable verzenden de eerste vier weken dezelfde versies, waarna de twee uiteenlopen.
- Er is geen uitgebreid bètakanaal; in plaats daarvan wordt de standaard bètacyclus van vier weken gebruikt om zowel stabiel als verlengd stabiel te stabiliseren. Bedrijven die ervoor kiezen om deel te nemen aan de verlengde stabiele periode van acht weken moeten het bètakanaal blijven gebruiken zoals ze dat nu doen, om proactief problemen te identificeren die van invloed kunnen zijn op hun omgeving.
Conclusie
Testen is een cruciaal onderdeel van softwareontwikkelingsbedrijven om de kwaliteit van hun producten te waarborgen en ook een belangrijke stap voor systeembeheerders, om medewerkers van een organisatie toegang te geven tot hoogwaardige software en verstoring van bedrijfsprocessen te voorkomen.
Om te slagen bij het implementeren van een testworkflow binnen uw organisatie is het belangrijk dat iedereen de gemeenschappelijke mentaliteit deelt dat kwaliteit en daarom testen een kenmerk is.
In dit artikel hebben we verschillende manieren besproken om best practices op het gebied van testen in uw organisatie te integreren. Voor een diepgaande evaluatie van de bestaande testtools kunt u ons artikel Tools van Chrome voor probleemloos, geautomatiseerd testen raadplegen.
Voor praktische begeleiding bij het testen, van begin tot eind, bekijk ook onze recente cursus Learn Testing en best practices voor testautomatisering op web.dev.