Stel je voor dat de belangrijkste software van je bedrijf plotseling crasht – wat zou er dan gebeuren? Bestellingen zouden zoekraken, deadlines zouden worden gemist, maar klanten zouden ongetwijfeld klagen.
Dit nachtmerriescenario is te vermijden: door een continu en rigoureus testproces te implementeren dat problemen opspoort voordat ze chaos veroorzaken. Maar zo'n proces in uw organisatie implementeren is makkelijker gezegd dan gedaan.
In dit artikel leggen we u uit waar u over na moet denken wanneer u aan de slag gaat met testen binnen uw bedrijf. Ook leggen we uit hoe u op de lange termijn kunt profiteren van testen.
Best practices testen voor productteams
Het eerste deel van dit artikel beschrijft het proces voor het implementeren van testen in uw workflow.
Implementeer een testcultuur in uw team
Om testen succesvol in je team te introduceren, moet iedereen een gemeenschappelijke mindset hebben en kwaliteit niet als een last, maar als een investering zien. Dit is een proces dat, net als elke andere cultuurverandering, tijd en consistentie vereist.
Eén ding dat deze cultuur kan helpen vormgeven, zijn regelmatige bijeenkomsten om gebreken te bespreken, de impact die ze hadden, waar ze vandaan kwamen en wat er nodig was om ze te verhelpen. Dit helpt om bewustzijn te creëren over waarom het goed is om dergelijke gebreken überhaupt te voorkomen.
Een toegewijde persoon in het team die de inspanningen overziet en aanstuurt, kan de kans op succes aanzienlijk vergroten. Iemand die team- of zelfs organisatiebrede richtlijnen definieert, best practices verzamelt en deelt, en de inspanningen op alle niveaus bepleit.
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 over 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 je team begrijpt dat kwaliteit een feature is, net zo belangrijk als alle andere functionaliteit die je voor je product bouwt. Zodra iedereen die mentaliteit omarmt, is het een natuurlijke ontwikkeling om te begrijpen dat tests ook een feature zijn. Want tests zorgen voor de geleverde kwaliteit.
Een stapsgewijs testproces
Zodra de verschillende teams die betrokken zijn bij de productontwikkeling op één lijn zitten, kunt u het bestaan en gebruik van tests verder formaliseren.
Maak testen onderdeel van de 'Definitie van Klaar'
Door tests als een functie-eis toe te voegen, geeft u aan dat een functie niet gereed is voor verzending totdat deze op de juiste manier en automatisch is getest.
Voer regelmatig tests uit
Eenmaal geïmplementeerd, kunnen geautomatiseerde tests uw bescherming bieden in elke stap van het ontwikkelingsproces. Ze vereisen geen menselijke tussenkomst en kunnen worden uitgevoerd op elke kritieke stap in uw ontwikkelingspijplijn. Bijvoorbeeld:
- Bij elke commit.
- Bij elke pull-request.
- Na elke volledige release of verandering van omgeving.
Als u in uw productieomgeving afhankelijk bent van services van derden, kan het zelfs zinvol zijn om uw tests uit te voeren tegen de productieomgeving om te controleren of de API's van derden zich gedragen zoals verwacht.
Definieer en verzamel statistieken
Het definiëren van een set metrics is belangrijk om de effectiviteit van uw tests en de impact van testworkflows op uw bedrijf te meten. Hier zijn enkele voorbeelden van metrics die u kunt gebruiken:
- Releases per maand : Een hoger aantal releases per maand kan wijzen op een flexibeler ontwikkelingsproces. Geautomatiseerd testen speelt hierbij een sleutelrol door ervoor te zorgen dat releases met vertrouwen kunnen worden uitgevoerd.
- Bug-rapporten : Een dalende trend in bug-rapporten kan een positief teken zijn dat uw test- (en ontwikkelingsprocessen) effectief zijn.
- Testdekking : Hoewel het nooit een exacte maatstaf is, kan dekking een goede indicator zijn van hoe grondig u kritische use cases test.
Houd er rekening mee dat deze statistieken ook beïnvloed worden door andere factoren die ze kunnen vertekenen. Zo kan het aantal releases tijdens de feestdagen dalen, terwijl het aantal bugmeldingen toeneemt. Vertrouw dus niet op slechts een paar en zorg ervoor dat je ze combineert met andere gegevens die je team ter beschikking heeft.
Wanneer u deze stappen succesvol implementeert met uw team, zal uw productgezondheid op de lange termijn zeker verbeteren. Maar er is nog meer dat u kunt doen!
Best practices voor systeembeheerders testen
Productteams kunnen niet zelfstandig werken. Ze zijn afhankelijk van de hardware, tools en infrastructuur die door systeembeheerders worden beheerd. Hoewel systeembeheerders meestal niet direct bijdragen aan de productontwikkeling, kunnen ze de ontwikkelworkflow wel degelijk positief beïnvloeden. Bijvoorbeeld door actief de browserversie te beheren die bepaalde gebruikersgroepen binnen het bedrijf gebruiken.
In het tweede deel van het artikel wordt uitgelegd hoe dit werkt aan de hand van de kanalen en het bedrijfsbeleid van Chrome.
Chrome-releasekanalen
Standaard vindt Chrome automatische updates plaats om ervoor te zorgen dat elke gebruiker de nieuwste, stabielste en veiligste versie van Chrome gebruikt, inclusief alle nieuwste functies: de versie van Chrome die is uitgebracht op het stabiele kanaal.
Als bedrijf dat een webgebaseerd product ontwikkelt, wilt u wellicht een browser gebruiken vóór het stabiele kanaal. Zo hebben uw productteams de tijd om uw product aan te passen aan wijzigingen op het webplatform.
Voor dit gebruiksvoorbeeld biedt Chrome in totaal vier releasekanalen, bedoeld voor verschillende gebruikersgroepen.
In het geval van Chrome zijn er verschillende releasekanalen die u kunt gebruiken om toekomstige browserwijzigingen te anticiperen 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 zal binnen vier tot zes weken stabiel zijn, zodat u de kans krijgt om een aankomende stabiele versie te bekijken en testen en u hierop voor te bereiden.
- Dev-kanaal : Dit kanaal krijgt wekelijks een nieuwe versie van Chrome en bevat alle nieuwste fixes die uiteindelijk in de bètaversie terechtkomen. Zoals de naam van het kanaal al doet vermoeden, is het in ontwikkeling en kan het daardoor onverwachts kapotgaan. Het bevat echter ook de nieuwste functies, soms lang voordat ze in de stabiele versie beschikbaar komen. Dat maakt het dev-kanaal een geweldige tool voor prototyping en baanbrekende ontwikkeling.
- Canary Channel : het meest experimentele kanaal, met alle nieuwste functies, maar zonder veel tests. Tenminste dagelijks uitgebracht.
Wil je meer weten over de kanalen van Chrome? Bekijk dan de relevante Chrome Concepts-aflevering .
Kanalen gebruiken in een voorbeeldorganisatie
De structuur van productteams verschilt per organisatie, omdat er geen standaardaanpak voor softwareontwikkeling bestaat. Als voorbeeld nemen we een team met de volgende rollen: Productmanagement, UX en UI, Engineering, Operations en Support.
Voor een organisatie als deze kunt u denken aan de volgende kanaalverdeling:
- Productmanagement : PM's kunnen meestal op het stabiele kanaal werken, zodat ze dezelfde versie kunnen gebruiken als de meeste gebruikers. Soms kunnen ze het bèta- of dev- kanaal gebruiken als ze werken aan een functie waarvoor een API nodig is die nog niet is gelanceerd.
- Engineering en UX : Delen van deze teams kunnen op het dev- kanaal staan, zodat ze toegang hebben tot de nieuwste functies, zoals View Transitions , zelfs voordat deze in stable zijn.
- Operations : Mogelijk in bèta , om te voorzien dat er problemen ontstaan die gebruikers kunnen treffen.
- Ondersteuning : U kunt op het stabiele kanaal blijven om ervoor te zorgen dat uw klanten met dezelfde browser met het product communiceren als de meeste van uw klanten.
Gebruik bedrijfsbeleid om kanalen te beheren
In plaats van richtlijnen te geven en de beslissing over welk kanaal gebruikt moet worden over te laten, biedt Chrome ook zakelijke en beheertools om actief te beheren welk kanaal elke gebruiker uiteindelijk gebruikt. Dit is handig omdat het testoppervlak direct wordt vergroot van een paar individuele gebruikers naar een deterministische groep gebruikers, wat helpt om fouten zo vroeg mogelijk en traceerbaar mogelijk te identificeren.
Als u deze mate van controle wilt gebruiken, raden wij u de volgende configuratie aan:
- Medewerkers (appgebruikers) : Om het risico op verstoringen te minimaliseren, zouden de meeste medewerkers het stabiele kanaal moeten gebruiken. Dit kanaal is volledig getest door het Chrome-testteam. Daarnaast kan een klein percentage gebruikers (5 tot 10%) het bètakanaal gebruiken. Dit kanaal krijgt een preview van de stabiele versie van 4 tot 6 weken 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 voor iedereen wordt uitgerold.
- IT-afdeling : Leden van de IT-afdeling, waaronder systeembeheerders zelf, kunnen op het bèta- of dev- kanaal terecht om een preview van 4 tot 6 of 9 tot 12 weken te krijgen van wat de stabiele versie van Chrome te bieden heeft.
Kanalen voor langdurige afgifte
De productontwikkeling verloopt mogelijk niet zo snel als gepland en Chrome's releasefrequentie van een maand is mogelijk te hoog. Voor deze use case biedt Chrome een Extended stable-kanaal waarmee u minder vaak functie-updates ontvangt, maar toch beveiligingsupdates ontvangt. Dit kanaal wordt elke acht weken bijgewerkt.
Het onderstaande diagram laat zien hoe verschillende mijlpalen via de verschillende releasekanalen van Chrome verlopen:
- Zowel de stabiele als de uitgebreide stabiele versie leveren gedurende de eerste vier weken dezelfde versies, waarna ze uiteengaan.
- Er is geen uitgebreid bètakanaal; in plaats daarvan wordt de standaard bètacyclus van vier weken gebruikt om zowel de stabiele als de uitgebreide stabiele versie te stabiliseren. Bedrijven die kiezen voor de uitgebreide stabiele versie van acht weken, dienen het bètakanaal te 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 voor softwareontwikkelingsbedrijven om de kwaliteit van hun producten te waarborgen. Ook voor systeembeheerders is het een belangrijke stap om medewerkers van een organisatie toegang te geven tot software van hoge kwaliteit en te voorkomen dat bedrijfsprocessen worden verstoord.
Om een testworkflow binnen uw organisatie succesvol te implementeren, is het belangrijk dat iedereen ervan overtuigd is dat kwaliteit en dus testen een belangrijk onderdeel is.
In dit artikel hebben we verschillende manieren besproken om best practices voor testen te integreren in uw organisatie. Voor een diepgaand overzicht 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, kunt u ook onze recente cursus Learn Testing en best practices voor testautomatisering op web.dev bekijken.