Förbättrande test!

En tanke som slog mig när jag testade under skapandet av en mashup website, härom kvällen, var hur kul testerna var. Jag funderade på varför och slogs direkt av att det var förbättrande test jag utförde och att jag som kravteknik nästan uteslutande använde mig av prototyping! De tester jag utförde syftade inte till att hitta fel utan att hitta den optimala användarupplevelsen för alla parter. En masup är alltså en website som ropar på en eller flera publika tjänster via API eller widgets. Väder prognosen, klockan samt kartan nedan är ett exempel på en sådan widget som jag ropar på ifrån www.vackervader.se, www.widgetbox.com respektive www.maps.google.com. Eller som Wikipeida uttrycker det “Mashup är en typ av webbapplikation som sammanställer information och funktionalitet från fler av varandra oberoende källor.” .

Det som är unikt när man kombinerar redan välanvända och beprövade online tjänster är alltså att testningen går ifrån att primärt hitta felaktigheter till att helt koncentrera sig på kund och leverantörsnyttan med olika lösningar. Levererar dessa komponenter önskad nytta och är arbetsflödet optimalt för alla intressenter?

Man kan på kort tid skapa ett antal versioner av sidan med samma funktionalitet men med olika layouter och arbetsflöden. Utifrån dessa olika versioner kan man sedan lätt utvärdera och validera den lösning som tillför mest kundnytta för tillfället. Det som blir extra tydlig är hur kraftfullt prototyping verkligen är, istället för att kunden funderar på vad som skulle fungera bäst, så prövar kunden helt enkelt de olika varianterna och kan fatta snabba och underbyggda beslut. Jag har tidigare varit förespråkare för prototyper men är nu ett stort fan av tekniken och kan inte tänka mig en bättre kravteknik för visuella applikationer.

En sak som verkligen är stimulerande med denna typ av tester är att allt syftar till förbättringar istället för verifieringar. Detta fokus borde ju vara självskrivet i alla projekt, men det blir lätt att testgrupperingen fokuserar på att verifiera kraven och hitta direkta felaktigheter. Ofta valideras affärs- och kundnyttan först i acceptanstestfasen i dessa felfokuserade projekt. Det borde ju rimligtvis vara tvärs om, det är ju nyttan som är syftet med hela projektet. Jag skulle vilja jämföra detta arbetsätt med det man har när man testar fram de optimala inställningarna på en racerbil. Man har ett tydligt mål, att bli så snabb som möjligt och det målet skall nås inom en tydlig deadline, racet. För att nå det målet innan deadlinen så testar man på ett så effektivt sätt som möjligt fram förbättringar. Man testar alltså inte om det är rätt inställningar, för det vet man inte, utan man testar om det finns några förbättringar att uppnå. I några lyckade agila projekt har jag varit med om liknade fokusering på förbättring i testerna och förundras varje gång över vilken effektivitet och glädje hela grupperingen känner. Det är precis samma effektivitet och glädje som man känner i depån under en racehelg.

Sedan får man självklart inte glömma att det när man använder sig av online tjänster behöver utföras en hel del tester av verifierande slag, så som säkerhet, prestanda, tillgänglighet, browser kompatibilitet m.m. Mycket av dessa tester blir dock ofta statiska och kan flyttas redan till kravarbetet runt din mashup eller till upphandlings och utvärderings arbetet av de ingående tjänsterna.