Blogginlägg -

Erfarenheter av en dedikerad testare i litet tekniskt projekt

I små utvecklingsprojekt med bara en eller två utvecklare är det ofta svårt att motivera att ha en testare på heltid. Kan det då löna sig att ta in en testare/testledare då och då, inför större leveranser?

Detta har vi på AddQ utvärderat i ett projekt där vi själva utvecklar en applikation hos en av våra kunder.

Applikationen som utvecklas används i ett mätinstrument för att styra, samla in data, utföra beräkningar och presentera resultat. Applikationen hanterar en rad olika inställningar, typ av mätinstrument och har stöd för flera olika språk.

Tidigare har kunden själv testat det mättekniska och vi har haft noggrann kontroll på de centrala beräkningarna med hjälp av automatiskt regressionstest. Vi har dock inte haft någon bra strategi för att testa användargränssnittet vilket efterhand blivit mer och mer komplext.

För att förbättra detta erbjöd vi kunden en dedikerad testare, under två veckor, för att planera, genomföra och dokumentera tester av användargränssnittet och därmed hitta fel som annars skulle komma in som supportärenden från slutanvändare.

Resultatet efter genomfört testarbete blev ett tjugotal identifierade buggar varav några ledde till programkrascher. Felen rättades och därefter genomfördes ytterligare en testomgång. Tanken var att kunna släppa en ny release direkt därefter men vår testare hade nu blivit mer varm i kläderna och hittade ytterligare buggar som rapporterats och rättats.

Vår slutsats av detta är att även i små utvecklingsprojekt lönar det sig att ta in en dedikerad testare, åtminstone inför varje release. På endast 10 arbetsdagar lyckades vi ta fram en teststrategi och en testplan, specificera testfall, genomföra en komplett testomgång och rapportera resultatet. Vi är övertygade om att detta kommer generera betydligt färre supportärenden från slutanvändare framöver.

    Ytterligare några slutsatser utifrån detta arbete är:

  • Användare är dåliga på att rapportera fel
    De har rapporterat en hel del fel under åren programmet varit i bruk men totalt färre än vad vår testare fått fram på två veckor! I stort sett alla buggar som identifierades skulle användaren ha drabbats av.
  • Utvecklingsprocessen behöver ses över
    För utvecklarna är det nu uppenbart att det inte är effektivt att testa sin egenutvecklade kod. En första åtgärd blir att granska varandras buggrättningar. ”Akut” ny funktionalitet har lett till buggar och försämringar av programvarans arkitektur.
  • Vi får värdefulla tips om användargränssnittets utformning
    Tack vare testarbetet fick vi en hel del värdefulla tips om vad vi borde förbättra i användargränssnittet.

Kort om författaren

Daniel Olsson har under de senaste 15 åren arbetat med test & kvalitetssäkring som utvecklare, testare, testledare, Scrum master och Agil coach. Daniel brinner för att utveckla test organisationer och är idag även konsultchef på AddQ.

Daniel Olsson på LinkedIn - AddQ, din partner för test

Ämnen

  • Data, Telekom, IT

Kategorier

  • addq
  • daniel olsson
  • göteborg
  • mätsystem
  • teknisk test
  • utvecklingsprocess
  • johan sandström
  • Användargränssnitt
  • uat
  • slutanvändare
  • testramverk
  • konsult

Regioner

  • Blekinge

Kontakter

Kennet Osbjer

Presskontakt VD +46 8 501 108 90