Introduksjon til test

Kursets innhold

Dette kurset gir deg en overordnet introduksjon til utvikling og test av IT-systemer. Kurset er rettet mot testere som har lite eller ingen tidligere erfaring med testing, og som vil ha manuell akseptansetest som sin primæroppgave.

Hovedmålgruppen er saksbehandlere som fungerer som testere i forbindelse med utvikling og forvaltning av NAVs IT-systemer. Kurset egner seg også som introduksjon for andre uerfarne testere.

Kurset inneholder generelt faglig innhold, og innhold som er tilpasset spesifikk gjennomføring av testing i Arbeids- og velferdsdirektoratet. Hver leksjon avsluttes med et sett av oppgaver og spørsmål. Noen leksjoner inneholder i tillegg praktiske oppgaver som skal løses "på papir" eller i ulike verktøy/programmer.

Som tillegg til dette kurset finnes en egen testmodul, der spørsmål og oppgaver omfatter kurset som helhet.

Praktisk informasjon

Kurset inneholder lenger til Confluence. De lenkede sidene vil åpnes i et nytt vindu. For å få tilgang til disse sidene må du være pålogget med din bruker i Confluence, og ha tilgang til området. Dersom du ikke allerede har tilgang til Confluence, så kan du bestille dette via din identadministrator.

Annet:?

Forventninger til deg

Testing av IT-systemer er et eget fagområde innenfor systemutvikling. De ulike områdene innen testfaget krever ulike kompetanse. De fleste som jobber med testing er utdannet innen IT, men det finnes også områder innen testing der domenekunnskap og erfaring med bruk av fagsystemer er minst like viktig som IT-kompetanse.

Personlige egenskaper og praktisk erfaring er forutsetning for å bli en god tester. Fortvil ikke dersom du synes det blir mye teori i dette kurset. Kurset skal gi deg et utgangspunkt for praktisering, og det er ikke forventet at du er utlært tester når kurset er gjennomført.

Vi ønsker at du hjelper oss med å forbedre kurset. Ta kontakt dersom noe av stoffet er vanskelig å forstå, eller du har innspill til forbedringer.

Spørsmål kan rettes til NAVN. Kontakt:

Lykke til!

 

FORVALTNING AV NAVs IT-SYSTEMER

Forvaltning av NAVs IT-systemer

Forvaltning av NAVs IT-systemer

Arbeids- og velferdsdirektoratet har ansvar for forvaltning av NAVs IT-systemer. Forvaltning handler om alt fra nyutvikling av moderne løsninger til daglig drift av operative systemer. 

IT-avdelingen (NAV IT) gjør dette i samarbeid med eierne av fagsystemene som tilhører Arbeids- og tjenesteavdelingen og Ytelsesavdelingen. 

KLADD:
Vi har organisert oss slik at ulike team har ansvar for hver sine systemer eller systemområder. Vi har for eksempel Team Arena, Team Bidrag, Team Innkreving og Team Selvbetjening.

Noe mer?

Leksjon 1 - INTRODUKSJON TIL SYSTEMUTVIKLING

Hva er systemutvikling?

Systemutvikling

Systemutvikling handler om det arbeidet vi gjør når vi lager nye IT-systemer, eller når vi gjør endringer i et eksisterende system.

Systemutvikling omfatter:

  • utvikling av nye systemer
  • utvikling av nye funksjoner i et operativt system
  • endring av funksjoner i et operativt system
  • retting av feil i et operativt system



Systemutvikling kan deles inn i en livssyklus som består av seks faser:

  1. Analyse 
  2. Design
  3. Implementasjon
  4. Produkjsonssetting
  5. Drift og forvaltning

1 - Analyse

Hva gjør vi i analysefasen?

Analyse handler om kartlegging av behov, krav og konsekvenser.

Vi stiller spørsmål som:

  • Hvem skal bruke systemet?
  • Hvilke oppgaver skal brukerne løse?

Vi kan bruke informasjon, som f.eks.:

  • tall om bruk fra operative systemer
  • statistikk over saksbehandlingstider



Vi må også vurdere konsekvenser som:

  • Vil andre systemer blir berørt? 
  • Hvor mange brukere blir berørt?
  • Hvilke konsekvenser har endringer for brukerne våre? 
  • Hva er kostnaden?

