Ledarskap inom testning: Testverktyg

• Samarbetsverktyg: dessa stöder insamling av idéer och krav, kommunikation inom teamet med viss integration med automatiserade processer och ibland robotar.
• Testverktyg: ett stort spektrum av verktyg som stöder hantering av testdata, testdesign, ramverk för enhetstestning, körning av funktionstester, prestanda- och belastningstestning, statisk testning, testdesign, hantering av testprocessen, testfall, testloggning och rapportering.
• DevOps- eller infrastrukturhanteringsverktyg: dessa verktyg stöder hantering av miljöer och plattformar, driftsättning med hjälp av infrastruktur som kod och containerteknik samt loggning, övervakning och analys i produktion.

The Tools Knowledge Base är ett onlineregister för verktyg som skiljer sig från de flesta onlineregister genom att registrets omfattning sträcker sig över samarbete, testning och DevOps. Det finns över 1 700 verktyg inom dessa tre områden. Verktygens webbsidor är indexerade och sökbara.

Webbplatsen samlar och indexerar även över 300 bloggare, och över 52 000 bloggar är också indexerade och sökbara. Vi har tillhandahållit webbadresser till de viktigaste verktygskategorierna samt genvägar för sökningar i dessa kategorier på bloggarna.

Det finns över 1 700 verktyg som stöder samarbete, testning och DevOps.

Vi tittar senare i den här artikeln på de största frågorna som påverkar och stöder testhantering.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Verktygsarkitektur

I bilden nedan har vi identifierat de olika typer av verktyg som de flesta moderna programvaruteam använder. Vi har separerat verktyg som vanligtvis används i utvecklings-, test- och produktionsmiljöer. 

Dessa verktyg bygger på infrastruktur verktyg som tillhandahåller plattformar, virtuella maskiner och containrar för att vara värd för miljöer samt verktyg som utför automatiserade driftsättningar. Verktygen som används för att hantera driftsättningar och releaser kallas verktyg för release- och pipelineorkestrering. Kommunikation inom teamet, liksom med många av de automatiserade processerna, hanteras av samarbets- eller ChatOps-verktyg.

Även om övergången till DevOps driver utvecklingen och införandet av verktyg som stöder kontinuerlig utveckling är nästan alla dessa verktyg användbara för alla utvecklings- eller driftteam inom programvara.

Du behöver inte ha en DevOps-kultur för att använda ”DevOps”-verktyg.

Testhantering

Testhanteringsverktyg är ett måste i alla projekt av större omfattning. Agila projekt använder vanligtvis ett verktyg för incidenthantering och förlitar sig när det gäller tester i viss utsträckning på användningen av verksamhetsberättelser och scenarier för att spåra viktiga exempel på, om inte alla, tester. Testhanteringsverktyg varierar i omfattning från mycket enkla lösningar, exempelvis Microsoft Excel, till omfattande produkter för hantering av applikationers livscykel (ALM).

Generellt omfattar testhanteringsverktyg flera områden:

Modell för testtäckning: De flesta testhanteringsverktyg låter dig definiera en uppsättning krav mot vilka testfall och/eller kontroller i tester kan mappas. Dessa krav kan ibland vara hierarkiska för att återspegla en dokuments innehållsförteckning. I allt högre grad kan även andra modeller, exempelvis användningsfall eller flöden för verksamhetsprocesser, fångas upp. Rapporter om täckning för testplanering och testkörning är vanligtvis tillgängliga.

Testfallshantering: Testfall och deras innehåll kan hanteras för att tillhandahålla ett dokumenterat register över tester. Testfallens innehåll kan förberedas före testningen eller fungera som dokumentation över tester som har genomförts. Testfall kan vara i fritt textformat eller strukturerade i steg med förväntade resultat. Det är vanligt att importera dokument och bilder som lagras tillsammans med tester eller steg.

Planering av testkörning: Tester kan struktureras i en hierarki eller taggas för att ge en mer dynamisk struktur. Medlemmar i testteamet kan tilldelas tester. Planerade testlängder kan användas för att publicera ett synkroniserat schema över tester som ska köras av teamet. Delmängder av tester kan väljas för att uppnå kravtäckning, testa utvalda funktioner och köra om regressionsuppsättningar. Tester som har loggats som ännu inte körda, blockerade, misslyckade eller med någon annan status kan också väljas för körning.

Testkörning och loggning: När tester körs av teamet registreras testernas status. För alla körda tester anges testaren och datum/tid samt varaktighet noteras. Godkända tester kan tilldelas en enkel godkänd-status. Misslyckade, blockerade eller avvikande testresultat kan förses med skärmbilder, tilldelade testresultat och en tilldelad incidentrapport. Många verktyg erbjuder kopplingar till verktyg för testkörning som hanterar och kör tester, loggar resultat och till och med skapar utkast till incidentrapporter.

