Webbtest i praktiken

Det diskuteras mycket kring teorierna kring testning, hur man passar in testningen i olika utvecklingsprocesser, vad ska vi mäta och inte mäta, vem gör vad och varför ska vi göra det ena eller andra. De flesta har tankar kring frågorna och äger kunskap om vilket angreppssätt som passar i just deras fall, vilka risker som bör hanteras i första hand och så vidare. Vad jag saknar att läsa om är mer handfasta erfarenheter och tips på testfallsdesign och praktiska tester; hur testar jag och hur hittar man bäst buggar i olika typer av applikationer?

Jag vill bidra med att försöka ge exempel på hur jag går till väga när jag testar webbapplikationer, eller på ren svenska; websiter.

Att testa webb är en större utmaning än vad många tror vid en första anblick. Webbsidor blir mer och mer avancerade och det var länge sedan, ur webb-perspektiv mätt, som webbsidor bara var ett sätt att visa upp kundsupportens telefon- och faxnummer. Webbteknik används allt oftare för avancerade tjänster och som “frontend” till komplicerade organisationssystem. Med den äran, anser jag. Men det innebär också att webb-baserade system blir mer och mer affärskritiska och därmed har mindre tolerans för fel och brister vilket tar oss in på test som ett led i aktiviteter för att kontrollera kvaliteten.

Testaktiviteterna i webbprojekt skiljer sig inte från andra typer av projekt, de bör planeras, förberedas, utföras och rapporteras. Hur de stegen utförs kan man, och bör man, ha långa (eller korta, intensiva) diskussioner om. Vad jag vill beröra är hur jag angriper testerna om jag får en webbsida framför mig.

För att effektivt konstruera tester för webbsidan är det vettigt, som oftast när större problem ska hanteras, att bryta ner det i mindre delar. Webbsidor kan betraktas som en sammansättning av i huvudsak tre delar. Jag benämner dem; infrastruktur, backend och frontend.

Infrastruktur berör de delar av systemet som ligger på databasnivå. Det innebär integrationer med andra system och tjänster.

Backend avser det man kan se i HTML, alltså den data som systemet levererar efter att all logik gåtts igenom.

Frontend handlar om presentation av informationen och utgörs i första hand av CSS-kod och JavaSkript-kod.

Varje funktion på webbsidan består av dessa tre delar, i olika stora portioner. Vissa funktioner är väldigt användarfokuserade och tunga på frontend, andra är mer datafokuserade och tunga på backend eller infrastrukturen. Det innebär också att varje funktion testmässigt kan angripas från dessa tre vinklar.

Tester av infrastruktur innebär en relativt hög teknisk nivå. Här kan det handla om att testa gränssnitt mellan databaser, webservices eller andra relaterade system. På denna nivå går det lätt att använda automatiska tester som kontrollerar datakvalité eller connectivitet. På siter med ett mer lättviktigt databeroende inkluderar jag i infrastrukturtester levererandet av redaktionellet styrt datainnehåll, vare sig det kommer från ett CMS eller från en textfil.

All HTML som levereras till webbläsaren har genomgått någon form av logik, t.ex. kanske det visas olika innehåll i en sida beroende på om man är inloggad eller inte. I backend-testerna testas denna logik. Testerna handlar alltså om att titta på det datainnhåll som kommer från webbservern utan att bry sig om varken stylesheet, CSS, eller javaskript. Enklast gör man det genom att helt enkelt inaktivera de två i webbläsaren som då bara visar den rena HTML:en. Teststegen bör täcka “alla” användarflöden som att fylla i data i formulär och skicka in, spara och ladda användaruppgifter och data, navigera mellan sidor, och liknande.

När man gått igenom logiken i den HTML-genererande koden kan man börja titta på presentationen av innehållet i frontend-testerna. Fontend kan delas in i två delar, “style sheet” och “java script” och det är en balansgång mellan de två eftersom viss uppbyggnad av sidans presentation kan vara beroende av javaskript. Man måste alltså som testare ha viss kunskap om hur de två beror av varandra i varje testobjekt. Enklast är det att genomföra testerna med både javascript och stylesheet och dela in dem i presentationstester och interaktionstester.

Presentationstester är relativt rätt-fram att genomföra. Olika sidor fylls med innehåll och element aktiveras och aktiveras utan att sidans tänkta form påverkas negativt. Viktigt är också att genomföra negativa tester som att fylla element med tomma strängar eller att fylla behållare med en väldig massa element. Fel i presentationen måste alltid också vägas mot vad användarna, redaktörerna, kan tänkas göra. Det kanske inte är försvarbart att anpassa sidan att klara av länkar som är 500 tecken långa eller rubriker som är 100 tecken långa utan att formen störs. Men oavsett om man tänker sig hantera fallen är det bra att känna till begränsningarna.

Interaktionstesterna, som är den andra delen av frontendtesterna, handlar mer om att testa användarupplevelsen och Javaskript-koden. Javaskript har den egenheten att det kan påverka både HTML-innehållet på en sida och presentationen. Dessutom hanteras kakor och sessionsobjekt i javaskriptkoden, det är heller inte ovanligt att mycket valideringar av användarinput finns i denna; korrekt e-post-format osv. Det är alltså ett av de mer komplicerade testdelarna där genomförda testfall från backend-testerna kan återanvändas, det är också en mest felbenägna delen.

Vanligt i dessa tester är att man stöter på fel som beror av krockande skript eller att inte alla fall av sidans status sparas och hanteras korrekt. Javaskript kan påverka sidans innehåll utan att det sparas i webbläsarens inbyggda minne, cachen. Det innebär att fram- och tillbaka- navigering är särskilt svår att hantera.

Det finns alltså mer att testa i webbsidor än man först tänker sig, men med en vettig indelning av funktionalitet och med några grundläggande punkter på sin checklista kan man komma långt.