Arbeidet ender opp i en kravspesifikasjon, som gir retningslinjer for den neste fasen.

2 - Design

Hva gjør vi i designfasen?

I denne fasen definerer vi funksjonelt og teknisk løsningsdesign med utgangspunkt i kravspesifikasjonen. 

Vi kan stille spørsmål som:

  • Hvordan skal løsningen gjøres tilgjengelig for brukerne?
  • Hvilke data skal håndteres av løsningen?
  • I hvilken rekkefølge skal ting gjøres?
  • Hvordan skal brukergrensesnittet se ut?
  • Hva skal skje dersom brukeren gjør en feil?


Vi må også finne ut hvordan vi teknisk skal konstruere systemet eller løsningen. Vi kan stille spørsmål som:

  • Hvordan skal systemet "snakke" med andre systemer? 
  • Kan vi gjenbruke data som ligger i andre systemer? 
  • Bør vi dele inn systemet i mindre deler?

Vi dokumenterer designet i løsningsbeskrivelsen som er input til den neste fasen. 

Husker du? Huk av for riktige svar.

  • Kartlegging av brukernes behov inngår i en analyse.
  • Det første vi gjør når vi skal utvikle nye systemer er å beskrive hvordan det skal fungere og se ut.
  • Design handler både om funksjonelle og tekniske egenskaper ved et system.
  • Designet dokumenteres i en løsningsbeskrivelse.
  • Resultatet fra analysefasen dokumenteres i en kravspesifikasjon.

3 - Implementasjon

Hva betyr implementasjon?

I denne fasen konstruerer vi systemet eller løsningen med utgangspunkt i løsningsbeskrivelsen. 

FJERNE? Vi implementerer systemet ved å konstruere det komponentvis, og ved å bryte arbeidet ned i mindre oppgaver.

For å få systemet til å gjøre det vi vil, må vi lage programmer som styrer datamaskinen. Dette gjør vi ved hjelp av spesielle koder som fungerer som instruksjoner. Vi kaller de som skriver slik kode for utviklere.

Konstruksjon kan også omfatte andre oppgaver som installasjon av programvare, eller å tilrettelegge for at ulike systemer "snakker sammen".

4 - Testing

Hva gjør vi når vi tester?

Når koden er ferdig utviklet må den testes. Vi må verifisere at løsningen oppfyller behovene og kravene som har blitt identifisert. Det gjør vi blant annet ved å utføre oppgaver i en testversjon av systemet.

Vi spør oss:

  • Har vi laget den løsningen vi bestemte at vi skulle lage?
  • Finnes det feil i den løsningen vi har laget? 

Husker du? Huk av for riktige svar.

  • Løsningsbeskrivelsen er utgangspunktet for implementasjon av et system.
  • Vi styrer datamaskiner ved å gi dem hemmelige tegn.
  • De som skriver programmeringskoder kalles for utviklere.
  • Implementasjon kan bety å hjelpe ulike systemer til å samarbeide.
  • Vi finner sjelden feil når vi tester.

5 - Produksjonssetting

Hvordan får vi tatt systemet i bruk?

Når testingen er gjennomført med tilfredsstillende resultat kan vi ta systemet eller løsningen i bruk.

Produksjonssetting er den tekniske jobben som må gjøres når vi skal gjøre systemet tilgjengelig for brukerne. 

Det er også en del innføringsaktiviteter som gjøres i forbindelse med at en løsning tas i bruk. Vi må for eksempel sørge for at alle interessenter holdes oppdatert på viktig informasjon, og at brukerne av systemet får nødvendig opplæring.

6 - Drift og forvaltning

Hvordan håndterer vi operative systemer?

Når systemet eller løsningen er tatt i bruk vil det fortsatt være behov for vedlikehold. Det kan skyldes feil som ikke har blitt oppdaget i testing, eller at det avdekkes behov for endringer og forbedringer. 

Behov og krav til slike endringer er input til en ny gjennomgang av fasene i systemutviklingens livssyklus.


Husker du? Huk av for riktige svar.

  • Vi må produksjonssette systemet før det kan tas i bruk.
  • Det er ikke så farlig om vi ikke har testet grundig før systemet settes i produksjon, for vi kan rette feil også i etterkant.
  • Operative systemer må vedlikeholdes.

