En användbar felrapport beskriver vägen fram till felet, inte en gissning om orsaken. Du ska kunna följa samma steg och se samma resultat. Kan du inte det vet varken du eller modellen vad en ändring ska rätta.
”Det fungerar inte” saknar fem saker
Den som använder appen ser ett enda problem: hon försökte göra något och misslyckades. Du behöver skilja händelsen från allt annat som råkade finnas på skärmen. Det gör du med fem uppgifter:
Orden ingenting hände är också ett faktiskt resultat. Be inte användaren tolka det. ”Knappen blev grå men sidan stod kvar” är bättre än ”skickandet gick sönder”, eftersom den första formuleringen går att jämföra med det du ser själv.
Jag vill försöka upprepa felet. Svara gärna på de här fem punkterna: 1. Vilken sida var du på, och var du inloggad? 2. Vad gjorde du precis före felet? Skriv klicken i ordning. 3. Vad väntade du dig skulle hända? 4. Vad hände i stället? Kopiera gärna hela felmeddelandet. 5. Använde du telefon eller dator, vilken webbläsare, och ungefär när hände det? Skicka inte lösenord, kortuppgifter, inloggningslänkar eller riktiga personuppgifter. Om ett exempel behövs, använd påhittade uppgifter.
Provet: kan en annan person följa rapporten?
Ge rapporten till någon som inte såg felet. Hon ska kunna börja på rätt sida och göra samma steg utan att fråga vad ”sedan” eller ”den där knappen” betyder. Behöver hon gissa är rapporten inte klar.
Samla inte in sådant du inte ska ha
En skärmbild kan hjälpa, men den kan också visa namn, mejladresser, medlemsnummer, privata meddelanden eller en återställningslänk som fungerar som en nyckel. Ett inspelat skärmflöde kan fånga ännu mer. Be därför först om stegen och felmeddelandet i text.
- lösenord, engångskoder eller länkar för inloggning och återställning;
- kortnummer, säkerhetskod eller bild på en betalningssida med riktiga uppgifter;
- en export av riktiga användare när ett påhittat exempel räcker;
- en skärmbild innan avsändaren har dolt personuppgifter och hemliga nycklar.
Om felet bara uppstår för ett visst konto behöver du inte börja med att låna kontot. Be användaren prova med påhittad information, eller skapa ett eget testkonto med samma roll. Provet är enkelt: underlaget ska fortfarande gå att använda om det vidarebefordras till den som hjälper dig med appen.
Återskapa felet innan något ändras
Öppna samma sida och följ stegen bokstavligt. Använd om möjligt samma sorts enhet och webbläsare. Lägg inte till rimliga mellansteg som användaren inte skrev. Om rapporten säger att hon tryckte två gånger, tryck två gånger.
Om felet går att upprepa har du ett före-prov: samma steg ska misslyckas före ändringen och lyckas efter den. Om felet inte går att upprepa är det också ett resultat. Skriv vad du provade och be om den enda uppgift som saknas; beställ inte en allmän fix ”för säkerhets skull”.
Gör samma steg två gånger. Om felet uppstår båda gångerna kan du gå vidare. Om det kommer och går behöver rapporten säga det, och modellen ska först hjälpa dig att samla mer bevis — inte låtsas att orsaken redan är känd.
Be om en förklaring före fixen
Ge modellen rapporten och skilj diagnosen från ändringen. Annars är det lätt att få en trovärdig gissning och en stor omskrivning i samma svar. Beställningen ska uttryckligen säga att inget får ändras ännu.
Här är en felrapport från en användare: [KLISTRA IN RAPPORTEN] Ändra ingenting ännu. Förklara först: 1. om rapporten räcker för att återskapa felet; 2. vilka högst tre orsaker som stämmer med just de beskrivna stegen; 3. vilket prov som skiljer orsakerna åt; 4. vilken ytterligare uppgift du behöver om underlaget inte räcker. Utgå inte från en teknisk orsak som rapporten inte ger stöd för.
Ett bra svar ger dig ett litet prov som kan fälla en gissning: fungerar samma sak i en annan webbläsare, händer felet bara när fältet är tomt, eller uppstår det efter det andra klicket? Ett dåligt svar säger bara att felet ”troligen” sitter i en viss del och börjar skriva om appen.
Jag har gjort provet. Resultatet blev: [SKRIV RESULTATET] Föreslå nu den minsta ändring som rättar den bekräftade orsaken. Beskriv före ändringen vilka delar som påverkas och vilka som ska lämnas orörda. Gör inga andra förbättringar. Ge mig sedan exakta steg för att prova både felet och de närmast berörda funktionerna.
Provet: kan du säga varför just den ändringen behövs?
Du behöver inte förstå koden. Men du ska kunna avsluta meningen: ”Vi ändrar detta därför att provet visade …” Kan du bara säga ”modellen trodde det” saknas fortfarande ett led.
Omprovet har två halvor
Börja med exakt samma steg som fick felet att uppstå. Byt inte testkonto, webbläsare och exempel samtidigt, för då vet du inte vilken skillnad som spelade roll. När felet är borta provar du den vanliga vägen bredvid: går det fortfarande att skicka formuläret en gång, logga in eller öppna listan?
Har du en återkommande provlista, kör den efter omprovet. Felrapporten visar att ett särskilt fel är borta; provlistan visar att gamla funktioner fortfarande lever.
När metoden inte räcker
En bra rapport gör felet synligt. Den gör inte varje fel säkert att rätta på egen hand. Stoppa och ta hjälp om problemet rör obehörig åtkomst, försvunna eller sammanblandade användaruppgifter, betalningar som dragits fel, läckta nycklar eller ett fel som skadar data när du försöker upprepa det.
Radera inte bevis, dela inte känsliga uppgifter i en vanlig chatt och fortsätt inte prova mot riktiga användares data. Skriv ned tidpunkt, steg och vad som påverkats. Vid ett misstänkt säkerhetsfel går säkerhetsguidens gränser före den vanliga felsökningsrutinen.
För vanliga fel fortsätter du i guiden om att backa och felsöka. Ska någon annan ta över själva åtgärden hjälper överlämningschecklistan dig att ge vidare rätt underlag utan att ge bort fel konton eller hemligheter.