Meny

Konsten att rapportera fel: Hur marknadsför jag och fixar dina buggar?

art bug reporting

Prova Vårt Instrument För Att Eliminera Problem

Varför finns det ett behov av att marknadsföra ett fel?

Det första jag tänker på när jag börjar skriva den här artikeln är orden av Cem Kaner - ”Den bästa testaren är inte den som hittar flest buggar eller som generar de flesta programmerare. Den bästa testaren är den som får flest buggar fixade. ”

Nu - Vad är skillnaden mellan hitta de flesta buggar och får de flesta buggar fixade ?

Är det inte uppenbart att något fel har loggat in a felhanteringssystem ska fixas av utvecklaren? Svaret är nej. Faktorer som tid för att marknadsföra produkten, tid att slutföra projektet enligt schema och utvecklare som arbetar med opraktiska snäva scheman etc. tvingar företag att släppa produkten med få buggar som inte påverkar användarna till stor del.

Felrapportering art

(bild källa )

Vem ger ledningen förtroende och säger att de fel som finns i produkten inte kommer att påverka kundens förtroende, tillförlitlighet och intressen hos intressenter? - Testingenjören eller testteamet - det är varje testingenjörs plikt att få felkorrigeringar som kan ha en negativ inverkan på produktkvaliteten.

Buggens prioritet , enligt min mening, beror till stor del på hur en fråga presenteras av testaren för utvecklings- och ledningsgrupperna.

Tänk på det som att annonsera eller marknadsföra marknadsföringen - detta innebär två steg:

  1. Skriv eller rapportera fel korrekt
  2. Vet allt om felet, så alla ytterligare detaljer kan förklaras bättre

Vad du kommer att lära dig:

The Art of Bug Reporting

Ja, felrapportering är en konst . Sättet på vilket ett fel skrivs visar den tekniska skickligheten, domenexpertisen och kommunikationsförmågan hos en testingenjör.

Normalt bör ett fel innehålla följande information:

  • Bug Sammanfattning
  • Steg för att reproducera
  • Bilagor (ögonblicksbild, loggfiler etc.,)
  • Bug reproducerbarhet
  • Bug Severity
  • Programversion, miljöinformation
  • Annan information baserad på organisatoriska krav.

En viktig anmärkning: Gräva alltid djupare för att hitta orsaken till problemet och rapportera det. Till exempel kan ett enkelt inloggningsfel med rätt kombination av användarnamn och lösenord relateras till olika orsaker, till exempel:

  1. Inloggningsuppgifterna validerades inte alls
  2. Problem med timeout för nätverk vid fjärrkontroll
  3. Systemet kan betrakta all CAPS som icke-CAPS.

Så som testare borde du kunna dechiffrera skillnaderna när du följer uttalandena om buggen:

  • 'Det går inte att logga in med rätt användarnamn och lösenord'
  • 'Det går inte att logga in med rätt användarnamn och lösenord när användarnamnet eller lösenordet innehåller en blandning av CAPS och icke-CAPS-alfabet.'

Det senare är en mycket tydlig beskrivning av problemet och är entydig. Med detta ökar du inte bara din trovärdighet som testare utan du rapporterar också det faktiska problemet istället för ett symptom.

Låt oss nu titta på varje fält som är inblandat i en buggrapport och diskutera de viktiga aspekterna av var och en:

# 1. Bug Sammanfattning

En buggsammanfattning bör ge en snabb ögonblicksbild av vad exakt problemet är. Det måste vara exakt och riktat.

Exempel :

Förutom teori försöker jag förklara med exempel.

Låt oss anta en enkel inloggningsmodul. Låt oss anta att problemet eftersom en ny användare som besöker en webbplats inte kan logga in med sitt standardlösenord. När jag presenterade samma scenario för många av de studenter som jag tränade under den inledande fasen av utbildningen, fanns det flera svar som felöversikt. Nedan följer några exempel på hur sammanfattningen såg ut:

lägg till ett element i en matris

' Ny användare kan inte logga in ”

“Användarinloggning fungerar inte som förväntat”

“Användaren kan inte logga in med rätt lösenord”

felöversikt fel och rätt

Från ovanstående exempel kan du välja ett uttalande som faktiskt beskriver problemet? Jag tror inte det. Sammanfattningen bör alltid ge fullständig information om det misslyckade scenariot.

Tänk på följande påstående:

