En ändring kan röra mer än det du bad om. Sortering, sökning och export kan använda samma uppgifter eller samma delar av appen, även när de ser fristående ut på skärmen. Utan att kunna läsa koden har du ett tydligt skydd mot följdfel: en kort lista över saker som ska fungera, och vanan att gå igenom den varje gång.
Varför någon annan hittar felet före dig
Du provar det du precis beställde. Det är rimligt — det är ju där något kan ha blivit fel. Problemet är att det är den enda delen av appen du provar, samtidigt som det är den del som just blivit granskad noggrannast.
Du kan inte räkna med att appen säger till när något slutar fungera. Knappen kan sitta kvar, sidan se likadan ut och ingenting blinka rött. Och ju äldre en funktion är, desto mer sällan använder du den själv: startsidan öppnar du varje gång, exportknappen tryckte du senast på för en månad sedan. Det är därför felet ofta upptäcks av någon annan, och långt senare.
Fördröjningen är den dyra delen. Rådet att fråga vad ändrades sedan i går fungerar bara om du märker felet i dag. Har det gått tjugo ändringar finns inget kort svar kvar, och du står med ett sökproblem i stället för ett fel.
- Det du aldrig tittar på. Exporten, utskicket, listan när den är tom, sidan som bara du som ansvarig ser.
- Det som ligger nära det du ändrade. Rörde ändringen sorteringen kan sökrutan eller filtret ha följt med, eftersom de arbetar på samma lista.
- Det som fungerade tack vare något annat. En ändring i hur uppgifterna sparas slår igenom överallt där de läses — och det kan vara fem ställen du inte tänkte på.
Provlistan är en handfull rader, inte ett testprotokoll
En provlista är inte teknisk och den kräver ingenting av dig som du inte redan kan. Varje rad är en sak en verklig användare gör, plus det du ska se när den fungerar. Kan du inte skriva vad du ska se, är raden inte färdigskriven.
Så här kan listan se ut för en anmälningslista till en förening. Sju rader, under fem minuter att gå igenom:
Notera vad som inte står där: ingenting om kod, filer eller databaser. Listan beskriver appen utifrån, vilket är den enda vy du har — och den enda som betyder något för den som ska använda appen.
Var listan ska ligga
- I samma dokument som din projektbeskrivning, eller i en egen anteckning bredvid den.
- Inte i chatten med modellen. Där försvinner den när samtalet tar slut, och den kan skrivas om av den som ska granskas.
- På ett ställe du kommer åt från telefonen, eftersom flera rader bara går att prova där.
Så skriver du listan för appen du redan har
Det tar tjugo minuter en gång, och du gör det på appen som den ser ut i dag. Behöver du bygga något för att kunna prova en rad har du hittat ett fel innan du ens börjat.
Provet är godkänt när du kan lämna listan till någon som aldrig sett appen och den personen kan gå igenom alla rader utan att fråga dig en enda gång. Fastnar de på en rad är det raden som är otydlig, inte personen.
När listan ska köras
Inte efter varje meddelande. Det skulle göra arbetet outhärdligt och är inte heller nödvändigt. Tre tillfällen räcker:
- Innan du sparar en version med ett namn. Det är den viktigaste körningen, och skälet står nedan.
- Efter en ändring som rörde något som redan fanns. Ett helt nytt och fristående tillägg behöver bara sitt eget prov. En ändring i något befintligt behöver hela listan.
- Före varje publicering. Här kostar ett fel mest, eftersom det är först nu andra ser det.
En sparad punkt är det du backar till när något gått fel. Är den punkten i sig trasig backar du i tron att du landat på fast mark, upptäcker att felet finns kvar och drar slutsatsen att det måste sitta någon annanstans. En trasig sparad punkt är sämre än ingen punkt alls.
Går en rad inte igenom: rätta den innan du går vidare med nästa beställning. En provlista som du kör men inte agerar på är bara en längre väg till samma överraskning.
Beställningen som håller modellen borta från det som fungerar
Listan fångar skadan i efterhand. Beställningen kan minska hur ofta den uppstår, och det gör den på ett sätt: genom att be om planen och om en uppräkning av vad som berörs, innan något ändras.
Jag vill ändra [beskriv den enda sak du vill ha ändrad]. Ändra ingenting annat.
Innan du ändrar något: beskriv planen kort, och räkna upp vilka andra delar av appen som kan påverkas av ändringen — även sådant jag inte har nämnt. Behöver något utanför det jag bett om ändras för att det ska fungera, säg det och vänta på mitt svar i stället för att göra det. Avsluta med vilka prov jag ska göra efteråt.
Uppräkningen du får tillbaka har ett direkt användningsområde: de delarna blir extra rader i dagens körning. Modellen kan ha fel om vad som påverkas, men den har oftare rätt om var den varit inne och skrivit än om huruvida resultatet blev bra.
Det är en förutsägelse, och den kommer från samma modell som gjorde ändringen. Vissa byggverktyg kan numera använda en webbläsare för att klicka, fylla i formulär och läsa fel — Lovables webbläsartestning är ett exempel. Men verktyget provar inte automatiskt varje gammal funktion eller varje miljö. Be det köra den exakta listan, och kör de viktigaste raderna själv före en sparad version och före publicering.
Kör provlistan nedan i appens förhandsvisning med webbläsartestning, om verktyget har den möjligheten. Utför varje rad som en användare skulle göra och rapportera handling, förväntat resultat och faktiskt resultat rad för rad. Hoppa inte över en rad utan att säga det. Rätta ingenting ännu — avsluta först med en lista över godkända, underkända och ej körbara rader.
[Klistra in provlistan här.]
Och när en rad faller: säg vilken rad, ordagrant. Ett fel som beskrivs som "exporten är trasig" ger en gissning tillbaka. Ett fel som beskrivs med handling, förväntat resultat och faktiskt resultat ger en förklaring.
[Funktionen] fungerade före den senaste ändringen och gör det inte nu. Så här provar jag: [skriv raden ur provlistan ordagrant]. Det ska hända: [det du ska se]. Det som händer i stället: [skriv exakt vad du ser, inklusive eventuell text på skärmen].
Ändringen jag bad om precis innan var [beskriv den]. Förklara först vad i den ändringen som kan ha orsakat det här, innan du rättar något. Rätta sedan bara det felet, utan att bygga om resten.
Vad listan inte fångar
En provlista visar att appen fortfarande gör det den gjorde i går. Det är mycket, och det är allt. Fyra saker ligger utanför:
- Många användare samtidigt. Att appen fungerar när du ensam klickar i den säger ingenting om vad som händer när fyrtio personer anmäler sig under samma kvart.
- Säkerhet. Hålen syns inte när man använder appen som det var tänkt — de handlar om vad någon kan göra som inte gör som det var tänkt. Det är en annan sorts kontroll, och den står i guiden om säkerhet.
- Andras utrustning. Du provar i din webbläsare, på din telefon, med dina inställningar. Låt någon annan gå igenom listan på sin egen utrustning då och då.
- Tjänster du inte äger. Ett betalfönster eller ett utskick kan sluta fungera utan att du ändrat något. Provlistan upptäcker det, men beställningen som rättar det räcker inte hela vägen — se guiden om att publicera och hålla appen vid liv.
Listan säger inte heller att appen är bra. Den säger att den är oförändrad. Om proven varit fel formulerade från början fortsätter de vara godkända ända tills någon använder appen på riktigt.
Skriv ned vad som ska fungera. Gå igenom listan innan du sparar en punkt. Rätta det som fallit innan du beställer nästa sak.
En sak i taget handlar om provet för den ändring du just gjort — provlistan är samma idé sträckt över tid. Faller flera rader samtidigt och du börjar stapla fixar, gå till guiden om när appen går sönder. Och kursens del om användbarhet innehåller det prov som ingen lista ersätter: att lämna över telefonen till någon annan och inte säga något.