Att beakta inför valet av verktyg för testledning

Testledning är ett vanligt förekommande område i våra systemrelaterade projekt. Vid införande eller förändring av system, applikation eller funktionalitet är en kritisk del i förändringsarbetet att testa förändringen med utgångspunkt i den initiala kravställningen och de förväntningar som finns på den tänkta lösningen. Därmed skapas förutsättningar för att, gärna i tidigt skede, identifiera problem, buggar och felaktigheter som kan adresseras och åtgärdas. Som stöd för testarbetet används ofta olika typer av digitala verktyg som syftar till att på ett systematiskt och effektivt sätt kunna hantera alla ingående delar som testarbetet utgörs av. Dessa verktyg skapar även förutsättningar för en effektiv samverkan mellan testpersoner och utvecklare samt möjliggör visualisering av relationerna som finns mellan exempelvis krav – testfall – testresultat – kod, så kallad spårbarhet.

Spårbarhet i testning

För att kunna uppnå förväntat resultat och för att kunna följa kravuppfyllnad i testarbetets iterativa arbete krävs det att du som testledare har strukturerat upp testarbetet på ett sätt som skapar spårbarhet genom hela testflödet, från krav till testcase, testresultat och avvikelserapportering, både framåt och bakåt i flödet.

Genom spårbarheten skapas möjligheter att enklare kunna överblicka hur relationen

mellan ovan nämnda entiteter ser ut och för att kunna härleda exempelvis en specifik avvikelserapport till ett krav eller vice versa. Det är med andra ord en förutsättning för att i slutändan kunna komma med en positiv rekommendation i testrapporten.

Ju mer omfattande ett testprojekt är ju svårare blir det att underhålla spårbarheten i alla led. Därför används olika typer av digitalt stöd för att dokumentera testarbetet och skapa spårbarhet i testarbetet. I dagens landskap finns en uppsjö av digitala verktyg med varierande funktionalitetsomfattning, fokus och tankesätt kring hur detta bäst hanteras men det är inte alltid självklart vilken riktning man ska röra sig mot gällande valet av verktyg för en organisation. Vi skulle därför vilja lyfta fram några av de viktigare faktorerna som vi upplever i ett sådant val utifrån vår erfarenhet i diverse mjukvaruutvecklingsprojekt som vi medverkat i genom åren.

Tre viktiga frågeställningar inför valet av verktygstyp för testledning

Det är givetvis många olika faktorer och aspekter som ligger till grund för vilken typ av verktyg som är lämpligt för ett specifikt testprojekt. Det första ni som organisation bör besluta om är vilken typ av verktyg ni ser störst behov av. Inför ett sådant beslut vill vi lyfta tre frågeställningar som vi anser är av hög vikt i valet av verktygstyp. Frågeställningarna vi vill lyfta lyder;

• Vilken utvecklingsmetod följer organisationen – Agil eller Vattenfall?

• Hur ser användargruppen av verktyget ut och vilken teknisk kompetens har dessa?

• Vilka typer av tester ska genomföras?

Tester inom agila mjukvaruutvecklingsprojekt där man arbetar i sprintar, utan någon långsiktig leveransplan, ser vi en fördel i att använda ett krav-/utvecklingssystem där tester genomförs i tillhörande testmodul. En av anledningarna till detta är för att på enklast möjliga sätt kunna upprätthålla spårbarheten mellan krav, testfall, avvikelserapporter och kod, i samma verktyg som används av mjukvaruutvecklarna. En annan anledning är ett det blir mer flexibelt och tidseffektivt om alla dessa delar hanteras i ett och samma verktyg. Däremot upplever vi att denna typ av testmoduler ofta är ganska komplexa att använda vilket innebär att det ofta kräver en viss typ av teknisk kompetens eller kräver en mer omfattande utbildning än vad exempelvis en renodlad testapplikation ofta gör. Vid tester där utvecklarna eller andra tekniskt erfarna medarbetare själva utför tester, exempelvis enhetstester eller regressionstester med en nära koppling till koden, ser vi stora fördelar i att använda denna typ av verktyg även för testning. Vid ett motsatt scenario, där testarna inte har någon större erfarenhet av avancerade krav- och utvecklingsverktyg så kan detta istället riskera att bli en tung uppförsbacke för de testande att bara ta sig förbi utbildning-/upplärningsfasen.

För vattenfallsprojekt, där det är tydligt vad som ska levereras i vilken del av projektet och där de planerade testfaserna inte överlappar varandra, ser vi istället en fördel i att använda en renodlad testapplikation som besitter stöd för kravhantering. De renodlade testapplikationerna är ofta mer intuitiva och mer lättanvända, framförallt för medarbetare som inte har någon omfattande teknisk bakgrund. Det innebär att det i regel inte krävs några större tekniska förkunskaper eller kräver några omfattande utbildningar för att genomföra testerna vilket, som tidigare nämnts, annars kan bli ett stort hinder eller en tidstjuv i testprocessen. Därav upplever vi att dessa typer av verktyg fungerar väldigt bra vid bland annat system-/acceptanstester där slutanvändarna själva är med vid genomförandet av testerna, just av denna anledning.

