Något man kontinuerligt stöter på inom DevOps är behovet av att införa nya testverktyg. Men ibland handlar det inte om ett behov utan snarare att man vill ha ett verktyg som man är van vid istället för att använda de verktyg man redan har. Det behöver inte betyda att man inte ska byta verktyg men då bör det nya verktyget tillföra något man tidigare saknat, vara mer kostnadseffektivt eller ha andra fördelar.
Innan man inför ett verktyg behöver man även ta sig en funderare på hur införandet kommer att påverka organisationen och arbetsprocesserna. Både här och nu men även på sikt. Genom åren har du säkert använt en rad olika testverktyg - bra och dåliga. Dock finns det ingen generell regel som säger om man ska välja ett kommersiellt verktyg eller ett öppet källkods-verktyg. Var och en av dessa kommer nämligen med både fördelar och nackdelar.
Så i det här inlägget går jag igenom vad som kan vara bra att tänka på inför valet av testverktyg, speciellt om du tidigare inte har använt öppna källkods-verktyg i ditt QA arbete.
Kommersiella verktyg utvecklas för användaren och i regel så är de enklare att komma i gång med än verktyg som bygger på öppen källkod. Verktyg med öppen källkod har oftast utvecklats av duktiga kodare men man har ibland glömt bort att användarna inte nödvändigtvis är lika duktiga som dem själva. Tänk på vilka i organisationen som kommer att använda verktyget. Oftast kommer man behöva lite mera tid inledningsvis för att sätta sig in i hur ett verktyg som bygger på öppen källkod fungerar.
Ett argument som ofta används mot öppen källkod är att det inte finns någon organiserad support för verktyget och därmed ska man undvika dessa. Detta stämmer säkert för en del verktyg men i verkligheten så är det snarare det omvända. Verktygen supportas ofta av utvecklare som också själva använder verktyget, så sannolikheten att ett fel som upptäcks också rättas är nog minst lika stor som för ett kommersiellt verktyg. Skillnaden är dock att då du betalar för supporten med ett kommersiellt verktyg har du en specifik organisation som du kan vända dig till. Tyvärr garanterar detta inte att felet rättas så fort som möjligt.
Det beror helt på organisationen bakom verktyget om du får den hjälp du behöver. Det är därför ingen klar nackdel respektive fördel att välja mellan kommersiella eller öppen källkods-verktyg. Däremot behöver du ha i åtanke hur er organisation ser ut, vad du förväntar dig för hjälp och hur fort du förväntar dig hjälpen.
Dokumentation av öppen källkod brukar tyvärr ofta vara bristfällig. Därför är det en klar fördel att välja ett kommersiellt verktyg, dock brukar dokumentationen som då finns vara relativt generell. Till exempel när man lärt sig grundfunktionerna och istället behöver mer specifika instruktioner om hur man använder verktyget i speciella fall så saknas den dokumentationen.
Den mer detaljerade dokumentation som man vanligtvis behöver saknas oftast när det gäller både kommersiella och öppna källkods-lösningar. Men ett aktivt användarforum där man kan få hjälp av andra är oftare mera värt än verktygets dokumentation.
Man brukar höra att öppen källkod inte kostar något. Det stämmer säkert men då glömmer man bort att det kan vara knepigare för de som inte är utvecklare att sätta sig in i hur verktyget fungerar. Det kan också krävas en utvecklingsinsats för att anpassa delar av verktyget till hur man önskar att det ska fungera, och det är ju inte gratis.
Ett kommersiellt verktyg som kanske är enklare att komma i gång med är inte heller gratis. Initialt ingår vanligtvis en årskostnad för support och ett begränsat antal licenser. Behöver man specialanpassningar är det inte säkert att dessa kommer att införas - och de kostar definitivt. Det man verkligen ska se upp med är licenskostnaderna som kan tillkomma då man integrerar verktyget i sina CI/CD pipelines. Då ökar antalet licenser med antalet parallella CI/CD processer. Detta glömmer man allt för ofta bort.
Så tänk på de dolda kostnaderna som tillkommer redan innan du köper verktyget.
Det är väldigt få verktyg som är helt fristående idag och i princip behöver man integrera alla typer av testverktyg med något annat verktyg. Därför är det viktigt att ha koll på sina processer och veta vilka integrationer som behövs. Överlag är det enklare att integrera öppen källkods verktyg. Dessa innehåller ofta olika integrationsmöjligheter som vid behov kan special anpassas. Kommersiella verktyg stöder ofta anpassningar mot andra större verktyg men har sämre support för anpassning mot äldre system. Då behöver man ofta själv anpassa detta med konverterare som vanligtvis kommer med en otrevlig underhållskostnad.
En sak som på senare tid dykt upp mer och mer är att verktygen integreras med egna dashboards och pipelines som låser in användaren mer och mer mot bara ett verktyg. Inom kvalitetssäkring används ofta många olika verktyg och för tydligheten och enkelhetens skull vill man ha en CI/CD process som producerar ett resultat för hela testet. Inte olika pipelines och rapporter.
Eftersom verktyg som använder egna pipelines och dashbords är svårare att integrera i befintliga processer och rutiner bör man undvika dessa, eller förbereda sig på en kostsam integration och ett kostsamt underhåll.
Det finns ingen enkel ekvation i valet av kommersiell lösning eller öppen källkod för testverktyg utan olika för och nackdelar ställs mot varandra. Om ett verktyg är enkelt att komma igång med inledningsvis kan det vara komplicerat att integrera i verksamheten. Det billiga kan också lätt övergå i höga kostnader när man är inlåst med ett svår integrerat verktyg.
Därför är det viktigt att tänka på helheten och enkelheten utifrån många olika aspekter då vi gör vårt val och rekommenderar ett visst verktyg både för användaren och verksamheten.