Meny

3 strategier for å håndtere en blokkeringsfeil

3 strategies dealing with blocker defect

Prøv Instrumentet Vårt For Å Eliminere Problemer

Blokkeringsdefekter tilfører mye drama til ellers vanlige testdager.

I denne artikkelen vil jeg dekke noen trinn en tester kan ta når de skal håndtere dem.

Jeg kommer til å anta at våre kjære lesere allerede forstår alvorlighetsgrad og prioritet av mangler dypt. Trenger du et raskt sammendrag? Sjekk ut dette.

Betyr det alltid at vi må slutte å teste helt hvis vi støter på et blokkeringsproblem?

I noen tilfeller “Ja”, men kanskje ikke alltid. Det kan være tilfeller der noe testaktivitet er mulig.

Håndtere blokkeringsfeil

bilde kilde

Nedenfor er noen situasjoner som jeg har opplevd i min karriere som tester. Jeg tror sterkt at trinnene som er beskrevet nedenfor (senere konsolidert til et flytskjema) skal følges for å gjøre denne prosessen enklere.

La oss hoppe rett inn.

Fremgangsmåte du bør ta når du kommer over en blokkeringsfeil

Trinn 1: Når du kommer over et problem, invester tid på å finne årsaken.

Jeg tror sterkt at arbeidet vårt ikke tester som tester rapportering av mangler . Hvis tiden tillater det, bør vi undersøke hva som kan ha forårsaket problemet. Vi kan ikke alltid være i stand til å påpeke det nøyaktige problemområdet, men prøver å feilsøke så mye som mulig. De samme detaljene kan oppdateres i mangelen som ytterligere kommentarer.

Jeg har gjort dette mye i prosjektene mine, og dette har resultert i en rask løsning. Fordelene med rotårsaksanalyse er:

  • Å være en verdiøkning, kan dette definitivt gi bedre retning til utvikleren for feilretting.
  • QA-testeren kan også gjenkjenne om dette problemet er selvskapt (datainnføring eller menneskelig bruk), og i så fall kan det løses av selve testeren. Når slike feil blir rapportert til utviklere uten at vi sjekker fra QA-enden, er de det betraktet som et ikke-tema og kunne skape et negativt rykte for testeren.

Så jeg foreslår at vi alltid dobbeltsjekker på slutten før vi logger en feil.

Her er noen sanntidseksempler fra prosjektene mine som vil forsterke punktene ovenfor:

Jeg jobbet med et prosjekt der testingen ville kreve at vi droppet en fil på et bestemt sted. Gi den nytt navn slik at den samsvarer med navnet i konfigurasjonen. En planlagt jobb vil hente datafilen og laste inn dataene i systemet. Deretter vil vi validere dataene i databasen og frontend.

hva er loadrunner i programvaretesting

Vi pleide å komme over problemer der jobben ville kjøre, men dataene ikke skulle lastes inn, og etter undersøkelse var det fordi testeren ikke har endret navnet mens den slipper filen på stedet.

Dette var en blokkering for oss, men ikke noe som krevde utviklerens oppmerksomhet. Vi måtte ta hensyn til detaljene og unngå slike små feil.

Følgende er noen vanlige kategorier, grunnårsaker og rettsmidler:

# 1) Vertsfil Utgave - Si, vertsfilen din har parametere som er feil og forårsaker problemet. I dette tilfellet kan du enten oppdatere vertsfilen selv eller søke hjelp fra noen med tilgang til å oppdatere og fortsette testutførelsen.

En mangel for det samme bør reises slik at utviklere vil undersøke, men med løsningen kan funksjonstesting fortsatt fortsette.

Merk: Ta kontakt med prosjektgruppene dine om det er OK for QA-teamet å gjøre disse endringene før du gjør det.

# 2) Konfigurasjon - Ofte har vi lagt merke til konfigurasjonsproblemer som ikke å peke på riktig miljø eller andre oppsettproblemer, som blokkerer problemer. I slike tilfeller kan også testere gjøre endringer og fortsette med testing.