Iterativ utvikling

Iterasjoner

Behov for endringer kan oppstå også før en løsning er satt i produksjon. Det kan skyldes ny innsikt om brukeres behov, at en lovendring påvirker krav til løsningen, at vi får tilgang på ny teknologi eller reduksjon i et budsjett. 

Vi kjører derfor ofte sekvensen av fasene i flere runder, som vi kaller iterasjoner. 

Vi kaller denne tilnærmingen til systemutvikling, der vi kan lære og tilpasse oss underveis, for iterativ utvikling.

Husker du hva de ulike fasene handler om?

  • Analyse
    Kartlegging av behov, krav og konsekvenser.
  • Design
    Utarbeide beskrivelse av funksjonell og teknisk løsning med utgangspunkt i kravspesifikasjonen.
  • Implementasjon
    Konstruksjon av et system med utgangspunkt i en løsningsbeskrivelse.
  • Testing
    Verifisere at systemet oppfyller kravene, og at det ikke finnes alvorlige feil.
  • Produksjonssetting
    Gjøre et system tilgjengelig for brukerne.
  • Drift og forvaltning.
    Vedlikehold av et operativt system.

Klarer du å sortere fasene i riktig rekkefølge?

  • Analyse
  • Design
  • Implementasjon
  • Testing
  • Produksjonssetting
  • Drift og forvaltning

Sant eller usant?

  • Systemutvikling er det vi gjør når vi lager nye og moderne løsninger for NAV.
  • Når vi gjør endringer i et eksisterende system så kaller vi det ikke for systemutvikling.
  • Systemutviklingens livssyklus kan deles inn i fem faser.
  • Det er vanlig å finne feil i et system også etter at det er testet.
  • Det er ikke lov å gjøre endringer i et system som allerede er satt i produksjon.
  • Det kan være lurt å kjøre gjentatte runder av fasene i livssyklusmodellen når vi driver med systemutvikling.
  • En iterasjon er et begrep som brukes om feil vi finner i systemet.

Leksjon 2 - FRA BEHOV TIL LØSNING

Initiativ

Hvem fremmer behov?

Initiativ til utvikling eller endring av systemer og løsninger kommer fra ulike interessenter: 

  • Fagsiden av NAV (direktoratet) - endring eller nye lover og regler (regjering)
  • Forretningssiden av NAV – (de som er opptatt av forretningsmessig verdi – effektive løsninger)
  • NAV brukere – de har kunnskap om NAV sine systemer fordi de har behov for tjenester som NAV tilbyr via sine datasystemer
  • Eksterne samhandlere – dvs enheter på utsiden av NAV som bruker NAV som leverandør av datasystemer (for eksempel Helse, statistikk, skatt)
  • IT-avdelingen i arbeids- og velferdsdirektoratet har behov for endringer (forbedringstiltak, fornyelse, effektivisering)


Introduksjon til praktisk case

Modernisering av NAVs CV-løsning

Vi bruker følgende case til praktiske eksempler i opplæringen:

I tråd med virksomhetsstrategien om "arbeid først", skal Arbeids- og velferdsdirektoratet hjelpe arbeidsledige ut i arbeid så fort som mulig. I forbindelse med dette ser vi at det er behov for å modernisere NAVs CV-løsning, da det er svakheter i dagens løsning for registering av CV. 

Disse påvirker både datakvaliteten i CV'en og antall registrerte CV'er. Vi har en hypotese om at vi kan øke både datakvaliteten og antall CV'er i databasen om vi lager en ny og bedre løsning for registrering av CV'er.

Hvilke behov har brukerne?

Brukerhistorier

Når vi skal utvikle noe nytt så starter vi med å kartlegge behov. Det er viktig med god dialog mellom ulike interessenter og aktører, og vi beskriver derfor behovene på en måte som gjør at alle kan forstå de. 

Når vi skal beskrive behovene tar vi utgangspunkt i brukerne, og inkluderer også en begrunnelse for behovet:

SOM en <rolle>
ØNSKER JEG <en målsetting>
SLIK at <en begrunnelse>

Vi kaller dette en brukerhistorie.


Vi beskriver først behovene på et overordnet nivå:

