Bekreftelsestesting

Eksempel

En testcase for innloggingsfunksjonen feilet fordi det ble funnet en defekt i passordvalideringen. Utvikleren retter defekten. Retesting kjører deretter den samme testcasen på nytt for å verifisere at rettetiltaket virket: innloggingen lykkes nå, og testcasen som tidligere feilet, består. Merk at retesting bare kjører på nytt testene som feilet — å verifisere uendret funksjonalitet er regresjonstesting.

FAQ

Hva er forskjellen mellom retesting og regresjonstesting? Retesting kjører testcaser som feilet sist de ble kjørt, for å verifisere at rettetiltakene lyktes. Regresjonstesting tester tidligere testet, uendret funksjonalitet for å sikre at endringen ikke innførte nye defekter. Begge deler trengs etter en rettelse.

Kalles retesting også for bekreftelsestesting? ISTQB-ordlisten behandler dem som relaterte: bekreftelsestesting er det samme konseptet med å verifisere at en defekt er rettet, og begge står i kontrast til regresjonstesting. Begrepene brukes om hverandre i mange læreplaner.

Når utføres retesting? Etter en defektrettelse, før rettelsen aksepteres. Det etterfølges vanligvis av regresjonstesting av den omkringliggende funksjonaliteten.

Kan retesting automatiseres? Ja. Den automatiserte testcasen som tidligere feilet, kjøres på nytt — ideelt sett som en del av en CI-pipeline som også kjører regresjonspakken.

Relaterte begreper

• bekreftelsestesting — verifisering av at en defekt faktisk er rettet
• regresjonstesting — testing av uendret funksjonalitet etter en endring
• defekt — det rettetiltaket retter seg mot
• testcase — enheten som kjøres på nytt
• feilsøking — å lokalisere og rette defekten før retesting
• feil — den observerte atferden som fikk testen til å feile