Meny

3 strategier för att hantera ett blockeringsfel

3 strategies dealing with blocker defect

Prova Vårt Instrument För Att Eliminera Problem

Blockerfel lägger till massor av drama till annars vanliga testdagar.

I den här artikeln vill jag täcka några steg som en testare kan ta när de hanterar dem.

Jag kommer att anta att våra kära läsare redan förstår svårighetsgrad och prioritet hos defekter. Behöver du en snabb sammanfattning? Kolla in det här.

Betyder det alltid att vi måste sluta testa helt om vi stöter på ett blockeringsproblem?

I vissa fall ”Ja”, men kanske inte alltid. Det kan finnas fall där någon testaktivitet är möjlig.

Hantera blockeringsfel

bild källa

Nedan följer några situationer som jag har upplevt i min karriär som testare. Jag tror starkt att stegen som beskrivs nedan (senare konsoliderade i ett flödesschema) ska följas för att göra processen enklare.

Låt oss hoppa direkt in.

Steg du bör ta när du stöter på en blockeringsfel

Steg 1: När du stöter på ett problem investerar du tid för att hitta orsaken.

Jag tror starkt att vårt testar bara inte slutar som testare rapportera brister . Om tiden tillåter bör vi undersöka vad som kan ha orsakat problemet. Vi kanske inte alltid kan peka ut det exakta problemområdet, men försök att felsöka så mycket som möjligt. Samma detaljer kan uppdateras i defekten som ytterligare kommentarer.

Jag har gjort detta mycket i mina projekt, och detta har resulterat i en snabb fix. Fördelarna med analys av rotorsaker är:

  • Eftersom det är ett mervärde kan detta definitivt ge bättre riktning till utvecklaren för felkorrigering.
  • QA-testaren kan också känna igen om det här problemet skapas själv (datainmatning eller problem med mänsklig användning) och i så fall kan det åtgärdas av testaren själv. När sådana fel rapporteras till utvecklare utan att vi kontrollerar från QA-slutet är de det betraktas som en icke-fråga och skulle kunna skapa ett negativt rykte för testaren.

Så jag föreslår att vi alltid kontrollerar i slutet innan vi loggar in en defekt.

Här är några realtidsexempel från mina projekt som förstärker punkterna ovan:

Jag arbetade med ett projekt där våra tester skulle kräva att vi släppte en fil på en viss plats. Byt namn på den så att den matchar namnet i konfigurationen. Ett schemalagt jobb skulle hämta datafilen och ladda in data i systemet. Därefter validerar vi data i databasen och frontend.

vad är loadrunner i programvarutestning

Vi stötte på problem där jobbet skulle köras men datan inte laddades, och efter utredning berodde det på att testaren inte har ändrat namn när den släppte filen på platsen.

Detta var en blockerare för oss men inte något som krävde utvecklarens uppmärksamhet. Vi var tvungna att vara uppmärksamma på detaljer och undvika sådana små misstag.

Följande är några vanliga kategorier, grundorsaker och lösningar:

# 1) Värdfil Problem - Säg, din värdfil har parametrar som är felaktiga och orsakar problemet. I det här fallet kan du antingen uppdatera värdfilen själv eller söka hjälp från någon med åtkomst till uppdatering och fortsätta testkörningen.

En defekt för detsamma bör tas upp så att utvecklare kommer att undersöka men med lösningen kan funktionstester fortfarande fortsätta.

Notera: Kontrollera med dina projektteam om det är OK för QA-teamet att göra dessa ändringar innan du gör det.

# 2) Konfiguration - Ofta har vi noterat konfigurationsproblem som att inte peka på rätt miljö eller andra installationsproblem som blockerar problem. I sådana fall kan testare göra ändringar och fortsätta med testningen.

Notera: Återigen, sök tillstånd innan du gör detta.

# 3) Kodfråga - Om du känner att problemet beror på kod kan ingenting göras av testarna. Logga in en blockeringsfel och vänta tills fixen fortsätter med testningen.

# 4) Distributionsproblem - Dålig distribution är en annan vanlig orsak till blockeringsproblem och dessa kan fångas under sanity-testet. Även här bör testningen avbrytas omedelbart tills en ny version tas emot.

# 5) Miljö ner - Om miljön är nere, säg att databasen inte blir ansluten till servern eller så fungerar inte webbadressen för webbplatser. testare kan inte göra mycket i dessa fall annat än att rapportera en defekt och vänta på att systemet är igång.

Om det finns en lösning, använd den därför för att fortsätta testa. Det enda sättet att hitta, om den nämnda lösningen finns, är att undersöka grundorsaken. Oftare än inte kan det finnas ett alternativ.

Steg 2: Det är väldigt lätt att falla i en oändlig slinga när man undersöker grundorsaken. Så se till att det inte konsumerar hela dagen och hela ansträngningen.

spela wow gratis privat server

Här är några tips:

  • Hitta en balans och känna igen stopppunkten när du kommer dit.
  • En testares erfarenhet och expertis är avgörande för en framgångsrik RCA. Det är dock en bra idé att involvera teamet och lagledningen vid behov.
  • När du känner att RCA är tidskrävande, rapportera först problemet omedelbart och ge så mycket information som möjligt. En skärmdump är alltid till hjälp.
  • Om det behövs, följ upp. Skicka ett e-postmeddelande till chefen eller utvecklaren för att uppmärksamma det kritiska problemet.
  • Fortsätt felsökningen efter att ha varnat nödvändiga parter.

Anledning till att blockeringsfel bör rapporteras omedelbart:

  • Ledningen bör göras medveten om alla stilleståndstider om problemet råkar vara en showstopper-defekt. Denna information måste vidarebefordras till klienten och kan också kräva uppdateringar av projektplaner (QA-tidslinjer), förändringar i leveranser etc.
  • Varje försening i QA-leveranser måste stödjas med bevis. Så det är alltid bättre att kommunicera så snart som möjligt istället för att vänta till slutet av dagen.

Steg 3: Nu går vi vidare till det sista steget eftersom vi är färdiga med att analysera problemet och kommunicera det, vad händer nu?

  • Om problemet blockerar åtkomst till ett funktionellt område, kontrollera om det har en inverkan på andra områden
  • Om frontend-appen är nere, kontrollera om backend / middleware / databas testning kan fortsättas.
  • Om ingen testkörningsaktivitet kan äga rum, försök att arbeta med lite dokumentation relaterat till ditt projekt.
  • Du kan också försöka identifiera områden för automatisering om du manuellt upprepar mycket arbete. Automation behöver inte alltid använda ett verktyg. Säg, rapportgenerering är en monoton uppgift för dig, det är ett område som kan automatiseras med enkla Excel-makron och sådant.
  • Spendera tid på att veta om open source-verktyg som kan implementeras i ditt projekt
  • Sist men inte minst , arbeta för innovation, det mantra som styr världen för närvarande!

Till sist , flödesschemat som sammanfattar hela diskussionen!

Flödesschema: Steg för att hantera en blockeringsfel

blockeringsfel

Författare : Den här fantastiska artikeln är skriven av STH-teammedlem Priya R.

Vilka steg tar du när du stöter på något blockeringsfel?

Rekommenderad läsning

^