Som NAV-veileder
ønsker jeg å vite hvilken kompetanse en arbeidssøker har
slik at jeg kan hjelpe denne med å komme i arbeid

Som arbeidsgiver
ønsker jeg å vite hvilken kompetanse en arbeidssøker har
slik at jeg kan ta kontakt med aktuelle kandidater

Som arbeidssøker
ønsker jeg å synliggjøre min kompetanse
slik at jeg kan komme i kontakt med potensielle arbeidsgivere

Detaljering av behovene

Fra epos til historier

Brukerhistorier som beskriver behov på et overordnet nivå kalles epos. Disse brytes gjerne ned i mindre og mer detaljerte brukerhistorier vi kaller historier

La oss ta utgangspunkt i følgende epos:

Som arbeidsgiverønsker jeg å vite hvilken kompetanse arbeidssøkere harslik at jeg kan ta kontakt med aktuelle kandidater

Vi kan bryte dette ned i mer detaljerte brukerhistorier som for eksempel:

Som arbeidsgiverØnsker jeg informasjon om arbeidssøkeres utdanning og arbeidserfaring Slik at jeg kan vurdere om de har nødvendig kompetanse 

Som arbeidsgiverØnsker jeg at arbeidssøkere oppgir epost og telefonnummerSlik at jeg kan kontakte aktuelle kandidater

Husker du? Huk av for riktig svar.

  • Brukerhistorier beskriver brukeres behov.
  • Brukerhistorier skal være enkle å forstå - slik at de understøtter dialog mellom ulike interessenter.
  • Vi benytter brukerhistorier for å beskrive krav.
  • Vi starter med de overordnete behovene.
  • Epos beskriver behov på et overordnet nivå.
  • Historier er detaljering av behov på eposnivå.
  • En brukerhistorie er det samme som en historie.

Initiativ - epos - historier

Forholdet mellom initiativ, epos og historier

Et initiativ kan resultere i mange epos, og hvert epos detaljeres av flere underliggende historier. 

Vi bruker formatet for brukerhistoriene til å beskrive både overordnete og underordnede behov.

Løsningsbeskrivelse

Hvordan løser vi behovene?

Neste steg er bestemme hvordan vi løse behovene. Vi dokumenterer krav og løsning i det som kalles for kravbeskrivelse og løsningsbeskrivelse for hver historie. 

Vi kan beskrive krav og løsningen på mange ulike måter. I tillegg til tekstlige beskrivelser vil det ofte være skisser til skjermbilder eller diagrammer og modeller av ulike slag.

Se eksempel for vårt case på https://confluence.adeo.no/x/ykB8DQ 

OBS! Du trenger dette for å gjøre de praktiske øvelsene i neste leksjon

Hva er riktig forklaring?

  • Brukerhistorie
    Notasjon for beskrivelse av brukeres behov.
  • Initiativ
    Fremmes av ulike interessenter når det er behov for nyutvikling eller endring.
  • Historie
    Detaljering av et overordnet behov (epos).
  • Epos
    Brukeres overordnede behov.

Leksjon 3 - HVA ER TESTING?

Hvorfor tester vi?

Hva er testing?

Testing er en type kvalitetskontroll. Når vi tester er vi opptatt av to ting:

  • Har vi laget den løsningen vi har avtalt å lage?
  • Har vi feil i den løsningen vi har laget?

Testing kan også bidra til kvalitetssikring dersom vi finner feilene tidlig. 


Hvordan oppstår feil?

Hvordan oppstår feil?

Mange ting kan gå galt når vi utvikler nye systemer, eller gjør endringer i en løsning. Feil kan for eksempel skyldes:

  • at vi har ulik forståelse av hva vi skal lage
  • at utviklere har skrevet feil kode 
  • at tilgrensende systemer ikke fungerer som vi trodde
  • at vi ikke har avdekket alle konsekvenser (f. eks. at en endring har en negativ påvirkning på andre deler av løsningen)


Feil har ulik alvorlighetsgrad (severity). Vi deler gjerne inn i:

  • A (kritisk) - Påvirker kritisk funksjonalitet og/eller kritiske data. Det finnes ingen «workaround» (midlertidig løsning).
  • B (alvorlig) - Påvirker viktig funksjonalitet eller vikitge data. Det finnes en "workaround"/feilen kan aksepteres i en kortere periode.
  • C (ikke alvorlig) - Påvirker ikke viktig funksjonalitet eller datakvalitet i løsningen.

