Ska du välja ett systemspecifikt testverktyg eller en övergripande plattform?

Systemspecifika testverktyg fungerar bra för avgränsade insatser i enskilda system. Men när organisationen driver flera projekt parallellt, har processer som går över systemgränser eller omfattas av revisionskrav växer riskerna. Testbevisen hamnar i silos, beviskedjan får luckor och kontrollen över kvalitetsunderlaget ligger hos leverantören i stället för hos er.

När ett nytt affärssystem, EAM eller HR-system ska införas är det lätt att lockas av testverktyget som följer med leverantörens ekosystem. Det känns smidigt i starten och löser det omedelbara behovet i projektet. Men i takt med att IT-landskapet växer ställs ledning och testansvariga inför ett strategiskt vägval.

Frågan handlar inte bara om vilket verktyg som fungerar bäst tekniskt. Den handlar om hur skalbara era processer är, vem som äger bevisen för att era system fungerar och om dokumentationen håller över tid, oavsett leverantör.

Vad är ett systemspecifikt testverktyg?

Ett systemspecifikt testverktyg eller ALM-verktyg är byggt för att kvalitetssäkra en enskild applikation, till exempel ett ERP-system som SAP, ett CRM eller ett HR- och lönesystem. Det följer ofta med leverantörens egen miljö.

Verktygen har verkliga styrkor. De är nära kopplade till systemets processmodeller och kan ge bra stöd när leverantören släpper uppdateringar. Begränsningen är att de är byggda för leverantörens värld, och få större organisationer lever i endast ett system.

När räcker ett systemspecifikt verktyg?

Innan du väljer verktyg för att kvalitetssäkra ett projekt behöver du ställa dig själv vissa frågor som hur många system och projekt ska testas, nu och de kommande åren? Går era verksamhetsprocesser över systemgränser? Omfattas ni av revisions- eller regelkrav som kräver spårbarhet och bevis över tid? Känner du igen din organisation i punkterna nedan räcker det ofta med leverantörens verktyg.

1. Projektet är avgränsat
   Ett system, ett fåtal personer och nya projekt hör till ovanligheten.
2. Flödena stannar inom systemet samt
   Informationen skapas och används i samma applikation.
3. Kraven på långsiktig spårbarhet är låga.
   Ni behöver inte kunna visa testbevis för en revisor om flera år.

När passar inte ett systemspecifikt verktyg?

När IT-landskapet växer och systemen kopplas ihop förändras kraven på testarbetet. I följande lägen räcker ett systemspecifikt verktyg ofta inte hela vägen.

1. Ni driver flera projekt och vill ha en gemensam metodik

I större organisationer pågår flera system- och IT-projekt samtidigt. Om varje system testas i leverantörens eget verktyg får varje projekt sina egna arbetssätt, sin egen rapportering och sin egen terminologi. I stället för att bygga strukturkapital börjar varje nytt projekt från noll. Med en gemensam plattform för krav och tester kan organisationen ha samma process och metodik i alla projekt, oavsett system.

2. Era processer går över systemgränser

En process som order-to-cash kan passera ERP, CRM, e-handel och integrationslager. Varje system kan fungera var för sig, men det är ofta i överlämningen som felen uppstår. Ett systemspecifikt verktyg testar sin egen del väl men ser inte hela kedjan.

3. Ni har krav på revision och långsiktig spårbarhet

När samma leverantör levererar systemet och verktyget som ska visa att det fungerar, blir ansvarsfördelningen mindre tydlig. En revisor som bedömer kontrollmiljön kan då fråga hur oberoende bevisen är. Revisorer vill också kunna följa kedjan krav, test, avvikelse och godkännande. Om kedjan går över flera system men dokumentationen bara finns för en del av dem, uppstår luckor.

I reglerade branscher som life science, finans och energi ska testbevis dessutom ofta sparas i många år. Då behöver ni veta vad som händer med historiken om licensmodellen ändras, avtalet löper ut eller verktyget ersätts.

4. Utvecklarorganisationen arbetar i andra verktyg, till exempel Jira

Inbyggda verktyg integrerar oftast bäst inom sitt eget ekosystem. Kopplingar till exempelvis Jira finns ofta i någon form, men de kan vara begränsade, enkelriktade eller kräva mellanprogramvara. Fält och statusar översätts inte alltid ett till ett. Då finns en risk att avvikelser loggas på två ställen och att utvecklingsteamet och testteamet ser olika bilder. Integrationerna behöver också förvaltas när leverantören uppgraderar sina gränssnitt.

5. Ni vill undvika inlåsning till en leverantör

Testfall, automatiseringar och kunskap som byggs i leverantörens plattform är svåra att ta med sig. Det påverkar förhandlingsläget och kostnaden vid ett framtida systembyte. Funktioner, prismodell och livscykel följer leverantörens planer. Varje nytt verktyg lägger dessutom till en licensmodell och ett gränssnitt att administrera.

Beslutsstöd: väg för- och nackdelar mot er verklighet

Från punktinsats till skalbar strategi

Systemspecifika testverktyg är bra på det de är byggda för: att testa en specifik modul i ett avgränsat projekt. Men för organisationer som driver flera projekt, har processer över systemgränser eller möter revisionskrav blir de snabbt en flaskhals.

Genom att samla krav, manuella testfall och automatiserade resultat i en gemensam, leverantörsoberoende plattform behåller ni själva ägarskapet över era kvalitetsbevis. Strukturen fungerar oavsett vilket system ni inför härnäst.

Läs mer och fördjupa dig

Vilket krav- och testverktyg passar din organisation — och vad skiljer Reqtest, Jira, Azure DevOps, TestRail och Excel åt?

Läs vårt white paper om nyckelfaktorer för ett lyckat affärssystem och vad som avgör att en ERP-implementation lyckas.

Så räknar du på om ett krav- och testverktyg lönar sig i ditt systeminförande.

Vanliga frågor

Hur påverkas möjligheten att skala om vi startar med ett systemspecifikt verktyg?

Skalbarheten blir ofta låst. När nästa projekt startar i ett annat system måste teststrukturen byggas upp från grunden igen, i stället för att återanvända mallar, metoder och kravkopplingar.

Behöver vi ett eget testverktyg om leverantören redan har ett?

Ja, om era processer går genom flera system eller om ni har revisionskrav. Leverantörens verktyg testar sitt eget system bra. Men helhetsflöden och oberoende testbevis kräver att resultaten samlas på ett ställe som ni själva äger.

Vad händer med vår testhistorik om vi byter system eller leverantör?

Det beror på avtalet och verktygets exportmöjligheter. Ta reda på i vilket format historiken kan exporteras och om spårbarheten mellan krav, test och avvikelser följer med.

Hur ofta måste man testa ett molnbaserat affärssystem?

Vid varje uppdatering från leverantören. Molnsystem uppdateras flera gånger per år. Automatiserade regressionstester av de viktigaste processerna gör det hanterbart.