Meny

Kunsten med feilrapportering: Hvordan markedsføre og få fikset feilene dine?

art bug reporting

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hvorfor er det behov for markedsføring av et feil?

De første tingene som kommer til meg når jeg begynner å skrive denne artikkelen er ordene til Cem Kaner - “Den beste testeren er ikke den som finner flest feil eller som flau for de fleste programmerere. Den beste testeren er den som får flest feil løst. ”

Nå - Hva er forskjellen mellom å finne de fleste feil og får de fleste feilene løst ?

Er det ikke åpenbart at noen feil logget inn a feilhåndteringssystem skal fikses av utvikleren? Svaret er nei. Faktorer som tid til å markedsføre produktet, tid til å fullføre prosjektet etter planen og utviklere som jobber med upraktiske stramme tidsplaner osv. tvinger selskaper til å frigjøre produktet med få feil som ikke i stor grad vil påvirke brukerne.

Feilrapportering art

(bilde kilde )

Hvem gir ledelsen tillit til å si at feilene i produktet ikke vil påvirke kundens tillit, pålitelighet og interessene til interessenter? - Testingeniøren eller testteamet - det er hver testingeniørs plikt å få fikset feil som kan ha negativ innvirkning på produktkvaliteten.

Prioriteten til feilen , avhenger etter min mening i stor grad av hvordan en problemstilling presenteres av testeren til utviklings- og lederteamene.

Tenk på det som å annonsere eller markedsføre problemet - dette innebærer to trinn:

  1. Skriv eller rapporter feil feil
  2. Vet alt om feilen, så ytterligere detaljer kan forklares bedre

Hva du vil lære:

The Art of Bug Reporting

Ja, feilrapportering er en kunst . Måten en feil er skrevet på viser den tekniske dyktigheten, domenekompetansen og kommunikasjonsmulighetene til en testingeniør.

Vanligvis bør en feil inneholde følgende informasjon:

  • Feilsummering
  • steg for å reprodusere
  • Vedlegg (øyeblikksbilde, loggfiler osv.,)
  • Feil reproduserbarhet
  • Feil alvorlighetsgrad
  • Programvareversjon, miljøinformasjon
  • Annen informasjon basert på organisatoriske krav.

En viktig merknad: Grav alltid dypere for å finne årsaken til problemet og rapporter det. For eksempel kan en enkel påloggingsfeil med riktig kombinasjon av brukernavn og passord være relatert til forskjellige årsaker som:

  1. Påloggingsinformasjon er ikke validert i det hele tatt
  2. Problemer med nettverkstidsavbrudd i tilfelle eksterne pålogginger
  3. Systemet kan vurdere all CAPS som ikke-CAPS.

Så som en tester bør du være i stand til å dechiffrere forskjellene mens du følger uttalelsene om sammendragene av feilene:

  • 'Kan ikke logge inn med riktig brukernavn og passord'
  • 'Kan ikke logge inn med riktig brukernavn og passord når brukernavnet eller passordet inneholder en blanding av CAPS og ikke-CAPS-alfabeter.'

Sistnevnte er en veldig klar beskrivelse av problemet og er entydig. Med dette øker du ikke bare troverdigheten din som tester, men du rapporterer også om det faktiske problemet i stedet for et symptom.

La oss nå se på hvert felt som er involvert i en feilrapport og diskutere de viktige aspektene ved hvert enkelt felt:

#1. Feilsummering

En feilsammendrag skal gi et raskt øyeblikksbilde av hva problemet er. Det må være presist og godt styrt.

Eksempel :

Bortsett fra teori, vil jeg prøve å forklare med eksempler.

La oss anta en enkel påloggingsmodul. La oss anta at problemet da en ny bruker som besøker et nettsted ikke kan logge inn med standardpassordet. Da jeg presenterte det samme scenariet for mange av studentene som jeg trente i den første fasen av opplæringen, var det flere svar som feiloppsummering. Nedenfor er noen eksempler på hvordan sammendraget så ut:

hvordan du kjører en jnlp-fil

' Ny bruker kan ikke logge inn ”

“Brukerinnlogging fungerer ikke som forventet”

“Brukeren kan ikke logge inn med riktig passord”

feiloppsummering feil og riktig

Fra eksemplene ovenfor, kan du velge en påstand som faktisk beskriver problemet? Jeg tror ikke det. Sammendraget skal alltid gi fullstendig informasjon om det sviktende scenariet.

Tenk på følgende utsagn:

“Ny bruker kan ikke logge inn med standardpassordet som tilbys via e-post eller SMS”

