Menu

Kunsten med fejlrapportering: Hvordan markedsføres og repareres dine fejl?

art bug reporting

Prøv Vores Instrument Til At Fjerne Problemer

Hvorfor er der behov for markedsføring af et fejl?

De første ting, der kommer til at tænke mig, når jeg begynder at skrive denne artikel, er ordene fra Cem Kaner - ”Den bedste tester er ikke den, der finder mest bugs, eller som generer de fleste programmører. Den bedste tester er den, der får de fleste bugs rettet. ”

Nu - Hvad er forskellen mellem at finde de fleste bugs og at få de fleste fejl rettet ?

Er det ikke indlysende, at enhver fejl logget ind a bug management system skal rettes af udvikleren? Svaret er nej. Faktorer som tid til at markedsføre produktet, tid til at gennemføre projektet efter planen og udviklere, der arbejder i upraktiske stramme tidsplaner osv. tvinger virksomheder til at frigive produktet med få fejl, som ikke i vid udstrækning påvirker brugerne.

Fejlrapportering art

(billede kilde )

Hvem giver ledelsen tillid m om, at de fejl, der findes i produktet, ikke vil påvirke kundens tillid, pålidelighed og interesser fra interessenter? - Testingeniøren eller testteamet - det er hver testingeniørs pligt at få bugs løst, der kan have en negativ indvirkning på produktkvaliteten.

Fejlens prioritet , afhænger efter min mening i vid udstrækning af, hvordan et emne præsenteres af testeren til udviklings- og ledelsesteamene.

Tænk på det som at annoncere eller markedsføre problemet - dette involverer 2 trin:

  1. Skriv eller rapporter fejl korrekt
  2. Ved alt om fejlen, så yderligere detaljer kan forklares bedre

Hvad du lærer:

The Art of Bug Reporting

Ja, fejlrapportering er en kunst . Den måde, hvorpå en fejl er skrevet, viser den tekniske færdighed, domæneekspertise og kommunikationsmuligheder hos en testingeniør.

En fejl skal typisk indeholde følgende oplysninger:

  • Fejloversigt
  • Trin til reproduktion
  • Vedhæftede filer (øjebliksbillede, logfiler osv.,)
  • Fejl reproducerbarhed
  • Fejl i sværhedsgrad
  • Softwareversion, miljøoplysninger
  • Andre oplysninger baseret på organisatoriske krav.

En vigtig note: Grav altid dybere for at finde årsagen til problemet, og rapporter det. For eksempel kan en simpel loginfejl med den korrekte kombination af brugernavn og adgangskode være relateret til forskellige årsager såsom:

  1. Loginoplysninger er slet ikke valideret
  2. Problemer med netværks-timeout i tilfælde af fjernlogins
  3. Systemet kan betragte al CAPS som ikke-CAPS.

Så som en tester skal du være i stand til at dechiffrere forskellene, mens du følger bugsammendragene:

  • “Kan ikke logge ind med det korrekte brugernavn og adgangskode”
  • 'Kan ikke logge ind med det korrekte brugernavn og adgangskode, når brugernavnet eller adgangskoden indeholder en blanding af CAPS og ikke-CAPS-alfabeter.'

Sidstnævnte er en meget klar beskrivelse af problemet og er utvetydig. Med dette øger du ikke kun din troværdighed som tester, men du rapporterer også det faktiske problem i stedet for et symptom.

Lad os nu se på hvert felt, der er involveret i en fejlrapport, og diskutere de vigtige aspekter af hver enkelt:

# 1. Fejloversigt

En fejloversigt skal give et hurtigt øjebliksbillede af, hvad problemet er. Det skal være præcist og velstyret.

Eksempel :

Bortset fra teori, vil jeg prøve at forklare med eksempler.

Lad os antage et simpelt login-modul. Lad os antage problemet, da en ny bruger, der besøger et websted, ikke kan logge ind med sin standardadgangskode. Da jeg præsenterede det samme scenarie for mange af de studerende, som jeg uddannede i den indledende fase af træningen, var der flere svar som fejloversigt. Nedenfor er der få eksempler på, hvordan resuméet så ud:

bedste video downloader fra ethvert websted

' Ny bruger kan ikke logge ind ”

“Brugerlogin fungerer ikke som forventet”

“Brugeren kan ikke logge ind med den korrekte adgangskode”

fejloversigt forkert og rigtigt

Fra ovenstående prøver kan du vælge en erklæring, der faktisk beskriver problemet? Jeg tror ikke det. Resumeet skal altid give en komplet information om det svigtende scenario.

