+47 67 20 66 67 kontakt@vivento.no

Testere uten testerfaring kombinert med begrensede eller manglende krav

Min historie er fra et helt ordinært mottaksprosjekt hvor jeg var testleder. Det var mangel på erfarne test ressurser og begrenset kvalitet på kravene. For å sikre tilstrekkelig testdekning og at vi faktisk var i stand til få systemet testet godt nok, måtte vi få det beste ut av vår tid og våre ressurser. Jeg vil i denne artikkelen komme innpå noen av avgjørelsene vi tok og hvorfor vi gjorde det.

Jeg vil bruke eksempler fra mottaksprosjektet, selv om mye av de utfordringene jeg omtaler sannsynligvis kan gjelde for mange andre typer prosjekter.

«Den beste treningen er den treningen du faktisk gjør»
Sitat: Oddvar Brå, langrennsløper

Oddvar Brå var, og er fortsatt ikke imponert av treningsteorier og diskusjoner om hva du bør gjøre for å bli en bedre langrennsløper. Joda, han hadde sine egne treningsplaner og hadde tro på grunnleggende teori, men var mer fokusert på å bruke tiden på å trene. Ikke snakke om når, hvor og hvordan man burde trene.

Jeg tror det er det samme med testing. Det spiller ingen rolle hva som planlegges av test. Det er testarbeidet prosjektet faktisk har levert som betyr noe. Den virkelige utfordringen er å optimere innsatsen, med de ressursene som er tildelt til deg som testleder. «Den beste testingen er testing som faktisk utføres».

Noen av utfordringene i mottaksprosjektet

Testorganisasjonen var umoden. Testgrunnlaget hadde ikke god nok kvalitet. Arbeidsprosessene var ikke dokumentert og testbare. Prosjektet hadde tilgang til domenekunnskap men tilgjengeligheten var begrenset på enkelte områder. Tiden var også en knapp faktor. Prosjektorganisasjonen hadde ikke test rammeverket på plass. Prosjektressursene som var tildelt å bidra til testprosessen trengte veiledning og opplæring. Testgrunnlaget krevde mye arbeid for å bli testbart og å utlede testtilfeller fra.

 

På den venstre siden – Testgrunnlaget var ikke godt nok, forretningsprosessene var ikke testbare. Testtilfellene var ikke opplagte.

På høyre siden – Domenekunnskapen var god, men hvordan konvertere denne kunnskapen til testbare arbeidsprosesser og andre testtilfeller var en utfordring.

Tilgjengeligheten av ressurser veier litt tyngre enn kvaliteten på testgrunnlaget

For å kunne administrere dette, må testleder se hele bildet. Testplanlegging uten hensyn til disse innsatsfaktorene kan resultere i feil beslutninger for valg av teststrategi.

 


En realistisk teststrategi

Testdesign– «keep it simple» men tilpass til forskjellige grupper av testere.
Testrapportering– «keep it simple», men hold oppdatert.
Testdekning- risiko basert, «happy-path» prioriteres.
Dokumentasjon av arbeidsprosessene «keep it simple», og visuelt.

Ut fra input-faktorene ovenfor, var det denne teststrategien som ble valgt. Det var viktig å unngå kompleksitet for å unngå sløsing med verdifull tid og ressurser. For å kunne foreta raske justeringer, måtte testrapporteringen være forståelig og oppdatert hele tiden. Det var nødvendig å prioritere med en risikobasert tilnærming. Dette var avgjørende for at prosjektet skulle ha tilstrekkelig med tid til å konsentrere seg om å dokumentere og teste de viktigste arbeidsprosessene.

Test nivåer

Selv med manglende tid og ressurser er det viktig å følge en normal testprosess der hvert enkelt nivå har klare godkjenningskriterier. Integrasjonene ble dokumentert, testet og klargjort for neste testnivå. Dette arbeidet ble gjort av tekniske prosjektressurser med minimal involvering av funksjonelle domeneeksperter.

I systemintegrasjonsfasen ble arbeidsprosessene testet ende til ende, uten brukertilgangskontroll. Testene ble utført av funksjonelle domeneeksperter, som hadde vært involvert i å dokumentere arbeidsprosessene. Testene var på dette nivået ikke systemspesifikke. Selve testgjennomføringen ble utført i workshops og nødvendige justeringer på arbeidsprosessene ble registrert nøye.

Test av risikokomponenter ble også testet i dette testnivået. Disse testene ble utført ved hjelp av utforskende testsesjoner.

Til slutt ble arbeidsprosessene testet i akseptansetest av sluttbrukere med deres egne tilganger. På dette nivået var det utviklet detaljerte systemspesifikke steg-for-steg guider som bygget på arbeidsprosessene.

Testplan for mottaksprosjektet

