Lederskab i test: Testværktøjer

Softwareteams, der selv organiserer deres arbejde, bruger flere forskellige værktøjer end nogensinde før. I et typisk softwareteam kan der være tyve eller endda tredive værktøjer i brug. For at hjælpe dig med at navigere i alt dette gennemgår vi i denne artikel:

• Værktøjer til test
• Værktøjsarkitektur
• Teststyring
• Testdesign
• Proprietære værktøjer eller open source?
• En øvelse i værktøjsudvælgelse

Lad os først se på de vigtigste typer værktøjer, du kommer til at bruge til test.

Værktøjer til test

Det er praktisk at inddele de værktøjer, der er relevante for test, i tre typer:

• Samarbejdsværktøjer: Disse understøtter indsamling af idéer og krav, kommunikation på tværs af teamet med en vis integration til automatiserede processer og sommetider bots.
• Testværktøjer: Et bredt spektrum af værktøjer, der understøtter testdatastyring, testdesign, enhedstestframeworks, funktionel testudførelse, ydelses- og belastningstest, statisk test, testdesign, styring af testprocessen, testcases, testlogning og rapportering.
• DevOps- eller infrastrukturstyringsværktøjer: Disse værktøjer understøtter styring af miljøer og platforme, udrulning ved hjælp af infrastruktur som kode og containerteknologier samt logning, overvågning og analyse i produktion.

The Tools Knowledge Base er et onlineregister over værktøjer, som adskiller sig fra de fleste onlineregistre ved, at registret dækker samarbejde, test og DevOps. Der findes over 1700 værktøjer inden for disse tre områder. Værktøjernes websider er indekserede og kan søges frem.

Websitet samler og indekserer også over 300 bloggere, og over 52.000 blogs er ligeledes indekserede og søgbare. Vi har angivet URL'er til de vigtigste værktøjskategorier samt genveje til søgninger i disse kategorier på bloggene.

Der findes over 1700 værktøjer, der understøtter samarbejde, test og DevOps.

Senere i denne artikel ser vi på de største udfordringer, der påvirker og understøtter teststyring.

Værktøjsarkitektur

I grafikken nedenfor har vi identificeret de forskellige typer værktøjer, som de fleste moderne softwareteams bruger. Vi har adskilt de værktøjer, der typisk anvendes i udviklings-, test- og produktionsmiljøer. 

Disse værktøjer understøttes af infrastrukturværktøjer, der leverer platforme, virtuelle maskiner og containere til hosting af miljøer, samt værktøjer, der udfører automatiserede udrulninger. De værktøjer, der bruges til at styre udrulninger og udgivelser, kaldes værktøjer til orkestrering af udgivelser og pipelines. Kommunikation internt i teamet og med mange af de automatiserede processer styres af samarbejds- eller ChatOps-værktøjer.

Selvom bevægelsen mod DevOps driver udviklingen og indførelsen af værktøjer, der understøtter kontinuerlig udvikling, er næsten alle disse værktøjer nyttige for alle softwareudviklings- eller driftsteams.

Du behøver ikke have en DevOps-kultur for at bruge “DevOps”-værktøjer.

Teststyring

Teststyringsværktøjer er en nødvendighed i alle projekter af en vis størrelse. Agile projekter tager normalt et værktøj til hændelseshåndtering i brug og anvender, når det gælder test, i nogen grad brugerhistorier og scenarier til at holde styr på vigtige eksempler på alle eller nogle af testene. Teststyringsværktøjer varierer i omfang fra meget simple løsninger som Microsoft Excel til omfattende produkter til styring af applikationslivscyklus (ALM).

Generelt dækker teststyringsværktøjer flere områder:

Model for testdækning: De fleste teststyringsværktøjer giver dig mulighed for at definere et sæt krav, som testcases og/eller kontroller i test kan knyttes til. Disse krav kan nogle gange være hierarkiske for at afspejle indholdsfortegnelsen i et dokument. I stigende grad kan andre modeller, f.eks. brugsscenarier eller arbejdsgange for forretningsprocesser, også registreres. Rapporter om dækning af testplaner og testudførelse er normalt tilgængelige.

Håndtering af testcases: Testcases og deres indhold kan håndteres, så der oprettes en dokumenteret registrering af testene. Indholdet i testcases kan være udarbejdet før testningen eller fungere som registrering af test, der er blevet udført. Testcases kan være i frit tekstformat eller struktureret i trin med forventede resultater. Det er almindeligt at importere dokumenter og billeder, der gemmes sammen med test eller trin.