Overvej følgende udsagn:

“Ny bruger kan ikke logge ind med standardadgangskoden, der leveres via e-mail eller SMS”

Som du kan se, kan en udvikler fra ovenstående erklæring klart forstå, hvad problemet er, og hvor problemet er.

Så prøv at finde de rigtige ord til at beskrive resuméet, der giver oplysningerne direkte. Generiske udsagn som 'ikke fungerer korrekt', 'fungerer ikke som forventet' osv. Skal undgås.

# 2. Trin til reproduktion og vedhæftede filer

Irreproducerbare bugs tager altid et bagsæde, selvom de kan være vigtige. Vær derfor forsigtig med at skrive trinnene korrekt og beskrivende.

Trin skal være nøjagtige og nøjagtigt de samme som dem, der førte til problemet. For funktionsrelaterede fejl er følgende eksempel det bedste eksempel.

Eksempel :

Overvej det samme problem, der er angivet i det foregående afsnit.

  1. Opret en ny bruger ved hjælp af Tilmeldingsmulighed på startsiden. (Eksempel på brugernavn: HelloUser)
  2. En e-mail og en SMS modtages med en standardadgangskode. E-mail-id'et og mobilnummeret til SMS gives, mens du opretter brugeren i trin 1. (Eksempel på e-mail: HelloUser@hello.com Eksempel på mobilnummer: 444-222-1123)
  3. Vælg Login-indstilling på startsiden.
  4. I tekstfeltet brugernavn skal du angive prøvebrugernavnet, der er angivet i trin # 1.
  5. I adgangskodefeltet skal du angive standardadgangskoden, der modtages via en e-mail eller SMS.
  6. Klik på knappen Log ind
  7. Forventet resultat: Brugeren skal være i stand til at logge ind med det angivne brugernavn og adgangskode og navigere til siden Brugerkonto.
  8. Faktisk resultat: Meddelelsen 'Ugyldigt brugernavn / adgangskode' vises.

fejlrapport trin

Hvis nogen af ​​oplysningerne ikke er angivet i ovenstående prøve, vil de gøre det resultere i kommunikationshuller og udvikleren kan ikke gengive problemet. Trinene skal være specifikke og detaljerede med de eksempeldata, du bruger under testningen.

Hvis det er muligt eller hvor det er relevant, skal du angive en øjebliksbillede af hvad du ser nøjagtigt på skærmen. På denne måde vil det ikke kun give udviklerne et godt overblik over problemet, men også et bevis på dit testresultat.

Det ikke-funktionel testtilfælde som f.eks. stress-, stabilitets- eller præstationstestsager ud over ovenstående detaljer kan oplysninger om scenariet, der forårsager stress til systemet, rapporteres, som det er. Derudover er der få systemer, der rapporterer logfiler for hver operation, der udføres. Logfiler er typisk udskriftserklæringer leveret af udviklerne i deres kode. Hver gang et modul udføres, udskrives eller vises de tilsvarende logfiler. Når logfiler er tilgængelige, vil det i høj grad hjælpe udviklere med at gengive problemet.

# 3. Fejl reproducerbarhed

Et problem, der er stort eller lille, prioriteres ud fra reproducerbarheden. Det kan ses altid, nogle gange, sjældent eller endda kun en gang. Et emne, der gengives som 'altid', prioriteres højere end resten.

kan ikke reproducere en defekt

Så det er en testingeniørs pligt at spore scenariet nøjagtigt for det emne, der altid gengives. Nogle gange kan der være få problemer ude af kontrol med en testingeniør, hvilket ville resultere i, at et problem kun gengives et par gange, men i flere forsøg. I sådanne tilfælde skal du altid nævne antallet af forsøg, et bestemt scenarie udføres sammen med antallet af gange, problemet ses under disse forsøg.

Dette vil igen tilføje troværdighed til den fejlrapport, du har nævnt. Igen vil dette forbedre dit omdømme som tester. Jeg vil senere fortælle dig grundene til at have et godt omdømme.

# 4. Fejl i sværhedsgrad

Alvorligheden er utvivlsomt en af ​​de største påvirkere for at prioritere bugten.

Følgende er de forskellige kategorier af sværhedsgrad. Bemærk, at dette kun er generelle prøver, og det varierer fra firma til virksomhed.

  1. Alvorlighed 1 - Vis stopper - for fejl, der er katastrofale, uden at være rettet, kan brugeren ikke fortsætte med at bruge softwaren, og der er ingen mulig løsning
  2. Severity 2 - High - for bugs svarende til Severity 1, men der er en løsning
  3. Sværhedsgrad 3 - Medium
  4. Sværhedsgrad 4 - Lav
  5. Sværhedsgrad 5 - Trivial.

