Leestijd : 1 minuten

Productkwaliteit borgen? Hier is de QA scorekaart die je nodig hebt

Keerthika
Lead Marketing Strategist

An INFJ personality wielding brevity in speech and writing.

We hebben jarenlang bedrijven uit alle sectoren geraadpleegd en realiseren ons keer op keer dat het opzetten van een intensief testproces, het herzien ervan en het periodiek doorvoeren van verbeteringen een betrouwbare manier is om producten op de markt te brengen die resoneren met de eindgebruikers en alle belanghebbenden betrokken.

Een van de eigenaren van productkwaliteit bij een bedrijf zei bijvoorbeeld dat ze al lang in de branche actief waren en zich behoorlijk hadden aangepast aan trends zoals test automatisering, het opzetten van een continue integratie

Hoewel het opzetten van een product-QA geruststellend lijkt, waren de eindresultaten niet wat ze zochten.

We zijn het erover eens dat geen enkel product of software defectvrij is. Maar het kan minder defect raken.

En dat is slechts één voorbeeld.

Er zijn bedrijven met verschillende benaderingen van softwarekwaliteit, sommige doen het zo goed, en andere hebben een vertekend beeld van kwaliteit door verkeerde statistieken te meten en slechte beslissingen te nemen.

Grote of kleine, incrementele veranderingen vinden plaats wanneer u een basisscorekaart voor softwarekwaliteit opstelt die het STLC-proces meet vanaf de vereisten totdat u op de knop Implementeren drukt.

QA-scorekaart: wat is het?

Een software QA-scorekaart is vergelijkbaar met uw fitbit-horloges: zoals het paneel weergeeft hoeveel stappen u hebt gezet, slaapuren en andere essentiële informatie, toont een product-QA-scorekaart de KPI van uw productkwaliteit – de statistieken die laten zien hoe goed uw productkwaliteit is.

Kortom: Identificeer snel verbeterpunten, inefficiënte processen of slecht presterende teams met QA-scorecards.

Wie gebruikt het?

Organisaties van elke omvang, klein of groot, gebruiken QA Scorecards om de prestaties van het team en hun QA-strategieën te verbeteren. Een organisatie kan de QA Scorecard-sjabloon met een lijst met checklists gebruiken als leidraad voor het team om regelmatig te voldoen aan de kwaliteit en de normen die door hun klanten worden verwacht

QA-scorekaarten worden in het algemeen nuttig voor de volgende mensen:

  • QA-analisten
  • Teamleiders
  • Beheerders
  • Toezichthouders

Engineeringteams kunnen zelf een QA-scorekaart opstellen of externe hulp zoeken op basis van de behoefte.

Het QA-team kan echter niet zelf de kwaliteit/prestaties van het team aannemen zonder te evalueren aan de hand van checklists, richtlijnen die het team/de organisatie volgt.

Voordelen van de QA-scorekaart:

Hieronder volgen de voordelen die het QA-team kan afleiden uit de QA-scorekaart:

  • Helpt bij het identificeren van de verbeterpunten in de roadmap voor kwaliteit
  • Duidelijk inzicht in de status of kwaliteit op basis van de feedback
  • Stel een benchmark op en teams kunnen ook best practices leren
  • Helpt de voortgang van de testactiviteiten te bewaken.

Het bouwen van een QA-scorekaart

Zoals eerder vermeld, is QA Score Card in feite een sjabloon met de lijst met standaardvragen op basis van het project of het bedrijf. Het bestaat uit een beperkte set vragen, laten we zeggen 10 tot 20 om de kwaliteit te bepalen.

Elke vraag die aan het team wordt gesteld, wordt vergezeld van een briefing en gedetailleerde uitleg van de verwachtingen en normen waaraan moet worden voldaan om de kwaliteit te behouden, zowel functioneel als niet-functioneel. Ook verschilt de weging van de vragen op basis van wat het team wil bereiken.

Hier is bijvoorbeeld een voorbeeld van een QA-scorekaartvragenlijst die u kunt gebruiken om uw volledige QA-activiteiten te meten