Merk: Nok en gang, søk tillatelse før du gjør dette.

# 3) Kodeutgave - Hvis du føler at problemet skyldes kode, kan ikke testere gjøre mye. Logg på en blokkeringsfeil og vent til reparasjonen fortsetter med testingen.

# 4) Problem med distribusjon - Dårlig distribusjon er en annen vanlig årsak til problemer med blokkering, og disse kan bli fanget opp under fornuftstesten. Også her bør testingen stoppes umiddelbart til en ny build er mottatt.

hvordan åpne .swf i krom

# 5) Miljø ned - Hvis miljøet er nede, si at databasen ikke blir koblet til serveren eller at URL-en ikke fungerer på nettsteder; testere kan ikke gjøre mye i disse tilfellene annet enn å rapportere en feil og vente på at systemet skal være i gang.

Derfor, hvis det finnes en løsning, bruk den for å fortsette testingen. Den eneste måten å finne, hvis den nevnte løsningen eksisterer, er å undersøke årsaken. Oftere enn ikke, kan det være et alternativ.

Steg 2: Det er veldig lett å falle i en uendelig løkke når man undersøker årsaken. Så sørg for at det ikke spiser hele dagen og all innsats.

Her er noen tips:

  • Finn en balanse og gjenkjenn stoppestedet når du kommer dit.
  • En testers erfaring og ekspertise er avgjørende for en vellykket RCA. Det er imidlertid en god ide å involvere teamet og teamledelsen, når det er nødvendig.
  • Når du føler at RCA er tidkrevende, må du først rapportere problemet umiddelbart og gi så mye informasjon du kan. Et skjermbilde er alltid nyttig.
  • Om nødvendig, følg opp. Send en e-post til lederen eller utvikleren for å gjøre oppmerksom på det kritiske problemet.
  • Fortsett feilsøking etter å ha varslet nødvendige parter.

Årsak til at blokkeringsfeil skal rapporteres umiddelbart:

  • Ledelsen bør gjøres oppmerksom på alle nedetider hvis problemet tilfeldigvis er en showstopper-feil. Denne informasjonen må videreformidles til klienten, og kan også kreve oppdateringer av prosjektplaner (QA-tidslinjer), endring i leveranser osv.
  • Enhver forsinkelse i QA-leveranser må støttes med bevis. Så det er alltid bedre å kommunisere så snart som mulig i stedet for å vente til slutten av dagen.

Trinn 3: Gå videre til det siste trinnet siden vi er ferdige med å analysere problemet og kommunisere det, hva er det neste?

  • Hvis problemet blokkerer tilgangen til ett funksjonsområde, sjekk om dette har innvirkning på andre områder
  • Hvis frontend-appen er nede, sjekk om backend / middleware / database testing kan fortsette.
  • Hvis ingen testutførelsesaktiviteter kan finne sted, kan du prøve å jobbe med litt dokumentasjon relatert til prosjektet ditt.
  • Du kan også prøve å identifisere områder for automatisering hvis du gjentar mye arbeid manuelt. Automatisering trenger ikke alltid å bruke et verktøy. Si, generering av rapporter er en ensformig oppgave for deg, det er et område som kan automatiseres av enkle Excel-makroer og slikt.
  • Bruk tid på å vite om open source-verktøy som kan implementeres i prosjektet ditt
  • Sist, men ikke minst , arbeid mot innovasjon, mantraet som styrer verden for tiden!

Endelig , flytskjemaet som oppsummerer hele diskusjonen!

Flytskjema: Fremgangsmåte for å håndtere en blokkeringsfeil

blokkeringsfeil

Forfatter : Denne fantastiske artikkelen er skrevet av STH-teammedlem Priya R.

Hvilke skritt tar du når du kommer over en hvilken som helst blokkeringsfeil?

Anbefalt lesing

^