Menu

3 strategier til håndtering af en blokeringsfejl

3 strategies dealing with blocker defect

Prøv Vores Instrument Til At Fjerne Problemer

Blocker-defekter tilføjer masser af drama til ellers regelmæssige testdage.

I denne artikel vil jeg dække nogle trin, som en tester kan tage, når de beskæftiger sig med dem.

Jeg vil antage, at vores kære læsere allerede forstår dybdens alvor og prioritet. Brug for et hurtigt resumé? Se lige det her.

Betyder det altid, at vi skal stoppe testen helt, hvis vi støder på et blokeringsproblem?

I nogle tilfælde “Ja”, men måske ikke altid. Der kan være tilfælde, hvor nogle testaktiviteter er mulige.

Håndter blokeringsfejl

billede kilde

Nedenfor er nogle situationer, som jeg har oplevet i min karriere som tester. Jeg er overbevist om, at nedenstående trin (senere konsolideret i et flowchart) skal følges for at gøre denne proces enklere.

Lad os hoppe lige ind.

Trin, du skal tage, når du støder på en blokeringsfejl

Trin 1: Når du støder på et problem, skal du bruge tid på at finde årsagen.

Jeg er overbevist om, at vores arbejde som tester bare ikke ender ved rapportering af mangler . Hvis tiden tillader det, bør vi undersøge, hvad der kunne have forårsaget problemet. Vi er muligvis ikke altid i stand til at påpege det nøjagtige problemområde, men prøv at foretage fejlfinding så meget som muligt. De samme detaljer kan opdateres i manglen som yderligere kommentarer.

Jeg har gjort dette meget i mine projekter, og dette har resulteret i en hurtig løsning. Fordelene ved rodårsagsanalyse er:

  • At være en værditilvækst kan dette helt sikkert give udvikleren bedre retning til fejlrettelse.
  • QA-testeren kan også genkende, om dette problem er selvoprettet (dataindtastning eller problemer med menneskelig brug), og i så fald kan det løses af selve testeren. Når sådanne fejl bliver rapporteret til udviklere uden at vi kontrollerer fra QA-slutningen, er de det betragtes som et ikke-problem og kunne skabe et negativt ry for testeren.

Så jeg foreslår, at vi altid dobbelttjekker ved vores ende, før vi logger en fejl.

Her er nogle eksempler i realtid fra mine projekter, der styrker ovenstående punkter:

Jeg arbejdede på et projekt, hvor vores test ville kræve, at vi droppede en fil på et bestemt sted. Omdøb det, så det passer til navnet i konfigurationen. Et planlagt job ville afhente datafilen og indlæse dataene i systemet. Herefter validerer vi dataene i databasen og frontend.

oracle sql interview spørgsmål til erfarne

Vi stødte tidligere på problemer, hvor jobbet kørte, men dataene ikke blev indlæst, og efter undersøgelse var det fordi testeren ikke har ændret navnet, mens den tabte filen på stedet.

Dette var en blokering for os, men ikke noget, der krævede udviklerens opmærksomhed. Vi måtte være opmærksomme på detaljer og undgå sådanne små fejl.

Følgende er nogle almindelige kategorier, grundårsager og retsmidler:

# 1) Værtsfil Problem - Sig, din værtsfil har parametre, der er forkerte og forårsager problemet. I dette tilfælde kan du enten opdatere værtsfilen selv eller søge hjælp fra en person med adgang til at opdatere og fortsætte testudførelsen.

En defekt for det samme skal rejses, så udviklere vil undersøge, men med løsningen kan funktionstest stadig fortsættes.

Bemærk: Spørg dine projektteams, om det er OK for QA-teamet at foretage disse ændringer, inden du gør det.

# 2) Konfiguration - Ofte har vi bemærket konfigurationsproblemer som f.eks. Ikke at pege på det korrekte miljø eller andre konfigurationsproblemer, der blokerer problemer. Også i sådanne tilfælde kan testere foretage ændringer og fortsætte med testningen.