Activiteiten Definitie
Vereisten
Helderheid Zijn de gestelde eisen duidelijk met gedetailleerde acceptatiecriteria?
Impact analyse Wordt er voor elk verhaal een impactanalyse uitgevoerd en bijgehouden?
Dev-testen
Unit- en integratietesten Worden unit- en integratietests geautomatiseerd en wordt de dekking geanalyseerd?
Statische code-analyse Wordt er een statische code-analyse uitgevoerd om problemen aan het licht te brengen nog voor de uitvoering?
DevOps (CICD)
Geautomatiseerde pijpleidingen Is het bouwproces geautomatiseerd samen met de uitvoering van geautomatiseerde tests?
Artefacten archiveren Worden de builds gearchiveerd en wordt de geschiedenis bijgehouden?
Teststrategie / planning
Soorten testen Zijn vereiste soorten testen geïdentificeerd en geschat tijdens de Sprint
Risico Zijn de risico’s met betrekking tot Planning Effort Environment Resources voorzien tijdens de planning?
Ontwerp testen
Traceerbaar naar wens Zijn de ontworpen testen herleidbaar naar de eisen?
Dekking Vindt de collegiale toetsing plaats om dekking te garanderen?
Automatisering testen
Planning & Uitvoering Wordt testautomatisering consistent gepland, ontworpen en uitgevoerd voor verschillende soorten tests?
Kwaliteit Wordt de effectiviteit van de automatisering gemeten?
Artefacten testen
Resultaten Worden de testresultaten vastgelegd en bijgehouden volgens de vereisten?
Afmelden Wordt vrijgave Go-No Go onderbouwd met testaftekenrapport?
Functioneel testen
Positief Negatief stroomt Dekken de functionele tests zowel positieve als negatieve stromen?
Complexe combinaties Dekken de functionele tests een complexe combinatie van stromen?
Niet-functioneel testen
Planning & Uitvoering Worden niet-functionele tests gepland en uitgevoerd als onderdeel van releasetesten?
Testgegevens en omgeving Testgegevens & omgeving specifiek voor niet-functionele tests beschikbaar?
Regressie testen
Impactgebieden per ticket Worden regressietesten op basis van impactanalyse geïdentificeerd en uitgevoerd voor elk ticket?
Volledig per Sprint/Release Volledige regressietestsuite uitgevoerd na het bevriezen van de code voor elke sprint
Productiegereedheid testen
Klant als E2E Worden End-to-End-testcases vergelijkbaar met klanttesten geïdentificeerd en uitgevoerd?
Testgegevens & omgeving & bronnen Is de testomgeving samen met de juiste testgegevens, randapparatuur/apparaten en andere integraties beschikbaar voor de E2E-testen?
Defectenanalyse
Parameters verzameld Zijn de verschillende parameters zoals probleembron, omgeving, component/functioneel gebied, hoofdoorzaak, bron/geïdentificeerde en opgeloste versie verzameld?
Geanalyseerd en gehandeld Worden de statistieken afgeleid op basis van de bovenstaande parameters, geanalyseerd en omgezet in bruikbare items?

Het scoren gebeurt meestal in cijfers van 0-5 of met standaard Ja/Geen optie om tot de score te komen. De uiteindelijke score wordt gegeven in termen van percentage op 100.

Voorbeeld van een QA-scorekaart:

 

  Doel Bereikt
Vereisten 5 4
Dev Testen 5 3.5
DevOps (CICD) 5 5
Teststrategie / Planning 5 3.5
Testontwerp 5 3
Test Automatisering 5 3.5
Testartefacten 5 3.5
Functioneel testen 5 1.5
Niet-functioneel testen 5 4
Regressietesten 5 4
Testen van de productiegereedheid 5 0
Defectenanalyse 5 2

 

Zoals je kunt zien, scoort dit team goed op CI/CD-processen, maar ze lopen nog steeds achter bij het testen van de productiegereedheid en het opzetten van een defectanalysesysteem. Het waarborgen van de kwaliteit van een product/software hangt af van al deze parameters samen.

Puntentelling in detail:

