Een kwaliteitsstrategie creëren
Opnieuw gepubliceerd met toestemming van Kristins uitstekende blog, thinkingtester.
In mijn vorige bericht introduceerde ik het concept van het kwaliteitsvolwassenheidsmodel: een reeks gedragingen die gekoppeld zijn aan kwaliteitskenmerken en die teams helpen verschillende kwaliteitskenmerken in hun software te bereiken.
Een belangrijk punt om op te merken is dat het invoeren van een kwaliteitsvolwassenheidsmodel vereist dat het hele team bijdraagt aan de kwaliteit.
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
Kwaliteit is niet iets dat aan testers moet worden “over de muur gegooid”; het is eerder een doel dat zowel ontwikkelaars als testers delen.
Maar hoe zorg je ervoor dat het hele team verantwoordelijkheid neemt voor kwaliteit?
Een manier is door een kwaliteitsstrategie op te stellen. Dit is een document waar het hele team gezamenlijk mee instemt. Zie het als een contract waarin wordt beschreven hoe het team kwaliteitssoftware ontwikkelt, test en uitbrengt.
Hier bespreek ik enkele vragen die je mogelijk in de kwaliteitsstrategie van je team wilt beantwoorden.
Gebruikersverhalen maken en verfijnen
Vraag: Hoe bepaalt het team aan welke gebruikersverhalen het werkt?
Dit kan een beslissing zijn van het hele team of alleen van de product owner. Of de prioritering kan worden uitgevoerd door iemand buiten het team.
Vraag: Wie verfijnt de gebruikersverhalen om ze klaar te maken voor ontwikkeling?
Dit kan het hele team zijn of een deel van het team. Idealiter nemen ten minste de product owner, één ontwikkelaar en één tester deel.
Ontwikkelproces
Vraag: Hoe bepaalt het team wie aan welk gebruikersverhaal werkt?
Het kan zijn dat ontwikkelaars elk gebruikersverhaal van het bord kunnen kiezen, of dat iedere ontwikkelaar gebruikersverhalen in specifieke functiegebieden heeft waaruit die kan kiezen.
In sommige teams werken softwaretesters ook aan eenvoudige ontwikkelverhalen, zoals het wijzigen van woorden of kleuren op een webpagina of het toevoegen van automatiserings-ID's om automatisering eenvoudiger te maken.
Vraag: Hoe ziet “Gereed” eruit voor het gebruikersverhaal? Wordt dit bepaald door aan alle acceptatiecriteria in het gebruikersverhaal te voldoen? Moet de ontwikkelaar unit-tests toevoegen voordat het gebruikersverhaal als gereed kan worden beschouwd? Hoe weet je dat een functie klaar is om te worden getest?
In veel teams wordt verwacht dat de ontwikkelaar eerst enige tests uitvoert om te controleren of de code die hij of zij heeft geschreven klaar is voor verdere tests.
Overdracht van functies
Vraag: Hoe wordt een gebruikersverhaal overgedragen voor het testen?
In sommige teams gebeurt dit eenvoudigweg door het gebruikersverhaal naar de kolom “Testen” op het storyboard te verplaatsen. In andere teams is een formelere overdrachtsceremonie vereist, waarbij de ontwikkelaar het werkende gebruikersverhaal demonstreert en suggesties doet voor verdere tests.
Vraag: Wie implementeert de code in de testomgeving?
Dit lijkt misschien een onbeduidend detail, maar het kan in werkelijkheid de oorzaak zijn van veel misverstanden en veel verspilde tijd. Als de ontwikkelaar denkt dat het de taak van de tester is om de code in de testomgeving te implementeren en de tester ervan uitgaat dat de ontwikkelaar dit heeft gedaan, kan de tester beginnen met testen zonder te beseffen dat de nieuwe code ontbreekt, totdat die al veel tijd aan het werken met de applicatie heeft besteed.
Vraag: Wie voert de tests uit?
In sommige teams kunnen ontwikkelaars eenvoudige testverhalen oppakken om de productsnelheid te helpen verbeteren, terwijl de complexere verhalen worden overgelaten aan de testexperts.
Testplannen opstellen
Vraag: Wie stelt de testplannen op? Hoe worden ze opgesteld? Waar worden de testplannen opgeslagen?
Sommige teams geven er misschien de voorkeur aan om verkennend testen op ad-hocbasis uit te voeren met minimale documentatie. Andere teams hebben mogelijk uitgebreide systemen voor testcasemanagement waarin alle tests voor het product worden gedocumenteerd. En er zijn nog veel andere opties daartussenin.
Wat je ook kiest, het moet geschikt zijn voor jouw team en voor jouw product.
Vraag: Wie schrijft de testautomatisering?
In sommige teams schrijven de ontwikkelaars de unit-tests en schrijven de testers de API- en UI-tests. In andere teams schrijven de ontwikkelaars de unit- en API-tests en maken de testers de UI-tests. Nog beter is het als zowel de ontwikkelaars als de testers de verantwoordelijkheid delen voor het maken en onderhouden van de API- en UI-tests.
Op deze manier kunnen de ontwikkelaars hun expertise in codebeheer inbrengen, terwijl de testers hun expertise bijdragen in het bepalen wat er getest moet worden.
Vraag: Wie voert andere soorten tests uit, zoals beveiligingstests, prestatietests, toegankelijkheidstests en tests van de gebruikerservaring?
Sommige grotere bedrijven hebben mogelijk toegewijde beveiligings- en prestatie-engineers die deze tests uitvoeren. Kleine start-ups hebben misschien slechts één ontwikkelteam dat verantwoordelijk moet zijn voor alles.
Testhulpmiddelen
Vraag: Welke hulpmiddelen worden gebruikt voor handmatig en geautomatiseerd testen?
Het selecteren van testhulpmiddelen is erg belangrijk wanneer je wilt dat het hele team verantwoordelijkheid neemt voor het testen. Ontwikkelaars willen waarschijnlijk hulpmiddelen gebruiken die dezelfde taal gebruiken als de taal waarin zij ontwikkelen, omdat dit de hoeveelheid contextwisselingen die ze moeten maken beperkt.
Testonderhoud
Vraag: Wie is verantwoordelijk voor het onderhouden van de tests?
Het is ongelooflijk hoe snel testautomatisering verouderd kan raken. Eén gewijzigd woord op een pagina kan een mislukte test veroorzaken. Idealiter hanteert een team het beleid “je maakt het kapot, je maakt het weer heel”, waarbij tests worden hersteld door degene die de code heeft ingecheckt waardoor ze zijn mislukt.
Als dat niet mogelijk is, zorg er dan in elk geval voor dat iedereen in het team begrijpt hoe de tests werken en hoe ze kunnen worden hersteld wanneer dat snel nodig is.
Bugs en technische schuld
Vraag: Hoe worden bugs afgehandeld wanneer ze tijdens het testen worden gevonden? Worden ze besproken door de ontwikkelaar en de tester, door het hele team beoordeeld en geprioriteerd, of op een achterstand geplaatst om later te worden bekeken?
Het is vaak een goed idee om bugs te herstellen zodra ze worden gevonden, omdat de ontwikkelaar al in dat gedeelte van de code werkt.
Vraag: Hoe gaat het team om met technische schuld?
Heeft het team afgesproken om per sprint een bepaalde hoeveelheid technische schuld op zich te nemen? Sommige teams hanteren een beleid waarbij een ontwikkelaar die geen verhalen meer heeft om aan te werken, technische-schulditems uit de achterstand oppakt.
Releases
Vraag: Welke tests voeren jullie uit vóór een release? Is er een regressietestplan dat het hele team samen kan uitvoeren? En hoe zit het met verkennend testen?
Een goed presterend team dat ik ken komt vlak voor een release samen voor verkennend testen. Met deze strategie hebben ze lastige bugs ontdekt en opgelost voordat de software naar productie werd uitgebracht.
Vraag: Hoe wordt de software uitgebracht?
Bij sommige bedrijven is er een releasemanager die verantwoordelijk is voor het uitvoeren van de release. Bij andere bedrijven brengen teamleden om de beurt de software uit. Een zeer nuttige techniek is continue implementatie, waarbij de software automatisch wordt geïmplementeerd en tests automatisch worden uitgevoerd om de implementatie naar elke omgeving te verifiëren. Zo bespaar je iedereen tijd en moeite.
Gerelateerd artikel: HOE JE API-ROOKTESTS UITVOERT IN JE PIJPLIJN VOOR CONTINUE IMPLEMENTATIE
Onderhoud
Vraag: Hoe meet je het succes van de release?
Zodra de software is uitgebracht, is het voor ontwikkelingsteams gemakkelijk om deze te vergeten; maar dit is het moment waarop gebruikers ermee beginnen te werken. Welke soorten statistieken zou je kunnen gebruiken om te meten hoe goed je product werkt? Je kunt defecten bijhouden die door klanten worden gemeld, of logboeken bekijken voor onverwachte fouten.
Vraag: Hoe houd je de gezondheid van je applicatie in de gaten?
Het zou een goed idee zijn om waarschuwingen in te stellen, zodat je problemen met je applicatie ontdekt voordat je gebruikers dat doen.
Vraag: Naar welke soorten gedrag moet je op zoek zijn?
Kwaliteitsstrategieën kunnen zo uiteenlopend zijn als sneeuwvlokken. Stel je de verschillen voor tussen een kleine start-up met vaak tien mensen die een mobiele chatapp maakt en een bedrijf met twintigduizend mensen dat software ontwerpt waarmee vliegtuigen vliegen. Deze twee bedrijven hebben zeer verschillende strategieën nodig!
Je kunt een kwaliteitsstrategie ontwerpen die goed werkt voor je team door deze vragen samen te bespreken en een strategie op te stellen waar jullie het allemaal over eens kunnen worden.
Bekijk deze lijst met hulpmiddelen en technologieën die je processen kunnen ondersteunen: 10 BESTE HULPMIDDELEN VOOR HET BEHEREN VAN TESTGEGEVENS.
