Productkwaliteit borgen? Hier is de QA scorekaart die je nodig hebt
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
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.