Som du kan se, kan en utvikler fra ovenstående uttalelse tydelig forstå hva problemet er og hvor problemet er.

Så prøv å finne de riktige ordene for å beskrive sammendraget som gir informasjonen direkte. Generiske utsagn som 'ikke fungerer ordentlig', 'fungerer ikke som forventet' osv., Må unngås.

# 2. Fremgangsmåte for reproduksjon og vedlegg

Irreproducible bugs tar alltid baksetet, selv om de kan være viktige. Vær derfor nøye med å skrive trinnene riktig og beskrivende.

Fremgangsmåten skal være nøyaktig og nøyaktig den samme som de som førte til problemet. For funksjonsrelaterte feil er følgende eksempel det beste eksemplet.

Eksempel :

Tenk på det samme problemet som ble oppgitt i forrige avsnitt.

  1. Opprett en ny bruker ved hjelp av Registreringsalternativ på hjemmesiden. (Eksempel på brukernavn: HelloUser)
  2. En e-post og en SMS vil bli mottatt med standard passord. E-post-ID og mobilnummer for SMS oppgis mens du oppretter brukeren i trinn 1. (Eksempel på e-post: HelloUser@hello.com Eksempel på mobilnummer: 444-222-1123)
  3. Velg påloggingsalternativ på hjemmesiden.
  4. I tekstfeltet brukernavn, oppgi eksempelbrukernavnet du oppga i trinn 1.
  5. I passordfeltet oppgir du standardpassordet du mottar via en e-post eller SMS.
  6. Klikk på Logg på-knappen
  7. Forventet resultat: Bruker skal kunne logge inn med det oppgitte brukernavnet og passordet og navigere til siden Brukerkonto.
  8. Egentlige resultatet: Meldingen 'Ugyldig brukernavn / passord' vises.

feilrapport trinn

Hvis noe av informasjonen ikke er gitt i eksemplet ovenfor, vil den gjøre det føre til kommunikasjonshull og utvikleren vil ikke være i stand til å reprodusere problemet. Trinnene må være spesifikke og detaljerte med eksempeldataene du bruker under testing.

Hvis mulig eller der det er aktuelt, oppgi en øyeblikksbilde av det du ser nøyaktig på skjermen. På denne måten vil det ikke bare gi utviklerne en god oversikt over problemet, men også et bevis på testresultatet ditt.

De ikke-funksjonell testtilfeller som stress-, stabilitets- eller ytelsestesttilfeller i tillegg til de ovennevnte detaljene, kan informasjon om scenariet som forårsaker stresset til systemet rapporteres som det er. I tillegg er det få systemer som rapporterer logger for hver operasjon som utføres. Logger er vanligvis utskriftsuttalelser fra utviklerne i koden. Hver gang en modul utføres, vil de tilsvarende loggene skrives ut eller vises. Når logger er tilgjengelige, vil det i stor grad hjelpe utviklere med å gjengi problemet.

# 3. Feil reproduserbarhet

Et problem som er stort eller lite vil bli prioritert ut fra reproduserbarheten. Det kan sees alltid, noen ganger, sjelden eller til og med bare en gang. Et spørsmål som er gjengitt som “alltid” vil bli prioritert høyere enn resten.

kan ikke reprodusere en feil

Så det er en plikt for en testingeniør å spore scenariet nøyaktig for problemet som alltid blir gjengitt. Noen ganger kan det være få problemer som ikke er kontrollert av en testingeniør, noe som vil resultere i at et problem blir gjengitt bare noen få ganger, men i flere forsøk. I slike tilfeller må du alltid nevne antall forsøk. Et bestemt scenario utføres sammen med antall ganger problemet blir sett under disse prøvene.

Dette vil igjen gi troverdighet til feilrapporten du har nevnt. Igjen, dette vil forbedre omdømmet ditt som tester. Jeg vil senere fortelle deg årsakene til at du har et godt rykte.

# 4. Feil alvorlighetsgrad

Alvorlighetsgrad er utvilsomt en av de største påvirkerne for å prioritere Bug.

Følgende er de forskjellige kategoriene av alvorlighetsgrad. Vær oppmerksom på at dette bare er generelle eksempler, og at det varierer fra selskap til selskap.

  1. Alvorlighetsgrad 1 - Vis stopper - for feil som er katastrofale, uten å være løst, vil ikke brukeren kunne fortsette å bruke programvaren, og det er ingen mulig løsning
  2. Alvorlighetsgrad 2 - Høy - for feil som ligner på Alvorlighetsgrad 1, men det er en løsning
  3. Alvorlighetsgrad 3 - Middels
  4. Alvorlighetsgrad 4 - Lav
  5. Alvorlighetsgrad 5 - Trivial.

La oss for eksempel sammenligne to lignende problemer.

I våre dekoder er det få tjenesteleverandører som gir frekvensinformasjonen til tjenesten slik den er innstilt. La oss anta at frekvensen vises som 100 MHz i stedet for 100,20 MHz. Dette påvirker kanskje ikke brukerens visning av tjenestene, men kan påvirke når det gjelder overvåking av diagnostikk av set-tops. Derfor kan dette presenteres som en alvorlighetsgrad 3-utgave.

Forutsatt et lignende problem i banksektoren: Hvis kontosaldoen din vises som $ 100, i stedet for $ 100,20, kan du forestille deg effekten av problemet. Dette må være en alvorlighetsgrad -1-feil. Som du kan se i begge tilfeller, er problemet veldig likt at brukergrensesnittet ikke viser sifrene etter desimaltegnet. Men påvirkningen varierer i henhold til det involverte domenet.

Effektiv deltakelse i programvareversjonskontrollmøter

Vanligvis har hver organisasjon sin egen prosess for å undersøke og prioritere feil. Generelt vil et møte finne sted med bestemte intervaller i løpet av prosjektet for å diskutere feilene og prioritere det samme.

Prosessen under slike møter er som følger:

  1. Spør listen over feil fra feilstyringssystemet i henhold til alvorlighetsgraden.
  2. Se på sammendraget og diskuter innvirkningen av feilen på brukerens opplevelse av å bruke et programvareprodukt.
  3. Basert på risiko- og konsekvensanalysen, angi prioriteten og tildel feilen til en passende utvikler for å fikse den samme.

Under trinn 2 er det viktig at enhver testingeniør tar til orde for feilens innvirkning på brukeropplevelsen hvis feilen ikke får den prioritet den fortjener. Tross alt er det vi testingeniører som vurderer synspunktet til en bruker for å skrive testsaker og for å teste produktet.

Tenk på eksemplet ovenfor om å ikke vise sifrene etter desimaltegn i et bankdomene. For en utvikler kan det virke som et mindre alvorlig problem. Han kan hevde at i stedet for å erklære variabelen som et heltall, vil han erklære det som et flytende punkt for å løse problemet og dermed mindre alvorlig.

Men som tester forklarer din rolle kundens situasjon. Poenget ditt bør være hvordan brukeren vil klage i dette scenariet. Testeren skal si at dette vil føre til panikk blant brukerne ettersom kunden mister pengene sine i cent.

Effekten av å ikke markedsføre en feil riktig

Hvis en feil ikke markedsføres riktig, vil det skape problemer som:

  • Feil feilprioritet
  • Forsink med å fikse de viktige problemene
  • Produktutgivelse med alvorlige mangler
  • Negative tilbakemeldinger fra kunder
  • Devaluere merkeverdien

Effekten av å ikke markedsføre en feil riktig

Bortsett fra alle grunnene nevnt ovenfor, er det veldig viktig å bygge din rykte som testingeniør . Det er mer som å utvikle en merkevareverdi for deg selv.

I den innledende fasen av karrieren din, hvis du kan holde antallet 'Kan ikke reprodusere' eller 'Trenger mer informasjon' eller 'Ikke et gyldig feil' eller endringer i alvorlighetsgrad så lavt som mulig, vil ikke feilene dine på et tidspunkt bli gransket i det hele tatt, og de vil bli direkte tilordnet den aktuelle utvikleren som skal løses.

For å utvikle slik merkevareverdi og for å vinne tilliten til teamet ditt og utvikling / eller ledergruppene, må du utvikle noen tekniske ferdigheter når det gjelder testing av kunnskap, domene og kommunikasjonsevner.

Konklusjon

Ethvert produkt eller tjeneste enten stor som liten, vil alltid mislykkes uten riktig reklame. Når et merke er etablert, kan ethvert lite produkt bli en superhit blant publikum.

Når det er sagt, kan overannonsering av et produkt også skade omdømmet.

Så en feil skal alltid skrives på en klar, kort og presis måte slik at den gir en nøyaktig plassering av feilen i det omfattende / uttømmende programvarekartet. Jeg gjentar at dette ikke bare forbedrer kvaliteten på programvaren, men også reduserer kostnadene ved testing og utvikling av programvaren i stor grad.

Det er ikke for sent nå! La oss gå videre og få feil løst med en gang!

hvordan du åpner en .air fil

Anbefalt lesing

^