Version Testteam 4 Testledare: Patrik Bäck

Transkript

1 Version Testteam 4 Testledare: Patrik Bäck 0

2 Sammanfattning Testplanen är utarbetad som ett svar på Konsumentverkets förfrågningsunderlag avseende upphandling av ett nytt budget- och skuldsaneringssystem, benämnt HEP. Testplanen är ett underlag för att beskriva hur testningen av det nya systemet kommer att genomföras med fokus mot strategier och riskhantering i testarbetet. Kravdokumenten ifrån Konsumentverket har använts som underlag och testteamet har genom dessa identifierat ett antal riskområden där säkerhet, beräkningar och integrationer mellan modulerna anses vara de mest kritiska. 1

3 Innehållsförteckning 1. Introduktion Testuppdrag Mål Risker Informationskällor Teststrategi Testtekniker Riskbaserad testning Kvalitetsegenskaper Sessionsbaserad testning Skriptad testning Utforskande testning Scenariotestning Användartester Enhetstester Testidéer Säkerhet Beräkningar Integrationer Projektrisker Testprocess Testmiljö Testverktyg Tidsåtgång Testresultat och leverabler Kriterier för godkänt/icke godkänt test Bilagor Bilaga 1: SFDPOT Bilaga 1: Flödesschema

4 1. Introduktion Testplanen ska ses som ett levande dokument och kan komma att ändras vid behov för att på bästa sätt uppfylla projektets mål att leverera ett så bra HEP-system som möjligt. Analysen av HEP har genomförts i ett arbetsteam av tre testare som analyserat kravdokumenten och utarbetat en testplan under en period av 4 veckor. 2. Testuppdrag Testplanen har skapats efter riktlinjen att möta Konsumentverkets krav för godkännande som övergripande mål för all testning. Arbetsmetoden har varit att granska och analysera kraven för att identifiera riskområden som senare ska ges högsta prioritet i kommande testarbete. De riskområden som identifierats är säkerhet, beräkningar och integrationer. 2.1 Mål Uppdraget går ut på att leverera en testplan för hur testarbetet ska genomföras med fokus på strategi och att skapa arbetsmetoder för att effektivt identifiera och eliminera risker med HEP. 2.2 Risker Det har identifierats tre stora riskområden med HEP genom kraven: Säkerhet: Då HEP tillhandahåller känslig information om privatpersoner krävs en hög grad av säkerhetstänk både för att följa krav ifrån konsumentverket och för att följa lagar och regler, exempelvis enligt Personuppgiftslagen(PUL). Beräkningar: Eftersom hela funktionaliteten i HEP bygger på beräkningar så kommer ett stort fokus att behöva läggas på att dessa blir rätt. Att undersöka samband och påverkan ifrån uppdateringar är andra faktorer som spelar in. Integrationer: HEP är uppbyggt på ett antal olika moduler. Att se hur dessa interagerar med varandra och att kopplingar, redovisning och uppdatering sker på rätt sätt blir då av största vikt. Förutom dessa huvudområden kommer även andra risker så som övrig överrensstämmelse med krav, användarupplevelser, drift och underhåll att testas. 2.3 Informationskällor Information till testplanen har hämtats ifrån kravdokumentationen av Konsumentverket. För att kunna analysera och skapa sig en bild över HEP och dess funktionalitet har modeller skapats. En produktanalys har genomförts med en så kallad SFDOPOT-modell, se bilaga 1: SFDPOT, samt ett flödesschema för att se arbetsgången, se bilaga 2: Flödesschema. Utöver denna input har även den föregående versionen av HEP körts för att skapa testidéer. Framtida informationsinsamling kommer att göras via intervjuer med sakkunniga, jämförelseorakel av liknande system och mot organisationer vilka är ämnade att kopplas samman via integrationer i HEP, exempelvis Skatteverket. 1

