Situationen gör testaren!

2010-09-14 Artikelbanken Test Läst 9242 gånger

Som testare kan man ställas inför mycket varierande utmaningar. Även om man lärt sig ett arbetssätt som fungerar bra i en miljö kan man känna sig bortkommen och ineffektiv när man hamnar i en annan. Lyckligtvis finns det numera en bra allmän kunskapsgrund att stå på, till exempel teststandarden enligt ISTQB. För att bli framgångsrik klarar man sig inte alltid med sådan generell kunskap utan man måste specialanpassa sitt arbetssätt efter den situation man befinner sig i. Den här artikeln presenterar sju olika faktorer som påverkar testarens verklighet och ger även tips om hur man hanterar de speciella utmaningar som var och en av de olika faktorerna för med sig.

1. Fokus på tid eller kvalitet

Den kanske viktigaste faktorn som påverkar testningen är vilka kvalitetskrav som finns. Här finns ett brett spektrum, från de livskritiska systemen där ett fel kan leda till förlust av människoliv, till möjliggörande system där användarna kan stå ut med en del problem bara de får något i utbyte, till exempel nya affärsmöjligheter eller spännande funktioner.

För livskritiska system krävs hård processtyrning. Det är här vi har den mest utbredda användningen av formella metoder och matematiska bevis för korrekthet. Centrala funktioner i livskritiska system kan ha dubblerad eller tripplerad kod, där samma funktioner implementerats på olika sätt utgående från samma specifikationer. Om det finns ett programmeringsfel kommer de olika programmen ge olika resultat och systemet går in i ett felsäkert tillstånd. Funktionerna är ofta utvecklade av olika utvecklingsteam men testas av samma testteam. I den livskritiska miljön har testaren ett viktigt arbete, stort inflytande och bra stöd i processen.

I den andra ytterligheten är det tid till marknaden som räknas. Det är svårt att sätta och upprätthålla kvalitetsmål. Kanske skall man här testa för att maximera nyttan av produkten och inte för att minimera antalet fel. Det är svårt att få den tid och de resurser man skulle önska för test. Alltför ofta blir man som testare överkörd och ens arbete nedprioriterat. Trots detta är det viktigt att fortsätta göra sitt jobb och vara beredd på att kvalitetskraven snabbt kan höjas. Ett sätt att få mer tid för test i denna miljö är att försöka mäta kostnaden för kvalitetsbristerna.

2. Användargränssnitt eller tekniska system

Testning av system med mycket användargränssnitt och testning av tekniska system är nästan skilda yrken. För testning av tekniska system krävs vanligen programmerings-bakgrund, medan de system som vänder sig mot människan med fördel testas av personer i den tilltänkta användargruppen.

Användargränssnitt är ofta löst beskrivna medan tekniska system däremot är hårt specificerade. Specifikationerna i form av sekvensdiagram, tillståndsmaskiner eller liknande är värdefulla eftersom de lätt kan användas för att ta fram testfall, kanske till och med generera dem automatiskt.

När man testar ett system där komplexiteten ligger i användargränssnittet kan man istället ta fram testfall från arbetsflöden och användningsfall. För sådana system är det ofta lätt att sätta upp testmiljön. Det är kanske bara att installera programvaran, starta den och börja testandet. För tekniska system är det vanligtvis mycket arbete att sätta upp miljöer för testerna, utveckla simulatorer, teststubbar och liknande.

3. Det är skillnad på stora och små projekt

En annan faktor som påverkar testaren är storleken på det projekt man ingår i. I ett litet projekt behöver man i regel inte arbeta så mycket med processfrågor eller dokumentation eftersom man kan kommunicera direkt med alla andra i projektet. Man kan sitta nära, intervjua, experimentera, försöka hitta svagheter och fel i det som utvecklas. Det är viktigt att förstå hela applikationen och användarnas behov.

I riktigt stora projekt däremot måste man som testare ofta arbeta mycket med process- och organisationsfrågor. För att kunna kommunicera och samverka med andra i projektet blir det viktigt med sådant som terminologi, dokumentmallar, samordning och projektstyrning. I det stora projektet måste testningen ofta organiseras i hierarkier, många testare arbetar utan att se helheten och utan direkt kunskap om slutanvändaren.

4. Hur unikt är projektet

Testaren påverkas också av hur unikt det projekt som man arbetar i är. Det är skillnad på ett projekt som tar fram ett helt nytt system jämfört med ett som tar fram version 11 av samma system. I förstagångsprojektet måste man ta fram eller anpassa allt från början: testprocess, metodik, verktyg. Ofta hinner man inte testa allt man skulle vilja utan tvingas prioritera. Planeringen är ofta osäker och ryckig och man måste kunna improvisera. Bristen på information och kunskap är något som karaktäriserar förstagångsprojektet. Testaren måste lägga mycket tid åt att leta efter information och för att lära sig systemet. I detta fall kan utforskande testning användas där man samtidigt testar och lär sig systemet.

Ett projekt som vidareutvecklar en redan existerande produkt kan därför kännas tryggare. Här finns det en inarbetad process och mycket dokumentation. Man kan ta fram en detaljerad och stabil planering som gör att man får mycket tid åt att utföra tester. Det blir också intressant att göra uppföljningar och mätningar för att gradvis förbättra sig. En utmaning man ställs inför i det upprepade projektet är hur man skall testa existerande funktionalitet. Projektet specificerar ofta endast de funktioner som skall läggas till eller förändras. Existerande funktionalitet är troligen inte dokumenterad så bra som man önskar sig. Då är det viktigt att låta personer som kan det tidigare systemet vara med vid testningen.

5. Styrning och formalism i organisationen