Husker du?  Huk av for riktige svar.

  • Hensikten med testing er å finne feil.
  • Testere bidrar til kvalitetssikring ved å finne feil tidlig.
  • Dersom vi har feil i systemet, så er det alltid utviklerne sin skyld.
  • Vi kategoriserer feil etter alvorlighetsgrad.

Hva skal vi teste?

Testing mot krav

Krav kalles også akseptansekriterier, og fungerer som målestokk når vi utfører akseptansetest. Vi tester om løsningen tilfredsstiller kravene. 

La oss ta krav nr. 4 fra CV-eksemplet, med tilhørende skisse over dialogen for registrering av personalia. 

Dersom vi skal teste denne må vi først og fremst verifisere at dialogen er i henhold til kravet: 

Når bruker oppretter CV første gangen så skal følgende felter fylles automatisk:- navn, fødselsdato og adresse skal populeres med data fra folkeregisteret- epost og telefon skal populeres med data fra kontakt- og reservasjonsregisteret

For å verifisere dette må vi opprette CV'er for ulike personer, og kontrollere at data i feltene blir fylt ut korrekt. 

Vi lager tester* som beskriver det vi må gjøre. Vi beskriver steg for steg:

  • hva den som tester skal gjøre (f.eks. klikke på en link)
  • hva resultatet skal være (at den linkede siden åpnes i en ny side i nettleseren)

*en test kalles også test case eller testskript

OPPGAVE 1

Ta utgangspunkt i krav nr. 4 fra CV-eksemplet, og lag forslag til minst tre teststeg. Du finner eksemplet her: https://confluence.adeo.no/x/ykB8DQ


Hva skal vi teste? (del 2)

Testtilfeller

Det er lurt å starte med en brainstorming av testtilfeller før vi begynner å skrive detaljerte tester. 

Vi tar utgangspunkt i kravene. I tillegg må vi bruke domenekunnskap, kjennskap til operative systemer, og fantasien til å tenke ut testtilfeller. Finnes det ulike måter å gjøre ting på? Er resultatet ulikt for ulike type testdata? Hvilke feilsituasjoner kan oppstå?

Resultatet av brainstormingen ser i vårt tilfelle slik ut:

  • felter og ledetekster skal være i henhold til kravbeskrivelsen
  • det kan registreres data i alle felter
  • knapper fungerer som forventet
  • du kan legge inn 2000 tegn i feltet for lenker 
  • sjekk at alle data kommer med i CV'en

Negativ test

I tillegg til å verifisere at funksjonaliteten fungerer som forventet, må vi prøve å få programvaren til å feile. Dette kalles ofte negativ test. 

Vi kan for eksempel:

  • skrive tall i stedet for bokstaver/bokstaver i stedet for tall
  • skrive inn veldig lange navn 
  • legge inn ugyldige datoer

Det er en stor fordel å være analytisk, grundig og kritisk for å lage gode tester. 

OPPGAVE 2

Ta utgangspunkt i skjermbildene du finner nedenfor kravbeskrivelsen på https://confluence.adeo.no/x/ykB8DQ. Lag en liste over hva som bør testes.

Sant eller usant?

  • Krav kalles også akseptansekriterier.
  • Tester beskriver hva testeren skal utføre, og hva resultatet av dette skal være.
  • Det er alltid lurt å starte med detaljene når vi skal lage tester.
  • Testere skal prøve å få ting til å feile. Det kalles negativ test.

Leksjon 4 - HVA SKAL DU GJØRE I PRAKSIS?

Hvilke verktøy (programvare) bruker vi når vi tester?

Hovedverktøy

Innledning her om at det finnes mange ulike verktøy som brukes i forbindelse med testing. Under forklarer vi tre av de mest brukte i NAV.

JIRA

KLADD

JIRA er et oppgavestyringsverktøy som...

Confluence

KLADD

Confluence brukes til...

HP ALM (QC)

KLADD

HP ALM (Quality Center) brukes til ....

Praktisk oppgave: fra JIRA til Confluence

Finn dokumentasjon av epos og historier

KLADD