5 3. Teststrategi Huvudteststrategin för HEP är att alltid genomföra riskbaserad testning utifrån krav och med fokus mot identifierade riskområden. Målet är att minst täcka alla krav ifrån Konsumentverket. Därutöver vill teamet täcka alla funktioner och minimera risken för att användarfel uppstår genom att gå in mer noggrant i de prioriterade områdena säkerhet, beräkningar och integrationer. Genom ett brett spektra av testtekniker skapas möjligheten att belysa olika delar av HEP och dess delar. Analysen av kravdokumentationen har gett testidéer om vad som behöver testas via de olika testteknikerna. 3.1 Testtekniker För att ge testningen både bredd och djup kommer ett antal olika tekniker att användas. Dessa kommer att hjälpa testningen att belysa och identifiera olika typer av fel så att de upptäcks innan driftsättningen av HEP. Under följande punkter kommer varje vald teknik att förklaras om varför den kommer användas och vilka fördelar den har. Att ha en stor bredd på testteknikerna är även en källa till att skapa nya testidéer vilket stärker testningen i stort Riskbaserad testning Riskbaserad testning kommer att genomföras med utgångspunkt ifrån angivna krav och kompletteras med ytterligare områden som bedöms viktiga. Genom analys av kraven har en riskbild skapats vilket kommer att ligga till grund för att prioritera testen så att mest tid och kraft läggs på de viktigaste områdena Kvalitetsegenskaper För att garantera att alla aspekter av produkten täcks i testningen så kan utgångspunkten kvalitetsegenskaper användas. I tekniken använder man sig av en checklista med olika kvalitetsområden för att se till så inget glöms bort och för att finna nya testidéer och skapa nya testfall Sessionsbaserad testning En teknik som exempelvis kan användas för att göra djupdykningar i specifika riskområden eller som källa till att finna nya testidéer då en session kan bestå av att testa inloggning under en timmes tid vilket ofta leder till nya tankar. Kan även göras funktionsbaserat och mer övergripande där inte ingående tester är av samma vikt Skriptad testning Skriptade tester bör göras för att möjliggöra regressionstester exempelvis uppdelat per modul. Dessa testfall ska sedan lämnas över till Konsumentverket för eventuell framtida testning exempelvis efter uppdateringar. Skriptade tester kan även fungera som ett underlag för eventuell testautomatisering Utforskande testning Att testa utforskande kan utföras som en egen teknik eller uppstyrt via exempelvis sessionsbaserade tester. Det är en källa till att finna sådant som annars lätt missas då en viss mån av utforskande tester bör finnas för att finna saker runtomkring som annars lätt missas. Kan även vara en bra teknik för att undersöka användarupplevelser och sådant som annars är svårt att mäta. Utforskande testning ger snabbt många testfall och bör därför dokumenteras för att redovisa vad som har gjorts. 2

6 3.1.6 Scenariotestning För att testa att olika arbetssätt går att genomföra, exempelvis för alternativa flöden och längre sekvenser, är scenariotestning en teknik som kan rekommenderas. Genom tekniken kan situationer och förhållanden som annars är svåra att finna eller hamna i att uppstå. Scenariotestning kan fungera som en källa för integrationstestning mellan moduler. Ytterligare ett användningsområde är för att jämföra mot orakel så som arbetssättet i dagens HEP jämför mot det nya Användartester En annan metod som testteamet förespråkar är användartester. Genom dessa skapas möjlighet att se dolda mönster och användningsområden som annars är lätta att missa. Genom att få möjlighet till att se hur en handläggare arbetar kan information om vad som fungerar bättre och sämre med dagenssystem upptäckas och på så vis förbättras i den nya versionen av HEP Enhetstester För att effektivast testa på enhetsnivå bör denna testning ske av utvecklarna som bäst kan koden och hur den fungerar. Ett alternativ är att utvecklarna lägger in kod för spårbarhet och loggning i senare tester från testteamet. 3.2 Testidéer Genom analysen av krav dokumentationen har testteamet funnit ett antal riskområden som bör prioriteras i testarbetet. Det första området är säkerhet som är av avgörande betydelse då HEP tillhandahåller känsliga uppgifter om privatpersoners ekonomiskalivssituation. Det andra området vi vill prioritera är beräkningar då hela systemet bygger på kalkyler och beräkningar där eventuella fel eller feltolkningar kan ha stor negativ effekt. Det tredje prioriteringsområdet är integrationer mellan moduler och deras påverkan på varandra. För att visa exempel på vilka testidéer som kommer användas följer en genomgång per riskområde nedan Säkerhet Angående säkerhet är det viktigt att ingen känslig information finns tillgänglig för obehöriga. Exempelvis ska privata delar hållas stängda för obehöriga och handläggare ska endast se information de har rätt till. Inloggningen ska vara säker och inte tillåta obegränsat antal försök. Att undersöka inmatnings alternativ vid inloggning är även det något som bör testas. Andra delar rörande lösenordet är giltighetstid, minst antal tecken och krav på variation av exempelvis versaler, text och siffror. Inaktiva användare bör bli utloggade efter en viss tid, exempelvis 15min, för att förhindra att obehöriga kommer in i systemet. En begränsning som förhindrar att samma inloggning används samtidigt på flera datorer. 3