Tabellen under viser fasene som fulgte etter at planleggingsfasen var ferdig og selve testimplementeringen startet. Planen viser 16 ukers gjennomføring av 3 testfaser parallelt med dokumentasjon og utvikling av opplæringsmateriell. For å muliggjøre dette må det være en høy grad av samarbeid mellom ulike bidragsytere til denne prosessen. Det er også viktig at de ulike gruppene respekterer og har forståelse for arbeidet de alle gjør parallelt i denne prosessen. Tabellen viser også bidragsyterne til fasene.

Figuren viser sekvensene i testplanen. Sirkelen i midten av figuren illustrerer at det i alle testfasene læres noe nytt som oppdaterer arbeidsprosess dokumentasjonen. Om nødvendig vil også defekter fikses og systemet måtte oppdateres.

 

Etablere test organisasjonen / Test-trening

Etableringen av testorganisasjonene innebærer å motivere og trene de som skal bidra i testprosessen. Jeg tenker da på domene eksperter og tekniske prosjektressurser som ikke har spesifikk test erfaring. Det er viktig å begrense treningen til bestemte aktiviteter som er det de faktisk skal gjøre i testprosessen.

  • De må lære å skrive testtilfeller direkte i en mal som kan importeres til testverktøyet. De må lære å registre testresultater i testverktøyet, samt å kunne registrere defekter og bidra i feilhåndteringsprosessen.
  • Det er viktig å minne prosjektet på hvorfor vi tester. Jeg forteller dem at den beste måten å lære systemet er faktisk å bruke systemet, ikke å skrive dokumenter.
  • Jeg forteller dem at vi vil finne mangler og svakheter og at vi da får muligheten til å redusere risikoene.
  • Jeg forteller dem at ved å teste vil den detaljerte systemspesifikke dokumentasjonen bli bedre og at det vil være mer effektivt og trene sluttbrukerne.
  • Hold det enkelt, men repeter ofte.

Etablere test-rammeverk

For å sikre effektiv testimplementering og gjennomføring er det smart å utvikle nødvendige importmaler slik at flere kan bidra i testprosessen uten å være avhengig av god kunnskap om testverktøyet. Vi må også forberede testverktøyet for rapportering på både kravdekning og testprogress.

I mottaksprosjektet valgte vi å dele inn kravene i 3 grupper. Det høyeste nivået i hierarkiet var arbeidsprosessene. Neste nivå var integrasjoner og det laveste nivået var risikoelementer. Det er svært viktig å ha  test rammeverket på plass før testimplementeringen starter.

Dokumentere arbeidsprosesser

I mottaksprosjekter var det viktig å etablere riktige detaljnivået for å dokumentere forretningsprosesser. Det høyeste nivået var visuelt. Det ble valgt å bruke BPMN som arkitekturspråk. Vi mente dette var noe alle burde kunne forholde seg til og forstå, både sluttbrukere, forretningssiden og de tekniske ressursene. Dette nivået skal kun beskrive arbeidsprosessen uten at det er systemspesifikt. Det ble valgt å planlegge og gjennomføre workshops på hver enkelt forretningsprosess. Workshopene ble fasilitert av arkitekter som var gode på å tegne og strukturere prosessene. Bidragsytere var funksjonelle domeneeksperter.

Neste fase av dokumentasjon var å gjøre arbeidsprosessene testbare for sluttbrukerne. Dette ble gjort ved å skrive trinnvise veiledninger som nå ble systemspesifikke ved at systemet ble kjørt. Dette arbeidet ble gjort individuelt av domeneeksperter men inkluderte en kvalitetskontroll.

I teststrategien valgte vi å kun importere inn aktivitetene i arbeidsprosessene som teststeg uten mer detaljer. Det ble da ekstremt viktig å instruere testerne å følge de detaljerte guidene selv om detaljene ikke ble registrert som detaljerte steg i testverktøyet. Årsaken var at vi mente at det var viktigere å ha fokus på å jobbe med og teste prosessene enn å bruke ressurser på å oppdatere teststeg

Arbeidsprosess – Høyt nivå – Ikke systemspesifikk

 

Arbeidsprosess – Detaljert nivå – systemspesifikk

 

Læring ved å dokumentere arbeidsprosesser og ved å teste disse

 

Noe av årsaken til at man kan velge å følge en teststrategi som jeg har beskrevet her, er å kunne oppnå mer i en testprosess en bare å dokumentere kvaliteten på systemet som testes. Man kan bli bedre til å integrere testingen i opplæringen. Bruke ressursene riktig og få mer ut av disse.

«Den beste treningen er den treningen du faktisk gjør»
(
«Den beste testingen er testing som faktisk utføres»)

Artikkelen er skrevet av Øyvind Woll, Seniorkonsulent i Vivento. Vil du vite mer om våre erfaringer fra testprosjekter, ta gjerne kontakt med oss.

Øyvind Woll
Seniorkonsulent
oyvind.woll@vivento.no

Digital omstilling

Meld deg på vårt nyhetsbrev

Liker du det du nettopp leste? Gjør som 600 andre og få nyheter fra Vivento direkte i din innboks. Du vil motta nyheter fra Vivento maks 6 ganger i året.

Takk for din påmelding, sjekk innboksen!