Shift left-trenden inom DevOps medför att man kommer i kontakt med verktyg som man tidigare kanske inte behövt hantera. Som utvecklare använder man testverktyg för API och GUI testning, till exempel SoapUI, JMeter, Postman, Selenium och Cypress. Medan man som testare behöver en bättre förståelse av Npm, Nuget och Maven som bygger ihop koden till en applikation. Ibland kan valet av rätt lösning kännas omöjligt i den djungel av tekniker, programmeringsspråk och verktyg som man idag behöver kunskap om, och som krävs för att säkerställa produktens kvalitet.
Alla har vi nog någon gång tänkt tanken att det verktyg som man använt inte riktigt löste problemet, och funderat över vad man skulle ha gjort annorlunda eller vilket verktyg som skulle löst problemet bättre. Svaret är att metodiskt utvärdera hur bra ett verktyg löser de problem som man ställs inför innan man sätter i gång.
Förstå problemet
Man kan inte nog påpeka vikten av att först verkligen sätta sig in och förstå problemet som man ska lösa. Inledningsvis fokuserar man på att beskriva problemet, avgränsa det och beskriva vilka symptom som problemet orsakar.
För att fokusera på rätt saker ska man alltså inledningsvis inte bry sig om:
Om man fokuserar på dessa riskerar man att man inte löser det verkliga problemet eftersom:
- Man blandar ihop åsikter med problemet
- Lösningen baserar sig på felaktiga grunder/data
- Eventuellt är det fel personer som tillfrågas/tar fram lösningen
Det är en stor risk att man tacklar fel orsak(er) om man tar fram en lösning innan man förstått det verkliga problemet, och slutligen löser man kanske bara en del av problemet eller något helt annat problem.
Kravställning på verktyget
Det slutliga valet av lösning innebär en investering som också ska hålla i framtiden. Efter att man analyserat problemet och förstått vad orsakerna är vet man också vad det är som man ska lösa. Nu är det viktigt att ta fram en kravspecifikation över dem krav som verktyget måste uppfyllas. Kravställningen underlättar utvärderingen och bör vara uppdelat i de krav som verktyget absolut måste stödja och de som kan anses vara bra att ha men som man kan leva utan.
I kravställningen är det även viktigt att tänka på följande:
- Vilka ska använda verktyget
- Hur många samtidiga användare behöver verktyget klara av
- Eventuella licenskostnader
- Hur lättanvänt verktyget är
- Vilka plattformar och operativsystem som måste stödjas
- Att verktyget kan integreras i en CI/CD pipeline
- Vad man mäter i uppföljningen vid/efter implementation av verktyget
Dessa kommer att påverka den tid som införande och senare underhållet av verktyget kommer att ta.
Vid kravställningen bör man även prioritera kraven utifrån en skala från 1 till n och samma prioritet används bara en gång. Alltså finns det bara ett prioritet 1 krav, ett prioritet 2 krav osv. Att en prioritet bara förekommer en gång sparar tid och förenklar också utvärderingen då man senare inte på nytt behöver överväga om ett krav var viktigare än ett annat.
Utvärdering
Sätt verktyget på prov. Verktyget behöver bevisa att det verkligen kan lösa problemet. Välj ett antal realistiska scenarion, som inte är för enkla utan också tar höjd för den komplexitet som en produkt har. Om man väljer för enkla testfall riskerar man att eventuella brister i verktyget inte upptäcks, både när det gäller användning och lösning av problemet. Något som man med all sannolikhet kommer att upptäcka då man inför det. Klarar verktyget att på ett fördelaktigt och smidigt sätt lösa problemet har man något att gå vidare med.
Om man har flera olika verktyg som ska utvärderas är det vanligt att man gör en matris över kraven och en poängbedömning hur väl ett verktyg uppfyller varje krav. Att använda en matris ger en överblick och uppföljning att samtliga krav utvärderats för samtliga verktyg. Men det finns en nackdel med detta och det är att i slutet riskerar man att utvärderingen blir väldigt mekanisk när samma krav testas för det femte verktyget. I stället för en sifferskala är det fördelaktigare att skriva ner det positiva och negativa med hur verktyget löste kravet. Då kommer man även senare bättre ihåg varför ett krav uppfyllts på ett bra sätt. Eller vad det var som gjorde att kravet inte uppfylldes. En ytterligare fördel med en kvalitativ utvärdering baserat på kommentarer istället för en kvantitativ (numerisk) är att man lättare upptäcker om krav som inledningsvis bedömts vara viktigare eller mindre viktiga behöver omprioriteras för att lösa uppgiften på ett effektivt sätt.
Uppföljning
Utan uppföljning vet man inte om problemet löstes och att förbättringar uppnåtts. Följ inledningsvis upp de förbättringar som uppnåtts och att problemet lösts. Fortsätt kontinuerligt med denna uppföljning då framtida förändringar av produkten eventuellt kan leda till att valet av verktyg behövs justeras.
Sammanfattning
Valet av verktyg behöver inte kännas omöjligt när man på ett strukturerat sätt sätter sig in i problemet, gör en kravställningen på verktyget, utvärderar och följer upp. Samma process kan också användas när ett problem löses med en ny eller förändrad process, teknik osv. Två arbetsmetodiker som fungerar på det här sättet är Sex Sigma och Kaizen.