Her skal det inn en oppgave: 

  • Finn et epos og tilsvarende Confluence-side
  • Finn de underliggende historier og de tilhørende Confluence-side

Praktisk oppgave: fra krav- og løsningsbeskrivelse til test

Lag en test

KLADD

Her skal det inne en oppgave:

  • Analyse & design: kladd en test
  • Implementer: steg for steg for å lage den i HP ALM

Praktisk oppgave: eksekver en test

Kjør (eksekver) en test

KLADD

Her skal det inn en oppgave:

  • Kjør en test steg for steg i HP ALM
  • Tips: notater, screen shot med mer

Praktisk oppgave: meld en feil

Melde feil

KLADD

Her skal det inn en oppgave:

  • Melde en feil: steg for steg i HP ALM/JIRA

Leksjon 5 - MER OM TEST (testnivåer, testtyper og testfaser)

Testaktiviteter

Kategorisering av testaktiviteter

Testing er en integrert del av systemutviklingsprosessen, ved at det finnes testaktiviteter som tilhører de ulike fasene og aktivieteter. Vi definerer testaktiviteter ved hjelp av:

  • testnivåer - beskriver hensikten med testaktivitetene relatert til systemutviklingsaktiviteter
  • testfaser - definerer en fase og/eller tidsperiode for når ulike testaktiviteter skal gjennomføres

I tillegg til de prosessrelaterte aktivitetene har vi ulike testtyper. Disse retter seg mot test av produktets ulike kvalitetsegenskaper (f.eks. brukervennlig, sikkerhet eller ytelse).

Hva er riktig forklaring?

  • Testfase
    Definerer en fase/tidsperiode for når ulike testaktiviteter skal gjennomføres.
  • Testnivå
    Beskriver hensikten med de ulike testaktivitetene som er relatert til systemutviklingsfasene.
  • Testtype
    Ulike typer test rettet mot ulike typer kvalitetsegenskaper.

Testnivåer

Testnivåer

Det er ulike mål for de ulike testaktivitetene, og vi beskriver disse som testnivåer. Nedenfor følger en kort forklaring av ulike testnivåer. 

Enhetstest utføres av utviklere for å sikre at koden deres virker og oppfyller kravene. Det er kun en liten bit av koden som testes.

I vårt eksempel kan en slik kodebit for eksempel være den instruksjonen utvikleren har laget for at det kun er seksjonen for Personalia som er åpen når vi skal starte med å registrere en CV. 

Komponenttest  er når vi tester komponenter bestående av flere enheter (kodebiter). 

I vårt eksempel kan en komponent for eksempel være funksjonalitet for registrering og endring av arbeidshistorikk.

Integrasjonstest er når vi tester funksjonaliteten til to eller flere komponenter som har blitt satt sammen (integrert).

I vårt eksempel kan det være å teste integrasjonen av komponenten som henter data fra folkeregisteret med komponenter for Personalia-seksjonen i selve skjemaet. 

Fra komponenttesten vet vi at Personalia-seksjonen fungerer som forventet, og det har også blitt testet at de riktige dataene hentes fra folkeregisteret. Men hva skjer når vi integrerer disse to komponentene? Vi må verifisere at funksjonaliteten i de to komponentene fortsatt fungerer. Vi må også verifisere at innhentete data vises korrekt i skjemaet.

Systemtest handler om å teste systemet som helhet. Vi må verifisere at systemet fungerer som forventet når systemets komponenter er satt sammen.

I vårt eksempel vil fokus være på prosessen for registreringen av CV som helhet, i tillegg til andre biter av systemet som hører sammen med denne. 

Systemintegrasjonstest handler om å teste samhandlingen mellom systemer. 

I vårt eksempel må CV-systemet og folkeregisteret snakke sammen. CV-systemet ber folkeregisteret om data for spesifikke personer, og må behandle disse dataene når de returneres fra folkeregisteret.

Akseptansetest er når vi tester mot kravene for å verifisere at disse er oppfylt. I praksis vil akseptansetest inneholde mange av de samme testene som i de andre nivåene. Når vi har fokus på kravene trenger vi strengt tatt ikke kjenne til hvilke komponenter eller systemer som snakker sammen. 

I vårt eksempel må vi verifisere alle kravene på kravlisten før vi kan akseptere løsningen.

