Forestil dig, at du er en udvikler, og en tester bringer dig en fejl, der blev fundet under regression. Du vil rette denne fejl, så du beder om at få oprettet en billet. Du forestiller dig allerede, hvordan du vil samle det op, knytte pull-anmodninger til det og tilføje estimater, så produktchefen ikke har nogen spørgsmål.  Der går noget tid, og en ny billet dukker op, men indeni er der kun et par linjer og et skærmbillede. Med et suk forsøger du at reproducere fejlen ved hjælp af denne information, men der er ingen fejl. Du forsøger flere gange, men til sidst skriver du til testeren, at fejlen ikke kan reproduceres, og en ny runde af afklaringer begynder.  Du bruger tid, der kunne have været brugt til at arbejde på nye opgaver, rette andre fejl eller endda   genskabe koden. se anime  Mit navn er   ; Jeg er en   , og jeg vil prøve at dele mit syn på, hvad der gør en god fejlrapport. Beklager den lange introduktion – lad os komme i gang. Evgeny Domnin QA   Titel  Prøv at besvare tre spørgsmål i billettitlen:   Hvor sker det?   Hvad sker der?   Under hvilke omstændigheder?  En erfaren udvikler behøver kun at kigge på titlen for at forstå problemet. For eksempel:   Loginside: Feltet er ikke fremhævet, når du indtaster en forkert adgangskode   Miljø  Jeg har ofte set testere glemme at angive i billetten, hvilket miljø problemet opstod i. Dette er især relevant i UI-relaterede billetter, hvor hjemmesidens adresse eller netværksanmodning ikke er synlig. Angiv altid dette. Hvis der er et separat felt i billetten, så læg det der. Hvis ikke, skal du nævne det i reproduktionstrinnene, for eksempel:   Log ind på iscenesættelsesmiljøet med en administratorkonto.  Apropos trin...   Reproduktionstrin  En af de vigtigste sektioner er instruktionerne til gengivelse af fejl. Jeg vil fremhæve to dele at fokusere på: formateringen af trinene (visuelt) og indholdet (data inde).  Visuel del   Vedligehold struktur  Der er forskellige variationer af fejlrapporter, men klassisk bør de indeholde følgende sektioner:  Trin  Forventet resultat  Faktisk resultat  Brug denne struktur, og hold dig altid til den. Dette er et af de tilfælde, hvor ensartethed vil hjælpe med at organisere dine tanker, når du beskriver problemet.   Brug en nummereret liste  Opdel trinene ved hjælp af en nummereret liste. Nogle gange skriver testere detaljerede beskrivelser, men som en kontinuerlig tekstblok. Gør ikke dette. Det vil være meget nemmere for alle at læse, hvis trinene er adskilt.  Når det er muligt, skriv uden grammatiske fejl.  Lad os nu gå videre til indholdet af disse trin.  Sund fornuft i beskrivelser  Du behøver ikke at nedbryde hver enkelt handling i et separat trin, hvis det ikke er afgørende for at reproducere fejlen – det er svært at læse og bruge i praksis. Vær ikke bange for at inkludere flere handlinger i ét trin. Hvad mener jeg?    : Dårlig  Gå til  test.com/login  Klik på login-feltet  Indtast login  Klik på adgangskodefeltet  Indtast adgangskoden    : Godt  Gå til   og log ind med en hvilken som helst konto test.com/login  Vi opdeler ikke trinene i ting, som udvikleren naturligt vil gøre, mens han følger standardflowet. Da jeg startede, tænkte jeg, at hver enkelt handling havde brug for sit eget skridt, men det er ikke nødvendigt.   Undgå tvetydighed  Suppler altid trinene med den specifikke anmodning om at kontrollere ved hvert trin, og skriv den specifikke knap, der skal trykkes på (især hvis der er knapper med samme navn).   Inkluder testdata  Angiv login-data, hvis fejlen er relateret til din konto, og tøv ikke med at inkludere test-nyttelast, der hjælper med at reproducere fejlen.   Gennemgå dine trin igen  Nogle gange skriver du trinene umiddelbart efter, at du støder på fejlen, men det kan vise sig, at du er gået glip af et trin for fuld forståelse, eller fejlen kan ikke reproduceres senere. I så fald skal der muligvis findes mere præcise trin.   Forventet resultat  Et separat afsnit er det forventede resultat, hvor vi (ikke overraskende) beskriver det resultat, der forventes, når trinene følges. Der er ikke mange specielle anbefalinger her, udover at denne sektion skal eksistere – udvikleren skal forstå, hvilken adfærd funktionaliteten skal føre til. Sætninger som "alt burde fungere fint" klipper det ikke – skriv den specifikke adfærd.   Faktisk resultat  Her skriver vi, hvad der rent faktisk skete, da vi fulgte trinene. Specificitet er også vigtig her. Skriv ikke bare “alt gik i stykker” (selvom det nok er det der skete). Beskriv de indikatorer, der viser, at alt gik i stykker. For eksempel:       En 500-fejl returneres på GET /accounts anmodningen, og brugergrænsefladen er blokeret. Brugeren kan ikke forlade siden eller klikke på elementer.   Opdatering af siden udløser anmodningen igen og fører til den samme fejl.  Med andre ord, beskriv den faktiske effekt, og hvordan den påvirker brugerens flow.   Yderligere filer  Dette er et særskilt afsnit, der er værd at nævne. Det er her, du vedhæfter yderligere oplysninger, der beskriver fejlen. Jeg kender nogle udviklere, der ikke er fans af at læse reproduktionstrin og går direkte til det faktiske resultat og yderligere materialer, der forklarer det.  Skærmbilleder af fejlen  Det er bedre at se det én gang end at høre om det hundrede gange. Dette er en fantastisk måde at visuelt vise, hvad der sker og hvor. Prøv altid at vedhæfte et skærmbillede.  Anmodning  Hvis der er en anmodning, hvor fejlen opstod, skal den altid være inkluderet i billetten. Forespørgsler indeholder dog mange forskellige parametre. Jeg fremhæver følgende som vigtigt at medtage:    – selve anmodningen, som du kan få fra netværkssektionen i browseren, hvor testen udføres. Fejl-URL    –   ,   ,   ,   osv. Der er mange metoder, ligesom der er anmodninger med samme URL men forskellige metoder. Glem ikke at angive det i billetten. Metode GET POST TRACE OPTION    - et andet vigtigt punkt. Du vil sandsynligvis ikke glemme det, men glem ikke at notere, hvilken kode der blev returneret fra serveren. Fejlkode    – dette er de data, vi sendte i vores anmodning til serveren. Dette er ikke til stede i enhver anmodning (f.eks. har HEAD eller GET det ikke), men det kan være årsagen til fejlen. Nyttelast    – serverens svar. Nogle gange indeholder den den fulde fejl, endda viser hvor den opstod, mens den andre gange blot er en standardpladsholder, der er sat op på backend for den type fejl. Sørg for at inkludere dette - det vil spare udvikleren for en masse tid. Response  Konsol logs  Nogle gange bliver der fundet fejl i konsollen, og disse kan tilføjes til billetten. Måske har du allerede gjort dette, men jeg vil lige bemærke, at en stor tekstblok altid kan gemmes som en   -fil og tilføjes til billetten. Dette forbedrer læsbarheden af både logfilerne og selve billetten. .log   Det her er godt og godt, men...  Det er alt sammen godt og vel, men hvor finder vi tiden til at få alt til at se så flot ud? Deadlines nærmer sig, lederen bliver sur, der er en blokering i produktionen, og jeg bliver bedt om at sidde og skrive det hele ud? Jeg sender bare en besked til udvikleren direkte, og det er det.  Dette er et logisk argument, der kan opstå. Jeg nærer ingen illusioner om den perfekte verden af en tester, hvor der er afsat rigelig tid til test, alt foregår i processen, og grundig og kvalitetsdokumentation vedligeholdes. Jeg forstår – ofte er det tidsnød, brændende... ja, øjne og et kapløb om at få alt gjort til tiden.  Små fejl har en tendens til at hobe sig op, tage mere tid på grund af kontekstskifte og føre til dårlig praksis. Hvis vi begynder gradvist at implementere forbedringer og overvåge, hvordan de fungerer, vil vi være i stand til at skabe en proces, der er mere stabil, standardiseret og forudsigelig for alle deltagere.  Projektlederen vil forstå, hvad der sker med produktet uden at skulle trække alle til opdateringer, udvikleren behøver ikke at bede testeren om afklaring af reproduktionsforhold og vil ikke trække dem væk fra test, og interessenter vil til gengæld, have et klart overblik over produktets fremskridt.  Denne artikel er mere rettet mod begyndere, der begynder eller allerede er begyndt deres vej i test. Jeg tror på, at små skridt fører til store resultater, og anbefalingerne i denne artikel vil føre til fejlrapporter af højere kvalitet.   Hvis du har spørgsmål, forslag, uenigheder eller klager, er du velkommen til at efterlade dem i kommentarerne - jeg er interesseret i at høre din mening!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

Sådan skriver du gode fejlrapporter: anbefalinger

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Sentry: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet Timescale: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Sentry: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet Timescale: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps