Testmanagement för projektledare - vad varje projektledare bör känna till om test och kvalitetssäkring Staffan Iverstam Testmanager QualityMinds
Testmanagement för projektledare 2013 Staffan Iverstam Version 1.0 www.qualityminds.se Kopiering Använd gärna Testmanagement för projektledare för egen del. Vill du trycka upp ett större antal kompendier, kontakta författaren. Har du synpunkter på texten? Hör gärna av dig till staffan.iverstam@qualityminds.se 2
Om författaren... 5 Inledning... 6 Välj rätt fel... 6 Testmanagement... 8 Vad är kvalitet?... 8 Kvalitet för olika roller... 9 Testplanen och teststrategi... 9 Testrapporten... 10 Kravgranskning... 12 Fler fel upptäcks tidigare... 12 Onödiga krav rensas bort... 13 Missade krav upptäcks... 13 Informationsglappen minskar... 13 Varför görs inte kravgranskning oftare?... 13 Riskbaserad test... 15 Hantera risker... 15 Riskbedömning... 15 Arbetssätt för att göra en riskbedömning för produktrisk... 16 Testobjekt... 17 Testarbetet... 18 Icke-funktionella tester... 18 Funktionella tester... 18 Testfall vs erfarenhetsbaserade tekniker... 19 Testverktyg... 21 Automatiserad testning... 21 Testmanagementverktyg... 21 Enhetstest... 22 Prestandatest... 22 Felhanteringsverktyg... 22 Vanliga orsaker till bristande kvalitet... 24 Ingen riskanalys eller indelning i testobjekt... 24 Kompetensbrist... 24 Kravhantering... 24 3
Tidsbrist... 24 Scope creep... 24 Risker faller ut... 25 Bristande kommunikation... 25 För stort... 25 4
OM FÖRFATTAREN Staffan Iverstam är utbildad civilekonom med en ekonomie magisterexamen från Handelshögskolan i Göteborg. Sedan 1996 arbetar han med IT och har under åren varit verksam inom flera områden allt från att starta en av de första internetbaserade matbutikerna, via reseförsäljning på internet till att numera arbeta som konsult inom test och kvalitetssäkring. Som konsult har han haft olika funktioner i flera utvecklingsprojekt hos såväl stora som mellanstora svenska företag. Arbetet har bland annat handlat om testledning, testdesign, prestandatest, testautomatisering, processutveckling, processkartläggning, kravhantering och projektledning. Han har också hållit utbildningar inom test och kravhantering. Under flera år har Staffan Iverstam varit styrelsemedlem inom SAST Väst en ideell organisation som varje år arrangerar välbesökta möten för personer verksamma inom test av IT-system. 5
INLEDNING I rollen som projektledare ingår att fatta beslut om hur ett projekt ska bedrivas. Det krävs inte djup kunskap i alla områden inom systemutveckling, men tillräckligt mycket behöver man känna till för att, tillsammans med andra kompetenser, kunna bedöma vilken väg man bör välja. Något som varje projektledare bör ha viss kännedom om är test och kvalitetssäkring, eftersom de har en så pass central del i utvecklingsarbetet. I många projekt tar man för lätt på testarbetet, ofta på grund av att man saknar kunskap om testmanagement och nya metoder för kvalitetssäkring. En djupare kunskap om testmanagement hjälper projektledaren att tillsätta rollen som testledare och skapa bra förutsättningar för att, i samarbete med testledaren och övriga projektdeltagare, skapa en bra programvara och ett lyckat projekt. Området test och kvalitetssäkring innefattar med andra ord allt rörande hur man arbetar i projektet för att få bra kvalitet till rätt kostnad och i rätt tid, och påverkar projektledning, kravhantering, utveckling och test. Genom bra projektledning och bra testmanagement får du bättre förutsättningar att styra rätt. Många har erfarit att det kan bli dyrt, kanske till och med väldigt dyrt, att inte tidigt arbeta med kvalitet i sin programvara. Att åtgärda fel som upptäcks då programvaran redan är driftsatt är många gånger dyrare än att upptäcka felet tidigt. Brandkårsutryckningar och panikartade åtgärder är både kostsamma och dåliga för din produkts anseende hos användarna eller kunderna. Det kan också innebära att organisationen som sedan ska handha produkten får en svårplanerad arbetssituation som orsakar missnöjda medarbetare. Den här texten syftar till att ge en grund i testmanagement samt en inblick i de nya metoder och verktyg som används idag inom test av IT-programvaror. VÄLJ RÄTT FEL Det kan kännas olustigt att veta att hur duktiga era systemutvecklare än är och hur mycket ni än testar så kommer det ändå att finnas kvar fel i programvaran - fel som dina användare förr eller senare kommer att upptäcka. Tänk då på att ju fler och bättre tester ni gör, desto fler fel kommer ni att hitta innan produkten tas i produktion. Och ju erfarnare projektdeltagare, desto större chans att en bra produkt levereras. Men det räcker inte; utan ett genomtänkt arbetssätt kommer du ändå bli stående med ett projekt som inte kan leverera produkten på grund av för många fel. Eller så har du en driftsatt en produkt som inte fungerar korrekt och med rasande, missnöjda användare (och rasande, missnöjda chefer) som följd. Hur gör du då för att slippa lägga över halva projektbudgeten på att testa programvaran och ändå bli stående med otrevliga felrapporter efter att den börjar användas? Det finns ingen enkel genväg, men genom att arbeta på ett genomtänkt sätt genom hela projektet kan felen minimeras. Då man utvecklar ett system måste man först och främst välja vilken kvalitetsnivå systemet ska ha. Ju högre kvalitet, desto mer kommer det att kosta i timmar av utvecklingsarbete som systemdesign, programmering och test. Med detta sagt bör man dock veta att det är svårt, kanske till och med omöjligt, att bygga ett program som är utan fel. Ett program kan användas på 6
tusentals sätt. Olika användare gör olika saker, använder olika inmatningar av förväntade och ej förväntade värden, trycker på rätt och på fel knappar, installerar programmet på datorer som alla ser olika ut, etc. Ska du försöka att testa alla möjliga varianter får du skaffa dig en rejält stor budget. Fel i programvaror är alltså något vi måste acceptera. Därför gäller det att upptäcka de kritiska fel som man inte vill råka ut för då systemet används. Kritiska fel är fel som gör programmet obrukbart, kanske på grund av alltför långa svarstider, eller till och med att programmet slutar att fungera. För att undvika att drabbas av kritiska fel då programvaran är i drift, behöver man arbeta med testmanagement och väl valda test strategier. 7
TESTMANAGEMENT Testmanagement är aktiviteten att planera och leda test- och kvalitetssäkringsarbete för att i slutändan kunna bevisa att de krav man ställt på systemet är uppfyllda. Det ingår också att upptäcka och peka ut de problem som finns innan programvaran sätts i drift. Testmanagement drivs av testledaren. Denna roll är viktig eftersom en bra testledare måste ha fokus på att upptäcka fel och vara ifrågasättande när det gäller programvarans kvalitet. En projektledare däremot, har fokus på leverans. Det gör att projektledaren kan förbise viktiga kvalitetsbrister som visar sig först då programvaran används. Testledaren ska istället fungera som projektledarens förlängda arm och bör ges uppdraget att slutligen rekommendera, inte besluta, om man kan driftsätta programvaran eller ej. I sin testrapport behöver han eller hon kunna påvisa att kvaliteten är tillräcklig eller om mer arbete krävs. Testledaren behöver ha tillräcklig teknisk kompetens för att kunna förstå tekniska problem som kan uppstå. Han eller hon behöver också ha tillräckligt med kännedom om kvalitetssäkring för att kunna ta fram ett lämpligt arbetssätt i ert projekt. I testmanagement görs val av test och kvalitetssäkringsmetoder som exempelvis riskhantering olika former av granskningar teststrategier testtekniker mätetal testverktyg Apple maps lanserades under hösten 2012 en lansering som visade sig inte vara så lyckad. Gatunamn och platser saknades, städer låg helt felplacerade. Bland annat så låg Stockholm i Vallentuna och Göteborg fanns inte med alls. Många andra orter var helt malplacerade. Det är upp till testledaren att använda och kombinera olika tekniker, metoder och verktyg som kan bidra med att programvaran levereras i tid, fungerar väl och enligt kravställd funktionalitet. Hur man uppnår detta skiljer sig från projekt till projekt, beroende på programvarans komplexitet och projektets valda arbetssätt. Valen testledaren gör dokumenteras i testplan och/eller teststrategi. Detta kan vara två skilda dokument och ibland innehåller testplanen avsnittet teststrategi. VAD ÄR KVALITET? Innan vi går djupare in på området testmanagement behöver ordet kvalitet definieras. Kvalitet är ju kärnan i det som hanteras i testmanagement. Det en person tycker är bra kan en annan tycka är mindre bra. För att kunna bedöma något så subjektivt som kvalitet kan man använda sig av olika metoder som har det gemensamt att de objektivt försöker bedöma kvaliteten i en produkt. Exempelvis kan man använda sig av olika kvalitetskriterier. 8
Då man bedömer ett IT-system använder man sig ofta av ett antal kvalitetskriterier för att beskriva vilka förväntningar, krav och vilken användning som ett system eller en programvara ska klara av. Följande kvalitetskriterier är vanliga: funktionalitet tillförlitlighet underhållbarhet prestanda användbarhet portabilitet Vad som bedöms vara av bra kvalitet beror på vem användaren är och programvarans användningsområde. För vissa är exempelvis användbarhet och funktionalitet avgörande medan andra kriterier inte är lika viktiga. Bygger du en mjukvara för att rapportera in fakturor för en ekonomifunktion ska gränssnittet vara enkelt och gå snabbt att använda utan stora krav på att vara snyggt. Bygger du en programvara som du ska sälja till designintresserade personer är kravet högre på att gränssnittet ska vara snyggt. Bygger du en programvara som ska vara en del i miljontals banktransaktioner har du kanske extremt höga krav på att den aldrig ska göra fel, men mindre krav på design. Bygger du å andra sidan en mjukvara för ett flygplan kanske den inte tillåts göra minsta fel för att undvika allvarliga olyckor. KVALITET FÖR OLIKA ROLLER Du måste alltså först bestämma dig för vad hög kvalitet är i varje programvara och vilka roller som du utvecklar för. Användaren av programvaror kan vara en eller flera roller. Om du utvecklar en mobilapplikation så har du en slutanvändare som ska ha appen i sin mobil och som ska använda de I maj 2010 skulle Volvo demonstrera sitt nya system med en bil som själv bromsar. Man hade visning inför massvis med journalister. Men istället för att stanna körde bilen rakt in i släpet. Teorin var att en snabbladdning av batteriet hade förstört mjukvaran som skulle bromsa bilen. Det hade varit bra om de hittat detta problem i någon tidigare test än under demonstration av systemet. funktioner du tagit fram. Om du istället bygger en webbplats som ska leverera spel eller mobila tjänster så har du flera olika roller som ska hantera programvaran; dels har du slutkonsumenten som använder sig av webben, dels har du dem som ska lägga in spel och annat innehåll på webbplatsen som kunden ska kunna köpa. Ytterligare roller har dem som ska installera och sköta webbplatsen när den är i drift. Det går snabbt att hitta flera olika användare som ska trivas med att arbeta med programmet och/eller webbplatsen. Funktionerna ska fungera, det ska vara ett lättanvänt och snyggt användargränssnitt. TESTPLANEN OCH TESTSTRATEGI Testplanen ska beskriva hur tester ska göras för att verifiera att ni tagit fram programvara av den kvalitet som är beställd. Testplanen beskriver vilka delar som ska testas och vilka delar som inte ska testas, till exempel om det finns delar av programvaran som ligger utanför projektets 9
åtagande och som ska testas av andra. Planen ska också beskriva hur testledaren har delat in programvaran i testobjekt, vilka som ska arbeta med testerna, vilka risker som finns, etc. Viktigt är att testplanen är ett levande dokument som fylls på vartefter testledaren lär sig mer om programvaran och hur den ska användas. Ofta är det kopplat en tidplan till testplanen, ibland är tidplanen en del av testplanen. Teststrategin beskriver angreppssättet för testerna och bestäms bland annat utifrån hur kritisk programvaran är, vilken tid man har på sig, vilka testresurser (både personer och verktyg) som finns tillgängliga och hur ny teknik som används. Vanliga strategier är riskbaserad testning och en blandning av tekniker såsom black-box-tekniker, utforskande test, kravgranskning och granskning av programvara med hjälp av checklistor. Dessutom förekommer ofta en stor del automatiserad testning. TESTRAPPORTEN Innan driftsättning av programvaran ska testledaren leverera en testrapport som bevisar eller avvisar att programvaran utför det den ska och är av den kvalitet som är beställd. Rapporten ska alltså påvisa de fall där kvaliteten inte är enligt beställarens krav eller där det finns problem som behöver belysas. En sådan rapport kan innehålla följande punkter: En sammanfattning av testledarens bedömning av mjukvarans kvalitet. Levererade krav samt eventuella ej levererade krav. Genomförda tester samt eventuella ej genomförda tester för varje del av mjukvaran (varje testobjekt) o funktionella tester o icke funktionella tester, såsom prestanda, uthållighet och säkerhetstest. Vid införandet av ett nytt affärssystem visade det sig att leverantören av systemet nyligen bytt teknisk plattform. Enligt säljaren skulle det inte vara några problem, men vid acceptanstest upptäcktes massvis buggar, både stora och små, och driftsättningen fick skjutas fram till dess att systemet blivit användbart. Antal inrapporterade fel och andra mätetal. Rekommendation till projektledare eller annan beslutsfattare hur man bör fortsätta, om vissa områden är problematiska och behöver extra fokus, etc. Testrapporten fyller en viktig funktion under hela utvecklingen av programvaran och ska skrivas efter varje avslutad fas och efter avslutat projekt. (Faser kan vara sprintar, iterationer, testnivåer såsom systemtest, acceptanstest, etc.). Målgrupperna för testrapporten är projektledaren, styrgruppen och andra som behöver veta hur programvaran fungerar. Det är viktigt att påpeka att projektledaren är ansvarig för att säkerställa att rapporten skrivs, även om ansvaret är delegerat till testledaren. Testledaren är inte sällan fullt inbegripen i dagligt arbete under tidspress och det är då lätt att skjuta på 10
rapporteringen. Kom ihåg att rapporten är en alltför viktig del i projektet för att inte skrivas eller läsas, så kräv in den! När testledaren skriver sin testrapport och då sammanfattar status på testarbetet och programvarans kvalitet, tvingas denne att fundera över sina beslut och sina framsteg. I det här skedet upptäcks inte sällan sådant som behöver åtgärdas, till exempel att ett område inte är tillräckligt testat eller att oroväckande många fel visar sig i kritiska delar av programvaran. Detta kan då åtgärdas av projektet och i testas i senare tester. 11
KRAVGRANSKNING Till grund för utvecklingen av en programvara ligger kraven från beställaren. För att nå en bra beskrivning av kraven krävs att man: inhämtar kunskap från många inblandade har en bra kommunikation för att få fram allas kunskap och önskemål tydliggör vilket behov systemet ska fylla rensar bort det som programvaran inte ska göra. Det finns undersökningar som visar att så mycket som ca 50 % av felen i en programvara härrör från kraven. Om vi kan hitta felen redan vid kravarbetet kan vi alltså arbeta mer effektivt. Ett fel som hittas och korrigeras innan utvecklingen påbörjats tar betydligt mindre resurser i anspråk, kanske endast en minut, än ett fel som hittas i drift som kan ta flera dagar att åtgärda. Istället för att kunna finputsa på mjukvaran för att få den perfekt behöver ni arbeta in i det sista för att den ska gå att använda. Hur gör man då för att undvika detta? Ett bra sätt är att granska kraven innan de godkänns. Genom att göra en kravgranskning kan man upptäcka fler fel i ett tidigare skede rensa bort onödiga krav upptäcka missade krav En bit in i 2000 talet infördes ett nytt system för spårinformation för pendeltåg. Skyltarna på perrongerna skulle ange på vilket spår som tåget skulle inkomma. Tyvärr fanns en bugg som visade sig att då ett tåg av någon anledning fick byta spår mot det i förhand planerade så visades det inte på perrongskyltarna förrän precis då tåget anlände till stationen. minska informationsglappen. FLER FEL UPPTÄCKS TIDIGARE Genom att granska kraven kan man redan på skrivbordsstadiet upptäcka många fel. Exempel: Om ett krav säger att man ska kunna ange förnamn, efternamn och telefonnummer då man registrerar sig så kanske det senare finns krav som säger att man ska kunna nå kunderna via mail. Då behöver kravet uppdateras med att man också ska ha ett fält där kunden skriver in sin e-mailadress. Se till att personer från olika områden är med i granskningen, inte minst testare/testledare som förmodligen tillhör de bästa granskarna. De är kritiska, vana att granska krav och har ofta stor kunskap om systemet. En erfaren testare funderar instinktivt på hur kravet ska testas i testfall och testdata, och på så sätt kan du upptäcka luckor eller tvetydigheter i kraven. 12
ONÖDIGA KRAV RENSAS BORT Genom att göra granskning av kraven upptäcker man inte bara fel tidigt, utan också oviktiga krav. Det projektgruppen hoppades på att kunna lösa med hjälp av kravet kanske går att lösa med en befintlig funktion i systemet, eller så har man ändrat sitt planerade arbetssätt så den funktion man kravställt inte längre kommer att användas. MISSADE KRAV UPPTÄCKS Kravarbete är svårt och hur väl man än försöker fånga alla krav är det lätt att missa mycket. Med hjälp av en kravgransknig tar man en ny vända med kraven som får synas av många och på så sätt upptäcks eventuella luckor. INFORMATIONSGLAPPEN MINSKAR När flera delprojekt ska leverera en lösning är det stor risk för informationsglapp. Det är svårt att se till att information hela tiden delges alla och det är lätt hänt, när trycket ökar, att de olika projekten fokuserar mer och mer på sin egen leverans och inte har tid att prata med övriga projekt. Då är risken stor att man mot slutet ser att leveranserna, som är beroende av varandra, inte överensstämmer. Exempel: En projektgrupp utvecklar ett webbgränssnitt i en applikation och en annan grupp utvecklar webbtjänster som ska förse webbgränssnittet med data. Det visar sig att webbtjänstprojektets kravspecifikation saknar krav på vissa parametrar som webbgränssnittet behöver. Detta upptäcks först mot slutet av utvecklingsperioden och projekten behöver lägga mer tid på att utveckla, eller kanske till och med göra om vissa funktioner. Vid ett universitet infördes en ny studentportal, bland annat skulle studenterna kunna anmäla sig till tentor och se sina studieresultat. När portalen började användas visade det sig att studenterna ibland blev inloggade på andras konton och fick se andras uppgifter. Det visar sig att det saknas hela funktioner eftersom kraven i det ena projektet fortsatt att utvecklas utan att de motsvarande kraven i det andra projektet uppdaterats. För att undvika informationsglapp är det förstås viktigt att de som arbetar med kravställningen hela tiden ser till att alla projekt hålls uppdaterade. Det är enkelt att säga men svårare att genomföra. Ofta är ju IT-projekt under stark tidspress och måste hantera förändrade och utökade krav som gärna ska hinnas med inom samma tid. Läs mer om kravgranskning och kravgranskningstekniker. Länk VARFÖR GÖRS INTE KRAVGRANSKNING OFTARE? Med tanke på alla buggar som hittas sent och som kostar mycket att åtgärda - med missnöjda kunder som följd är det konstigt att inte mer tid läggs på granskning. Varför görs det då inte mer? Några tänkbara förklaringar kan vara: 13
Kostnaden för att genomföra granskningsarbetet är lätt att räkna ut, men vinsterna är mycket svårare att se. Projektledningen, och den som beställt utvecklingen, är inte säker på granskningens förträfflighet. Det är svårare att göra bra granskning än att sätta sig med ett program och klicka och leta fel. Tidsbrist som slår mot testgruppen. När trycket ökar måste även den mest nitiske granskare fokusera på att testa leveransen som nyss kommit, istället för att granska kraven för en framtida version av systemet. 14
RISKBASERAD TEST HANTERA RISKER En viktig faktor i prioriteringen av vad som ska utvecklas och testas först är risk. Hur stor är risken att det finns allvarliga problem inom ett område och vilken effekt skulle dessa eventuella problem få om de blir verklighet? Man talar om riskbaserad test. I korthet innebär detta att man analyserar vilka risker som finns som hindrar programvaran och projektet att bli klart i tid med en bra produkt. Sedan planeras arbetet och omfattningen av testarbetet utifrån denna riskanalys. Innan vi går vidare in på detta så behöver risker beskrivas. Det finns två sorters risker: projektrisker och produktrisker. Projektrisker tas vanligtvis omhand av projektledare och är något som en erfaren projektledare alltid hanterar. Exempel på projektrisker är brist på kompetens och personal, leverantörsfaktorer där det kan bli kontraktsproblem. Detta har mindre påverkan på hur programvaran ska utvecklas eller testas. Produktrisker däremot, är lättare att förbise. Produktrisker behöver aktivt hanteras av projektet som utvecklar programvaran. Dessa risker behöver hanteras i planer och arbetssätt under hela utvecklingen, från design av programmet till test och leverans. Exempel på produktrisker: Det har visat sig finnas säkerhetsbrister i många webbplatser, och många säkerhetsbrister har säkerligen tystats ner. Det som man kunnat läsa om är exempelvis då hackers har kommit över användaruppgifter till olika webbplatser och kortnummer till betalkort har stulits. många fel i den levererade programvaran möjligheten att programvaran/hårdvaran kan skada individer eller företag dåliga programvaruegenskaper (såsom funktionalitet, tillförlitlighet, användbarhet och prestanda) programvara som inte utför det den är avsedd för programvaran kommer hantera känslig information eller vara åtkomlig från internet och ha högre krav på säkerhet. RISKBEDÖMNING Riskbedömningen används för att alla i projektet ska bli medvetna om de utmaningar programvaran, eller olika delar av programvaran, har. Om det framkommer att en del i ett program kommer att ställa höga krav på säkerhet så är det viktigt att alla projektdeltagare är medvetna om det. Den som arbetar med krav kan behöva komplettera med fler krav kring hur säkerheten ska hanteras. På samma sätt blir de som arbetar med systemarkitektur, systemdesign och utveckling medvetna om kraven på säkerhet och har det i åtanke vid design och programmering. Och de som arbetar med test kan se till att fler tester kring säkerhet planeras och utförs. 15
Inte bara kritiska risker, såsom säkerhet, kan upptäckas. Andra exempel på risker är att en del funktioner av en webbplats kommer att utnyttjas väldigt frekvent av viktiga kunder. Utvecklingsprojektet behöver då vara medvetet om detta och säkerställa att dessa funktioner fungerar bra. ARBETSSÄTT FÖR ATT GÖRA EN RISKBEDÖMNING FÖR PRODUKTRISK Följande är viktiga delar i riskbedömning och riskhantering: Analysera er programvara och dela in den i mindre delar, så kallade testobjekt, för att kunna se vilka tester som krävs för varje del och för att ni inte ska missa att testa något vitalt område. Se avsnitt om Testobjekt Gör en riskanalys och analysera varje testobjekt för sig, så att både ni och de som ska sköta utvecklingen/testarbetet förstår vilka delar i er programvara som är viktigast. Se avsnitt om Test/Riskhantering Planera och utför tester som hanterar den risk som ni kommit fram till. Se till att ni får en testrapport som belyser vilka tester som gjorts för varje testobjekt, och resultatet av dessa tester. Se avsnitt om Test/Testrapporten De i projektet som har inblick i programvaran, bör uttala sig om hur de ser på produktrisken. Dessa kan vara: kravställare och användare kravställaren vet vilka av kraven som är viktiga att de realiseras och vilka funktioner som är viktigast projektledare kunder systemarkitekter systemdesigner utvecklare. Sammankalla till ett riskmöte med målet att gå igenom alla funktioner i produkten/ testobjekt. Varje testobjekt behöver tilldelas ett värde för sannolikhet och ett värde för effekt, förslagsvis i en skala från 1 till 5. Sannolikheten värderar hur sannolikt det är att det blir problem i funktionen. Sannolikhet är beroende av hur komplex funktionen är, hur ofta den ska användas mm. Effekt är ett mått på allvarlighetsgraden om det uppstår ett fel. Ju allvarligare skada, desto högre effektpoäng. Väger man samman detta, exempelvis genom att multiplicera dessa värden med varandra, så får man ett värde som kan hjälpa till att bedöma hur viktigt det är att funktionen testas ordentligt innan driftsättning. Vid utveckling kan det också vara lämpligt att utveckla de funktioner med höga värden först. Ett vanligt fel är att man inte märker att vissa områden är mer komplicerade än andra, eller till och med att man väljer att skjuta på komplicerade områden till senare. Det kan ofta istället vara bra att tidigt adressera dessa områden för att undvika att i slutet av projektet upptäcka att problemet var större än vad man först trodde. Det innebär ofta att projektet inte kan avslutas enligt tidplan. 16
TESTOBJEKT Dela in systemet i testobjekt. Exempel: Kundgränssnitt inloggning sökfunktion utloggning kundvagn browsa till artiklar betalning kort, faktura mm anmälan till kundbrev avbeställning av kundbrev nyregistrering av kund glömt lösenord Administrationsfunktioner låsa upp spärrat konto lägga upp ny kund webbstatistik larm vid driftproblem Företagskundgränssnitt inloggning sökfunktion utloggning kundvagn browsa till artiklar ansöka om konto betala genom faktura anmälan till kundbrev avbeställning av kundbrev nyregistrering av kund Utskick och rapport kundregister mailutskick till kunder månadsrapport betalningsrapport sammanställning av dagens order Integrationer externa system bank kortinlösare återförsäljare Integrationer interna system affärssystem CRM Kundtjänst 17
TESTARBETET När programvaran blir klar börjar den fas i testarbetet då man aktivt arbetar med programvaran, istället för att, som tidigare, endast ha planerat. Man behöver ha bestämt vilka funktionella tester och vilka icke-funktionella tester som ska göras. Exempel på funktionella tester är vanliga testfall och görs för att säkerställa att funktionerna gör det de är tänkta att göra, till exempel att det går att logga in. Icke-funktionella tester är exempelvis prestandatester och säkerhetstester. ICKE-FUNKTIONELLA TESTER Icke-funktionella tester kräver ofta specialkompetens, såsom kunskap om hur man genomför prestandatester och hur verktyg för dessa tester ska användas, eller hur man gör säkerhetsgenomgångar av en programvara. Grundläggande tester inom dessa områden kan dock erfarna testare utföra. Ska man utföra egna säkerhetstester för en webbplats rekommenderas att man inhämtar kunskap på exempelvis owasp.org FUNKTIONELLA TESTER Funktionella tester är oftast den större delen av testarbetet och det som de flesta testare och testledare arbetar mest med. Traditionellt sett har man alltid arbetat med testfall. Hur detaljerat man beskrivit teststegen och det förväntade resultat skiljer sig dock åt mellan olika testledare och organisationer. Hur testfall tas fram beskrivs i olika testdesigntekniker: blackbox, specifikationsbaserade tekniker white-box erfarenhetsbaserade Innan release av en ny stor portal gjordes en prestandatest. Det var tur att testen gjordes eftersom portalen visade sig ha ett stort minnesläckage vilket gjorde att den slutade att fungera efter 2 timmars användning. I black-box-teknikerna arbetar man som om man inte känner till hur programvaran är programmerad. Man utgår alltså inte från koden utan skriver testfall i form av användarscenarier och använder specifikationen eller kunskapen hur en funktion ska användas som underlag för att skriva testfallet. Testdesigntekniker som används är till exempel ekvivalensuppdelning, gränsvärdesanalys eller användande av beslutstabeller. I white-box-teknikerna använder man kunskap om koden och planerar och utför test baserat på olika varianter som finns i koden. Man kan till exempel analysera hur många if else som finns och se till att man testar de olika varianterna. Man kan då också försöka mäta hur stor del av koden man testat. Erfarenhetsbaserade tekniker har vuxit sig starkare på senare år. I dessa tester utnyttjas testarens erfarenhet av fel som funnits i andra program man arbetat med, samt testarens 18
generella kunskap om test. Dessa tekniker är mer fria och använder sig inte av testfall i gammal mening, istället utforskar man oftare programvaran för att aktivt leta fel i själva arbetet med programvaran. Exempel på testtekniker är utforskande test och sessionsbaserad test. Gemensamt för dessa typer av test är att man, genom att inte lägga ner lika mycket tid på att skriva testfall, får mer tid över till test av applikationen. Det är också svårt att komma på alla olika typer av testfall då man ska skriva ner och planera dem. En duktig testare kommer på många bra tester under tiden denne arbetar med test av programvaran. Viktigt att poängtera är att testaren under testen använder sig av sina kunskaper i testdesigntekniker, det vill säga under testen, så att man till exempel kan testa att mata in värden i ett inmatningsfält och då använda värden som är framtagna genom gränsvärdesanalys. Detta är inget som en oerfaren testare kan göra lika bra som en erfaren. Dessa tekniker har ändå ett regelverk som behöver följas, det är inte tillräckligt att bara sätta sig och klicka planlöst. Genom regelverket får man fokus på testarbetet, möjlighet att se vilka områden man testat, ett sätt att kontinuerligt följa upp vad man gjort och välja nästa område att testa. Man använder ofta testuppdrag så kallade test charters i utforskande test där testaren får ett avgränsat uppdrag att testa en del av programvaran: Leta reda på alla fält där användaren kan mata in data och testa dem utifrån fältlängd, olika varianter av tecken. Jämför applikationens GUI utifrån den framtagna beskrivningen över våra GUI. Testa om sökfunktionen ger rätt resultat på sökningar om våra produkter. Testledaren bestämmer i vilken mån testerna ska dokumenteras, om resultatet av testerna gör att man känner sig nöjd eller om testerna ska fortsätta inom detta område. Läs mer om dessa former av test på Wikipedia: exploratory testing, session based testing. TESTFALL VS ERFARENHETSBASERADE TEKNIKER Av de tre testdesignteknikerna ovan har black-box teknikerna i många fall inte varit ifrågasatta alls. Tidigare var det självklart att man skrev detaljerade testfall för hela applikationen. På de senare åren har det svängt över mer åt man vill använda mer utforskande tekniker. Och detta är inte enbart i agila projekt utan även då man använt sig av utvecklingsmetod mer lik V-modellen. De traditionella testfallen är ofta som i exemplet nedan:: Teststeg Starta en webbrowser och gå till www.xyz.se Logga in genom att klicka på knappen Log in i övre högra hörnet Förväntat resultat Startsida visas. Inloggningssida visas där du kan fylla i användarnamn och lösenord. Knapp med text Log in. 19
Logga in med användare Jenny Kund genom att i fältet User skriva JennyKund och i fältet Password skriva xyz123. Klicka på knappen Log in. Välj tjänst saldo genom att klicka på länk saldo som är listad i högra menyn. Klicka på Log out Klicka på Yes Startsida för Jenny Kund visas. Sidan ska innehålla de tjänster som är aktiva för henne. Längst upp till vänster står Logged in user: Jenny Kund Sida för saldo visas. Sida för utloggning visas med text You are now logging out. Proceed? Med grön knapp Yes till vänster och röd knapp No till höger under texten Du blir utloggad. Startsida visas. Längst upp till vänster står You are not logged in Kritiken mot dessa testfall är bland annat att de tar lång tid att skriva - tid som istället kan användas till faktiska tester. När man sedan testar, utförs exakt dessa steg vid varje testomgång och risken är stor att man missar viktiga buggar som inte blivit täckta i testfallet. Det finns ju nästan oändligt många vägar en användare kan ta i en programvara med olika typer av testdata såsom användare och olika typer av inmatning. Att skriva ner alla dessa varianter i testfallen skulle ta oproportionerligt lång tid. När sedan funktionaliteten ändras har man hundratals testfall som behöver skrivas om. Det är också så att en viktig del i testarens uppdrag är att upptäcka specialfall där det blir fel. Huvudflöden brukar ofta fungera men användarna arbetar på sina egna sätt och gör långtifrån alltid som manualen säger. Det är svårt att komma på testfall som tar dessa vägar i programvaran på förhand, och det blir väldigt många testfall som ska skrivas. I många projekt väljer man fortfarande att arbeta med detaljerade testfall men en allt större del av testerna görs med hjälp av utforskande tekniker.. 20