Incidenthantering: Testmisslyckanden loggas i körningsloggen. Dessa kräver vanligtvis ytterligare utredning, med felsökning och åtgärd när ett fel orsakats av en bugg. Misslyckanden som kräver utredning dokumenteras vanligtvis med hjälp av incident- eller observationsrapporter eller buggrapporter. Incidentrapporter kan innehålla en stor mängd stödjande information. Incidenter tilldelas vanligtvis en typ, ett testobjekt, en prioritet och en allvarlighetsgrad. Vissa företag loggar enorma mängder information och matchar den mot en avancerad incidenthanteringsprocess.

Rapportering: Rapporter och analyser av data från alla ovanstående funktioner, efter behov. Utbudet av rapporter varierar från planerad jämfört med faktisk testtäckning och incidentrapportstatus för att följa upp pågående utrednings-, åtgärds- och omtestningsarbete, till analyser av tiden det tar att åtgärda olika typer av fel, per funktion, allvarlighetsgrad och brådskandegrad, och så vidare.

Det mest populära testhanteringsverktyget på planeten är fortfarande Microsoft Excel.

Testdesign

Testdesign baseras på modeller. När det gäller system- och acceptanstestare är typiska modeller kravdokument, användningsfall, flödesscheman eller simbanediagram. Mer tekniska modeller, såsom tillståndsmodeller, samarbetsdiagram, sekvensdiagram och så vidare, utgör också en stabil grund för testdesign.

I många projekt används modeller för att fånga upp krav eller övergripande design. När de görs tillgängliga för testare kan de användas för att spåra vägar och direkt från modellen välja ut täckningsobjekt. Om sådana modeller inte finns tillgängliga är det ofta användbart för testteamet att exempelvis dokumentera processflödesscheman eller simbanediagram. Dessa hjälper testare att ha mer meningsfulla diskussioner med intressenter, särskilt när det gäller angreppssättet för täckning.

På den proprietära marknaden växer det fram verktyg som gör det möjligt att fånga upp modeller som flödesscheman och använda dem för att generera testfall genom att spåra vägar enligt något täckningsmål, exempelvis alla länkar, alla processer, alla beslutsutfall, alla par och alla vägar. Dessa verktyg kan kopplas samman med verktyg för hantering och generering av testdata för att generera kombinationer av testdata som kan användas med manuella eller automatiserade tester.

Det finns även verktyg som gör det möjligt att utföra modellering i verktyg för testkörning. Som exempel kan dessa verktyg låta testutvecklaren fånga upp alla fält på en webbsida, skapa länkar för att ”koppla ihop” fälten och skapa en navigeringsmodell för sidan – allt i grafiskt format.

Modellen används sedan för att skapa navigeringsvägar och skapa en uppsättning tester som uppfyller vissa täckningskriterier – precis som modelleringsverktygen ovan. Dessa körningsverktyg kan skapa automatiserade testvägar med hjälp av valda kriterier eller generera dem slumpmässigt, och även rapportera täckning mot dessa modeller.

Detta är ett dynamiskt område just nu – håll utkik efter modelleringsverktyg som stöder testdesign och testgenerering samt körningsverktyg som stöder modellering av systemet som testas och automatiserat urval och rapportering av testvägar.

More Articles

• Så integrerar du DevOps-verktyg för AWS
• 9 bästa konferenserna om digital transformation att delta i 2026–2027
• Så använder du DevOps-mätvärden för att skala upp ditt företag

Proprietärt eller öppen källkod?

Under de senaste tjugo åren har användningen av fria och öppna programvaruprodukter (FOSS), särskilt för att köra infrastruktur, varit utbredd. Kostnaden för licenser för operativsystem och tillhörande webbserverprogramvara från Microsoft, samt den allmänna uppfattningen att Linux/Unix är mer tillförlitligt och säkert än Windows, innebär att Linux/Unix är det operativsystem som föredras för servrar i många miljöer. 

Även om artikeln diskuterar för- och nackdelarna med verktyg med öppen källkod och proprietära verktyg, kan vår omfattande guide om testhanteringsverktyg specifikt för Jira hjälpa dig att fatta ett välgrundat beslut om du specifikt letar efter lösningar som integreras väl med Jira.

De två tabellerna nedan (uppdateras dagligen på w3techs.com) visar den relativa populariteten hos operativsystem och webbserverprodukter. Omkring 85 % av webbplatserna kör de mest kända webbserverprodukterna med öppen källkod, Apache och Nginx.

Populariteten hos dessa FOSS-infrastrukturprodukter bevisar att programvara med öppen källkod kan vara lika, om inte mer, tillförlitlig än proprietära produkter.

För ett programvaruteam som behöver tjugo eller trettio programvaruverktyg för att stödja sin verksamhet finns det tillförlitliga och funktionella FOSS-verktyg och proprietära verktyg för varje uppgift. Hur väljer man mellan en proprietär produkt och en FOSS-produkt?

Tabellen nedan sammanfattar några av de överväganden du kan göra när du väljer verktygstyp.

	Proprietärt	FOSS