Planlægning af testudførelse: Test kan struktureres i et hierarki eller forsynes med tags for at skabe en mere dynamisk struktur. Medlemmer af testteamet kan få tildelt test. Planlagte testvarigheder kan bruges til at offentliggøre en synkroniseret tidsplan for test, der skal køres på tværs af teamet. Delmængder af test kan vælges for at opnå dækning af krav, afprøve udvalgte funktioner og køre regressionssæt igen. Test, der er registreret som endnu ikke kørt, blokeret, fejlet eller med en anden status, kan også vælges til udførelse.

Testudførelse og logning: Efterhånden som teamet kører testene, registreres testenes status. For alle udførte test identificeres testeren, og dato/tidspunkt samt varighed noteres. Beståede test kan tildeles en enkel status som bestået. Ved fejlede, blokerede eller afvigende testresultater kan der tilknyttes skærmbilleder, testresultater og en hændelsesrapport. Mange værktøjer har integrationer til testudførelsesværktøjer, som håndterer og kører test, logger resultater og endda opretter kladder til hændelsesrapporter.

Hændelseshåndtering: Testfejl logges i udførelsesloggen. Disse kræver normalt yderligere undersøgelse med fejlsøgning og rettelse, hvis fejlen skyldes en fejl. Fejl, der kræver undersøgelse, registreres normalt ved hjælp af hændelses- eller observationsrapporter eller fejlrapporter. Hændelsesrapporter kan indeholde store mængder understøttende oplysninger. Hændelser tildeles normalt en type, et objekt under test, en prioritet og en alvorlighedsgrad. Nogle virksomheder logger enorme mængder oplysninger og matcher dem med en sofistikeret proces til hændelseshåndtering.

Rapportering: Rapporter og analyser af data fra alle ovenstående funktioner efter behov. Udvalget af rapporter varierer fra planlagt kontra faktisk testdækning og status for hændelsesrapporter til sporing af udestående undersøgelses-, rettelses- og gentestarbejde samt analyser af tid til rettelse for forskellige fejltyper efter funktion, alvorlighedsgrad, hastende karakter osv.

Det mest populære teststyringsværktøj på planeten er stadig Microsoft Excel.

Testdesign

Testdesign er baseret på modeller. For system- og accepttestere er typiske modeller kravspecifikationer, brugsscenarier, flowdiagrammer eller svømmebanediagrammer. Mere tekniske modeller som tilstandsmodeller, samarbejdsdiagrammer, sekvensdiagrammer osv. giver også et solidt grundlag for testdesign.

I mange projekter bruges modeller til at registrere krav eller design på højt niveau. Når de gøres tilgængelige for testere, kan de bruges til at spore stier og udvælge dækningspunkter direkte fra modellen. Hvis sådanne modeller ikke er tilgængelige, er det ofte nyttigt for testteamet eksempelvis at registrere procesflowdiagrammer eller svømmebanediagrammer. De hjælper testere med at føre mere meningsfulde drøftelser med interessenter, især når det gælder tilgangen til testdækning.

På området for proprietære løsninger dukker der værktøjer op, som gør det muligt at registrere modeller som flowdiagrammer og bruge dem til at generere testcases ved at spore stier i henhold til et bestemt dækningsmål, f.eks. alle links, alle processer, alle beslutningsudfald, alle par eller alle stier. Disse værktøjer kan forbindes med værktøjer til håndtering og generering af testdata for at generere kombinationer af testdata til brug ved manuelle eller automatiserede test.

Der findes også værktøjer, som gør det muligt at udføre modellering i testudførelsesværktøjer. Som eksempel kan disse værktøjer give testudvikleren mulighed for at registrere alle felterne på en webside, oprette links for at “forbinde” felterne og oprette en navigationsmodel for siden – alt sammen i et grafisk format.

Modellen bruges derefter til at oprette navigationsstier og skabe en testsuite, der opfylder bestemte kriterier for testdækning – ligesom i modelleringsværktøjerne ovenfor. Disse udførelsesværktøjer kan oprette automatiserede teststier ved hjælp af udvalgte kriterier eller generere dem tilfældigt og kan også rapportere testdækning i forhold til disse modeller.

Dette område er dynamisk i øjeblikket – hold øje med modelleringsværktøjer, der understøtter testdesign og testgenerering, samt udførelsesværktøjer, der understøtter modellering af systemet under test og automatiseret udvælgelse og rapportering af teststier.

Proprietær eller åben kildekode?

I løbet af de seneste tyve år har brugen af gratis softwareprodukter med åben kildekode (FOSS), især til drift af infrastruktur, været udbredt. Omkostningerne ved licenser til operativsystemer og tilknyttet webserversoftware fra Microsoft samt den generelle opfattelse af, at Linux/Unix er mere pålideligt og sikkert end Windows, betyder, at Linux/Unix for mange miljøer er det foretrukne operativsystem til servere. 

Selvom artiklen diskuterer fordele og ulemper ved værktøjer med åben kildekode og proprietære værktøjer, kan vores omfattende guide til teststyringsværktøjer specifikt til Jira hjælpe dig med at træffe en velinformeret beslutning, hvis du specifikt leder efter løsninger, der integrerer godt med Jira.

De to tabeller nedenfor (opdateres dagligt på w3techs.com) viser den relative popularitet af operativsystemer og webserverprodukter. Omkring 85 % af webstederne kører de bedst kendte webserverprodukter med åben kildekode, Apache og Nginx.

Populariteten af disse FOSS-infrastrukturprodukter beviser, at software med åben kildekode kan være lige så pålideligt som, eller mere pålideligt end, proprietære produkter.

For et softwareteam, der har brug for tyve eller tredive softwareværktøjer til at understøtte deres aktiviteter, findes der pålidelige og funktionelle FOSS- og proprietære værktøjer til alle opgaver. Hvordan vælger man mellem et proprietært produkt og et FOSS-produkt?

Tabellen nedenfor opsummerer nogle af de overvejelser, du kan gøre dig, når du vælger værktøjstype.

FOSS-produkter kan være billigere at anskaffe, men andre omkostninger og ansvarsområder kan være betydelige. Den afgørende faktor mellem de to er normalt en blanding af jeres kultur, risikovillighed og tekniske kompetencer.

Når man køber proprietære produkter og supportaftaler, er risiciene forbundet med inkompatibilitet (med andre produkter), pålidelighed, brugervenlighed og opmærksom teknisk support generelt lave, selvom de undertiden er dyre.

Med FOSS-produkter skal man normalt foretage langt mere omfattende undersøgelser, før man beslutter sig for at bruge et af dem. Der er trods alt ingen sælger at tale med, og dokumentationen kan være funktionel snarere end informativ. En prøveperiode er naturligvis nem at oprette, og man kan tage så mange værktøjer i brug, som man ønsker, men man bliver nødt til at undersøge værktøjets funktionalitet mere grundigt. 

Dårligere brugervenlighed og inkompatibilitet med dine eksisterende værktøjer kan give problemer, så du kan blive nødt til at skrive integrationssoftware eller plugins samt værktøjer til rapportering eller import/eksport af data. 

Derudover skal du oplære dig selv og dit team, så de kommer op i fart, og normalt selv stå for softwaresupporten. Dit team vil dog have et mere indgående kendskab til værktøjets funktion og i høj grad kunne yde support til sig selv.

Et FOSS-værktøj kan hjælpe dig med at få erfaring med en ny type værktøj til lave omkostninger. Med den erfaring vil du være bedre rustet til at vælge et proprietært værktøj på lang sigt.

En øvelse i valg af værktøj

Hvis du leder efter et teststyringsværktøj til at understøtte dit nuværende eller et velkendt, nyligt projekt og program. Med udgangspunkt i funktionsområderne i ovenstående gennemgang af teststyringsværktøjer skal du lave en liste med 15-20 funktioner, der enten er:

• Obligatoriske
• Ønskværdige

Dette kan omfatte funktionelle muligheder, integrationer, fokus på brugervenlighed, support eller en stor brugerbase eller onlinefora/FAQ'er. Hvis du allerede har et værktøj på plads, skal du ikke vælge det.

Brug teksten fra dine krav til at søge i Tools Knowledge Base for at finde tre værktøjer (herunder et proprietært produkt og et FOSS-produkt), der ser ud til at passe til dine krav. Brug værktøjernes funktionsbeskrivelser til at oprette en funktionssammenligningstabel over de tre produkter. Tilføj en fjerde kolonne for det værktøj, du rent faktisk bruger – til sammenligning.

• Hvordan klarer værktøjerne sig med hensyn til funktioner?
• Hvilke funktioner mangler FOSS-værktøjet eller FOSS-værktøjerne sammenlignet med de proprietære værktøjer?
• Hvor mange værktøjer findes der, som i store træk opfylder dine krav?
• Hvor lang tid tror du, du ville have brug for til at undersøge værktøjer for at udarbejde en kortliste med for eksempel tre?

Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus Ledelse inden for test – det kan varmt anbefales til dem, der ønsker at gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER til at få $60 i rabat på den fulde kursuspris!

Lær af andre testere ved at lytte til vores podcasts eller læse vores blogs. Her er et, som vi tror, du kan lære en masse af: SÅDAN GJORDE TESTFÆRDIGHEDER MIG TIL EN BEDRE AUTOMATISERINGSUDVIKLER