how perform test documentation reviews 6 simple steps qa process
We weten inmiddels allemaal dat voor een tester, Documentatie is een integraal onderdeel van zijn dagelijks leven. Er is een overbelasting aan testartefacten die worden gemaakt, beoordeeld, goedgekeurd, gebruikt, onderhouden en verspreid. We hebben altijd duidelijke processen voor het maken van een document, hoe het te gebruiken, naar wie het moet gaan, enz.
Via dit artikel gaan we wat licht werpen op het kleine maar belangrijke onderwerp - Recensies.
Reviewen is ook een vorm van testen - het verificatiedeel van de V&V wordt ook wel Static Testing genoemd.
Wat je leert:
- Soorten beoordelingen
- Stap 1: definieer de criteria
- Stap 2: voer de controle uit
- Stap 3: Noteer uw resultaten
- Stap 4: Deel, bespreek en implementeer de vereiste wijzigingen
- Stap 5: Versiebeheer De betrokken documenten
- Stap 6: Meld u af en gebruik het document zoals bedoeld
- Punten om te onthouden
- Terug naar jou
- Aanbevolen literatuur
Soorten beoordelingen
- Herziening van uw eigen werk - zelfcontrole
- Peer-review
- Toezichthoudend
Als validatie de helft is van de testmethoden, dan is verificatie de andere, maar vaak zijn de richtlijnen onduidelijk. Laten we dat NU veranderen. Is het een algemene praktijk met de artikelen bij STH, dan beginnen we met de vragen: Wat? Waarom? Hoe?
hoe schrijf je testcases
Wat beoordelen we?
Alles wat gemaakt is, moet worden beoordeeld. De volgende zijn enkele van de meest voorkomende artefacten die zijn beoordeeld:
- Testplan
- Test scenario's
- Test sjablonen
- Testgevallen
- Testgegevens
- Rapporten… enz
Waarom beoordelen?
Om precies dezelfde reden testen we de software, Bijvoorbeeld,
- Om fouten te ontdekken
- Om te controleren op volledigheid
- Om ervoor te zorgen dat de normen en richtlijnen worden nageleefd of niet ... enz.
Hoe te beoordelen?
De volgende zijn de lijst met betrokken activiteiten:
- Definieer de criteria - Heeft u een checklist van waar u op moet letten?
- Voer de controle uit
- Noteer uw resultaten
- Deel, bespreek en implementeer de benodigde wijzigingen
- Versiebeheer van de betrokken documenten
- Meld u af en gebruik het document zoals bedoeld.
We zullen nu elke stap bespreken in het gedeelte 'Hoe' - met andere woorden, het proces om het uit te voeren.
(De meeste van ons testers houden niet van de tekstverwerker, nietwaar? Voor ons betekent het ofwel veel meer werk of een of andere managementtaak op hoog niveau die we moeten doen, zelfs als we dat niet willen - voor omwille van enige naleving waar we geen idee van hebben, maar geloof me, als je een proces dat werkt en het is eenvoudig genoeg om te begrijpen waarom we het moeten doen, het kan leuk zijn! Speel gewoon met me mee.)
Het proces voor peer reviews en supervisie reviews is volgens mij hetzelfde omdat een supervisor ondanks de hogere aanwijzing ook peer is.
Stap 1: definieer de criteria
# 1) Wat verwacht je te vinden? U kunt zoeken naar zaken als:
- Spelfouten (Klinkt te gek? Ik denk het niet, een keer schreef ik 'Wed Object' in plaats van 'Web Object' in een van mijn artikelen - Verandert de betekenis volledig. Maakt het bijna te dom om serieus te worden genomen.)
- Naleving van indeling / sjabloon
- Functionaliteitsdekking en correctheid
- Gemakkelijk te begrijpen
- Gevolgde normen - naamgevingsconventies, consistente nummering… enz.
#twee) Maak een checklist - Checklists zijn erg veelzijdig. Het kan zo ingewikkeld zijn als een controlelijst voor recensies of zo simpel als een boodschappenlijst. Het enige dat nodig is, is wat tijd om het te maken en als je dat eenmaal hebt gedaan, is het net zo eenvoudig als AAN of UIT zetten.
# 3) Hoe de resultaten rapporteren? - Kies wat handig is, bij voorkeur een methode die kan worden opgenomen en gevolgd.
- Soms kan dit zo simpel zijn als het toevoegen van een extra kolom in het Excel-blad met testgevallen en iets in het rood schrijven als het niet is wat het zou moeten zijn.
- Kan mond-tot-mondreclame zijn
- Een lijst in een e-mail
Stap 2: voer de controle uit
# 1) Gebruik de checklist die je eerder hebt gemaakt, verifieer het document en geef je feedback.
Stap 3: Noteer uw resultaten
# 1) Nogmaals, gebruikmakend van de methode die in stap 1 is besloten, noteer en rapporteer uw resultaten.
#twee) Behandel uw opmerkingen of suggesties voor verandering niet anders dan het melden van een defect. Zie niets over het hoofd. Wees gedetailleerd.
# 1) Niemand vindt het leuk om te horen dat hun werk onjuist of onvolledig is. Houd dus rekening met de volgende richtlijnen wanneer u negatieve feedback geeft.
- Geef opbouwende kritiek - Denk eraan om niet kritisch te zijn over de persoon, maar wijs op gebreken in dit product
- Wees niet competitief - alleen omdat hij 30 recensie-opmerkingen over uw testcases heeft ingeleverd, probeer het niet te verslaan.
- Geef redenen om uw opmerkingen te steunen
#twee) Zorg voor een afmelding.
# 3) Laat de wijzigingen aanbrengen
Stap 5: Versiebeheer De betrokken documenten
# 1) Verwijder de oudere versies van de documenten niet. Geef ze een passende naam en bewaar ze in een gecentraliseerde projectmap. Dit is tenslotte het bewijs van al ons werk
Stap 6: Meld u af en gebruik het document zoals bedoeld
# 1) Zodra alle wijzigingen zijn verwerkt, wordt de versie opgeslagen, geeft u het beoordelingsproces een handtekening en gaat u verder met het gebruik van het document waarvoor het is gemaakt.
#twee) Een andere vraag die opkomt is: controleren we opnieuw nadat de wijzigingen zijn aangebracht? Hoe vaak gaat dit proces door - werk- review-fix-en vervolgens opnieuw beoordeeld? Tot wanneer?
Nee, een review hoeft niet steeds opnieuw te gebeuren. Het is een kwaliteitscontrole-activiteit die zich richt op het verifiëren of de testhulpmiddelen goed zijn gemaakt of niet. Zoals altijd zijn foutloze documenten onmogelijk. Dus een redelijk niveau van beoordeling - één keer door een collega is acceptabel.
Daar ben je klaar. Is dit proces niet eenvoudig?
Punten om te onthouden
- Niet elk project hoeft deze geformaliseerde beoordelingsmethode te volgen, maar zelfs als ze een informele methode hebben, zullen deze stappen helpen om de verwachting te scheppen en u verder te begeleiden.
- Test documentatie tijdlijnschattingen zijn doorgaans gebaseerd op de tijd die nodig is voor het maken en beoordelen van de documenten, dus het is erin ingebouwd, ook al herkennen we het niet altijd.
- Herziening is geen proces dat beperkt is tot handmatige testteams. Automatiseringsteams voeren ook code-walkthroughs uit, ontwerpbeoordelingen, enz.
Ten slotte is dit hoe een typisch document met recensie-opmerkingen voor testcases eruit ziet. De commentaren zijn in het rood. Niet per se echte opmerkingen, maar iets om te laten zien hoe het moet.
Voorbeeld testcases beoordelingsdocument: (klik om afbeelding te vergroten)
SQL server interviewvragen en antwoorden voor ervaren pdf
Terug naar jou
Dus, heb je nog steeds het gevoel dat processen ontmoedigend zijn? Voer je reviews uit in je projecten? Deel hieronder uw ervaringen, uitdagingen, vragen en opmerkingen.
Over de auteur: Dit is een bericht van Swati Seela - een expert in handmatige en automatiseringstests met meer dan 9 jaar ervaring in de sector Ze is ook een instructeur voor onze cursus Software Testing.
Als je Softwaretesten van de experts wilt leren, bekijk dan het schema voor onze aanstaande batch en meer over deze cursus op deze pagina
Aanbevolen literatuur
- 4 stappen naar de ontwikkeling van de Agile-testmentaliteit voor een succesvolle overgang naar een Agile-proces
- Hoe u softwareproducttests uitvoert - gedetailleerde processen en methoden met voorbeelden
- Business Process Testing (BPT) - Hoe u het testproces kunt vereenvoudigen en versnellen met BPT
- Genereer levende documentatie met augurken voor Specflow-functiebestanden
- Documentatiegids voor softwaretests (waarom het belangrijk is)
- Wat de QA-tester moet weten over het beheerproces voor release en implementatie
- Grep-opdracht in Unix met eenvoudige voorbeelden
- 6 belangrijkste stappen om uw testrapporten nog beter te maken