Tidigare har vi sett hur projekt med varierande storlek och olika kvalitetskrav skapar olika behov av hur hård processtyrning som behövs. Graden av styrning kan också vara något som bestäms av den organisation man arbetar i.

Många testare uppskattar hård styrning. Det ger många fördelar för testaren. Projekt- och process-styrning gör det lätt att få tid för testning. Tydliga specifikationer gör att man har något att utgå ifrån. Det finns en tydlig ansvarsfördelning och hierarki. Även om fördelarna överväger finns det också risker med hård styrning. Man kan ibland finna sig upptagen med uppgifter som inte känns så meningsfulla utan mest görs för att någon process eller standard föreskriver det.

En organisation med bristfällig eller ingen styrning kan vara jobbig för testaren. Det är svårt att veta vad som pågår. Specifikationer, beslut, ansvar, planer etc. är otydliga och förändras utan att man får information om det. Det gör att man ofta prioriterar fel och koncentrerar sig på fel saker. Det är sällan möjligt att från en position som testare införa en hel process i organisationen. Istället kan man börja med några bra testaktiviteter och sedan bygga vidare med stegvisa förbättringar. Eftersom det inte finns någon tydlig organisation måste man ägna mycket tid åt kommunikation för att sälja in testningen på alla nivåer. Om man inte ger sig, och är beredd att ge och ta i diskussionerna kan resultatet till sist bli riktigt bra.

6. Systemets arkitektoniska komplexitet

System med komplex arkitektur utgör en speciell utmaning för testaren. De flesta moderna system av någon storlek är komplexa till sin uppbyggnad. Systemen innehåller olika delar, som var och en har olika egenskaper och som har kopplingar till varandra, till databaser och kanske till externa system. Delarna kan ha utvecklats med olika utvecklingsverktyg och exekveras på olika plattformar. Systemen är beroende av tredjepartsprogram vid utveckling, kompilering eller körning. Tredjepartsprogrammen blir en ny källa till fel som både är svåra att ringa in och att få rättade. Det kan ibland vara möjligt att etablera ett samarbete med testorganisationen hos leverantören så att man kan ta del av varandras resultat. Testaktiviteter som blir speciellt viktiga för system med komplex uppbyggnad är integrationstest och installationstest.

Testningen av ett komplext system blir extra beroende av att utvecklingen av de olika delarna håller tidplanen, eftersom testaktiviteterna vanligtvis kräver samverkan mellan flera utvecklade komponenter. Då kan det vara nödvändigt att testaren tar initiativet och fungerar som delprojektledare för hur systemet stegvis integreras och kvalitetssäkras.

7. Kommersiella villkor

Vilka kommersiella villkor som råder mellan utvecklingsorganisationen och dess beställare påverkar hela utvecklingsarbetet. En del utvecklingsprocesser förutsätter att man arbetar med kontraktsutveckling mot en väldefinierad kund. Att det finns någon att stämma av krav mot och som kan utvärdera tidiga leveranser så att man vid projektets slut har tagit fram en produkt som uppfyller kundens krav. Även om kunden är krävande innebär detta arbetssätt en viss trygghet för testaren. Kvalitetskraven är enkla att definiera - att få kunden nöjd. Kunden kanske vill godkänna testprocessen och ha insyn i arbetet. Det är bara bra. Det gör att testningen får fokus och inte kan prioriteras ned.

Produktbolag tar inte fram system för enstaka kunder utan för en hel marknad. Beställaren finns inom det egna företaget. Kvaliteten på de krav man har att utgå ifrån är beroende på hur väl beställarorganisationen lyckats tolka marknadens krav. Vilka krav som är viktiga varierar över tiden beroende på att ny information blir känd eller att nya viktiga kunder köper produkten. Testaren måste därför vara beredd på snabba kast.

Ett system som är gjort för en hel marknad är i allmänhet möjligt att konfigurera på en mängd sätt för att passa olika kunder. För testningen blir det ytterligare en dimension att ta hänsyn till. Vilka av alla upptänkliga konfigurationer och parametrar skall man testa? För att få vägledning kan man använda sig av användarprofilering (personas) eller studera felrapporter från existerande kunder.

Vid kontraktsutveckling har man oftast fördelen av att ha en kund som utför acceptanstest. För att i någon mån uppnå samma sak vid marknadsdriven utveckling kan man gå två vägar. Antingen ingår man en överenskommelse med en målkund som ligger i ett viktigt kundsegment. Kunden åtar sig att utföra en sorts acceptanstest, kanske i utbyte mot att få produkten först och mycket stöd. Om målkunden är nöjd förutsätter man att andra kunder i samma segment också blir nöjda. Det andra alternativet är att skicka ut produkten till betatest hos en större och lösare sammansatt grupp av tilltänkta användare och hoppas att de börjar använda produkten och ger tillräcklig återkoppling. I båda fallen är det naturligt att testorganisationen ägnar mycket energi åt att få användarna att ta sig an produkten och ge återkoppling.

Situationsanpassad testning

Exemplen ovan visar på några av de olika ytterligheter testare kan ställas inför. Det finns naturligtvis också andra faktorer som påverkar testarens vardag och alla har säkert egna erfarenheter. Den stora variationen gör att man aldrig kan slå sig till ro med ett visst arbetssätt eller lita på gamla framgångsrecept. Istället måste man hela tiden tänka nytt, vara innovativ, inspireras av hur andra gör och ständigt försöka tränga djupare i förståelsen av sin verklighet för att kunna skräddarsy sitt arbetssätt och uppnå hög kvalitet och arbetsglädje.

Nästa steg

Låt Konsultbolag1 hjälpa er analysera vilka unika utmaningar som finns i er testorganisation! Vi kan ta fram ett arbetssätt för test som är skräddarsytt och effektivt samtidigt som det är baserat på den allmänna kunskapsbas som finns inom testområdet.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln