Valg af Test Management Tool

Når man overvejer at introducere et Test Management Tool, er det som at skulle kigge efter en ny bil. Der er mange alternativer, og alle er enige om at det skal være brugbart, brugervenligt, have plads nok til det nødvendige, have de ønskede features og for nogle også være lidt smart 🙂

Lige som med et godt valg af en bil, når man længere med et velvalgt tool – men der er altid risiko for at man kommer til at betale mere end nødvendigt. Betydelige omkostninger, som er forbundet med en investering får os til at lave analyser og sammenligning af valgmuligheder for at vælge den bedste, og processen er langt fra altid en nem opgave. I modsætning til det med biler, er der også omkostninger i forbindelse med introduktion af værktøjer. Opstart, undervisning men også tiden der er brugt i forbindelse med opsætning, oprettelse af krav, test cases og meget andet som er en forudsætning før det valgte værktøj kan begynde at give afkast. Vælger vi forkert, skal vi måske gøre det om igen – i tilfælde vores data ikke kan nemt flyttes i mellem alternative værktøjer.

Hvordan vælger vi det rigtigt første gang? For nyligt skulle jeg forholde mig til sådan en situation og jeg fik genopfrisket mine erfaringer med disse overvejelser:

  • Den oplagte start er ikke krav / kriterier men i stedet processen man ønsker at automatisere. Hvorfor det? En ineffektiv proces som understøttes eller automatiseres med et værktøj bliver kun hurtigere men ikke bedre af det. Et eksempel kunne være at man først skriver krav, dernæst laver design, test cases og til sidst skriver kode (den såkaldte vandfaldsproces), hvor informationen fortolkes og skrives ned igen flere gange i forskellige former. På den måde risikerer vi både at tabe detaljer og den rigtige vinkel på formålet med det vi laver – processen kan blive en slags ”broken phone” leg når det endelige resultat langt fra matcher det oprindelige udgangspunkt.

Hvis vi starter med at kigge på processen, har vi måske mulighed for at forbedre det i samme omfang vi introducerer et tool. Hvad med at gøre krav og test til en og samme arbejdsprodukt, sådan som det fungerer i Behaviour Driven Development (BDD)? Man behøver slet ikke at introducere store forandringer i specifikationsprocessen for at kunne blive enige om at alle krav illustreres med eksempler, som kan bruges til at verificere kravet med. Eksemplet tjener både det formål at kommunikere hvad er ideen, udgangspunktet og slutmålet med ønsket er og samtidig også bruges som et test-scenarie. Eksemplet kan nemt skrives i prosa, hvis man ikke gider at bruge nye former for specifikationssprog, men gerne køres igennem et review med testbarheden for øje. Ændringerne i krav medfører ændringer i test, hvilket reducerer risikoen for at test grundlaget kommer ude af trit med krav.

Det er blot et eksempel på en procesforbedring, hvor standard for specifikation er et og et bedt emne. Vi kunne også kigge på test data management, test strategi og arbejdsmetoder, kommunikation og quality intelligence (overblikket over tværgående aspekter i organisationen på tværs af processer og værktøjer). Jo mere harmonerer vores tool med alle disse, desto større gevinst får vi – f.eks ved at tænke på kvalitetssikring i alle stadier af et produktudviklingsforløb!

  • Mennesker, og ikke mindst deres mål (og i mindre grad – deres behov) i forbindelse med deres relationer til test og kvalitetssikringsprocesser. Et værktøj kan være smart for nogle men en forhindring for andre. Det offentlige sundhedsvæsen er et eksempel, hvor logning og tidsregistrering giver bedre information til ledelsen men ses som et byrde af dem der skal udføre dette. Er detaljeret overblik over udførte test cases virkelig nødvendigt, hvis det betyder at testere når at teste mindre? På nogle projekter er det. Måske har vi brug for overblikket for at kunne koordinere på tværs af personer, teams og endda afdelinger i forskellige lande. I så fald er vi tilbage til det første punkt, med spørgsmålet om hvordan gør vi det smartest.
  • Næste punkt er drivkraften, for hvis der er fordele må der også være nogle som høster dem. Måske er det en god ide disse mennesker er med til at vælge / teste den valgte løsning før denne bliver virksomheds standard. Det er lige som med den agile udvikling: involvering af slutbrugeren er altafgørende for at forstå kravene!
  • Beskrivelsen af kriterier, som måske kunne udføres med eksempler i stedet for den sædvanlige punktopstilling i tabelform. Tænk over situationer i stedet for adjektiver og sætninger som beskriver det åbenlyse meget generelt.

I stedet for ”brugervenlig” – ”man skal kunne oprette en test case alle steder i programmet”, eller ”en søgning efter en bestemt testcase bør ikke tage mere end 10 sekunder”.

I stedet for ”nem at integrere med” -> ”skal kunne indlæse eller linke til krav i Jira”, eller ”skal kunne eksportere test cases til CSV og Excel filformat.

Ud over eksempler på funktionalitet, kunne der også eksempler på hvilket overblik man ønsker at skabe for test-relaterede personer. Kunne rapportering fra automatiseret test, defect tracking og nylige ændringer i krav være en del af overblikket?

  • Bredden af mulige alternativer – hvor langt ud skal vi kigge? Hvis vores eneste krav er håndtering af nedskrevne test cases der kan deles mellem flere testere, behøver vi måske ikke en dyr Content-Management System (CMS) pakket ind som et Test Manageent Tool.. At flere vælger at bruge CMS til teststyring er ikke nødvendigvis et problem, men måske snarere afspejling af de egentlige behov der kan løses med simplere systemer. Når disse ikke længere kan modsvare voksende krav, i takt med procesoptimeringer, er der tid til at kigge på andre. Dog kan man stadig kigge bredere – f.eks er der et standard system som vedligeholdes af en ekstern part som kan tilpasses til behovet?

Disse punkter er mine personlige forudsætninger som gerne skal overvejes før den endelige valgproces, som jeg ikke vil gå i dybden med. Der findes mange måder at træffe beslutninger, hvilket er nærmest et emne for sig selv. Det eneste sikre er at processen med fordel kunne gøre brug af et pilotprojekt, som kan give ro i maven over den valgte løsning.

God jagt på den bedste Test Management Tool derude!

38341d85f8c136873d5176303ff24a9a

ps. der findes jo også gode sammenligninger af forskellige tools på nettet (her tænker jeg ikke på dem der er lavet af selvsamme producenter af disse tools). Jeg ville ikke bruge tid på at skrive om noget alle kan google, men til gengæld vil jeg gerne høre om jeres erfaringer i forbindelse med valg af test management tools og skrive en case-baseret guide til samme emne 🙂

https://www.linkedin.com/in/pouls

 

 

Reklamer

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

w

Connecting to %s