Hva Er Retesting?
Retesting: for å sikre at feilene som ble funnet og postet i den tidligere bygningen, ble løst eller ikke i den nåværende bygningen.
Retesting kjører de tidligere mislykkede testtilfellene igjen på den nye programvaren for å verifisere om feilene som er lagt ut tidligere, er løst eller ikke.
I enkle ord tester Retesting en bestemt feil etter at den ble løst.
Eksempel: Si, Build 1.0 ble utgitt. Under testing Av Build 1.0 fant Testteamet noen feil (For Eksempel Defekt Id 1.0.1 Og Defekt Id 1.0.2) og postet. Testteamet tester feilene 1.0.1 og 1.0.2 I Build 1.1 (bare hvis disse to feilene er nevnt I Utgivelsesnotatet Til Build 1.1) for å sikre at feilene er løst eller ikke.
Prosess: Per Bug Livssyklus, når en tester funnet en bug, er feilen rapportert Til Utviklingsteamet. Statusen For Feilen skal være «Ny». Utviklingsteamet kan godta eller avvise feilen. Hvis utviklingsteamet aksepterer feilen, løser de det og slipper det i neste versjon. Statusen for feilen vil være «Klar FOR QA». Nå tester verifiserer feilen for å finne ut om det er løst eller ikke. Denne testen er kjent som retesting. Retesting er en planlagt testing. Vi bruker samme testtilfeller med samme testdata som vi brukte i tidligere bygg. Hvis feilen ikke er funnet, endrer vi statusen til feilen som «Fast» ellers endrer vi statusen som «Ikke Fast» og sender Et Feilprøvingsdokument Til utviklingsteamet.
Sjekk under videoen for å se «Hva Er Retesting & Når Gjør Vi Retesting»
Vær tålmodig. Videoen lastes inn i noen tid.
hvis du likte denne videoen, kan du abonnere på Vår YouTube-Kanal for flere videoopplæringer.
Når Gjør Vi re-testing:
1. Når Det er en bestemt bug fix spesifisert I Utgivelsesnotatet:
Når utviklingsteamet slipper den nye bygningen, må testteamet teste de allerede postet feilene for å sikre at feilene er løst eller ikke.
2. Når En Feil er avvist:
til tider, nekter utviklingsteam noen bugs som ble oppdratt av testere og nevne status for feilen Som Ikke Reproduserbar. I dette tilfellet må testerne teste det samme problemet for å la utviklerne vite at problemet er gyldig og reproduserbart.
for å unngå dette scenariet må vi skrive en god feilrapport. Her er et innlegg om hvordan du skriver en god feilrapport.
3. Når En Klient krever en retesting:
til tider, Kan Klienten be oss om å gjøre testen igjen for å få tillit til kvaliteten på produktet. I dette tilfellet tester testteam produktet på nytt.
et produkt bør aldri bli utgitt etter endring har blitt gjort til koden med bare retesting feilrettinger, må Vi Gjøre Regresjonstesting også.
Les Også: Forskjell Mellom Regresjon og re-testing
Sjekk dette ut For Fullstendig Manuell Testopplæring