Hvad er Retesting?
Retesting : for at sikre, at de fejl, der blev fundet og bogført i den tidligere bygning, blev rettet eller ikke i den nuværende bygning.
Retesting kører de tidligere mislykkede testsager igen på det nye program for at kontrollere, om de tidligere fejl, der er lagt ud, er rettet eller ej.
i enkle ord tester Retesting en bestemt fejl, efter at den blev rettet.
eksempel: Sig, Build 1.0 blev frigivet. Under test af Build 1.0 fandt testteamet nogle fejl (eksempel defekt Id 1.0.1 og defekt Id 1.0.2) og blev sendt. Testteamet tester manglerne 1.0.1 og 1.0.2 i Build 1.1 (kun hvis disse to mangler er nævnt i Udgivelsesnotatet til Build 1.1) for at sikre, om manglerne er rettet eller ej.
proces: i henhold til bugens livscyklus, når en tester fandt en fejl, rapporteres fejlen til udviklingsholdet. Status for Bug skal være”ny”. Udviklingsholdet kan acceptere eller afvise fejlen. Hvis udviklingsholdet accepterer fejlen, løser de det og frigiver det i den næste udgivelse. Status for fejlen vil være”klar til kvalitetssikring”. Nu kontrollerer testeren fejlen for at finde ud af, om den er løst eller ej. Denne test er kendt som retesting. Retesting er en planlagt test. Vi bruger samme test cases med samme testdata, som vi brugte i den tidligere build. Hvis fejlen ikke findes, ændrer vi Status for fejlen som” fast”, ellers ændrer vi status som” ikke fast ” og sender et Defektgenprøvningsdokument til udviklingsholdet.
tjek nedenstående video for at se “hvad er Retesting & hvornår gør vi Retesting”
vær tålmodig. Videoen indlæses om et stykke tid.
hvis du kunne lide denne video, skal du abonnere på vores YouTube-kanal for flere videotutorials.
hvornår gør vi re-test:
1. Når der er en bestemt fejlrettelse angivet i Udgivelsesnoten:
når udviklingsholdet frigiver den nye build, skal testteamet teste de allerede bogførte fejl for at sikre, at fejlene er rettet eller ej.
2. Når en fejl afvises:
til tider nægter udviklingsholdet få fejl, som blev rejst af testerne og nævner status for fejlen som ikke reproducerbar. I dette tilfælde skal testerne teste det samme problem igen for at lade udviklerne vide, at problemet er gyldigt og reproducerbart.
for at undgå dette scenario skal vi skrive en god fejlrapport. Her er et indlæg om, hvordan man skriver en god fejlrapport.
3. Når en klient kræver en gentest:
til tider kan klienten anmode os om at udføre testen igen for at få tillid til produktets kvalitet. I dette tilfælde tester testteams produktet igen.
et produkt bør aldrig frigives, efter at der er foretaget Ændring af koden med bare at teste fejlrettelserne igen, vi er også nødt til at udføre regressionstest.
Læs også: forskel mellem Regression og Re-test
tjek dette for komplet manuel test Tutorial