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 [email protected] 2 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare Tidsbrist .................................................................................................................................................................... 24 Scope creep .............................................................................................................................................................. 24 Risker faller ut ........................................................................................................................................................ 25 Bristande kommunikation ................................................................................................................................. 25 För stort ..................................................................................................................................................................... 25 4 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 Apple maps lanserades testrapport behöver han eller hon kunna påvisa att kvaliteten under hösten 2012 – en är tillräcklig eller om mer arbete krävs. Testledaren behöver lansering som visade sig inte ha tillräcklig teknisk kompetens för att kunna förstå tekniska vara så lyckad. Gatunamn problem som kan uppstå. Han eller hon behöver också ha och platser saknades, städer tillräckligt med kännedom om kvalitetssäkring för att kunna ta låg helt felplacerade. Bland fram ett lämpligt arbetssätt i ert projekt. annat så låg Stockholm i Vallentuna och Göteborg I testmanagement görs val av test och fanns inte med alls. Många kvalitetssäkringsmetoder som exempelvis andra orter var helt riskhantering malplacerade. olika former av granskningar teststrategier testtekniker mätetal testverktyg 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 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. 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 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 © 2013 Staffan Iverstam Testmanagement för projektledare å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: 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. 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. 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 © 2013 Staffan Iverstam Testmanagement för projektledare TESTOBJEKT Dela in systemet i testobjekt. Exempel: Kundgränssnitt Företagskundgränssnitt inloggning inloggning sökfunktion sökfunktion utloggning utloggning kundvagn kundvagn browsa till artiklar browsa till artiklar betalning kort, faktura mm ansöka om konto anmälan till kundbrev betala genom faktura avbeställning av kundbrev anmälan till kundbrev nyregistrering av kund avbeställning av kundbrev glömt lösenord nyregistrering av kund Administrationsfunktioner Utskick och rapport låsa upp spärrat konto kundregister lägga upp ny kund mailutskick till kunder webbstatistik månadsrapport larm vid driftproblem betalningsrapport sammanställning av dagens order Integrationer externa system Integrationer interna system bank affärssystem kortinlösare CRM återförsäljare Kundtjänst 17 © 2013 Staffan Iverstam Testmanagement för projektledare 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 Innan release av en ny stor webbplats rekommenderas att man inhämtar kunskap på portal gjordes en exempelvis owasp.org prestandatest. Det var tur 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: att testen gjordes eftersom portalen visade sig ha ett stort minnesläckage vilket gjorde att den slutade att fungera efter 2 timmars användning. blackbox, specifikationsbaserade tekniker white-box erfarenhetsbaserade 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 © 2013 Staffan Iverstam Testmanagement för projektledare 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 Förväntat resultat Starta en webbrowser och gå till www.xyz.se Startsida visas. Logga in genom att klicka på knappen Log in i övre högra hörnet Inloggningssida visas där du kan fylla i användarnamn och lösenord. Knapp med text Log in. 19 © 2013 Staffan Iverstam Testmanagement för projektledare 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. 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 Välj tjänst saldo genom att klicka på länk saldo som är listad i högra menyn. Sida för saldo visas. Klicka på Log out 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 Klicka på Yes 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 © 2013 Staffan Iverstam Testmanagement för projektledare TESTVERKTYG För att assistera i testarbetet finns verktyg för testmanagement, testautomatisering, felrapportering och ärendehantering. AUTOMATISERAD TESTNING Att testa en programvara tar mycket tid och kostar med andra ord mycket pengar. Därför har Det länge varit en dröm, inte minst för de som betalar för utveckling och underhåll av programvaror, att kunna automatisera testerna. På senare år har det blivit allt viktigare, men nu också av andra skäl som att man arbetar i kortare iterationer och behöver installera och testa programvaran oftare. Det är dyrt att sköta detta I december 2012 fick många manuellt, i den mån man alls hinner. Testautomatiseringen användare problem med görs dock inte så som man ofta tänker – att man spelar in Gmail och Chrome när en tester mot det grafiska gränssnittet som sedan spelas upp vid bugg i en uppdatering av behov och fel upptäcks och loggas. Trots att det finns bra Googles mjukvara för verktyg som används för att automatisera tester mot lastbalansering, påverkade webbgränssnitt, exempelvis Selenium, har tyvärr detta sätt att tillgängligheten av främst automatisera tester inte lyckats så ofta, mycket på grund av att Gmail och Chrome. På det stora under underhåll/arbete som krävs för att ta hand om Google var de snabba med dessa testfall så att de fortsätter att fungera. Då ett system att rulla tillbaka till den förändras, som det ofta gör då man bestämmer sig för att tidigare versionen av vidareutveckla en programvara, så behöver också de programvaran och automatiserade testerna uppdateras. I det arbetet försvinner problemet kunde stoppas mycket av vinsten med testautomatiseringen. Dessutom har efter 18 minuter. testfallen tagit ganska lång tid att ta fram i det första skedet. Istället automatiseras testerna av koden under gränssnittet. Exempelvis kan en webbapplikation bestå av ett webbgränssnitt som är programmerat i html. Under det finns annan kod som är programmerad i java, som kanske har kontakt med databas och andra system. Javakoden är lättare att programmera tester emot, i det att den inte ändras lika mycket som webbgränssnittet. Populära verktyg är exempelvis Fitnesse, JMeter, Cucumber som kan användas för dessa tester. Om ni istället utvecklar webbtjänster som andra system ska kunna anropa så finns exempelvis SoapUI, men också JMeter används ofta i dessa tester. I dessa fall är det dock inte frågan om man ska automatisera testerna utan hur mycket. Gränssnitten är mycket lämpliga att skapa automatiserade tester mot och verktygen används också för att göra prestandatester för att verifiera att programvaran klarar att hantera den förväntade storleken på användandet. Verktygen som nämnts ovan finns som gratisverktyg, men det finns också liknande verktyg från leverantörer som Microsoft, HP och IBM. Alternativet finns också att utveckla egna verktyg. TESTMANAGEMENTVERKTYG 21 © 2013 Staffan Iverstam Testmanagement för projektledare De vanligaste verktygen för att stödja testarbetet är sådana för att hantera testfallen och för att ta fram statistik över antal testfall, antal tester som gjorts, hur många tester som genomförts med lyckat resultat etc. Att använda liknande verktyg i någon form är stort stöd i de flesta fall av testarbete. Övrigt stöd för testmanagement är ganska skralt, det som används mest är kalkylark, ordbehandlingsprogram och tidplaneringsverktyg liknande Microsoft Project. ENHETSTEST Programmerarna har en mycket viktig del i test- och kvalitetssäkringsarbetet. Dels innebär det att ju duktigare de är, desto mindre fel finns och desto mindre tid krävs i testarbetet. Men det är dessutom så att programmerarna är ansvariga för enhetstester, det vill säga testerna av sin egen kod. Till hjälp har de testverktyg som JUnit och NUnit som hjälper dem att automatisera tester av deras programkod. Bra användning av detta gör en hel del för programvarans kvalitet. Bland annat eftersom de tidigt testar om koden fungerar eller om den blivit påverkad av ny funktionalitet man byggt. Ett problem man behöver hantera är att programmerare för det mesta inte har den största kunskapen inom test, och de lägger inte heller ner så mycket tid på sina enhetstester som de borde. Kvaliteten på programvaran som de lämnar ifrån sig till de som ska sköta testarbetet kan för det mesta bli bättre. Som projektledare kan du, tillsammans med testledaren, fundera på hur ni ska kunna förbättra enhetstesterna. Ett exempel är att se till att ni håller en utbildning inom enhetstest och testteori för utvecklarna. Ni kan också ta fram checklistor och annat som kontrollerar att koden blivit bra testad innan den lämnas över till nästa testnivå (till exempel systemtest eller integrationstest). Inom agil utveckling försöker man hantera problemen ovan på olika sätt, bland annat genom att se till att testare och utvecklare samarbetar i utvecklingsarbetet Läs mer om agil utveckling. PRESTANDATEST Oftast behövs någon form av prestandatest av programvaran, både under utvecklingsarbetet och efter att (man tror att) utvecklingen är klar. Olika verktyg är gjorda för olika typer av programvaror. JMeter är ett open source-verktyg som med fördel kan användas både i tester av webbapplikationer, databaser och webbtjänster, mm.. Det finns också en uppsjö av verktyg där man behöver köpa licenser. Dessa licenser kan vara väldigt dyra, men är det viktigt att verifiera prestandan kan det vara värt att lägga ner dessa pengar. Verktygen är ofta också enklare, och går snabbare att skapa script och analysera resultatet för dessa tester, och du sparar in arbetskostnaden genom att använda dessa verktyg istället för gratisverktyg. Exempel på verktyg där du behöver köpa licens är Loadrunner och Neoload. För prestandatest av webbtjänster finns som tidigare nämnts JMeter men också SoapUI. FELHANTERINGSVERKTYG En absolut hörnsten i testmanagement är verktyg för att hantera felrapporter. Ofta upptäcks så mycket fel i en applikation då man testar att utvecklarna inte hinner åtgärda allt på en gång. För att inte glömma bort att rätta till defekter, används felhanteringsverktyg. Exempel på vanliga 22 © 2013 Staffan Iverstam Testmanagement för projektledare verktyg är Bugzilla, JIRA. Men många testmanagementverktyg har också denna funktionalitet inbyggd. 23 © 2013 Staffan Iverstam Testmanagement för projektledare VANLIGA ORSAKER TILL BRISTANDE KVALITET Det mest effektiva sättet att lyckas med kvalitet är att inte skapa felen överhuvudtaget. Det finns en mängd olika metoder och teorier som försöker hantera detta. Följande kapitel försöker inte ge en heltäckande bild utan lyfter fram vanliga problem som jag sett och som är allmänt kända som vanliga orsaker till bristande kvalitet i programvaror. INGEN RISKANALYS ELLER INDELNING I TESTOBJEKT Ingen analys av systemet är gjord och man vet alltså inte vilka delar som är viktigast att de fungerar perfekt på det sättet de kommer att användas. Det kan till och med vara så illa att man inte vet vilka funktioner programvaran består av. Risken är då att man helt glömt att testa olika viktiga funktioner av programvaran, eller att man testat för lite. KOMPETENSBRIST Ett vanligt problem är kompetensbrist, hos såväl beställare som utförare. Beställare kan ofta ha får dålig kunskap om system och vilka krav man ska ställa. De beställer också inte helt sällan det de tror de vill ha, men som sedan visar sig inte stämma. Att vara en duktig beställare kräver en hel del erfarenhet av både IT och den egna verksamheten. KRAVHANTERING Kravhantering är ett annat vanligt problem. Det är svårt att sköta detta, speciellt i de fall då man ofta ska kravställa ett system inom ett område som man inte har tidigare kunskap om och dessutom saknar kunskap om beställarens verksamhet. En erfaren kravställare kan ofta behöva börja med att ifrågasätta om beställaren verkligen vet vad de vill ha och vad de behöver! TIDSBRIST I början har alla projekt gott om tid. Mot slutet ser man att det är knappt om tid om man börjar att slarva. Ett stort problem är ofta att man valt att skjuta på svåra saker till slutet, som sedan kan visa sig väldigt svåra och tidskrävande att lösa. SCOPE CREEP Ett vanligt problem är scope-creep. Det innebär att det läggs till mer och mer funktionalitet i projektet som ska levereras inom samma tidsram, eller med endast en liten förlängning. Då försämras självklart kvaliteten på programvaran som utvecklas. En väl fungerande programvara brukar växa fram efter hand. I början kanske man fått fram alla funktioner, men det är mycket som inte fungerar. Undan för undan börjar felen avhjälpas och färre nya fel tillkommer. När produkten sedan stabiliserats på en nivå där man känner sig ganska nöjd så kan man slutligen göra den slutliga putsningen för att för den riktigt väl fungerande och användbar. Det är programvarans utveckling från att krypa till att lära sig gå. Frågan är om det är värt pengarna? Många väljer hellre att skapa ett snyggt yttre, vissa välsmorda centrala funktioner medan en stor del av programmet fortfarande är av ganska dålig klass. Det är ändå ofta till syvende och sist 24 © 2013 Staffan Iverstam Testmanagement för projektledare kunden som avgör – kan programmet säljas eller ha tillräckligt nöjda användare så kan det räcka gott. RISKER FALLER UT Prestandaproblem, säkerhetsproblem eller annat som man inte förstått eller lyckats hantera. BRISTANDE KOMMUNIKATION Kommunikation och samarbete är en central del i att uppnå bra kvalitet i leveranser; en deltagare vad som krävs, en annan känner till vilka krav som ställs, en tredje vet hur en användare kan komma att använda systemet, en fjärde vet hur systemet ska designas och hur arkitekturen ska vara. Problemet är att denna information sällan når ut till alla som behöver den. I kapitlet om kravhantering beskrivs vikten av att kommunicera ut kraven så att alla har hela bilden klar för sig och att de som behöver även ska ha bra kontroll på detaljer. I rollen som utvecklare är det en framgångsfaktor att kunna fokusera på ett problem och hitta en bra lösning. Ofta blir utvecklaren tilldelad något arbetspaket som ska utvecklas. Det är också ett ganska ensamt arbete där många gillar att själva sitta och klura ihop snygga lösningar. Men för att kommunikation och samarbete ska blomstra krävs en mer social inställning än vad som är vanligt bland programmerare. Hur ska då bra kommunikation nås? I de agila utvecklingsmetoderna, exempelvis SCRUM, byggs möten in som en av grundpelarna i arbetsmetoden. Dagliga, korta möten där varje person får delge sin status på de arbetspaket man blivit tilldelad. Eftersom arbetssättet också innebär att man arbetar i små team som är ansvariga för att lösa en uppgift, byggs det in möjligheter för tät kommunikation och samarbete mellan utvecklare och utvecklare, mellan kund och utvecklare, mellan kravställare och testare etc. Alla inblandade har korta vägar till att kommunicera med varandra. Även om ett projekt inte valt att arbeta enligt SCRUM så är det viktigt att planera så att tät kommunikation mellan alla delar i projektet är möjligt. Det ska vara lätt att ställa en fråga om det är något man inte förstår, eller att ge ett tips på problemlösning. Det underlättar kommunikationen om man sitter i samma rum som det övriga projektet, då får man fördelar av överhörning (man hör några prata om något problem och det är lätt att man själv lär sig av vad de pratar om eller har något att tillägga bidrar till samtalet). FÖR STORT Stora IT-projekt misslyckas ofta. Håll dig ifrån att försöka få till allt från början, genomför hellre flera små projekt. 25 © 2013 Staffan Iverstam Testmanagement för projektledare