”Ny användare kan inte logga in med standardlösenordet som tillhandahålls via e-post eller SMS”

Som du kan se, från ovanstående uttalande kan en utvecklare tydligt förstå vad problemet är och var problemet är.

Så försök hitta rätt ord för att beskriva sammanfattningen som skulle ge informationen direkt. Generiska uttalanden som 'fungerar inte ordentligt', 'fungerar inte som förväntat' etc. måste undvikas.

# 2. Steg för att reproducera och bilagor

Irreproducerbara buggar tar alltid baksätet trots att de kan vara betydelsefulla. Var därför noga med att skriva stegen korrekt och beskrivande.

Stegen bör vara korrekta och exakt samma som de som ledde till problemet. För funktionsrelaterade buggar är följande exempel det bästa exemplet.

Exempel :

Tänk på samma fråga som anges i föregående avsnitt.

  1. Skapa en ny användare med alternativet Registrera dig på startsidan. (Exempel på användarnamn: HelloUser)
  2. Ett e-postmeddelande och ett SMS kommer att tas emot med ett standardlösenord. E-post-ID och mobilnummer för SMS anges när du skapar användaren i steg 1. (Exempel på e-post: HelloUser@hello.com , Exempel på mobilnummer: 444-222-1123)
  3. Välj inloggningsalternativ på startsidan.
  4. I användarfältets textfält anger du det användarnamn som anges i steg 1.
  5. I lösenordsfältet anger du standardlösenordet som tas emot via e-post eller SMS.
  6. Klicka på knappen Logga in
  7. Förväntat resultat: Användaren ska kunna logga in med det angivna användarnamnet och lösenordet och navigera till sidan Användarkonto.
  8. Faktiskt resultat: Meddelandet 'Ogiltigt användarnamn / lösenord' visas.

steg för felrapporter

Om någon av informationen inte finns i ovanstående exempel kommer den att göra det resultera i kommunikationsbrister och utvecklaren kommer inte att kunna reproducera problemet. Stegen måste vara specifika och detaljerade med de exempeldata som du använder under testningen.

Om möjligt eller i förekommande fall, ange en ögonblicksbild av vad du exakt ser på skärmen. På det här sättet kommer det inte bara att ge utvecklarna en bra bild av problemet utan också ett bevis på ditt testresultat.

De icke-funktionell testfall som stress-, stabilitets- eller prestanda testfall utöver ovanstående detaljer kan information om scenariot som orsakar stress för systemet rapporteras som det är. Dessutom finns det få system som rapporterar loggar för varje operation som utförs. Loggar är vanligtvis utskriftsuttalanden från utvecklarna i deras kod. När en modul körs kommer motsvarande loggar att skrivas ut eller visas. När loggar finns tillgängliga skulle det i stor utsträckning hjälpa utvecklare att återskapa problemet.

# 3. Fel reproducerbarhet

En fråga som är stor eller liten prioriteras baserat på reproducerbarheten. Det kan ses alltid, ibland, sällan eller till och med bara en gång. En fråga som återges som 'alltid' prioriteras högre än resten.

kan inte reproducera en defekt

Så det är en testingenjörs plikt att spåra scenariot exakt för den fråga som alltid reproduceras. Ibland kan det finnas få problem som inte är kontrollerade av en testingenjör, vilket skulle resultera i att ett problem reproduceras bara några gånger men i flera försök. I sådana fall ska du alltid ange antalet försök, ett visst scenario utförs tillsammans med hur många gånger problemet ses under dessa försök.

Detta skulle i sin tur lägga till trovärdighet till den felrapport som du nämner. Återigen skulle detta förbättra ditt rykte som testare. Jag skulle senare berätta varför du har ett gott rykte.

# 4. Bug Severity

Svårighetsgrad är utan tvekan en av de största påverkarna för att prioritera buggen.

Följande är de olika kategorierna av svårighetsgrad. Observera att detta bara är allmänna prover och att det varierar från företag till företag.

  1. Svårighetsgrad 1 - Visa stoppare - för fel som är katastrofala, utan att rättas till kommer användaren inte att kunna fortsätta använda programvaran och det finns ingen möjlig lösning
  2. Severity 2 - High - för buggar som liknar Severity 1, men det finns en lösning
  3. Svårighetsgrad 3 - Medium
  4. Svårighetsgrad 4 - Låg
  5. Svårighetsgrad 5 - Trivial.

