Meny

Det här scenariot förklarar hur viktigt det är att dokumentera de fel som ofta påträffas

  • Huvud
  • Bug Defect Tracking
  • Det här scenariot förklarar hur viktigt det är att dokumentera de fel som ofta påträffas

this scenario explains how important it is document frequently encountered errors

Prova Vårt Instrument För Att Eliminera Problem

Tror du att programvarufel inträffar bara en gång och att när de fixas kommer de aldrig upp igen? Jag känner att cirka 30% av felen återkommer.

I den här artikeln vill jag täcka hur viktigt det är att dokumentera några av de ofta förekommande felen.

Nedan hittar du några gemensamma områden där problem ses och en mall för att dokumentera dem.

Hoppas du kommer att finna det till hjälp!

Dokumentera de fel som ofta uppstått

bild källa

Scenario 1

Koden är distribuerad och redo för QA. John, testaren är redo med sina testfall. Delvis genom testning kommer han över ett problem. Han känner att det märktes flera gånger tidigare, men John visste inte hur man skulle lösa det.

Dokumentera fel 1

Dokumentera fel 2

Både John och Sheryl letade efter Smith som hade sett samma fel tidigare och hade löst det tidigare. Tyvärr var Smith på ledighet den dagen.

Vad ska John göra nu? Ska John försöka nå Smith för att hitta en resolution även när Smith inte är tillgänglig?

Därför, om en miljöfråga ses upprepade gånger i flera utsläpp, det är en bra idé att dokumentera detaljerna och placera den på en delad plats. Detta eliminerar beroendet av en individ och hjälper alla teammedlemmar att hitta en lösning själva när detta händer.

Scenario # 2

John testar en ny version och stöter på ett känt fel igen. Den här gången vet han att en defekt skapades för den i en av de tidigare utgåvorna. Men frågan är: 'hur hittar jag felnummer och andra tillhörande detaljer?'

I det här fallet, vad tror du skulle hjälpa John?

Det här är möjligheter.

Men enligt min mening, om sådana frågor är väl dokumenterade i ett separat område och delas med teamet, tillför det värde och sparar tid.

Vad du kommer att lära dig:

Några av områdena med frekventa fel:

1) Parameterfil - Baserat på min erfarenhet av Informatica-verktyget har jag i många fall märkt att paramfilen pekar på en felaktig DB-anslutning. Det har resulterat i samma problem flera gånger. Den främsta anledningen var att anslutningen delades mellan dev och QA. Så paramfilen måste alltid uppdateras enligt behov för att undvika felet.

2) URL pekar på fel DB

3) Åtkomstproblem - Användare stöter på problem när de har otillräckliga eller felaktiga åtkomstbehörigheter till DB eller i det här fallet skulle ett dokument som beskriver de steg som ska vidtas eller den person / personer som ska kontaktas vara till stor hjälp.

4) Problem med testdata - Användning av felaktigt format eller värden för data kommer oftast att resultera i problem.

5) DB-problem - Tidsgränsen för DB-anslutning är ett sådant vanligt problem. En del av stilleståndstiden är tillfällig, planerad och ibland kan vi behöva DBA: s hjälp. Användarna meddelas i förväg för planerat underhåll men för tillfälliga fel och upplösning behöver testarna definitivt

De flesta upprepade fel är i allmänhet miljöfrågor .

Dock, kodfrågor kan inte ignoreras. Ovanstående diskussion är generisk och inkluderar inte kodfrågor eftersom kodfrågor är mer specifika för din applikation, ramverk, programmeringsspråk etc.

gratis registret renare nedladdning för Windows 10

Ett litet område med defekter kan också vara datainmatning eller misstag för mänsklig användning s .

Ladda nerMallar för att spåra ofta stött på fel

Word-format

=> Ladda ner felspårningsmall (världen)

Excel-format

=> Ladda ner felspårningsmall (Excel)

Fördelar med att dokumentera fel som ofta förekommer

1) Eliminerar beroende - I Scenario 1 var John beroende av Smith för upplösning. Hade det funnits ett dokument för Johns referens skulle det inte vara fallet.

2) Snabbare vändning - Ta scenario 2. En testare behöver inte gå igenom hela listan över redan inloggade defekter om det fanns ett dedikerat dokument för högfrekventa problem.

3) Hjälper nya teammedlemmar att vara självförsörjande

4) Hjälper till att lösa mänskliga fel

Slutsats

Jag skulle säga att det definitivt är fördelaktigt att dokumentera de vanligare problemen eftersom det skulle göra en underbar referens och ett mervärde.

Det kan bli tråkigt att dokumentera medan testkörningen pågår, men som en bästa praxis kan grova anteckningar tas under körningen som senare kan sammanfattas och uppdateras i delade dokument.

Rekommenderad läsning

^