Gevinster:
- Evne til å transformere spredte observasjoner til en rapport som inneholder en klar tittel, deterministiske reproduksjonstrinn, forventede/faktiske resultater og bevis med støtte fra kunstig intelligens
- Å være i stand til å påtvinge regelen om "kun bruk informasjonen jeg gir, ikke gjøre opp" til kunstig intelligens og garantere reproduserbarhet med egen kontroll
- Å kunne skille mellom alvorlighetsgrad (teknisk påvirkning) og prioritet (forretningsmessig haster) og gi den endelige merkelappen med forretningskonteksten
Feilen en tester finner er bare verdifull hvis den er fikset; Å fikse det avhenger i stor grad av kvaliteten på feilrapporten – en post som dokumenterer en defekt på en måte som utvikleren kan forstå, reprodusere og fikse den. En dårlig skrevet feilrapport ("pålogging fungerer ikke") vil stoppe utvikleren i timevis, føre til frem-og-tilbake-korrespondanse, og ofte lukke som "kan ikke reprodusere". En god rapport inkluderer klare trinn, forventede og faktiske resultater, kontekstinformasjon og bevis. Kunstig intelligens (AI) er veldig flink til å gjøre dine spredte observasjoner om til en profesjonell, strukturert rapport. Men det sentrale forbeholdet gjelder også her: AI kan ikke gjøre opp trinn du ikke ser; kan fylle ut den manglende informasjonen med "rimelig utseende", men unøyaktige gjetninger. Din jobb er å sørge for at hver linje i rapporten er basert på det du faktisk observerte.
Anatomien til en god feilrapport
En effektiv rapport inkluderer disse komponentene:
- Tittel: Kort, spesifikk, søkbar. Ikke "Det er en feil"; "Kan ikke klikke på "Kasse"-knappen med mer enn 10 varer i handlekurven (Chrome)".
- Trinn for å reprodusere: Nummerert, sporbar fra bunnen av, deterministisk. Utvikleren skal kunne se feilen etter å ha fulgt disse trinnene.
- Forventet resultat: Hva skulle ha skjedd i henhold til akseptkriteriene.
- Faktisk resultat: Hva skjedde (feilmelding, skjerm, atferd).
- Miljø: Nettleser/enhet, versjon, miljø (test/live), brukerrolle, data.
- Bevis: Skjermbilde, video, logg, feilsporing (stakksporing).
- Alvorlighetsgrad og prioritet: Detaljert nedenfor.
Tips: Før du sender en rapport, spør "hvis jeg gir disse trinnene til noen andre, kan de se feilen uten min hjelp?" spørre. Hvis svaret er "nei", er rapporten ufullstendig. AI kan gjøre rapporten vakker, men bare du kan garantere reproduserbarhet.
Vold og prioritering: to forvirrede begreper
Alvorlighetsgrad er den tekniske effekten av feilen: krasjer systemet, data går tapt, eller er det en skrivefeil? Prioritet er hvor raskt det må fikses; handler om forretningseffekt. De to går ikke alltid i samme retning: feilstaving av firmanavnet på hjemmesiden er lav alvorlighetsgrad, men høy prioritet (omdømme). I et sjeldent kanttilfelle kan en kollaps være av høy alvorlighetsgrad, men lav prioritet. AI hjelper deg med å gjøre denne forskjellen når du gir observasjonen; men den endelige merkelappen gis av deg som kjenner forretningskonteksten.
vold
eksempel
prioritet
eksempel
Kritisk (blokkering)
Betaling kan ikke gjennomføres
Haster (P1)
Tap av inntekt i live
Høy (major)
Rapport gir feil totalsum
Høy (P2)
Et must for kommende utgivelse
Middels (Minor)
Sjelden kantsaksfeil
Middels (P3)
I en planlagt sprint
Lav (trivielt)
Knappjustering er av
Lav (P4)
Når det er en sjanse
Svak forespørsel / Sterk forespørsel
Svak: "Rapporter denne feilen: betalingen fungerer ikke."
Sterkt: "Oversett mine observasjoner nedenfor til standard feilrapportformat: tittel, reproduksjonstrinn (nummerert), forventet resultat, faktisk resultat, miljø, alvorlighetsgrad og prioritetsanbefaling (begrunnet). Bruk bare informasjonen jeg oppgir; fyll opp eventuelle manglende felter, merk "INFORMASJON MANGLER: ...". Observasjoner: Chrome 120, testmiljø, 12 varer i handlekurven skjer ikke når jeg trykker på, en funksjon ikke er definert. konsollen, det er ikke noe problem med 11 produkter."
Kraftig ledetekst; pålegger formatet, regelen "tilpasning" og merking av manglende informasjon. På denne måten vil rapporten være både nøyaktig og ærlig.
Duplikatfeilregistrering
I store team rapporteres den samme feilen om og om igjen. AI kan sammenligne den nye rapporten din med eksisterende åpne feil og flagge potensielle duplikater – dette holder feilsporingssystemet (Jira, Azure DevOps, GitHub-problemer) rent. Men pass på: to feil som ser like ut på overflaten kan ha forskjellige grunnårsaker; Sammenlign de gjentatte produksjonstrinnene og miljøet til begge rapportene før du lukker AIs "dupliserte" forslag. Et utilsiktet lukket "duplikat" mangler faktisk en egen feil.
Fra feilsporing til rotårsak: Kraften til AI til å lese logger
Den mest tekniske delen av en feilrapport er ofte feilsporingen (stakksporing – en sammenbrudd av hvilken kodelinje, med hvilken anropskjede som utløste en feil). Lange og komplekse logger kan slite selv utvikleren. AI leser en logg med hundrevis av linjer og oppsummerer på sekunder de mest kritiske linjene, hypotesen om mulig rotårsak og kodepunktet der feilen ble utløst. Dette både forkorter rapporten og gir utbygger et direkte utgangspunkt.
Husk imidlertid to grenser. For det første er grunnårsaken gitt av AI en hypotese, ikke bevis; Utvikleren bør ikke prøve å fikse dette uten å bekrefte det. For det andre inneholder logger ofte personlige data (e-post, bruker-ID, sesjonstoken); Masker disse områdene før du legger stokken på kjøretøyet. En god praksis er å først få AI til å si "liste opp feltene som må maskeres i denne loggen" og deretter analysere den rensede loggen.
Tips: I stedet for å lime inn hele loggen i rapporten, inkluderer du de mest kritiske 3-5 linjene som AI oppsummerer og en lenke til hele loggen. På denne måten forblir rapporten lesbar, og utvikleren som trenger detaljer kan få tilgang til hele loggen.
Fire kopierbare maler
1) Fra observasjon til rapport:
Din rolle: senior QA. Oversett følgende råobservasjoner til en standard feilrapport: Tittel / Reproduksjonstrinn (nummerert) / Forventet / Faktisk / Miljø / Bevisnotat / Alvorlighet + Prioritet (begrunnet). REGEL: bruk kun informasjonen jeg gir; merk det manglende feltet som "MANGLER INFORMASJON:..." Observasjoner: [rånotater]
2) Reproduserbarhetskontroll:
Les denne feilrapporten fra perspektivet til en utvikler som aldri har sett feilen. Følg trinnene og merk stedene der den ikke vil produsere feilen: tvetydig trinn, manglende forutsetning, manglende testdata, hoppet over tilstand. Fortell meg hvilken informasjon jeg bør legge til for hvert gap. Rapport: [lim inn rapport]
3) Alvorlighets-/prioritetsrådgiver:
Jeg beskriver følgende feil: [feil + forretningskontekst]. Gi forslag og begrunnelse separat for alvorlighetsgrad (teknisk påvirkning) og prioritet (forretningsmessig haster). Forklar hvorfor de to kan være forskjellige. Jeg tar den endelige avgjørelsen.
4) Logg-/feilsporingssammendrag:
Undersøk feilsporingen/loggen nedenfor. Gi meg en oppsummering av (1) grunnårsakshypotesen, (2) det sannsynlige kodepunktet der feilen oppsto, (3) de 3 mest kritiske linjene som skal legges til i rapporten. Mask hvis det er personlige data. Logg: [lim inn logg]
tre minisaker
Sak 1 - Frigjøring fra "Jeg kunne ikke produsere." I ett team ble 30 % av feilene lukket som "kan ikke reprodusere". Malen "reproduserbarhetssjekk" er lagt til rapportprosessen; Før hver rapport ble sendt, flagget AI manglende trinn og forutsetninger. Tre måneder senere falt andelen "kunne ikke produsere" fra 30 % til 8 %. Forskjellen var at trinnene var nøyaktige fra begynnelsen.
Tilfelle 2 — Faren for falske trinn. En tester fikk AI til å skrive en rapport med ufullstendige observasjoner; AI la til et trinn som aldri skjedde, for eksempel "brukeren slår på varsler fra innstillingssiden". Da utvikleren fulgte det trinnet, kunne han ikke finne feilen og tapte tid. Teamet håndhevet en "bruk bare informasjonen jeg gir, ikke gjør det opp"-regel; Sammensatte trinn er eliminert.
Tilfelle 3 — Alvorlighets-/prioritetsskille. Det var en skrivefeil i firmaets slagord på hjemmesiden. Testeren ville gi dette av som "lav"; AI-konsulenten minnet om at teknisk vold er lav, men forretningsprioritet er høy (omdømmeelementet som hver besøkende mottar). Feilen ble rettet samme dag med "høy prioritet"-taggen.
Vanlige feil
- Uklar tittel. Usøkbare, ikke-diskriminerende overskrifter som «fungerer ikke».
- Manglende/hoppet over trinn. Ikke å skrive det som er åpenbart i din sammenheng; utviklerens manglende produksjon.
- La AI gjøre det opp. Å ha den manglende informasjonen fylt ut med et "rimelig estimat"; feil trinn.
- Skriver ikke forventet resultat. Sier "feil", men spesifiserer ikke hva som er riktig.
- Forvirrende vold og prioritering. Å ta feil av de to som én etikett; Feilvurdering av virksomhetens innvirkning.
- Sensitive data i bevis. Dele ekte personlige data i skjermbilder/logger uten å maskere dem.
Oppsummert
Verdien av feilrapporten er at utvikleren kan reprodusere og fikse feilen uten din hjelp. AI er veldig flink til å gjøre spredte observasjoner om til en profesjonell, strukturert rapport; Den organiserer tittel, trinn, forventet/faktisk resultat, miljø og bevis, og gir rådgivning om skillet mellom alvorlighetsgrad og prioritet. Men AI kan gjøre opp for manglende informasjon; Håndhev "bare bruk informasjonen jeg gir, merk den manglende"-regelen og garantere reproduserbarhet selv. Maske personlige data som bevis.
Søknadsoppgave
Ta en feil du nylig har funnet, og gjør de rå observasjonene dine om til en rapport ved å bruke "observasjon for å rapportere"-mønsteret (med "tilpasning"-regelen). Utfør deretter "reproduserbarhetskontrollen" og fyll ut de markerte hullene. Gi rapporten til en kollega og se om han kan produsere feilen uten din hjelp. Bestem til slutt merkelappene med "volds-/prioriteringskonsulenten" og fullfør det etter eget skjønn. Legg merke til all informasjon AI prøver å gjøre opp i prosessen.
sjekkliste
- [ ] Tittelen min er spesifikk og søkbar.
- [ ] Reproduksjonstrinn er fra bunnen av, deterministisk og fullstendig.
- [ ] Jeg skrev de forventede og faktiske resultatene separat.
- [ ] Innstillingen og bevisinformasjonen er fullstendig; Jeg maskerte personlige data.
- [ ] Jeg innførte regelen "gjør det opp, merk det som mangler" på AI og fylte ut hullene selv.
- [ ] Jeg evaluerte alvorlighetsgraden og prioriteringen separat og tok den endelige avgjørelsen.