Lad os f.eks. Sammenligne to lignende problemer.

I vores set-top-bokse leverer få tjenesteudbydere frekvensoplysningerne for tjenesten som aktuelt indstillet. Lad os antage, at frekvensen vises som 100 MHz i stedet for 100,20 MHz. Dette påvirker muligvis ikke brugerens visning af tjenesterne, men kan påvirke med hensyn til overvågningsdiagnostik af set-tops. Derfor kan dette præsenteres som et Severity 3-emne.

Antages et lignende problem i bankdomænet: Hvis din kontosaldo vises som $ 100 i stedet for $ 100,20, forestil dig virkningen af ​​problemet. Dette skal være en alvorligheds -1-defekt. Som du kan se i begge tilfælde, er problemet meget ens, at brugergrænsefladen ikke viser cifrene efter decimaltegnet. Men virkningen varierer afhængigt af det involverede domæne.

Effektiv deltagelse i softwareversionskontrolmøder

Normalt har hver organisation sin egen proces til at undersøge og prioritere fejl. Generelt ville der være et møde med bestemte intervaller under projektet for at diskutere fejlene og prioritere det samme.

Processen under sådanne møder er som følger:

  1. Spørg listen over fejl fra fejlstyringssystemet i henhold til sværhedsgraden.
  2. Se på resuméet og diskuter indvirkningen af ​​bugten på brugerens oplevelse af brugen af ​​et softwareprodukt.
  3. Baseret på risiko- og konsekvensanalysen skal du indstille prioriteten og tildele fejlen til en passende udvikler til at rette den samme.

Under trin 2 er det bydende nødvendigt, at hver testingeniør går ind for bugens indvirkning på brugeroplevelsen, hvis fejlen ikke får den prioritet, den fortjener. Når alt kommer til alt er det vi testingeniører, der overvejer brugerens synspunkt til at skrive testcases og til at teste produktet.

Overvej ovenstående eksempler på ikke at vise cifrene efter decimal i et bankdomæne. For en udvikler kan det virke som et mindre alvorligt problem. Han hævder måske, at i stedet for at erklære variablen som et heltal, ville han erklære det som et flydende punkt for at løse problemet og dermed mindre alvorligt.

Men som tester forklarer din rolle kundens situation. Dit punkt skal være, hvordan brugeren klager i dette scenarie. Testeren skal sige, at dette vil medføre panik blandt brugerne, da kunden mister sine penge i cent.

Virkningen af ​​ikke at markedsføre en fejl korrekt

Hvis en fejl ikke markedsføres ordentligt, vil det skabe problemer som:

  • Forkert prioritets prioritet
  • Forsink med at løse de vigtige problemer
  • Produktfrigivelse med alvorlige mangler
  • Negativ feedback fra kunder
  • Devaluering af brandværdi

Virkningen af ​​ikke at markedsføre en fejl korrekt

Bortset fra alle de ovennævnte grunde er det meget vigtigt at bygge din omdømme som testingeniør . Det er mere som at udvikle en brandværdi for dig selv.

I den indledende fase af din karriere, hvis du kan holde dit antal 'Kan ikke reproducere' eller 'Brug for mere information' eller 'Ikke et gyldigt fejl' eller ændringer i sværhedsgrad så lavt som muligt, vil dine bugs på et tidspunkt ikke blive undersøgt overhovedet, og de vil blive direkte tildelt den relevante udvikler, der skal rettes.

For at udvikle en sådan brandværdi og for at vinde tillid hos dit team og udvikling / eller ledelsesteams skal du udvikle nogle tekniske færdigheder med hensyn til test af viden, domæne og kommunikationsevner.

Konklusion

Ethvert produkt eller enhver tjeneste, som er stor eller lille, vil altid mislykkes uden ordentlig reklame. Når et brand er etableret, kan ethvert lille produkt være et superhit hos publikum.

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

Så en fejl skal altid skrives på en klar, kortfattet og præcis måde, så den giver en nøjagtig placering af fejlen i det omfattende / udtømmende softwarekort. Jeg gentager, at dette ikke kun forbedrer softwarekvaliteten, men også reducerer omkostningerne ved test og udvikling af softwaren i høj grad.

Det er ikke for sent nu! Lad os gå videre og få bugs rettet med det samme!

indsættelsessorteringskode c ++

Anbefalet læsning

^