datastage interview spørgsmål og svar pdf

Bemærk: Bed igen om tilladelse, inden du gør dette.

# 3) Kodeudgave - Hvis du føler, at problemet skyldes kode, kan testerne ikke gøre noget meget. Log en blokeringsfejl, og vent på, at rettelsen fortsætter med testningen.

# 4) Implementeringsproblem - Dårlig implementering er en anden almindelig årsag til problemer med blokeringen, og disse kan fanges under fornuftstesten. Også her skal test stoppes med det samme, indtil en ny build er modtaget.

# 5) Miljø ned - Hvis miljøet er nede, skal du sige, at databasen ikke oprettes forbindelse til serveren, eller URL'en ikke fungerer i tilfælde af websteder; testere kan ikke gøre meget i disse tilfælde andet end at rapportere en defekt og vente på, at systemet er i gang.

Derfor, hvis der findes en løsning, skal du bruge den for at fortsætte testningen. Den eneste måde at finde, hvis den nævnte løsning findes, er ved at undersøge grundårsagen. Oftere end ikke kan der være et alternativ.

Trin 2: Det er meget let at falde i en uendelig løkke, når man undersøger grundårsagen. Så sørg for, at det ikke spiser hele dagen og al indsats.

Her er nogle tip:

  • Find en balance og genkend stoppestedet, når du kommer derhen.
  • En testers erfaring og ekspertise er afgørende for en vellykket RCA. Det er dog en god ide at involvere teamet og teamledelsen, når det er nødvendigt.
  • Når du føler, at RCA er tidskrævende, skal du først rapportere problemet med det samme og give så mange oplysninger som muligt. Et skærmbillede er altid nyttigt.
  • Hvis det er nødvendigt, følges op. Send en e-mail til manager eller udvikler for at gøre opmærksom på det kritiske problem.
  • Fortsæt fejlfinding efter at have advaret om de nødvendige parter.

Årsag til, at blokeringsfejl skal rapporteres straks:

  • Ledelsen bør gøres opmærksom på alle nedetider, hvis problemet tilfældigvis er en showstopper-defekt. Disse oplysninger skal videresendes til klienten og kan også kræve opdateringer af projektplaner (QA-tidslinjer), ændringer i leverancer osv.
  • Enhver forsinkelse i QA-leverancer skal understøttes med bevis. Så det er altid bedre at kommunikere så hurtigt som muligt i stedet for at vente til slutningen af ​​dagen.

Trin # 3: Gå nu videre til det sidste trin, da vi er færdige med at analysere problemet og kommunikere det, hvad er det næste?

  • Hvis problemet blokerer adgangen til et funktionelt område, skal du kontrollere, om dette har indflydelse på andre områder
  • Hvis frontend-appen er nede, skal du kontrollere, om backend / middleware / database-test kan fortsættes.
  • Hvis ingen testudførelsesaktiviteter kan finde sted, skal du prøve at arbejde på noget dokumentation relateret til dit projekt.
  • Du kan også prøve at identificere områder til automatisering hvis du manuelt gentager en masse arbejde. Automatisering behøver ikke altid at bruge et værktøj. Sig, generering af rapporter er en monoton opgave for dig, det er et område, der kan automatiseres ved hjælp af enkle Excel-makroer og sådan.
  • Brug tid på at vide om open source-værktøjer, der kan implementeres i dit projekt
  • Sidst men ikke mindst , arbejd mod innovation, det mantra, der styrer verden i øjeblikket!

Langt om længe , rutediagrammet, der opsummerer hele diskussionen!

Flowchart: Skridt til at håndtere en blokeringsfejl

blokeringsfejl

Forfatter : Denne fantastiske artikel er skrevet af STH-teammedlem Priya R.

Hvilke skridt tager du, når du støder på en blokeringsfejl?

Anbefalet læsning

^