Det var en gång...

Flera decennier inom QA ger en del dråpliga och insiktsgivande berättelser att förmedla. För min egen skull har jag börjat beskriva en del av dessa här.

Detta är en av dem.

Erfarenhetsrapport Optigroup-uppdraget

Idag avslutar jag mitt uppdrag på Optigroup och har just gått igenom Checklista för avslutande av konsultuppdrag. Här kommer en erfaranhetsrapport.

Uppdraget var väldigt luddigt formulerat. Normalt gillar jag luddigt formulerade uppdrag eftersom det ger mig chansen att frittta tag i det som verkar vara mest givande för kunden. Denna gång var det dock frustrerande.

Optigroup är en paraplyorganisation som äger ett 50-tal olika grossist-bolag med olika brands. Många av dessa brands säljer till offentlig sektor, men också storföretag som t.ex. Volvo. De förser bl.a. typ hälften av Europas alla sjukhus med allt som inte är medicin och har alla produkter och kläder för en massa brandmän, poliser, städbolag och mycket mer. Omsättningen är enorm - liksom komplexiteten i affären.

Uppköpen har gått ganska fort och något drygt halvdussin av dessa organisationer använder samma SAP-lösning i botten (de andra använder egna ehandelslösningar), med SAP Commerce Cloud som frontar.

Mitt uppdrag var i eBusiness-teamet på plats nere i Mölndal (Mölndal motsvarar ungefär Göteborgs Märsta), men teamet var internationellt med en del indier och spritt i världen (Tunisien, Polen, Storbritannien, Växjö och Mölndal).

Jag började med en serie workshopar för att förstå hur man jobbade och vad som förväntades av mig. Svaren var olika från alla. Några ville få igång testautomatisering, några ville att jag skulle se över testsidorna i Confluence.

Testautomatiseringsinförande

Jag började med testautomatiseringen, för tillfället var passande eftersom man samtidigt gick ut med alla servrar i molnet och därmed skapade om alla byggpipelines i Azure.

Vi passade på under ett sprintdemo och frågade brands-ansvariga (key users) om de hade några regressionstester dokumenterade (teamet själva hade haft regressionstester i Zephyr tidigare, men det hade dräpts av licenskostnadsskäl så de fanns inte kvar), och vi fick fram en serie vettiga regressionstestfall.
Dessa testfall prioriterades för implementation baserat på ett antal kriterier.

En kravlista för testautomatiseringsverktyg sammanställdes därefter och en serie verktyg utvärderades mot den (Postman, Karate, SoapUI, Robot Framework, JUnit-lösning, VS Code REST Client, TestComplete, Playwright, Tosca). Vilket slutade med att vi använde Playwright för både API- och GUI-tester. Ovanpå dessa lades en Gherkin-lösning med Cucumber.js och kopplades in i byggpipelines och mot Jira/Confluence.
Implementation av automatiserade testfall genomfördes och i samband med det skapade vi Test Automation Guidelines och annan dokumentation runt automatiseringen.

Quality System

Så småningom lyckade avdelningschefen uttrycka vad hon önskade: Hon ville ha ett Quality System. Jag var tvungen att googla och fråga ChatGPT vad som innefattas av ett Quality System.

Det slutade med att jag utifrån workshopar och intevjuer samt sittande med i teamet tog fram omfattande dokumentation i Word-format och på Concluence. Denna dokumentation innefattade:

Dessa dokument innehåller i sin tur Defect Management Processes för defekter funna av olika grupper av intressenter eller i olika miljöer och efter olika typer av ändringar, QA Activities per Test Level för att rollbaserat strukturera upp arbetet, System classification för att beskriva test-skillnader baserat på kritikalitet och scope (infrastruktur, middleware, applikations-backend, applikations-frontend o.s.v.) och mycket mer.

Förankringsarbetet för dessa dokument skedde i en trappskala baserad på hur mottagliga vi uppfattade att personerna var, med början i påhejarna så att vi fick medhållsmomentum inför en bredare lansering till de mer potentiellt motsträviga.

Det viktiga var att det nu fanns beskrivningar för QA-hanteringen för t.ex. SAP-uppgraderingar, runtime-changes av parametrar, konfigurationsändringar globalt och lokalt, incidenthantering, defektfixande av olika magnitud och typer, implementerade Change Requests samt egna förvaltningsaktiviteter o.s.v.

Test Management Tool

Eftersom den tidigare Zephyr-lösningen hade stängts ner och alla intressentgrupperna av regressionstester (manuella och automatiserade) inte kom åt exekveringen i Azure DevOps gjorde vi en utvärdering av verktyg för testinformationshantering.

Precis som med testautomatiseringen sammanställde vi en kravlista och därefter utvärderade vi ett antal verktyg (Azure DevOps TestPlan, as is, XRay, Tricentis, Zephyr Squad, Zephyr Scale, AIO Test, Behave Pro, AssertThat, Confluence och ReQtest) mot denna.

Valet föll på att ta fram en egen Confluence-sida för testresultat samt införa Behave Pro som verktyg för att duplex-synka Jira-issues acceptanskriterier mot testautomatiseringsrepositoryt i git för att få levande dokumentation.

Övriga take-aways

Parallellt med mitt arbete skedde ett årslång analys inför övergång till SAP S4/Hana. Den tog mycket tid och kraft från nyckelpersoner i teamet och gjorde att en del av förutsättningarna för mitt arbete förflyttades ett flertal gånger.

Under mitt arbetes gång fick avdelningschefen sparken och hela visionen för hur SAP-lösningen ska drivas förändrades från centraliserad till decentraliserat. Det gjorde att jag behövde göra ett omtag på hur den affärsnära kvalitetssäkringen bör genomföras eftersom CCB/CAB samt Key Users fick en ny roll.

Lärdomar