Tillgänglighet	Verktyg finns tillgängliga för alla områden.	Vissa områden, särskilt utvecklings- och infrastrukturverktyg, har bättre stöd än andra.
Inköpskostnad	Ofta dyrt, särskilt företagsprodukter.	Gratis, eller licens för användning i gemenskapen utan kostnad. Kommersiella licenser kan finnas för företags- eller värdbaserade versioner.
Dokumentation	Vanligtvis mycket bra.	Varierar. Ibland utmärkt, ibland obefintlig och allt däremellan. Ofta skriven av programmerare för programmerare och därför mindre användbar än kommersiell dokumentation.
Teknisk support	Mycket bra, mot en kostnad.	Varierar. Vissa verktygsskapare erbjuder utmärkt support och lägger till och med till funktioner på begäran. Många verktyg har onlineforum – men de kan vara mycket tekniska. Andra verktyg har dåligt stöd.
Tillförlitlighet/kvalitet	Vanligtvis mycket bra.	Varierande. Produkter med många användare, lokaliseringar och stora supportteam brukar vara utmärkta. Vissa verktyg som skrivits av enskilda personer med få bidragsgivare och få användare kan vara instabila.
Funktionsrikedom	Funktionsuppsättningarna följer vanligtvis publicerade produktfärdplaner och är oftast omfattande.	Produkter tenderar att utvecklas utifrån användarnas efterfrågan och storleken på teamet av bidragsgivare. Bidragsgivare tenderar till exempel att lägga till funktioner som de själva behöver, snarare än att utgå från kundundersökningar.
Frekvens för lanseringar/korrigeringar	Större lanseringar sker vanligtvis med flera månaders, ibland flera års, mellanrum. Regelbundna korrigeringsversioner. Varningar och versionsanteckningar brukar vara mycket bra.	Varierar. Större lanseringar av infrastrukturprodukter sker, liksom för proprietära produkter, med längre mellanrum. Mindre och mindre populära produkter lanseras oftare. Lite eller ingen förvarning, bristfälliga versionsanteckningar och ibland förlorad bakåtkompatibilitet.

FOSS-produkter kan vara billigare att skaffa, men andra kostnader och ansvarsområden kan vara betydande. Den avgörande faktorn mellan de två är vanligtvis en blandning av er kultur, er riskbenägenhet och er tekniska förmåga.

När ni köper proprietära produkter och supportavtal är riskerna förknippade med inkompatibilitet (med andra produkter), tillförlitlighet, användarvänlighet och uppmärksam teknisk support i allmänhet små, även om kostnaden ibland är hög.

Med FOSS-produkter måste ni vanligtvis göra mycket mer omfattande efterforskningar innan ni bestämmer er för att använda en. Det finns trots allt ingen försäljare att prata med, och dokumentationen kan vara funktionell snarare än informativ. Naturligtvis är det enkelt att konfigurera en testperiod och ni kan ta på er så många verktyg som ni vill, men ni måste göra en mer fullständig undersökning av verktygets kapacitet. 

Sämre användbarhet och inkompatibilitet med era befintliga verktyg kan skapa problem, så ni kan behöva skriva programvara eller insticksprogram för integration samt verktyg för rapportering eller import/export av data. 

Ni måste också utbilda er själva och teamet för att få dem uppdaterade, och vanligtvis sköta er egen programvarusupport. Teamet kommer dock att ha en mer ingående kunskap om hur verktyget fungerar och i stor utsträckning kunna ge support åt sig självt.

Ett FOSS-verktyg kan hjälpa dig att skaffa erfarenhet av en ny typ av verktyg till en låg kostnad. Med den erfarenheten har du bättre förutsättningar att välja ett proprietärt verktyg på lång sikt.

En övning i verktygsval

Om du letar efter ett testhanteringsverktyg som stöd för ditt nuvarande eller ett välbekant, nyligen genomfört projekt och en tillhörande applikation, kan du utifrån funktionsområdena i diskussionen om testhanteringsverktyg ovan skapa en lista med 15–20 funktioner som antingen är:

• Obligatoriska
• Önskvärda

Det kan omfatta funktionella möjligheter, integrationer, fokus på användarvänlighet, support eller en stor användarbas eller forum/FAQ online. Om du redan har ett verktyg på plats ska du inte välja det.

Använd texten i dina krav och sök i kunskapsbasen om verktyg för att hitta tre verktyg (inklusive en proprietär produkt och en FOSS-produkt) som verkar motsvara dina krav. Använd verktygens funktionsbeskrivningar för att skapa en jämförelsetabell över de tre produkterna. Lägg till en fjärde kolumn för verktyget du faktiskt använder – som jämförelse.

• Hur står sig verktygen när det gäller funktioner?
• Vilka funktioner saknar FOSS-verktyget eller FOSS-verktygen jämfört med de proprietära verktygen?
• Hur många verktyg finns det som i stora drag uppfyller dina krav?
• Hur lång tid tror du att du skulle behöva lägga på att undersöka verktyg för att sammanställa en kortlista med, säg, tre verktyg?

Prenumerera på nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kursen Ledarskap inom testning – rekommenderas varmt för dig som vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER och få $60 rabatt på kursens fullständiga pris!

Lär dig av andra testare genom att lyssna på våra poddar eller läsa våra bloggar. Här är en som vi tror att du kommer att lära dig mycket av: SÅ GJORDE TESTKUNSKAPER MIG TILL EN BÄTTRE AUTOMATISERINGSUTVECKLARE