Kundetest i NAV

Når tester vi hva?

I NAV utfører vi noe av utviklingen selv, men vi bruker også leverandører til å gjøre utviklingen for oss. Leverandørene er konsulentselskaper vi har tegnet avtale med for å levere oss systemutviklingstjenester. I de tilfellene vi bruker leverandører til å gjøre utviklingen så betegner vi oss selv (NAV) som kunden

Når vi opererer som kunde er det testnivået akseptansetest som er hovedfokuset vårt. Vi utfører akseptansetest i flere faser:

  • Kontrollpunktstest (KPT) er en fase som utføres gjentatte ganger i løpet av konstruksjonsperioden
  • Akseptansetest (AT) er en fase som gjennomføres etter at konstruksjonsperioden er avsluttet

OBS!: Vi har altså både et testnivå akseptansetest, og en fase som kalles akseptansetest (AT).

Leverandører er i hovedsak kun anvarlig for "sitt" system. Som kunde må vi derfor også ta ansvar for testnivået systemintegrasjonstest i KPT og AT. Dette gjør vi gjerne i form av "ende-til-ende-test". Det er en metode som brukes for å teste om flyten i en applikasjon fungerer som spesifisert fra start til slutt. Hensikten med å gjennomføre en slik test er å identifisere systemavhengigheter, og å sikre at riktig informasjon sendes mellom ulike systemkomponenter og systemer.

Testtyper

Hvilke ulike testtyper finnes det?

Det finnes en rekke ulike testtyper som har som mål å teste ulike egenskaper ved produktets kvalitet. Eksempler på dette er:

  • brukervennlighetstest (i hvilken grad løsningen er lett å lære, forstå og drifte)
  • ytelsestest (måling av responstid og test av kapasitet under gitte kriterier)
  • sikkerhetstest (testing for å vurdere sikkerheten til en løsning)

Regresjonstest er en type test som er aktuell på alle testnivåer. Alle endringer kan forårsake nye feil. Derfor er det viktig å teste om eksisterende funksjonalitet er intakt. Vi må regresjonsteste når ny funksjonalitet har blitt utviklet, når forbedringer har blitt utført og når feil har blitt rettet. 

I vårt eksempel kan det bety at vi må teste layout på utskrift av CV på nytt dersom det blir lagt til et ekstra datafelt i CV'en.

Leveranser i NAV

Hovedleveranser

I NAV gjennomfører vi fire hovedleveranser (HL) i året. En hovedleveranse vil si at det leveres endinger i mange av NAVs systemer samtidig. Tidsplanen for en slik leveranse viser en oversikt over ulike fasene som skal gjennomføres, og når: 

Under konstruksjon ser vi at det er angitt ulike iterasjoner. En iterasjon er her en systemutviklingssyklus. Testnivåene som enhetstest, komponenttest, integrasjonstest og systemtest gjennomføres (av leverandøren) som en del av hver iterasjon. I slutten av hver iterasjon gjennomfører vi (som kunde) såkalt Kontrollpunktstest. Vi akseptansetester det som er utviklet hittil. 

Når all utvikling er avsluttet gjennomføres en fase som kalles avsluttende systemtest (ST) av leverandør, og deretter kundens akseptansetest (AT).

Sant eller usant?

  • Testing er en integrert del av systemutvikling, ved at de ulike systemutviklingsaktivitetene har tilhørende testaktiviteter.
  • Et testnivå er det samme som en testfase.
  • Testfaser handler om tid, mens testnivåer og testtyper handler om hva som skal testes.
  • Testnivået akseptansetest kan utføres både underveis i utviklingen, og etter at systemet er ferdig utviklet.
  • Regresjonstest er test vi utfører for å verifisere at endringer ikke har introdusert nye feil.
  • Sikkerhetstest er en type test vi utfører etter at utviklingen er ferdigstilt for å være helt sikre på systemet er feilfritt.

Leksjon 6 - MER OM TEST (testledelse, testmiljø og testdata)

Hva er et testmiljø?

Hva er et testmiljø?