Activiteiten Doel Bereikt
Vereisten    
Helderheid 5 4
Impactanalyse 5 4
Dev-testen    
Unit- en integratietests 5 4
Statische codeanalyse 5 3
DevOps (CICD)    
Geautomatiseerde pijplijnen 5 5
Artefacten archiveren 5 5
Teststrategie / planning    
Soorten testen 5 4
Risico 5 3
Ontwerp testen    
Traceerbaar naar vereiste 5 4
Dekking 5 2
Automatisering testen    
Planning en uitvoering 5 4
Kwaliteit 5 3
Artefacten testen    
Resultaten 5 4
Afmelden 5 3
Functioneel testen    
Positieve + Negatieve stromen 5 2
Complexe combinaties 5 1
Niet-functioneel testen    
Planning en uitvoering 5 4
Testgegevens en -omgeving 5 4
Regressie testen    
Impactgebieden per ticket 5 4
Vol per Sprint/Vrij 5 4
Productiegereedheid testen    
Klanten zoals E2E 5 0
Testgegevens & Omgeving & Hulpmiddelen 5 0
Defectenanalyse    
Verzamelde parameters 5 3
Geanalyseerd & gehandeld 5 2
  120 76
    63.33%

Het doel van elk productkwaliteitsteam is: continue verbetering en prestatie. Een team kan deze QA-scorecard gebruiken voor twee verschillende soorten projecten.

  • Bestaand project
  • Nieuw project

Laten we een voorbeeld nemen van een externe QA-leverancier die samenwerkt met een klant die de QA-score voor zijn product wil bereiken. Het team van de leverancier zal een duidelijk doel moeten bedenken voordat de vragenlijst voor de QA-scorekaart wordt samengesteld.

In de meeste gevallen wil de klant de reden achter de productieproblemen en gemiste bugs weten In dergelijke gevallen zal de leverancier een kickstart geven met een eerste opdracht, waarbij hij nauw zal samenwerken met het team van de klant om inzicht te krijgen in hun werkmodel, testproces en werkcultuur en om tot de reeks vragen te komen die zullen helpen de doelen te bereiken. van de klant.

Het voordeel hiervan is om te helpen begrijpen of het lekken van bugs naar productie plaatsvindt als gevolg van slechte QA of al hun technische praktijken gecombineerd vanaf de vereiste om vrij te geven.

Om tot de eindscore te komen, zijn er wekelijkse vergaderingen met het team, het bestuderen van hun vereisten, het spreken met hun technische team, de processen die ze volgen en het doornemen van testartefacten en tools voor het opsporen van defecten.

Het analyseren en presenteren van de score duurt meestal 8 weken, gevolgd door het aftekenproces aan de klant.

Voor teams die net beginnen met het bouwen van een product, kan het team de QA-scorekaartsjabloon vanaf de beginstatus als checklist hebben om de kwaliteit van het product te behouden.

Dit zou hen helpen om de hiaten in het proces en de kennis te overbruggen, en gebieden waaraan ze moeten werken om hun prestaties te verbeteren en succesvol te zijn in termen van het leveren van een naadloze gebruikerservaring.

Criteria voor QA-scorekaart

QA-scorekaartcriteria

Wat kunnen QA-teams afleiden uit de scorekaart?

QA-teams leiden het volgende af uit de scorekaart:

  • Op basis van de score identificeren ze verbeterpunten, namelijk proces, documentatie
  • Oorzaak van het probleem
  • Kwaliteitsniveau van het product
  • Evalueer zichzelf aan de hand van de standaardprocedures

Manieren om de QA Scorecard te verbeteren

Zoals bij elke praktijk, gaat kwaliteit gepaard met continue verbetering. Het bereiken van de QA-scorekaart moet niet worden gezien als een eenmalig proces. Hieronder volgen enkele manieren om de QA-scorekaart in een continue verbeteringsmodus te brengen.

  • Systematisch monitoren
  • Samenwerken tussen teams (Dev, QA, Ops)
  • Beloningen en erkenning binnen het team
  • Transparantie en continu feedbacksysteem

Wilt u de dekking van uw testautomatisering verbeteren? Kijk eens bij Zucitestautomatiseringsdienstenen kijk hoe u Zuci kunt inzetten voor uw zakelijke behoeften.

Het artikel is mede geschreven doorVidya Shanmugam, Testleider @Zuci Systems.

Leave A Comment