Värt att tänka på är att det i många fall faktiskt går att få det bästa av båda världar genom att kombinera dessa verktyg. Särskilt då det inte är ovanligt att de renodlade testapplikationerna har standard API:er mot flera av de vanliga krav-/utvecklingssystemet. Det innebär att systemen automatiskt kan kommunicera och sprida information mellan varandra. De tester som är bättre lämpade för ett visst system, exempelvis enhets- och regressionstester, kan genomföras i krav-/utvecklingsverktyget medan till exempel system-/acceptanstester kan genomföras i testapplikationen. Genom API:n kan då resultaten automatiskt hämtas från testapplikationen och samlas upp i krav-/utvecklingssystemet så att utvecklarna kan ta vid med arbetet att korrigera koden. Det bör även tilläggas att API-kopplingen inte är kritisk utan arbetet med att registrera avvikelser från testresultatet manuellt också är ett tänkbart alternativ.

Automatiserad testning

Vi vill såklart även lyfta en mer modern metod för testning, nämligen testautomatisering. Testautomatisering möjliggör testning som inte kräver involvering av mänskliga resurser utan sker helt digitalt. För att kunna automatisera tester krävs ofta en speciell typ av verktyg. Dessa verktyg låter dig bygga upp repeterbara testflöden med fördefinierade händelser. Därefter kan sedan jämförelse av resultat mot förväntat utfall och rapportering av framgångsrika och/eller misslyckade resultat ske per automatik. Eftersom tester i regel bör genomföras varje gång koden förändras och automatiserade testflöden kan återanvändas obegränsat antal gånger kan man genom detta både spara tid och pengar. Tester kan genomföras på samma sätt varje gång vilket ökar kvaliteten samtidigt som automatiska testflöden ofta kan köras på ett betydligt mer tidseffektivt sätt än manuell testning. Ett verktyg med stöd för automatisering av tester är därför ännu en viktig aspekt att ta hänsyn till utifrån sina egna behov vid valet av verktyg.

Med detta sagt så vill vi vidare lyfta vikten av att testautomatisering främst bör ses som ett komplement till manuell testning. Automatiserade tester kan med andra ord inte helt och hållet ersätta manuella tester med mänsklig involvering. Anledningen till att vissa typer av tester är bättre lämpade för mänskligt genomförande istället för datorer är just för att datorer är helt styrda till uppbyggda flöden och har inte samma förmåga att uppfatta, tolka, förstå, och fatta beslut som människor. Tester riktade mot exempelvis användarvänlighet och användargränssnitt behöver därför genomföras manuellt för att uppnå bästa möjliga resultat.

Att beakta inför valet av leverantör

När man slutligen kommit fram till vilken typ av verktyg som är bäst lämpat, om inte en kombination av båda typer, så är nästa steg att välja vilken leverantör av den beslutade verktygstypen som man ska vända sig till. Som vi tidigare nämnt finns en hel uppsjö varianter av verktyg, oavsett verktygstyp, med varierad omfattning av funktionalitet, fokus och finesser. Vilken leverantör valet landar på är även det helt baserat på organisationens behov, förutsättningar, preferenser osv. Här bör man beakta frågor som;

• Vilken funktionalitet behöver vi i våra testprojekt?

• Vilka användargrupper kommer att komma i kontakt verktyget?

• Vilken teknisk kompetens har de olika användargrupperna?

• Hur lätt är verktyget att använda?

• Hur stor budget har vi för upphandling av verktyget?

• Osv.

Det är sedan viktigt att skanna av marknaden för att identifiera vilken/vilka leverantörer som har ett verktyg som uppfyller organisationens kriterier. Vi anser att en viktig framgångsfaktor vid alla typer av system-/applikationsupphandlingar är att lägga ned mycket tid och engagemang på kravställningen och utifrån den genomföra någon typ av Proof of Concept (POC) där ett urval av leverantörer får möjlighet att demonstrera hur deras verktyg uppfyller era krav och varför deras verktyg är det bästa valet för just er organisation. Ofta gör vi detta i flera iterationer. I den inledande POC:en brukar vi ofta fokusera på kravuppfyllnad, dv.s. hur uppfyller verktyget kundens krav i praktiken. Vid efterföljande iterationer brukar leverantörerna få komplettera sin demo med vissa specifika delar eller med delar som missats vid tidigare genomgång. Detta itereras sedan ett antal gånger, där någon eller några av leverantörerna faller bort vid varje iteration, tills dess att kunden fått all nödvändig information för att kunna identifiera vilket alternativ som är bäst lämpat för den specifika kunden.

Står er organisation i begrepp att handla upp någon typ av system/applikation men saknar kompetens för en framgångsrik upphandling, testledning eller implementering? Tveka då inte på att höra av er till oss på ERP & Friends så hjälper vi gärna till!

Ni finner all information ni behöver på vår hemsida.