Dersom vi gjør større endringer i et system eller en løsning, så kan vi ikke gjøre det rett inn i systemet som er i bruk. Vi lager derfor en kopi av produksjonssystemet i et eget testmiljø. Det betyr at du kan logge deg på et system som ligner produksjonssystemet, men som kan inneholde andre data (mer om testdata og personvern under "Hva er testdata?") . 

Testmiljøer består typisk av maskinvare, programvareverktøy og andre elementer. I testmiljøet kan vi prøve ut ting på andre måter enn i et produksjonsmiljø. Vi kan for eksempel lage CV'er for andre brukere enn oss selv, eller utøve operasjoner vi ikke selv ville hatt tilgang til i produksjonssystemet.

I NAV har vi ulike testmiljøer til ulike formål. Vi snakker gjerne om:

  • U-miljøer (utviklingsmiljøer)
  • T-miljøer (systemtestmiljøer)
  • Q-miljøer (akseptansetestmiljøer)

U-, T- og Q-miljøer er i ulik grad "komplette". Q-miljøene skal være tilnærmet like produksjonsmiljøene ved at man har tilgang på de fleste systemer, og at disse snakker sammen. Systemintegrasjonstest og ende-til-ende-tester på tvers av flere systemer krever komplette miljøer. 


Husker du? Huk av for riktig svar.

  • Et testmiljø er en kopi av et system i produksjon.
  • Vi må alltid teste i et testmiljø.
  • Testmiljøer gir oss mulighet til å utføre operasjoner vi ikke har tilgang til i produksjonssystemet.

Hva er testdata?

Hva er testdata?

Testdata er data (informasjon) vi bruker i forbindelse med testing. Det kan være data som allerede finnes i systemet eller i en fil, eller det kan være data vi konstruerer selv mens vi utfører funksjoner i systemet. Testdata påvirker, og blir påvirket av, testingen vi utfører. 

I vårt eksempel kan testdata være de ulike brukerne (inkludert info om personalia etc.) vi lager CV'er for. CV'ene vi oppretter under testingen kan også betegnes som testdata. 

I NAV benyttes flere ulike typer av testdata:

  • reelle data (produksjonsdata) er opplysninger som ikke er endret og kan spores til enkeltindivider
  • maskerte data er reelle datasett som er anonymiserte slik at det ikke er mulig å identifisere enkeltindivider ved bruke av et felt, en kode eller andre metoder
  • fiktive data er data som genereres for testing og som ikke er basert på reelle data

Personvern er viktig også under testing, og det er derfor strenge regler for bruk av testdata. Blant annet: 

  • fiktive data skal som hovedregel benyttes
  • maskerte data kan benyttes der fiktive data ikke er tilgjengelig
  • personer med kode 6 eller 7 skal ikke finnes i NAVs testmiljøer


Vær obs på dette når du utarbeider test, og logger testresultater og avvik. Spør testlederen din om du er usikker!

Husker du? Huk av for riktig svar.

  • Testdata kan finnes både i og utenfor systemet.
  • Vi skiller mellom reelle data, maskerte data og fiktive data.
  • Det er ikke så nøye med personvern når vi tester.
  • Du skal spørre testlederen din når du er usikker på hvordan du skal forholde deg til personvern i forbindelse med testdata.

Hva gjør en testleder?

Hva gjør en testleder?

Testlederens oppgaver har å gjøre med planlegging, overvåking og styring av testaktiviteter og testrelaterte oppgaver. 

Typiske ansvar og oppgaver for en testleder er:

  • estimere testomfang og behov for testressurser
  • utarbeide testplaner og teststrategi
  • sørge for at testmiljøer og testdata er tilgjengelig
  • daglig ledelse av testaktiviteter
  • rapportere status




Du kan forvente at testlederen din:

  • gir deg oppgaver, og hjelper deg med å prioritere disse
  • støtter deg i gjennomføring av dine oppgaver med å lage tester og å kjøre tester
  • hjelper deg med spørsmål om sånt som bruk av verktøy, testdata, tilgang til testmiljøer og registrering av feil
  • ruter deg videre til rett person ved behov

Hva er riktig forklaring?

  • Testmiljø
    Består av maskinvare og programvare, og er gjerne en kopi av et system i produksjon.
  • Testdata
    Kan finnes i systemet eller en fil. Kan også konstrueres av testeren.
  • Testleder
    Planlegger, overvåker og styrer testaktiviteter.