7 3.2.2 Beräkningar Beräkningar kommer behöva testas noggrant för att förhindra fel. Ett alternativ är att göra samma beräkningar i både gamla och nya HEP för att se på skillnader. Scenarion för att testa olika typer av beräkningar. Undersöka inmatningsalternativ, begränsningar och felaktig inmatning för att se så varningar och förklaringar fungerar som önskat. Minskar även risken för fel. Förklaringar till beräkningar och formler kan vara en viktig del för att minska risken för fel, kanske genom exempel för inmatning och resultat. En testidé kan då vara att göra beräkningar genom dokumentation och hjälpavsnitt. Resultat och sammanställningar bör gå att härleda för att kunna ändra, tolka och förstå hur de uppstår. Testa att ändra och uppdatera information för att se så sammanställningar och tabeller uppdateras. Exempel på testidéer är funktionerna för förhandsgranskning, utskrifter, export och att öppna exporterade filer. Statistik ska gå att läsa och förstå och inte vara missvisande. Tydliga rubriker och sammanställnings rader är därför av största vikt. I de fall det går att göra diagram ska skalor vara relevanta och rätt dimensionerande Integrationer Då HEP är uppbyggt av ett antal olika moduler som ska kunna interagera med varandra är det område som kräver mycket test. Bland de testidéer som kommer användas finns att undersöka avbrott mellan modulerna. Beroenden mellan moduler och hur olika förhållanden påverkar dem exempelvis genom att manipulera för att orsaka vissa lägen. Att följa data eller värden mellan modulerna för att se på förändringar kan vara ett led i att finna eventuella problem. Även att värden är kopplade till rätt plats är av största vikt och något som måste undersökas noggrant. Ett annat område är hur uppdateringar av tillexempel av skattesatser följer med mellan moduler och att det fungerar som avsett. Att diskutera potentiella risker med utvecklare för att få tips om riskfaktorer är något som kan leda till fler testidéer på området. 3.3 Projektrisker Risker med projektet är att testteamet behöver kalla in en expert på säkerhetsområdet då HEP behandlar känslig information om privatpersoner och deras ekonomiska situation. Detta för att garantera att ingen känslig information läcker ut till obehöriga. För att garantera att alla lagar och regler vid hantering av sådana uppgifter följs kan ett behov uppstå av att kunna rådfråga sakkunnig 4

8 inom exempelvis PUL. För att lösa denna bit kan antingen tillgång till expertis hos Konsumentverket eller inkallande av expert lösa eventuella problem. 4. Testprocess Att ha test som en löpande del tillsammans med utvecklingen under hela projektet är av yttersta vikt för att effektivt hitta och rapportera problem när de uppstår. I annat fall riskerar problem att påverka större delar av systemet och bli svårare att finna och åtgärda i och med integrationerna i HEP. 4.1 Testmiljö Målet med testmiljön är att den ska vara så lik verkligheten ute hos användarna som möjligt. Att kunna köra med rätt operativsystem, browser versioner och så hårdvarulika förhållanden som möjligt blir därför avgörande för att garantera användarupplevelserna av systemet. Att få tillgång till användardata ifrån Konsumentverket skulle möjliggöra en så driftslik miljö som möjligt. 4.2 Testverktyg För att bredda och fördjupa testning kommer ett antal verktyg att användas som hjälpmedel. För att hålla nere kostnaderna är målet att främst använda open source(os) verktyg. Modellering X-mind(OS) Säkerhetstester - Zed attack proxy(os) Prestandatester - JMeter(OS) Buggrapportering - Redmine(OS) eller Reqtest Då produkten inte är färdigutvecklad kan listan behöva kompletteras eller ändras i ett senare skede. Gäller kompletteringen ett testverktyg som kostar pengar kommer Konsumentverket att informeras och vara avgörande beslutsfattare om inköp baserat på rekommendationer av testteamet. 4.3 Tidsåtgång Tidsåtgången för testprojektet bör anpassas efter utvecklingstiden av HEP och ske jämsides med systemutvecklingen. Anledningen till denna bedömning är att fel är lättast att hitta och fixa när de uppstår. Skulle testningen ske i efterhand kommer en längre tid att behöva läggas på att identifiera eventuella problem. 5. Testresultat och leverabler Leverablerna ifrån testarbetet kommer att presenteras genom skriftliga statusrapporter, buggrapporter, diagram och en slutrapport med en kvalitets- och riskbedömning över HEP. Rapporteringen kommer att ske löpande och jämt fördelat över testprojektets tid. Rapportering kommer att ske till utvecklare och de intressenter hos Konsumentverket som vill ta del av informationen. 5

9 5.1 Kriterier för godkänt/icke godkänt test Ett test anses vara godkänt om det stämmer överrens med kravdokumenten ifrån Konsumentverket. Om ett test inte uppfyller godkänt kriterierna enligt kravdokumentationen bedöms testet som icke godkänt. 6

10 6. Bilagor En förteckning över de modeller som använts i testarbetet för att visualisera HEP och som underlag till nya tankar och testidéer. 6.1 Bilaga 1: SFDPOT En modell över HEP och dess funktionalitet vilket även återfinns i sin helhet på: 7

11 6.2 Bilaga 1: Flödesschema En modell över arbetsflödet i HEP. 8