Låt oss till exempel jämföra två liknande problem.

I våra digitalboxar är det få tjänsteleverantörer som tillhandahåller frekvensinformationen för tjänsten som för närvarande inställd. Låt oss anta att frekvensen visas som 100 MHz istället för 100,20 MHz. Detta påverkar kanske inte användarens visning av tjänsterna men kan påverka när det gäller övervakning av diagnostik för set-tops. Därför kan detta presenteras som en Severity 3-fråga.

Om du antar en liknande fråga inom bankdomänen: Om ditt kontosaldo visas som $ 100, istället för $ 100,20, föreställ dig effekten av problemet. Detta måste vara en svårighetsgrad -1-defekt. Som du kan se i båda fallen är frågan mycket lik att användargränssnittet inte visar siffrorna efter decimal. Men påverkan varierar beroende på vilken domän som är inblandad.

Effektivt deltagande i möten för programvaruversionskontroll

Vanligtvis har varje organisation sin egen process för att undersöka och prioritera buggar. Generellt sett skulle ett möte inträffa med specifika intervaller under projektet för att diskutera buggarna och prioritera detsamma.

Processen under sådana möten är som följer:

  1. Fråga listan över buggar från felhanteringssystemet beroende på svårighetsgraden.
  2. Titta på sammanfattningen och diskutera felets inverkan på användarens upplevelse för att använda en programvaruprodukt.
  3. Baserat på risk- och konsekvensbedömningen ställer du in prioriteten och tilldelar felet till en lämplig utvecklare för att fixa densamma.

Under steg # 2 är det absolut nödvändigt att varje testingenjör förespråkar felets inverkan på användarupplevelsen om felet inte får den prioritet det förtjänar. När allt kommer omkring är det vi testingenjörer som överväger en användares synvinkel för att skriva testfall och testa produkten.

Tänk på exemplet ovan om att inte visa siffrorna efter decimal i en bankdomän. För en utvecklare kan det verka som en mindre allvarlig fråga. Han kan hävda att i stället för att förklara variabeln som ett heltal skulle han förklara det som en flytande punkt för att lösa problemet och därmed mindre allvarligt.

Men som testare förklarar din roll kundens situation. Din poäng bör vara hur användaren skulle klaga i det här scenariot. Testaren bör säga att detta kommer att orsaka panik bland användarna eftersom kunden tappar sina pengar i cent.

Effekten av att inte marknadsföra ett fel korrekt

Om ett fel inte marknadsförs ordentligt kommer det att skapa problem som:

  • Fel felprioritet
  • Försena med att lösa de viktiga frågorna
  • Produktutsläpp med svåra defekter
  • Negativ feedback från kunder
  • Devaluera varumärkesvärde

Effekten av att inte marknadsföra ett fel korrekt

Förutom alla ovan nämnda skäl är det mycket viktigt att bygga din rykte som testingenjör . Det är mer som att utveckla ett varumärkesvärde för dig själv.

Om du i början av din karriär kan hålla ditt antal 'Kan inte reproducera' eller 'Behöver mer information' eller 'Inte ett giltigt fel' eller förändringar i svårighetsgrad så lågt som möjligt, kommer dina buggar i ett skede inte att granskas alls och de skulle direkt tilldelas till lämplig utvecklare som skulle fixas.

För att utveckla ett sådant varumärkesvärde och för att vinna förtroendet hos ditt team och utveckling / eller ledningsgrupper måste du utveckla några tekniska färdigheter när det gäller testning av kunskap, domän och kommunikationsförmåga.

Slutsats

Varje produkt eller tjänst, antingen stor eller liten, kommer alltid att misslyckas utan korrekt reklam. När ett varumärke väl har etablerats kan vilken liten produkt som helst bli en superhit bland publiken.

Med detta sagt kan överannonsering av en produkt också skada rykte.

Så ett fel ska alltid skrivas på ett tydligt, koncist och exakt sätt så att det ger en exakt plats för felet i den omfattande / uttömmande programkartan. Jag upprepar att detta inte bara förbättrar kvaliteten på programvaran utan också minskar kostnaden för att testa och utveckla programvaran till en stor del.

Det är inte för sent nu! Låt oss gå vidare och fixa fel direkt!

vad är en nätverkssäkerhetskod

Rekommenderad läsning

^