TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

Transkript

1 TDT4735 Systemutvikling, fordypning Metoder for systemtest av websystemer Hong Trang Thi Nguyen Veileder: Tor Stålhane Høst Norges teknisk-naturvitenskapelige universitet

2 Forord Dette prosjektet er skrevet i forbindelse med fordypningsfaget TDT4735 Systemutvikling på NTNU i 5. årskurs ved Institutt for Datateknikk og Informasjonsvitenskap, IDI. Oppgaven handler om metoder for systemtesting med fokus på websystemer. Jeg vil gjerne sende en stor takk til IT-sjefen for Proxycom, Trond Johansen, for å ha delt sine praktiske erfaringer og gitt meg gode råd når det gjelder systemtesting. Jeg setter også stor pris på Proxycom og Sparebank 1 som har tatt seg tid til intervjuer, slik at jeg fikk mange gode opplysninger om deres arbeid innenfor dette emnet. Til slutt vil jeg gjerne takke min veileder, Tor Stålhane, for den gode oppfølgingen og hjelpen gjennom dette semesteret. Trondheim 20/ Hong Trang Thi Nguyen II

3 Innhold 1 Innledning Oppgavebeskrivelse Mål med prosjektet Testing Definisjon av testing Testklassifisering Black Box White Box Testfaser Modul/Enhetstest Integrasjonstest Systemtest Regresjonstest Usability test Akseptansetest Plassering av systemtesting i prosjektutviklingen Forstudium Kravspesifikasjon Design Programmering Testing Vedlikehold Praktiske erfaringer med systemtest Feilfinning Testplan Testteam Testrapport Risikoanalyse Konfigurasjonshåndtering Websystem Definisjon av websystem Struktur Krav til websystem Intervju med IT-bedrifter Proxycom Bedriftsintervju med Proxycom Sparebank Bedriftsintervju med Sparebank Krav til metoder for systemtesting av websystemer Metodeundersøkelse 23 III

4 7.1 Metoder for systemtesting Resultat fra metodeundersøkelsen Oversikt over aktiviteter ved systemtesting Generell fremgangsmåte for utførelsen av systemtesting Design for testcase Definisjon av testcase Fremgangsmåte for å lage testcase Illustrering av å lage testcase Oppsummering Validering av prosjektet 42 A Vedlegg - Spørsmål til bedriftsintervju 43 B Vedlegg - Bedriftsintervju med Proxycom 44 C Vedlegg - Bedriftsintervju med Sparebank 1 47 D Vedlegg - Ordforklaringer 50 Figurer 1 Testmodell Testrekkefølge V-modell Websystem arkitektur Use Case diagram for funksjonenene kunden har i systemet Use Case for Bestill produkt Tabell over alle hendelser i riktig rekkefølge Sekvensdiagram - Bestill produkt Tabeller 1 Tabell som viser ansvarsfordeling Tabell for risikoanalyse Kravmatrise for metodene A: Gradering av feil B: Gradering av feil Tabell over alle testene med tilhørende krav Malen for testtabell basert på IEEE std Liste over feil ved første systemtest Liste for testresultatene Use Case - Bestill produkt Testcase - Bestill produkt

5 1 Innledning 1.1 Oppgavebeskrivelse Testing er viktig for å kontrollere validering og verifikasjonsprosessen. Validering er å finne ut om vi har laget det rette produktet, mens verifikasjon ser på om man har laget produktet på riktig måte. Validering og verifikasjon brukes på alle trinn i systemutviklingen for å sikre at systemet følger spesifikasjonen og at man lager det som brukeren ønsker [35]. Testing er et stort emnet i systemutvikling, derfor har jeg begrenset oppgaven til metoder for systemtesting av websystemer. Dette syns jeg er et interressant emnet, for det er viktig å utføre så god systemtesting av websystemer som mulig, ellers kan det få katastrofale konsekvenser for bedrifter. I kapittel 2 vil jeg beskrive hva testing er og hvilke typer tester som man bør utføre for websystemer. Kapittel 3 handler om ulike faser i prosjektutviklingen med tilhørende dokumenter. Det er viktig å vite de praktiske erfaringer med systemtesting som er beskrevet i kapittel 4. Oppgaven går ut på å finne en systematisk metode eller retningslinjer for systemtesting og utforming av testcase manuelt, derfor har jeg foretatt metodeundersøkelser i kapittel 7 ved å intervjue to IT-bedrifter. Hvilke krav disse bedriftene har til systemtesting av websystemer er beskrevet i kapittel 6, og nærmere beskrivelser av strukturen til websystemer i kapittel 5. Hvilke aktiviteter som finnes ved systemtesting, og hvordan man utformer gode og testbare testcase er beskrevet i kapittel 8. Oppsummering og validering av prosjektet finnes i kapittel 9 og Mål med prosjektet Dårlig systemtesting av websystemer kan føre til store økonomiske konsekvenser, derfor er det behov for bedrifter å få mer informasjon om flere metoder for systemtesting av websystemer slik at man kan tilpasse en metode til sitt eget prosjekt. Det er mange bedrifter som ikke benytter noen bestemte metoder eller verktøy for systemtesting. Fremgangsmåten som mange benytter idag er manuell systemtesting basert på egne erfaringer. Å utføre systemtesting av websystemer systematisk er en god fremgangsmåte for å sikre at alle de viktige aktiviteter blir utført. Det er også viktig å ha en god fremgangsmåte til å lage testcase i systemutvikling. Målet med dette prosjektet er derfor å finne informasjoner om metoder for systemtest av websystemer, og samtidig beskrive en systematisk fremgangsmåte i systemtesting av websystemer og utforming av testcase slik at bedrifter kan høy sannsynlig utvikle et kvalitetsprodukt. Alle bedrifter vil at deres produkter og tjenester skal vise kvalitet og effektivitet, og det er essensielt at testing må være godt utført. Ved å ha en formalisert testprosess kan man oppdage feil som oppstår på et tidlig tidspunkt, og da har man mulighet til å rette dem opp før man lanserer produktet. Dette vil føre til mange fordeler for en bedrift som besparelse av tid, ressurser og kostnader. Jo senere en feil oppdages, desto mer alvorlig og større konsekvenser får den. 2

6 2 Testing Testing har lenge vært undervurdert i systemutvikling, og mange prosjekter mislykkes på grunn av dette. Testing er viktig i alle utviklingsarbeid, fordi testing vil kunne validere om kravene til et system er tilfredsstilt som forventet. Testing er nødvendig, så det er viktig å vite hva testing egentlig er. 2.1 Definisjon av testing Testing brukes for å kontrollere utførelse, pålitelighet og brukergrensesnitt og for å sjekke om kravene var riktig i forhold til hva brukeren ønsker [34]. Målet for testing er å sjekke hvor godt et system oppfyller kundenes krav, og resultatet av kjøringer blir sammenlignet med fasit. Det er derfor lønnsomt å teste tidlig og jevnlig under hele utviklingen. Når man snakker om testing vil man ofte forbinde det med kvalitetssikring. Hensikten med testing er å finne feil, og en vellykket test er en test der man finner feil i programkoden, designet, kravspesifikasjonen eller dokumentasjonen for systemet [27]. Fordelen med testing er at man kan finne feil i tidlig fase av utviklingen, slik at man kan spare tid og arbeid. Testing kan ikke garantere at systemet er feilfri, men testing kan brukes til å vurdere om man vil eller kan produksjonssette en release av et system. Det er større sannsynlig at testing blir vellykket, dersom den inneholder disse tre punktene [7]: Repeterbarhet : hvis man finner feil, repeterer man senere testen for å sjekke at feil er blitt fikset. Systematisk : random (tilfeldig) testing er ikke tilstrekkelig, derfor er det lurt å gjennomføre testing systematisk for å dekke alle brukstilfellene i systemet. Dokumentert : bedre oversikt når man har skrevet testdokumentet med resultater fra testene, slik at kunden kan også se hvilke tester som er blitt utført for systemet. Det er viktig å skille mellom debugging og testing. Debugging reparerer en påvist feil, og testing søker å påvise slike feil. Debugging er en prosess for lokalisering hvor i koden feilen ligger, og deretter blir feilen rettet opp. Debugging skjer på følgende måte [2]: Bruke minimal test som fremprovoserer feil. Lokaliser feil. Reparer feil. Teste igjen med minimal test. 3

7 Figur 1 viser en typisk testmodell i systemutvikling. Under testingen setter man opp et sett av inndata og forventede utdata basert på de gitte inndata, og kjører deretter testen for å sjekke om de faktiske resultatene stemmer overens med de forventede resultatene. Figur 1: Testmodell Her er en nærmere beskrivelse av figuren: Testobjekt: systemet vi skal teste Testprogram: aktiviteter i testprosessen 1. Spesifisere tester 2. Utføre tester 3. Skrive testrapport Inndata: det som skal testes Utdata: forventede resultater eller output 4

8 Et system kan befinne seg i ulike tilstander avhengig av hvor i utviklingsprosessen det er. De lagrede data i databasen bestemmer systemets tilstand. Systemets output bestemmes ikke bare av input, men også av systemets tilstand. Variablene i det kjørende programmet vil forandre seg under testingen, og systemets tilstand vil være avhengig av databasens innhold. Det er viktig å identifisere hver enkelt transaksjon med en transakjonsid som er generert automatisk av databasesystemet. Systemloggen lagres regelmessig på disk og brukes for å gjenopprette tilstanden i databasen rett før feilsituasjonen oppstod [17]. 2.2 Testklassifisering Nedenfor har jeg tatt for meg to måter å gjennomføre test på, Black box- og White box testing Black Box Black box testing eller funksjonell testing er en testmetode der testen bygger på programmet eller komponentspesifikasjon. Under black box testing velger man tester ved å se på systemets eller komponentens grensesnitt og ikke på hvordan komponenten er realisert [1]. Black box [11]: Sterke sider: Lett å bevare fokus på og teste funksjonaliteten. Lett å automatisere testen ut fra kravspesifikasjonen. Svake sider: Kan ikke hjelpe oss når vi skal finne feil i koden White Box White box er en metode der testene bygger på kunnskap om programvarestrukturen og implementasjon. White box testing skjer når man velger tester ut fra hvordan systemet eller komponenten er realisert. Hensikten er å teste alle veier gjennom systemet [1]. White box [11]: Sterke sider: Kan teste alle veier og ta hensyn til spesielle forhold ved implementasjonen. Svake sider: Lett å fortape seg i detaljer ved implementasjonen og glemme funksjonaliteten. 5

9 2.3 Testfaser Testing er en aktivitet som vil foregå under hele utviklingsprosjektets levetid. Det er viktig å gjennomføre testing på flere nivåer for å avdekke feil og kvalitetssikre produktet. Typiske former for testing underveis er enhetstesting av kodemoduler, integrasjonstesting når man setter sammen flere moduler eller skal ha systemet til å fungere sammen med eksterne systemer, brukbarhetstesting for å avdekke problemer med brukergrensesnitt. Vi kan begynne å teste modulene etterhvert som de blir utviklet, for så å teste om den fungerer i samspill med resten av systemet som er utviklet. Dermed vil feil bli oppdaget på et så tidlig tidspunkt som mulig [29]. Teststrategien medfører følgende tester : Modul/Enhetstest Integrasjonstest Systemtest Regresjonstest Usability test Akseptansetest Alle disse testfasene er ikke nødvendig for alle prosjekter, men i websystemer bør man ihvertfall bruke de fire testfasene enhetstest, integrasjonstest, systemtest og akseptansetest. Det er vanlig å gjennomføre disse testfasene i den rekkefølgen som er vist i figur 2, og gjerne i flere iterasjoner. En iterasjon er gjennomgang av hele rekken av arbeidsoppgaver. Man planlegger, spesifiserer, designer, implementerer, integrerer og tester litt av gangen for hver iterasjon. Figur 2: Testrekkefølge 6

10 Alle disse testene utføres når systemet lages første gang og ved enhver senere endring av systemet. Enhetstest og integrasjonstest utføres med White box testing, fordi testene gjerne forutsetter innsikt i systemets indre oppbygning. Metoder og verktøy for disse to testfasene er ofte ganske like, og det er ikke uvanlig at de flettes mer eller mindre sammen. Systemtest og akseptansetest utføres med Black box testing, fordi testene ikke skal forutsette innsikt i systemets indre oppbygning. Metoder og verktøy for disse to fasene er ofte ganske like, så i prosjekter med sterk brukermedvirkning er det derfor er det vanlig at de flettes mer eller mindre sammen [28] Modul/Enhetstest Enhetstest eller modultest er testing av en avgrenset del av et system separat. Enheten som tester en enkelt modul som f.eks. en klasse eller kildekodefil uten de andre enhetene som den normalt kommuniserer med Integrasjonstest Integrasjonstest er testing av grensesnittet mellom enheter eller moduler i et system. Denne testingen utføres med White box testing og tar utgangspunkt i både koden og designet. Integrasjonstesten skal ikke dekke all kode, og heller ikke all funksjonalitet. Den har fokus på det som ikke er med i enhetstestene, det vil si fokusere på at de enhetstestede modulene fungerer sammen som de skal [28]. Integrasjonstesten kan godt inneholde noe ad hoc testing i tillegg, og ad hoc testing betyr i denne sammenheng å teste brukergrensesnittet på tvers av enhetene som systemet er bygget opp av. Ad hoc testing bør tas med når man har integrert seg opp til et nivå med brukergrensesnitt Systemtest Systemtest består i å teste systemet som helhet, og grunnlaget for testingen er kravspesifikasjonen for systemet. Her tester man om systemet oppfører seg korrekt i samspill med omgivelsene, og denne testingen blir ofte utført av en egen testgruppe. Systemtest skal ikke bare teste funskjonelle kravene, men skal også inkludere ikke-funksjonelle tester [28]. 7

11 De typiske testene innen systemtest for websystemer er ytelsestest, sikkerhetstest, stresstest, recoverability-test og nettlesertest. For websystemer trenger man [11]: Funksjonell test for å sjekke om en modul tilfresstiller de eksterne kravene man har satt til den. Ytelsestest for å teste hastigheten for en transaksjon. Sikkerhetstest for å sikre systemet mot inntrengere. Stresstest for å teste hastigheten på mange samtidige transaksjoner. Nettlesertest for å sørge at systemet støtter alle versjoner av nettleserne. Recoverability-test for å sjekke systemets håndtering av uforutsette avbrudd Regresjonstest Regresjonstest betyr gjentagelse av en eller flere testfaser for å verifisere at feilrettinger eller endringer ikke har introdusert nye feil eller uønskede effekter [28]. Denne testingen skal samtidig sjekke at systemet fremdeles tilfredsstiller de spesifiserte kravene. Man kjører bare en utvalgt del av de aktuelle testfasene for å spare tid. Regresjonstest er nødvendig i forbindelse med feilretting under nyutvikling, eller når man senere lager nye utgaver av systemet Usability test Usability testing, eller brukbarhetstesten er testen for å finne ut hvor lett systemet er å forstå og bruke [31]. Ved å observere brukere under brukbarhetstesten vil man få tilbakemeldinger på hva som bør forbedres i eksisterende systemer. Man trenger brukbarhetstest for å teste designet mot virkeligheten, altså av reelle brukere Akseptansetest Akseptansetest blir ofte kalt for en alfa test, og hensikten med denne testen er å få systemet godkjent av kunden [35]. For at systemet skal bestå akseptansetest må systemet fungere i henhold til brukernes krav. Akseptansetest er nesten samme som systemtest, men her blir testingen utført av kunden. 8

12 3 Plassering av systemtesting i prosjektutviklingen Det finnes mange forskjellige systemutviklingsmodeller idag. Fossefallsmodell og inkrementellutvikling er de mest brukte i prosjektutvikling. Systemutviklingsmodellene gir en oversikt over faser, aktiviteter og milepæler til et IT-prosjekt [20]. I fossefallsmodellen deles prosjektene opp i forstudie, kravspesifisering, design, programmering og vedlikehold, mens inkrementell utvikling innebærer at et system utvikles trinnvis i flere iterasjoner [25]. Uansett hvilke modell man bruker i systemutvikling, så bør den inneholde disse fasene: 1. Forstudium 2. Kravspesifikasjon 3. Design 4. Programmering 5. Testing 6. Vedlikehold Når man har analysert kundekravene grundig og konstruert en logisk modell for systemet, vil det være mer sannsynlig at prosjektet lykkes. Det er vanlig å bruke de fire testtypene enhetstest, integrasjonstest, systemtest og akseptansetest i websystemer. Her er en V-modell som skal vise sammenhengen mellom dokumenttyper og testfasene [28]: Figur 3: V-modell 9

13 3.1 Forstudium Forstudiet fokuserer på å avklare omfanget av systemet, slik at man kan finne ut hvor stor kostnad og tid det vil være for å utvikle et bestemt system. Man trenger denne fasen for å avgjøre om det er lønnsomt for organisasjonen å gå videre med prosjektet eller om den bør stoppes. Noen av hovedaktivitene i denne fasen er [12]: Å definere målsetning og omfang for systemet. Å lage et overordnet systembeskrivelse. Organisering av prosjektgruppen. Estimering av kostnader og tid. Utarbeide risikoliste. Å vurdere alternative løsninger. Planlegging av videre arbeid. 3.2 Kravspesifikasjon I denne fasen er det viktig å forstå kundekravene, og for å sjekke om man har forstått kunden riktig bør man tenke gjennom hva kunden ønsker seg, hvilke problemer som skal løses og hvordan man kan omforme kundekrav til systemkrav på best mulig måte. En annen viktig del av kravspesifikasjonen er sporing av kundekravene. Sporing fra kode til krav og omvendt kan være viktig for å skjønne implementasjonen, og det vil lett oppstå problemer dersom kravene ikke er entydig spesifisert. Det finnes mange krav, så det er vanlig å dele dem inn i to hovedgrupper: Funksjonelle krav : Hva systemet skal gjøre. Ikke funksjonelle krav : Hvordan systemet skal gjøre det, f.eks. responstid. 3.3 Design Når man har analysert kundekravene, kan man gå til designfasen. I denne fasen er det viktig at man lager modeller som for eksempel systemstruktur på en forståelig måte, slik at programmerer realiserer løsningen. 10

14 3.4 Programmering I programmeringsfasen skal man utvikle programsystemet med fokus på å tilfredsstille kundekravene. Programmerere skal realisere løsningen ut fra designdokumentet, og noen oppgaver som programmerer må utføre er [18]: Utarbeide programmoduler Utføre refaktorering: refaktorering er en teknikk som går ut på minst mulig kostnad å endre på programkoden. Skrive kode for metoder 3.5 Testing Det er viktig å teste grundig for å sikre kvaliteten på produktet. Testtypene som finnes er beskrevet i kapittel 2.3, og det er i denne fasen systemtest blir utført. Det er nødvendig å dokumentere testene slik at man får oversikt over hva man har testet og hvilke problemer som oppstår under testingen. Man kan velge mellom automatisert- eller manuell systemtesting, og det er fortsatt mange som benytter manuell testing siden dagens automatiserte verktøy er tidkrevende. 3.6 Vedlikehold Det finnes flere typer vedlikehold : man retter feil, tilpasser til nye omgivelser, legger til ny funksjonalitet eller endre eksisterende funksjonalitet [36]. 11

15 4 Praktiske erfaringer med systemtest 4.1 Feilfinning Når man har funnet feil i en test, må man lete etter feilkilden og rette den opp [32]. Det kan være vanskelig å finne kilden til feilen, særlig når det er flere som har bidratt i kodingen. Det er derfor vanlig å innskrenke området for hvor feilkilden ligger ved å legge inn utskrifter med meldinger om hvor langt kjøringen av programmet har kommet istedenfor å gjøre mange omkompileringer [11]. Når man observerer rekkefølgen av utskriftene etter at feilen har oppstått, vil man ha en viss anelse hvor feilen kommer fra. Dette er en systematisk måte å gjøre dette på, men endelig har man etterhvert feilfinningsverktøy som gjør det enklere for de som programmerer. 4.2 Testplan Systemtestplan Før man skal utføre systemtesting, lønner det seg å lage en systemtestplan. Uansett hvilke metode man velger for systemtesting bør man lage testplan basert på IEEE-standard [15] som inneholder: sammendrag innledning målsetting for systemtesting testverktøy: hvilke hardware/software som brukes under systemtesting klassifisering av feil gradering av feil rapportprosedyre: Testresultatene tidspunkt og personer til å utføre testing ansvarsfordeling for godkjenning av testingen: se eksempel i tabell 1 Hvorfor trenger vi en testplan? Det er nyttig å ha en testplan for alle store prosjekter, siden dette letter koordinering med andre aktiviteter i prosjektet [11]. Når man har en testplan vet man hvem som er ansvarlig for hvilke aktiviteter, hva som skal testes og hvordan man skal kjøre testene. Testplan er spesielt nødvendig å ha dersom kostnaden eller risikoen ved å feile er stor. Tabell 1 er et eksempel på ansvarsfordelingen mellom prosjektmedlemmer. 12

16 Test Tid timer Ansvarlig Systemtest timer Hong Trang Thi Nguyen Brukbarhetstest timer Berit Eleni Sirris Akseptansetest timer Olav Engelsåstrø Tabell 1: Tabell som viser ansvarsfordeling 4.3 Testteam Testing blir en stadig viktigere del av det totale utviklingsprosjektet. Et av problemene med testingen er at man ikke har fått nok opplæring i testing. Det kan være vanskelig å sette seg inn i brukerens situasjon eller at det har vært dårlig testledelse i prosjektet. Hvem burde teste hva? 1. Testere og kundestøtte : Tester det funksjonelle og grensesnittet. 2. Utviklere : Testing av funksjoner og moduler. 4.4 Testrapport Når man har fullført en test, skal man skrive en rapport som oppsummerer resultatet av testingen. Rapporten bør beskrive de feilene som er funnet, for små prosjekt holder det med testlogg [19]. 4.5 Risikoanalyse Risikoanalysen innebærer at man går gjennom alle aktiviteter i prosjektet, og tenker på hva som kan gå galt, hvor sannsynlig er det og hvilke konsekvenser det vil få [1]. Risikoanalyse er nødvendig for å prøve å forhindre slike situasjoner og eventuelt sette tiltak hvis tilfellet skjer [9]. For å oppnå en god kvalitetssikring av systemet er det viktig å utføre risikoanalyse i testing, slik at bedrifter kan vurdere hvilke tiltak som må iverksettes dersom en avvik oppstår. Risikoanalyse hjelper til å kontrollere hvorvidt endringene eller tiltak vil påvirke systemet [21].Tabell 2 er et eksempel på hvordan man kan sette opp en iverk risikoanalyse. 13

17 R3 Forandringer i kravspesifikasjon fra kunde Nr Risiko Beskrivelse Sannsynlighet Alvorlighetsgrad Begrenset innsikt i R1 Gruppen mangler kunnskap og erfaring verktøy kan forsinke prosjektarbeid eller av Høy Middels prosessen R2 Forfall i gruppen Sykdom Høy Lav R3 Feil i estimering Undervurdering av tids- Høy Høy forbruk Må gjøre deler av prosjektet på nytt. Tabell 2: Tabell for risikoanalyse Lav Høy 4.6 Konfigurasjonshåndtering En konfigurasjon er en samling av alle komponentene til et system, og der hver komponent er representert med nøyaktig en versjon. Konfigurassjonsstyring skal håndtere endringer og ulike versjoner av komponenter, og den er basert på et sett av standarder [13]. En konfigurasjonsstyringsplan bør inneholde: Info om endringer og ulike versjoner. Definering av typer dokumenter og navngivningskonvensjon Beskrivelse av verktøyene som brukes for konfigurasjonsstyring, og deres begrensninger Ferdiglagde skjemaer for endringer Oppfølging og arkivering Definering av personansvar 14

18 5 Websystem Websystemer representerer en stadig økende teknologi med mange internett brukere. Det som er utfordrende for slike applikasjoner er å benytte testing til å sikre pålitelighet, sikkerhet, robusthet og høy ytelse. Hva er kjennetegnet til websystemer og hvilke områder man bør teste når man utvikler websystemer vil bli beskrevet i kapittel 5. Hvordan vi skiller systemtesting av websystemer fra tradisjonelle programvarer blir diskutert i kapittel Definisjon av websystem Websystem innebærer lagdelte applikasjoner som aksesseres via en webbrowser; standard HTTP-protokoll, og det er den store forskjellen fra tradisjonelle programvarer. Testingen av internettløsninger vil ha tilnærmet samme strategier og metoder som testing av grafiske brukergrensesnitt. Den første utfordringen for websystemer er testing av flere nettlesere, og det bør også testes på ulike operativsystemer. Testingen går ut på å sette opp et sett av inndata og forventede utdata basert på de gitte inndata. Deretter blir testen kjørt, og man ser om de oppnådde resultatene stemmer overens med de forventede resultatene [27]. En annen utfordring er presset til å ha en time-to-market som er kort som mulig. Testene som blir gjennomført vil da ha fokus på å oppdage feil som kan forårsake uakseptable oppførsel. Det er viktig å finne en god metode eller et verktøy til å måle robusthet i websystemet, noe som jeg har utelatt på grunn av begrensing av oppgaven. Målet for alle prosjekter er å levere en feilfri vare, men i tillegg til det vil websystemer fokuserer mye på høy kvalitet, ytelse og stabilitet. Det er derfor nødvendig å benytte stabilitetstest og stresstest for å finne hvor bra systemet takler når en mengde brukere blir koplet til systemet samtidig (skalerbarhet) [14]. 5.2 Struktur Websystemer innebærer klienter som for eksempel er kundens nettleser, og en eller flere fysiske servere som bidrar til flere typer av service [14]. En server kan for eksempel være en webserver eller databaseserver som inneholder alle data. En webservice er en samling av protokoller og standarder som brukes for å dele data mellom applikasjoner. En nettleser (browser) er et program som brukes til å vise innhold ifra internett, og all spørringer vil gå fra klienten til serveren [1]. Figur 5 viser en typisk struktur for et websystem: 15

19 Figur 4: Websystem arkitektur Et websystem skal være organisert som en bok med sider, og koblingen mellom sidene bør være logisk og lett og oppfatte [22]. Det er viktig å ha et forståelig og godt brukergrensesnitt, slik at brukeren kan finne fram til den han/hun leter etter uten å måtte gå via for mange sider med linker. Linker bør plasseres slik at brukeren lett finner dem, og for å fremheve dem kan man skille linkene tydelig fra annen tekst med farge eller grafiske symboler. 5.3 Krav til websystem Følgende faktorer er viktige når vi utvikler et nettsted [37]: 1. Time-to-market: Hvor fort kan produktet leveres? Tiden det tar fra å starte produktutviklingen til produktet er ferdigstilt og tilgjengelig på markedet. 2. Robusthet: Tåler systemet uventede problemer? Et robust system må bygges på en solid fundament for ikke å feile. 16

20 3. Understøttelse: Støtter systemet eksisterende standarder og ulike versjoner av nettlesere og operativsystemer? Det bør støtte eksisterende standarder og tilrettelegge for enkle oppgraderinger. 4. Brukervennlighet: Er det lett å forstå logikken i systemet? For at systemet i det hele tatt skal få noen brukere så må det være brukervennlig og intuitivt. Hvor brukervennlig er navigasjonen på nettstedet, og hvor klart og lett forståelig er budskapet? 5. Testbarhet: Kunne alle kravene testes i det ferdige systemet? Det bør også være lett å teste systemet etter modifisering. 6. Yteevne: Oppfyller systemet kravene til responstid? Her bør man definere krav for systemets ytelse i form av nedlastingstider for hver side. 7. Sikkerhet: Er systemet sårbar for inntrengere? Systemet bør ha en beskyttelse mot hackere, og en måte man kan finne ut om systemet kan hackes på er å prøve hacke det selv. 8. Flyttbarhet: Kan systemet kjører på ulike plattformer? Systemet bør være flyttbarhet, det vil si at for eksempel klientene er web-browsere og at database løsningen kan flyttes fritt fra web-server til web-server. 17

21 6 Intervju med IT-bedrifter Oppgaven går ut på å finne gode metoder for systemtesting av websystemer og hvilke krav metodene må tilfredstille. For å vite mer om dagens bedrifter innen systemtesting, har jeg intervjuet to bedrifter for å undersøke hvilke metoder disse bedriftene benytter idag. Etter at metodeundersøkelsen er utført, skal jeg beskrive hvilke framgangsmåte og teknikker som er effektiv for systemtesting av websystemer i kapittel 8. Hensikten med intervjuene er å finne ut hvordan bedriftene jobber med systemtesting spesielt av websystemer, og hvilke krav de har til metode av systemtesting. Jeg har fulgt rådene for hvordan man bør lage og forberede et intervju fra Norsk Nettskole [16]. Det er viktig å være klar over hva du skal spørre om under intervjuet, derfor laget jeg en liste over alle de spørsmålene som skal stilles. Begge bedriftene får samme spørsmål å svare på, siden dette gjør det lettere å sammenligne svarene [9]. Først kontaktet jeg bedriftene for å avtale tidspunkt for intervjuet med IT-sjefen, så sendte jeg en til intervjuobjektene om hva dette går ut på slik at de kan forberede seg og eventuelt finne personalet som har kompetanse innenfor emnet. Det er viktig å finne generell info om bedriften og hvilket forhold intervjuobjektet har til systemtesting. Referat fra disse intervjuene ble sendt ut til intervjuobjektene for godkjennelse fra dem om at det som står der er riktig før jeg legger dem inn i prosjektrapporten min. I kapittel 6.1 og 6.2 er det en liten oppsummering fra disse to intervjuene, selve referatene har jeg lagt som vedlegg på slutten av denne rapporten. 18

22 6.1 Proxycom Proxycom er et konsulentselskap som ble etablert i De har høy kompetanse blant annet innenfor systemutvikling, kvalitetssikring og informasjonssikkerhet. Proxycom fokuserer på å dekke kundenes behov og ønsker å utvikle kvalifiserte løsninger som er kostnadseffektive og fremtidsdrevet. De er spesialister når det gjelder å utvikle IT-systemer som krever høy sikkerhet, pålitelighet, tilgjengelighet, brukervennlighet og ytelse [20]. Proxycom benytter metoden TRIUMF (TRInnvis UtviklingsMetode For programsystemer) i systemutvikling, og TRIUMF er en framgangsmåte for hvordan man bør gjennomføre alle faser i vedlikehold- og utviklingsprosjekter [12]. Proxycom har mange fagpersoner som har høy kompetanse og erfaring innen flere fagområder, derfor har selskapet også en avdeling som tilbyr IT-rådgivning. Proxycom består av tre avdelinger: Proxycom Consulting Proxycom Services Proxycom Research and Development Proxycom setter også fokus på utnyttelse av ny teknologi, for det er fremtidsrettet og vil være en fordel både for selskapet og kunden. Proxycom kan tilby IT-løsninger for datatekniske problemer for både store og små bedrifter, f.eks: Webbasert lagringsstyring Ressursplanlegger Company Management System - CMS Timeregistrering på web Kontorstøtte Reiseregning på web 19

23 6.1.1 Bedriftsintervju med Proxycom Proxycom bruker TRIUMF-modellen som sin utviklingsmodell i systemutvikling. Siden systemutviklere har godt kjennskap til kravspesifikasjonen, er det naturlig at de utfører systemtesten. De bruker vanligvis disse testene for alle sine prosjekter: enhetstest integrasjonstest systemtest ytelsestest brukbarhetstest akseptansetest Proxycom bruker hovedsakelig manuell systemtesting, men de er interessert i å finne et godt automatisert verktøy. De har prøvd ut en del verktøy for automatisert testing, men de var ikke fornøyd på grunn av at det er tidkrevende. De konverterer kravene fra kravspesifikasjonen til testcase ut fra sine egne erfaringer, men har ingen spesiell metoder for dette. Proxycom ønsker derfor å ha retningslinjer for spesielt utforming av testcase ut fra Use Case. Vanligvis bruker de omtrent 20 prosent av prosjekttiden til systemtesting, men det varierer fra prosjekt til prosjekt. Det er viktig å fokusere på brukervennligheten i websystemer for å øke tilliten hos brukere. Brukervennligheten blir avklart i kravspesifikasjonen, men det er ikke noe fullstendig lister over hva som kjennetegner brukervennlighet. Proxycom fokuserer på at GUI skal henvise til kravspesifikasjonen og skal se pent ut med tanke på plassering av knapper og tomme linjer for å gi litt luft. Det er systemutviklere som utfører i systemtesten, og brukere i brukbarhetstesten. Det er effektiv å la de personene som har utarbeidet kravspesifikasjonen til å utføre systemtest, siden de har mest kjennskap til kravene. Det er nyttig å dokumentere testcasene så godt som mulig, slik at kunden kan se hva som har blitt utført. 20

24 6.2 Sparebank 1 SpareBank 1 Gruppen er et finanskonsern med virksomheter innen bank, livs- og fondsforsikring, skadeforsikring, fond og eiendomsmegling. SpareBank 1 Gruppen er eid av SpareBank 1-bankene, LO og svenske ForeningsSparbanken AB. De har ca 950 ansatte og kontorlokaler sentralt plassert i Oslo. IT-seksjon koordinerer felles utviklings- og driftsoppgaver for enhetene i SpareBank 1 Gruppen og for SpareBank 1-alliansens 18 selvstendige banker [23] Bedriftsintervju med Sparebank 1 Sparebank 1 bruker i utgangspunktet RUP som utviklingsmodell i systemutvikling. Det finnes mange risiko ved websystemer, derfor har Sparebank 1 egne tester for sine websystemer, som for eksempel nettbank. Det er viktig å bruke nok tid til systemtesting for å holde systemene i stabil drift. Sparebank 1 bruker vanligvis disse testtypene: enhetstest funksjonelle test ytelsestest stabilitetstest tekniske test regresjonstest innstallasjonstest akseptansetest brukbarhetstest Sparebank 1 bruker foreløpig manuell testing i regresjonstesting, men de har på noen få områder bygd opp automatiske script for dette (QTP). De har beskrevne retningslinjer for systemtesting, men her er det avvik fra prosjekt til prosjekt alt etter erfaring fra de som utfører systemtesten. Det er som regel en gruppe som lager testcase basert på kravspesifikasjonen, men de har tenkt å benytte et verktøy til å konvertere krav til testcase i fremtiden. Alle prosjektene er Use Case orientert, men bruker i tillegg andre teknikker som sekvensdiagrammer i noen prosjekter. Det er brukere som utfører både i systemtest og brukbarhetstest hos Sparebank 1, fordi det er fordel å ha noen som ikke kjenner så godt til kravspesifikasjonen enn systemutviklere til å teste systemet. Systemtest skal egentlig være en intern test utført av systemutviklere, men det er leverandør som har ansvaret for systemtesting av prosjektet og Sparebank 1 som mottaker er ansvarlig for akseptansetest. Testing er viktig for Sparebank 1, derfor har de lagt mye vekt på å sette av nok tid til det. Når det gjelder systemer for ansatte så går omtrent 50 prosent av prosjekttiden til testing, og for eksterne systemer omtrent 70 prosent. 21

25 6.3 Krav til metoder for systemtesting av websystemer Oppgaven fokuserer på manuell systemtesting av websystemer, derfor bør metoden være beregnet på dette. I tillegg bør den være Use Case orientert og testcasene skal kunne skrives i et uformelt språk. Proxycom vil gjerne ha retningslinjer både for utforming av testcase og aktiviteter i systemtesting, og for hvordan testscript kan utformes slik at databasen kan tilbakestilles etter testen. Sparebank 1 vil gjerne ha mer av automatisert testing der testscriptene kan bygges og kjøres om natta. Automatisert testing er tidkrevende, så Sparebank 1 håper at det kommer bedre verktøy i nærmeste fremtid. Ved å sammenligne svarene fra Sparebank 1 med Proxycom, så finner jeg en del ulikheter og likheter mellom dem. Andelen av prosjekttiden som brukes til testing er svært ulik i de to bedriftene. Selv om Sparebank 1 bruker RUP, mens Proxycom bruker TRIUMF som sin systemutviklingsmodell som er basert på RUP. Begge bedriftene utfører manuell systemtesting, men er på utkikk etter gode verktøy til automatisert testing. Proxycom er interessert i manuell systemtesting, mens Sparebank 1 ønsker mer automatisert testing. De kravene som Proxycom nevnte under intervjuet brukes videre i metodeundersøkelsen for å se på om det finnes metoder som tilfredsstiller alle dem. 22

26 7 Metodeundersøkelse Jeg skal undersøke hvilke metoder som kan dekke mest mulig av bedriftens krav, og den metoden som viser seg til å dekke flest mulig av kravene vil jeg beskrive i kapittel Metoder for systemtesting Mange systemutvikler vil gjerne ha en metode som kan hjelpe dem til å lage bedre systemer og samtidig tilfredsstiller kundekravene. En god metode for et prosjekt betyr ikke at det passer like godt til alle prosjekter eller applikasjoner. Det finnes mange metoder, derfor er det viktig å velge en metode som man kan tilpasse til eget formål. Jeg har valgt å undersøke noen av metodene, og en beskrivelse for hver av dem er vist nedenfor. 1. RUP - Rational Unified Process RUP er et prosessrammeverk for systemutvikling og ble utviklet av Rational Software [10]. Dette rammeverket består av de beste arbeidsmetodene fra internasjonale industriledere. RUP er en plan-drevet metode, og i denne metoden lager man en liste over alle aktiviteter som bør utføres. Man vil få en viss kontroll når man har en punktvis liste over aktiviteter i systemtesting, for da kan man sørge for at disse viktige punktene blir berørt. Systemtesting blir gjennomført systematisk, og dette kan bidra til god oversikt over hva som skal testes og hvilke feil som må gjenopprettes. Metodikken for RUP er å redusere prosjektrisiko, forbedre kommunikasjonen i prosjektteamet, forbedre kontroll over prosjektplan og effektiv bruk av UML [10]. Metodikken går ut på: Lage en detaljert design dokumentasjon av Software. Software blir implementert. Software blir testet. Software blir innstallert hos kundene. RUP gir en rettledning i hvordan man fordeler ansvar og arbeidsoppgaver innen et utviklingsprosjekt. Hele systemet er Use Case drevet og testing tar utgangspunktet i Use Casene. Når man bruker RUP i systemutvikling, vil man alltid ha oversikt over hva som er neste skritt i prosessen. RUP bidrar til å oppnå høy kvalitet på det ferdige produktet og tilfredsstiller kravene fra sluttbrukerne innen en bestemt tidsramme og budsjett. 23

27 2. XP - Extreme Programming XP representerer en kodesentrisk utviklingsmetode med vanligvis få personer involvert, og denne metoden består av parprogrammering og partesting. Metoden legger mye vekt på kode og ikke modeller, derfor begynner programmeringen tidligere enn i andre metoder [39]. Med XP får man tettere samarbeid med kunden, og kunden får vanligvis konkrete resultater tidlig slik at han/hun har større muligheter til å gjøre endringer underveis. Metodikken går ut på: Kodegjennomgang Design: endre hele tiden Testing : teste hele tiden Enkelhet: Velge alltid den enkleste mulige løsning 3. ISO- og IEEE standard Mange bedrifter bruker et kvalitetsstyringssystem basert på ISO standarder for å leve opp til kundenes krav [15]. Standarden ble utviklet av den Internasjonale Organisasjon for Standardisering, ISO, for å fastsette internasjonale krav til et ledelsessystem for kvalitetsstyring [4]. Et kvalitetsstyringssystem med interne rutiner vil bidra til økt kundetilfredshet. Mange systemutviklere bruker også standard for IEEE, og der finner det en retningslinje for systemtesting når man lager testplan eller testcase [24]. Standarder inneholder dokumentasjon for kriterier, begreper og definisjoner og tekniske spesifikasjoner. 4. Scenariobasert testing Noen prosjekter bruker scenariobasert testing til å dokumentere kravene, og for hvert brukstilfelle lages det tester som skal verifisere at brukeren kan utføre de definerte funksjoner som forventet [15]. Scenariobasert testing er nødvendig i alle prosjekter for å sjekke at alle brukstilfellene fungerer, for problemer som oppstår trenger ikke komme fra en komponent, men fra interaksjonen mellom komponenter [38]. Scenario er relevant for de fleste testtyper som for eksempel systemtest, akseptansetest osv. 24

28 7.2 Resultat fra metodeundersøkelsen RUP er en systemutviklingsmetode som har en meget omfattende dokumentasjon, så en bedrift kan ta ut et subsett av metoden og tilpasser den for vedkommende bedrift eller prosjekt. TRIUMF er et slikt subsett og inneholder stort sett de samme aktiviteter og ansvarsfordeling som RUP. Det som Proxycom savner, og som ikke RUP har, er en retningslinje for å skrive testcase basert på Use Case. Metodeundersøkelsen viser at noen av metodene dekker aktiviteter og maler for systemtesting, men ingen av dem har noen form for regler eller retningslinjer for å lage testcase spesielt fra Use Case. Dette er en av bedriftenes krav, så derfor har jeg skrevet i kapittel om hvordan man kan lage testcase ut fra Use Case. Her er en matrise som viser hvilke krav hver metode dekker og ikke dekker i forhold til bedriftenes krav: Metode Aktiviteter for Dokumentasjonsmaler Regler for å utforme systemtesting for systemtesting testcase fra Use Case 1. RUP Ja Ja Nei 2. XP Ja Nei Nei 3. ISO/IEEE-standard Nei Ja Nei 4. Scenariobasert testing Ja Ja Nei Tabell 3: Kravmatrise for metodene Denne matrisen viser at ingen metode er perfekte, derfor er det lønnsomt å kombinere noen av de nevnte metodene til en ny metodikk for å dekke identifiserte gap. Når noen spør hvor langt man har kommet i testingen, så har testere noen ganger vanskelighet med å svare. Det kan være at de ikke har klar oversikt over hva som er blitt testet eller hvilke krav de ferdige testene hører til. Å lage liste over alle aktiviteter vil være en fordel her, for da har man en plan som man kan gå ut ifra for å sjekke om alle definerte og funksjonelle testene blir kjørt riktig, samtidig unngå forsinkelser i prosjektet. I kapittel 8 har jeg kombinert metodene RUP, scenariobasert og ISO- og IEEE-standarder til en fremgangsmåte for manuell systemtesting av websystemer. Metodeundersøkelsen viser at det ikke finnes noen spesifikke regler for utforming av testcase, og dette er noe mange bedrifter har behov for. Design av testcase vil bli beskrevet og illustrert i kapittel

29 8 Oversikt over aktiviteter ved systemtesting Det finnes mange måter å utføre en systemtest på, og det er ikke noe fasit på hvilke metode som er best. Mange bedrifter bruker ikke noe bestemte metoder for systemtesting, men de utfører testene ut fra sine egne erfaringer. Det lønner seg allikevel å ha et oppskrift eller retningslinje å følge etter når man skal utføre tester på kravene. Alle de viktigste punktene blir berørt når man har et systematisk metodikk til å utføre testing på. Dette vil bidra til god oversikt over hva som er blitt testet og hva som må reteste. Systemtesting er generelt Use Case orientert, men hvordan Use Case blir brukt på er helt avhengig av hvilke type og størrelse på prosjektet [15]. I kapittel 8.1 beskriver jeg en måte man kan gå fram trinnvis i systemtesting for websystemer. Måten å lage testcase i systemtesting er avhengig av hvordan systemet og kravene blir representert i kravspesifikasjonen. Noen bruker Use Case diagrammer og tekstlig Use Case til å illustrere funksjonene til systemet, mens andre foretrekker å lage sekvensdiagram i tillegg. Det er nyttig å kombinere alle disse modellene for å få en bedre oversikt over systemet, men om dette er mulig vil det komme an på hvor mye tid man har til rådighet i prosjektet. I kapittel 8.2 vil jeg beskrive nærmere flere grunnlag til å designe testcase på. 26

30 8.1 Generell fremgangsmåte for utførelsen av systemtesting Systemtest skal verifisere at de funksjonelle kravene er tilfredsstilt av det implementerte systemet. Den etterfølgende metode er bare et forslag til hvordan man kan gå fram i systemtesting. Det vil si at ikke alle punkter må være gjennomført for at det skal bli en vellykket systemtest, så jobben til testlederen av prosjektet er å finne ut hvilke punkter som kan passe til sitt eget prosjekt. Det er effektiv å ha dokumenterte retningslinjer til å gjennomføre systemtest for særlig store prosjekter med kompliserte funksjoner i systemet [1]. Her er en trinnvis beskrivelse av hvordan man kan utføre systemtesting på: 1. Systemtestplan Lage en systemtestplan som er beskrevet i kapittel Gradering av feil Klassifisering og kategorisering av feil er nyttig. Ved å samle data om feil under utvikling, kan man dermed finne ut hvilke kategorier av feil som opptrer hyppigst. Da har man et redskap til å sette inn tiltak for å eliminere årsaken til disse feilene [16]. Det er viktig å gradere hvor kritiske feilene er, slik at man kan bestemme om man kan fortsette med testingen eller om systemet må forkastes på grunn av for alvorlige feil [32]. Tabell 4 viser en måte å gradere feil på. Høy Middels Lav Feil som har kategorier høy er de som forårsaker gale resultater og utilfredsstilte funksjoner av systemet. Dette er en kritisk tilstand. Middels feil er de som medfører unøyaktige resultater. Dette er ikke en kritisk situasjon hvis disse feil ikke blir gjenopprettet. Feil som har kategorier lav er de som er relatert til lav prioriterte krav. Tabell 4: A: Gradering av feil 27

31 En annen måte man kan gradere feil på er å sette en tidsfrist for å rette på feilene i henhold til alvorlighetsgrad [12]. Denne tabellen er vist i tabell 5. Alvorlig feil Middels alvorlige feil Liten feil Bør rettes straks. Bør rettes innen en uke. Bør rettes innen to uker. Tabell 5: B: Gradering av feil 3. Gå gjennom kravene i kravspesifikasjonen Først bør man gå gjennom kravene som er blitt beskrevet i kravspesifikasjonen sammen med kunden. Vanligvis blir alle kravene testet, men i noen prosjekter kan ikke alle kravene bli testet på grunn av streng tidsramme. I slike tilfeller bør man fokusere på kravene som kunden har satt høyest prioritet på, og lager testcase for dem til systemtesting. 4. Lage en tabell over alle testene Når man har gått gjennom alle kravene som skal teste, kan man lage en oversiktstabell over alle testene i systemtest. Denne tabellen bør inneholde tre elementer: Test ID, krav ID og selve navnet på hver test. Denne tabellen vil hjelpe til å holde kontroll over alle testene med tilhørende spesifiserte krav, slik at det blir enklere når man skal lage testcasene til systemtest. Her illustrerer jeg hvordan tabellen kan se ut for et nettbank system: Test ID Krav ID Navn T1 Krav 1 Autentisering av bruker T2 Krav 2 Åpne liste for kontoinformasjon T3 Krav 3 Foreta en utbetaling T4 Krav 4 Foreta flere utbetaling samtidig T5 Krav 5 Øverføring av penger til en annen konto T6 Krav 6 Åpne liste over alle transaksjoner for siste måneden T7 Krav 7 Avslutte nettbank Tabell 6: Tabell over alle testene med tilhørende krav 28

32 5. Lage testcase ut fra kravspesifikasjon Hva går man ut ifra til å lage testcase er avhengig av hvilke modeller som benyttes i kravspesifikasjonen: for eksempel sekvensdiagram eller Use Case. Man kan bruke listen i punkt 4 til å holde oversikten over hva som skal teste. Her er et eksempel på en testcase [15] for autentisering av bruker: Test ID and Navn Test type Ansvarlig person Dato Estimert tid Målet med testen Systemets tilstand T1. Autentisering av bruker (systemtest, brukbarhetstest, akseptansetest) (Beskrivelse) (Nettsiden til systemet er åpnet) 1. Åpne websystemet. Tekstlige beskrivelse av testen: 2. Skrive inn brukernavn og passord. Godkjenningskriterie: Brukeren kommer inn i systemet etter at brukernavn og passord er identifisert av websystemet. Beskrivelse av feil Feilgradering Tidsfrist Beskrivelse av feiloppretting Test utført av Virkelig tidsbruk av testen Notater ( høy, middels, lav) (Kommentar til testen) Tabell 7: Malen for testtabell basert på IEEE std 829 En testcase vil beskrive hva du skal gjøre i testen og i tillegg vil den inneholde hvilke hendelser som skjer når du utfører denne testen. Dermed kan man sjekke underveis om resultatet av testen er lik det forventede utfallet. Det er en mer detaljert beskrivelse om hvordan man lager testcase i kapittel

33 6. Utføre systemtesting Nå kan man teste systemet ved å utføre hver testcase. Testeren skal utføre i henhold til de punktene som står testcasen, og observerer om de får det forventede resultatet. Hvis testcasen gikk som planlagt, så kan man notere OK i slutten av tabellen 7. Hvis det gikk galt, så må man beskrive de feilene som har oppstått slik at programmerer kan fikse dem. 7. Ajourfør systemtestlogg Når testcasene gjennomføres, lages det en liste over de testene som har feilet. Listen bør inneholde test ID, beskrivelse av feil, gradering av feil og eventuelt hvilke konsekvenser det vil ha dersom en bestemt feil oppstår. Tabell 8 viser hvordan en slik tabell kan se ut. Test ID Beskrivelse av feil Gradering T1 Kunne ikke identifisere bruker Høy T4 Kunne ikke foreta flere utbetalinger samtidig Høy T7 Brukeren får ikke logget ut av websystemet Middels Tabell 8: Liste over feil ved første systemtest 8. Videresende listen til programmerer Denne listen, gjerne sammen med skjermutskrifter, gir man videre til programmerer, slik at de kan se hvor feilen oppstår i koden og retter i koden før restesting. 9. Retesting etter feilrettingen Når feilene er blitt fikset og eventuelt endret på Use Case tabellene, så kan testere utføre prosessen fra punkt 6 igjen helt til det ikke oppstår noen feil. Det er bra å lage en liste her også for å ha kontroll over hvilke feil som er blitt rettet opp og hvem som har ansvar for opprettingen. 30

34 10. Lage en liste for testresultatene Etter at systemtestingen er utført, kan man lage en resultatsliste over alle testene og markere om de er OK. Det er bra å ha alle testcasene som vedlegg i selve testdokumentasjonen, slik at kunden kan se hva som har blitt utført. Tabell 9 er et eksempel på en liste over testresultater. Test ID Kommentar Resultater T1 OK T2 OK T3 OK T4 OK T5 OK T6 OK T7 Brukeren får ikke logget ut av websystemet Ikke bestått Tabell 9: Liste for testresultatene 31

35 8.2 Design for testcase Fremgangsmåten for å lage testcase som jeg har beskrevet i kapittel er Use Case orientert, og i tillegg er det nyttig å bruke sekvensdiagrammer. Det er vanlig å kombinere disse to teknikkene i systemutvikling Definisjon av testcase En testcase er et kravbasert dokument som beskriver en input, handling og forventet resultat (output), for å bestemme om en feature av et system fungerer riktig [8]. Utviklingsprosessen for testcase vil hjelpe til med å finne problemer i kravene eller design av et system, siden man må tenke på alle mulige operasjoner av systemet [3]. Det er derfor viktig å forberede testcasene tidlig i utviklingsprosjektet. En testcase bør inneholde disse faktorene [5]: Testcase navn Testcase identifikasjonsnummer Mål Oppsett av testen Input data for kravene: Beskriver trinn for trinn hva som skal gjøres Output data: Beskriver forventet resultatet ut fra testen Målet med testcase er å lage tester som dekker alle kundekravene. Hva menes med en god testcase? En god testcase skal være [38]: Effektiv: Finne feil Evaluerbar: Lett å verifisere resultatet Oversiktelig: Lett å se hvilke problem som har oppstått Utviklerbar: Enkel å vedlikeholde Økonomisk: Billig å bruke eller gjenbruke 32

36 8.2.2 Fremgangsmåte for å lage testcase Testcase skal hovedsakelig dekke alle kundekravene fra kravspesifikasjonen. Dette kapittelet beskriver hvordan man kan lage testcase, utføre testcase og evaluere resultatene. For å konvertere kravene til en eller flere testcase, bør man vite hvordan systemet virker. Det er også viktig å være klar over hva som skal testes og hvordan det skal testes [3]. Her er fire punkter som man bør fokusere på når man lager testcase: A. Identifisering av hva som skal testes B. Design av testcase for funksjonene C. Gruppere alle testcasene under samme krav D. Henvisning testcasene til systemplan A. Identifisering av hva som skal testes Det er viktig å ha oversikt over hva som skal testes, og da bør man sette opp en liste over alle funksjonene for systemet som vi vil teste. Disse funksjonene skal være basert på kundekravene som er beskrevet i kravspesifikasjonen, og de kan bli identifisert ved for eksempel ved å bruke sekvensdiagrammer eller Use Case modeller. B. Design av testcase for funksjonene Når man har laget liste over alle funksjonene som skal testes, kan man bruke den for å lage et sett av testcase som skal dekke kundekravene. Her er det viktig å bestemme hvordan testene skal bli utført, og finne ut hvilke input, handlinger og forventet resultat for hver test. Malen for en testcase bør være basert på IEEE std. 829 som er illustrert i tabell 7. Her vil jeg beskrive nærmere om kombinasjoenen av Use Case og sekvensdiagram som grunnlag til å lage en testcase på. Kombinasjon av Use Case og sekvensdiagrammer Use case diagram viser interaksonene mellom omverden og systemet. Et Use Case er et dokument som beskriver hendelsessekvensen når en bruker anvender systemet til å gjennomføre oppgave [30]. Use Case brukes ofte som grunnlag til å lage testcase basert på kravene i systemtesting, fordi Use Case identifiserer hvilke operasjoner som skal utføres. I mange prosjekter brukes sekvensdiagrammer i tillegg til Use Case for å beskrive hvordan scenarioene i et Use Case realiseres gjennom objekter som samarbeider. Man bør lage sekvensdiagrammer for viktige Use Case, og dette vil skape en bedre forståelse av dynamikken i systemet. Hovedpoenget med sekvensdiagrammet er at man skal kunne oppdage metoder, klasser og koblinger mellom klasser som mangler og tenke gjennom hvordan disse virker sammen [33]. 33

37 Følgende fem punkter bør man gå gjennom for å lage testcase fra Use Case [15]: 1. Samle inn alle Use casene fra kravspesifikasjonen. Først må man se på både Use Case diagrammer og tekstlige Use Case som er beskrevet i kravspesifikasjonen, for å få en god oversikt over alle funksjoner til systemet. 2. Analysere disse Use Casene for å se sammenhengen mellom dem. Det er viktig å se sammenhengen mellom Use Casene, for å kunne bestemme hvilke funksjon som må testes først. 3. Analysere hver Use Case basert på dens normale handlinger. For hver Use Case bør man ha det klart hvilke hendelser som man forventer skal skje for et bestemt brukstilfelle. Her kan man bruke sekvensdiagrammer til å sjekke ut hvilke hendelser som må skje for at en bestemt melding kan sendes videre. Det å ha oversikt over alle testcasene som henger sammen for en bestemt Use Case vil være til stor hjelp for programmerer når det gjelder planleggingen av implementasjonen. 4. Analysere hver Use Case basert på dens alternative handlinger. Nå må man analysere hvert Use Case for å finne andre mulige hendelser som kan forekomme for en bestemt Use Case. 5. Lag testcase i form av tabell. For å sikre at de handlingene som er beskrevet blir utført korrekte, må man lage en eller flere testcase for hver Use Case. Nå kan man lage testcase direkte fra tekstlige Use Case ved å se på alle hendelser som skjer for et bestemt brukstilfelle. Hvordan en testcase kan se ut er vist i tabell 7. 34

38 8.3 Illustrering av å lage testcase For å vise hvordan man bruker denne retningslinjen til å lage testcase ut fra Use Case, vil jeg bruke et e-handlesystem som eksempel med en Use Case og tilhørende testcase. Her vil jeg bruke de fem nevnte punktene for å illustrere trinnene fra Use Case til å lage testcase. Eks. 1. Samle inn alle Use casene fra kravspesifikasjonen. For å skaffe seg oversikt over hva som skal testes, må man se på alle Use Casene som er skrevet i kravspesifikasjonen. Her er et eksempel på et Use Case diagram som presenterer alle funksjoner kunden har i systemet: Figur 5: Use Case diagram for funksjonenene kunden har i systemet 35

39 Her har jeg tatt ut en enkel funksjon, Bestill produkt, som eksempel for å illustrere hvordan man kan bruke retningslinjen som er beskrevet til å lage testcase ut fra Use Case. Figur 6: Use Case for Bestill produkt 2. Analysere Use Casene for å se sammenhengen mellom dem. Figur 6 består av mange sub Use Case av hovedfunksjonen, Bestill produkt. Det er viktig å lage en liste over rekkefølgen av hendelser for dette brukstilfellet. Ved hjelp av denne listen, vil man se om noen av Use Casene er avhengige av hverandre når det gjelder testing. Figur 7: Tabell over alle hendelser i riktig rekkefølge 36

40 3. Analysere hver Use Case basert på dens normale handlinger. Her skal man tenke på hvordan man går frem i systemet for å bestille et eller flere produkter. Man kan utarbeide videre med lista fra punkt 2 for å spesifisere forventede hendelser for hvert brukstilfelle, men her beskriver jeg bare normale hendelser for Bestill produkt. Normale hendelser for Bestill produkt : a. Logge inn - skrive inn passord og brukernavn b. Legg til produkt - velge produkter og legg i handlekurven c. Betal produkt - velge betalingsmåte d. Bekrefte bestilling - trykke OK knappen for bekreftelse av bestillingen slik at systemet kan for eksempel trekke beløpet fra kundens konto og en kvittering på mail til kunden eller sende kunden faktura e. Logge av - trykke på logg ut knappen på skjermen Når man har analysert de normale hendelser som man forventer for et brukstilfelle, bør man i tillegg til Use Case lage et sekvensdiagram for dette. Her er et eksempel på et sekvensdiagram for bestilling av produkter: Figur 8: Sekvensdiagram - Bestill produkt Et sekvensdiagram har to dimensjoner: den vertikale retningen skal representere tiden og den horisontale retningen kommunikasjonen mellom objekter [6]. Når noe skal utføres sendes det en melding fra et element til et annet. Når en operasjon utføres internt i et element, så går meldinger direkte tilbake til avsenderen. Det er viktig at metodenavn i sekvensdiagram er lik i implementasjonen, slik at det blir lettere å finne kilden til feil senere. For å gjøre kodingen lettere for programmerer, er det noen som bruker metodenavn istedenfor å skrive oppgaver for hver melding som sendes mellom objektene, og det er blitt gjort i figur 8. 37

41 4. Analysere hver Use Case basert på dens alternative handlinger. Når man har analysert de normale handlinger for Bestill produkt, må man tenke på alternative hendelser eller feilmeldinger for hver hendelse som er nevnt i punkt 3. Her er det viktig å bestemme hvordan systemet skal reagere i feilsituasjoner som kan forekomme i systemet. Spesielt for denne og forrige aktivitet savner Proxycom gode retningslinjer slik at de får med seg flest mulig av normale og alternative handlinger som kan skje. a. Påloggingsprosess: Feil passord eller brukernavn. Kunden kommer ikke inn i systemet, og en feilmelding kommer opp som sier at han/hun må prøve på nytt. b. Legg til produkt: Varen som kunden har valgt blir ikke markert på grunn av at varen er utsolgt, og en melding om det kommer også opp på skjermen. c. Betalingsprosess: Betalingen er ikke i orden på grunn av at kunden har gitt feil informasjon om sitt kredittkort. d. Bekreftingsprosess d.1 Systemet kan ikke bekrefte ordren på grunn av systemfeil, og en feilmelding dukker opp på skjermen. d.2 Kvittering blir ikke sendt til kunden etter betalingen. e. Avloggingsprosess: Kunden klarer ikke å logge av på grunn av systemfeil. 5. Lag testcase ut fra tekstlige Use Case. Tekstlige Use case fra kravspesifikasjonen skal holde oversikt over alle hendelser for dette brukermønsteret, slik at det blir lettere å lage testcase for det. Her er et eksempel på en slik tekstlig Use case i form av en tabell: 38

42 Use Case ID og Navn Ansvarlig person Dato 2.1 Bestill produkt 1. Kunden åpner websystemet. Systemet viser et vindu der man skal skrive inn passord og brukernavn. 2. Skrive inn brukernavn og passord. Brukeren kommer inn i systemet etter at brukernavn og passord er identifisert av websystemet og systemet viser hovedsiden. 3. Kunden velger et eller flere produkt, dato og tid for levering. Beskrivelse av handlinger: 4. Systemet ber om bekreftelse fra kunden. 5. Systemet viser mulige betalingsmåter. 6. Kunden velger betalingsmåte. 7. Systemet bekrefter bestillingen og kvittering blir sendt direkte til kunden via Systemet sender ordren til bestemt avdeling. 9. Ansatte hos avdelingen pakker og sender varer til kunden. Alternativer: 2.a I punkt 2, brukeren taster inn feil brukernavn eller passord og da vil det komme en feilmelding opp på skjermen. 3.a Kunden har valgt varer som har gått tomt for, og feilmelding kommer opp. 4.a Systemet fungerer ikke pga systemfeil. 6.a Kunden vil betale med kort, taster inn kortinformasjon og systemet sjekker inntastet informasjonen mot banksystem. 7.a Systemet kan ikke bekrefte bestillingen pga feil kortinformasjon og feilmelding kommer opp. 7.b Systemet gir beskjed om betaling OK. 8.a Systemet kan ikke sende ordren til avdelingen, og det kommer opp en melding om at kunden skal prøve igjen senere. 9.a Ansatte leverer feil vare. Tabell 10: Use Case - Bestill produkt 39

43 Nå kan man lage flere testcase direkte ut fra denne tekstlige Use Case ved å lage en testcase for hver normale og alternative hendelser. Man bør også tenke på hvilken form feilmelding skal ha for å informere kunder. Feilmeldinger kan for eksempel være små popup-vinduer. Her er et eksempel på oppsettingen for tre av testcasene i samme tabell: Use Case ID og navn 2.1 Bestill produkt Test ID T.1 T.2 T.3 Beskrivelse handlinger av Godkjenningskriterie Beskrivelse av feil Feilgradering Tidsfrist Beskrivelse av feiloppretting Test utført av Virkelig tidsbruk av testen Notater Skrive inn feil brukernavn eller passord. Brukeren kommer ikke inn i systemet, men får en feilmelding opp på skjermen. ( høy, middels, lav) (Kommentar testen) til Tabell 11: Testcase - Bestill produkt Velge en vare som har gått tomt. En feilmelding om at varen er tomt kommer opp på skjermen. Skrive inn feil kortinformasjon. Systemet viser en melding om at kortinformasjon er feil. C. Gruppere alle testcasene under samme krav Det er ikke alltid bare en test for hvert krav eller funksjon. Ofte må man dele testene inn i deltester for å dekke et krav. Her bør man ordne alle testene i samme kravkategori, slik at man vet hvilke tester som er avhengige av hverandre for å tilfredsstille et bestemt krav. Det er greit å beskrive aktuelle avhengigheter av testene i testdokumentasjonen. D. Henvisning testcasene til systemplan Når testcasene er på plass så bør man forholde dem til systemplanen. Det lønner seg å lage en liste over når hver test skal utføres og hvem som har ansvar for det i følge systemplanen. 40

44 9 Oppsummering Det er viktig å bruke god tid på testing, og mange systemutviklere vil anbefale at man bruker minst 1/3 del av tiden under utviklingsprosjektet [33]. Man kan aldri forvente at systemet er 100 prosent perfekt og ikke feiler etter godkjenningsfasen. Tester hjelper til å finne mulige feil som kan oppstå, og en Use Case modell er nyttig når det gjelder systemtesting av websystemer. Jeg fant ingen metoder fra metodeundersøkelsen som dekker regler for hvordan man kan utforme testcase ut fra Use Case, derfor er det behov for å utvikle metoder innen dette området slik at testing kan foregå mer systematisk. Det finnes ingen perfekte metoder for å lage testcase, derfor bør man i noen tilfeller kombinere Use Case med andre teknikker som for eksempel sekvensdiagrammer [26]. Dersom man finner mangler i Use Case, må man fikse den slik at prosjektet ikke blir forsinket i forhold til planen. Når en Use Case blir endret kan det også påvirke testcasene, og det kan ta lang tid før alt er rettet. Dersom godkjenningskriterie for testingen ikke oppnås, må man eventuelt lage og utføre flere testcase. Å lage testcase i form av tabeller vil være effektiv, for det vil både spare tid og arbeid når man skal vedlikeholde dem. Når man finner feil ved å utføre testcasene under testing, vil man ha en god oversikt over de feilene som har oppstått. Feilene blir dermed rettet raskere, og billigere blir det også når det gjelder gjenbrukbarhet av tabellene. Siden testcasene er basert på kravspesifikasjonen, kan man evaluere om systemet har dekket alle kravene fra kunden. 41

45 10 Validering av prosjektet Prosjektet gikk ut på å finne metoder for systemtest av websystemer, og følgende aktiviteter skulle utføres: 1. Beskriv praktiske erfaringer med systemtesting. 2. Innsamling foretas fra Internett, litteratur og bedrifter. 3. Spesifiser krav til metoder for systemtesting basert på praktiske erfaringer. 4. Gi en oversikt over metoder for systemtesting. Innsamling foretas fra Internett og litteratur. 5. Evaluer metodene og vurder i hvilken grad de tilfredstiller kravene. 6. Åpent: Utprøving av metode, formulere bedre metoder eller prototyper av verktøy. I prosjektet er disse aktivitetene blitt utført, og det viste at det finnes metoder som beskriver aktiviteter og dokumentmaler, men det mangler metoder som gir retningslinjer for hvordan testcase kan skrives. I prosjektrapporten er det beskrevet en fremgangsmåte for systemtesting basert på de eksisterende metodene. Videre arbeid med dette prosjektet kan være å la IT-bedrifter følge beskrevne fremgangsmåten til å gjennomføre systemtest og utforming av testcase på, og til slutt få tilbakemelding fra dem om det var noe forbedring i deres systemtesting. En annen ting som man kan jobbe videre med er å utvikle bedre metoder for systemtesting og utforming av testcase. 42

46 A Vedlegg - Spørsmål til bedriftsintervju Dette vedlegget inneholder spørsmål om systemtesting som jeg har utarbeidet før selve intervjuene, og de blir brukt under intervjuene med Proxycom og Sparebank Hvilke systemutviklingsmodell bruker dere? 2. Hvilke erfaringer har dere med systemtesting av websystemer? 3. Hvilke konsekvenser får dere når det er dårlig systemtesting av websystemer? 4. Hvilke typer tester tar dere? 5. Bruker dere manuell eller automatisert testing? Hvilke verktøy? 6. Hvilke metoder bruker dere til systemtesting? 7. Hvordan går dere fra krav til å lage testcase? 8. Bruker dere mye tid til testing? 9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn? 10. Hvem er det som tester? Systemutviklere eller brukere? 11. Hvor viktig er testing for dere? 12. Hvilke krav har du til en bedre metode for systemtesting? 43

47 B Vedlegg - Bedriftsintervju med Proxycom Dette vedlegget er resultatene av intervjuet med Proxycom om systemtesting. Intervjuet med IT-sjefen, Trond Johansen, varte i nesten en time og dette ble avholdt onsdag 28.september i Trondheim. Etter dette intervjuet så har jeg skrevet et referat fra intervjuet og sendt det til Trond for å få det godkjent før jeg la dette sammendraget i prosjektrapporten. 1. Hvilke systemutviklingsmodell bruker dere? Vi bruker TRIUMF-modell. 2. Hvilke erfaringer har dere med systemtesting av websystemer? Systemtesting er viktig, for man vil vanligvis finne 4-5 feil i hver brukstilfelle som er middels kritiske. Hvis man ikke legger vekt på systemtesting, så vil en del feil slippe igjennom i godkjenningsfasen. Det er effektiv å la de personene som har utarbeidet kravspesifikasjonen til å utføre systemtest, siden de har mest kjennskap til kravene. Det er nyttig å dokumentere testcasene så godt som milig, slik at kunden kan se hva som har blitt utført. 3. Hvilke konsekvenser får dere når det er dårlig systemtesting av websystemer? Dersom vi har utført dårlig systemtesting før lansering av produktet, så vil det oppstå flere systemfeil som kan være kritiske. For eksempel når vi har laget et program med tusenvis av brukere, så kan feil berøre mange brukere og kan medføre økonomiske konsekvenser. 4. Hvilke typer tester tar dere? Vi bruker disse testene i denne rekkefølgen for alle våre prosjekter: 1. enhetstest: per brukstilfelle 2. integrasjonstest : per brukstilfelle 3. systemtest : når hvert brukstilfelle er ferdig 4. brukbarhetstest 5. akseptansetest 44

48 5. Bruker dere manuell eller automatisert testing? Hvilke verktøy? Vi utfører hovedsakelig manuell systemtesting, men vi er på jakt etter en god automatiserte verktøy. Vi har prøvd en del verktøy i dette feltet, men resultatet fra denne utprøvelsen var at det tok for lang tid til å endre testcasene. Vi bruker verktøy for visse typer systemer, som for eksempel benytter vi et program til å simulere datautveksling. Det kan være et websystem som mottar XML meldinger fra et annet system. Dette verktøyet kan teste et bestemt system uten at andre systeme er i drift. 6. Hvilke metoder bruker dere til systemtesting? Vi bruker våre egne erfaringer til å konvertere kravene fra kravspesifikasjonen til testcase. I utgangspunktet så er blir det laget en testcase eller flere testcase for hver tekstlig Use Case. Vi utfører i tillegg ytelsetest ved bruk av et program fra Microsoft. Dette programmet gir statistikk i tidsforbruk og responstid for hvert brukstilfelle. 7. Hvordan går dere fra krav til å lage testcase? Det har jeg allerede svart på forrige spørsmål, og som sagt utgangspunktet fra egne erfaringer. 8. Bruker dere mye tid til testing? En del tid bruker vi til testing, men det varierer om det er et enkelt eller komplisert program. Vanligvis bruker vi ca. 20 prosent til systemtesting. 9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn? GUI skal henvise til kravspesifikasjonen, og selvfølgelig skal det også se pent ut med tanke på plassering av knapper og tomme linjer for å gi litt luft. Brukervennligheten blir avklart i kravspesifikasjonen, og den blir fokusert i brukbarhetstesten som utføres av en som har arbeidet med kravspesifikasjonen. 10. Hvem er det som tester? Systemutviklere eller brukere? Det er systemutviklere som utfører i systemtesten, og brukere i brukbarhetstesten. 45

49 11. Hvor viktig er testing for dere? Systemtest er veldig viktig for oss, fordi den hjelper oss til å finne feil før brukstilfeller overleveres til oppdragsgiver eller settes i drift. 12. Hvilke krav har du til en bedre metode for systemtesting? Metoden bør: være beregnet for manuell systemtest av websystemer være Use Case orientert ha et slags uformelt språk for å skrive testscript(testcase) ha retningslinjer for hvordan man kan skrive testscript for å teste ulike krav i kravspesifikasjonen ha retningslinjer for hvordan testscript kan utformes slik at de kan tilbakestille databasen etter testen 46

50 C Vedlegg - Bedriftsintervju med Sparebank 1 Dette vedlegget er resultatene av intervjuet med Sparebank 1 om systemtesting. Intervjuet med IT-sjefen, Ketil Berg, varte i nesten en time og dette ble avholdt mandag 10.oktober i Trondheim. Før intervjuet spurte jeg om jeg kunne ta opp samtalen under intervjuet, og det var i orden for Ketil. Etter dette intervjuet så har jeg skrevet et referat fra intervjuet og sendt det til Ketil for å få det godkjent før jeg la dette sammendraget i prosjektrapporten. 1. Hvilke systemutviklingsmodell bruker dere? Vi bruker i utgangspunktet RUP som utviklingsmodell som vi har gjort tilpasning av den til vårt eget formål. 2. Hvilke erfaringer har dere med systemtesting av websystemer? Vi har mange erfaringer innen systemtesting av websystemer. Det er helt klart at det finnes mange risiko ved websystemer, og for å sikre kravene så har vi egne retningslinjer for testing. Vi har for eksempel egne tester for nettbank, og spesielle tester som blir utført her er ikke bare ytelsestest, men også ulike tekniske tester samt innbruddsdtester. 3. Hvilke konsekvenser får dere når det er dårlig systemtesting av websystemer? Dersom det er snakk om systemer for de ansatte, så vil risikoen være at systemene stopper opp og de ansatte får da ikke behandle kundene. Når det gjelder eksterne systemer som for eksempel nettbank, så er det risiko for sikkerhetsinnbrudd. Dette vil da medføre til dårlig stabilitet og ytelse som kan være alvorlige økonomiske konsekvenser. Det er viktig for oss at det skal være våre systemer i stabil drift. 4. Hvilke typer tester tar dere? Det varierer litt på hvilke tester vi bruker fra prosjekt til prosjekt. Rammeverket vårt er at alle våre prosjekter må gå gjennom enhetstest. Vi bruker som vanligvis også funksjonelle test, integrasjonstest, systemtest, ytelsestest, stabilitetstest, tekniske test, regresjonstest, innstallasjonstest og akseptansetest. Stabilitetstest skal teste med høy trykk over lang tid, og i tekniske test så kjører vi avbrudd på komponentene i koden for å sjekke hvordan applikasjonen reagerer. Brukbarhetstest bruker vi i noen tilfeller, og for å avgjøre om denne type testing skal gjennomføres så må vi kjøre vurdering på det først. 47

51 5. Bruker dere manuell eller automatisert testing? Hvilke verktøy? Det er manuell testing i regresjonstesting hittil, men vi er i ferd med å gå over til å bruke for eksempel verktøyet Mercury til automatisert testing. Vi har i mange år benyttes Load Runner fra Mercury Interactive. De verktøyene vi nettopp har starta med er Test Director og QTP. 6. Hvilke metoder bruker dere til systemtesting? Framgangsmåte er å kjøre alle definerte og funksjonelle testene. Det er RUP rammeverk vi går ut i fra her, men hvilke metoder vi benytter i systemtesting varierer litt med typer prosjekter. 7. Hvordan går dere fra krav til å lage testcase? Det varierer fra prosjekt til prosjekt, men som regel så er det en gruppe som beskriver testcasene basert på kravspesifikasjonen. Vi er i ferd med å bruke verktøy til å konvertere krav til testcase. Alle våre prosjekter er Use Case orientert, men i noen tilfeller bruker vi også sekvensdiagram i tillegg. 8. Bruker dere mye tid til testing? Vi bruker mye tid til testing, og det som tar mye tid er blant annet ytelsestest og stabilitetstest. Når det gjelder interne systemer så bruker vi omtrent 50 prosent til testing, og omtrent 70 prosent for eksterne systemer. 9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn? Det er viktig for oss å ta vare på brukervennligheten, og det er verdien for Sparebank 1. Det som er problemet her er at vi ikke får nok ressurser til å teste grundig nok som vi kunne ha gjort. Det har kommet forslag om å danne en egen brukskvalitetslab der vi kan observere brukbarheten til systemet, og nøkkelordet her er mer systematikk. Vi har en egen godkjenningskriterie for hvordan GUI skal være. 10. Hvem er det som tester? Systemutviklere eller brukere? Det er brukere som tester i både systemtest og brukbarhetstest. Vi føler at det kan være bra å la andre enn systemutvikleres til å teste systemet, siden de ikke kjenner godt til kravspesifikasjonen. 48

52 11. Hvor viktig er testing for dere? Testing har vært lenge undervurdert, og det har gitt alvorlige konsekvenser når systemet skal lanseres. Testing er som sagt veldig viktig for oss, derfor har vi brukt mye tid til det. 12. Hvilke krav har du til en bedre metode for systemtesting? Det som kan bidra til bedre systemtesting er å utføre mere automatisert testing der testscriptene kan bygges og kjøres om natta. Det som har holdt oss tilbake når det gjelder automatisert testing er at det er tidkrevende, men de verktøyene som har kommet i det siste er bedre nå. 49

53 D Vedlegg - Ordforklaringer Akseptansetest : Test gjennomført på et system i den hensikt å fastslå at systemet fungerer i henhold til brukernes behov og krav. Black-box testing : Black-box testing eller funksjonell testing er en testmetode der testen bygger på programmet eller komponentspesifikasjonen. Database : En stor samling av data som for eks. i en datamaskin, og den er organisert slik at man kan oppdatere, utvide og gjenopprette hurtig for flere brukere. En database på nett kan også bestå av linker til andre nettsider. Enhetstest/Modultest : En avgrenset del av et system (f.eks. én subrutine) testes for seg. Feil : Gal oppførsel som blir resultatet av en mangel. Funksjonell test : Sjekker om en modul tilfresstiller de eksterne kravene man har satt til den. HTML : HyperText Markup Language - er språket som blir brukt til å publisere dokumenter på internett. HTTP : Hypertext Transfer Protocol - er en protokoll for å overføre data over internett. HTTP brukes for wetjenester som for eksempel sørger den for at en hjemmeside er leselig på internett. IEEE-standard : Inneholder maler og retningslinjer for blant annet testplan og testcase. Input : Det som skal testes. 50

54 Integrasjonstest : Test av grensesnittet mellom enheter/moduler i et system. Grunnlaget for testingen er designet for systemet (og koden). ISO-standard : ISO er en standardiseringsorganisasjon som gjelder world-wide. Klient : En klient som er ansvarlig for interaksjon med brukeren, for eksempel ved å ta imot tastetrykk, og vise informasjon på skjermen. Når vi holder på med publisering vil den typiske klienten være nettleseren vår. Krav sporbarhet: Brukerene ønsker at kravene er slik de ønsket. Test slik at hvert krav blir individuelt testet. Output: Forventet resultat. Regresjonstest : Her tester man hele systemet eller deler av systemet etter at ny kode er lagt til eksisterende kode. RUP : Er et prosessrammeverk for systemutvikling, utviklet av Rational Software. Scenario : Scenario er et sett av forventede handlinger som blir utført av en potensiell bruker av systemet. Sekvensdiagram : Interaksjonsdiagram som viser objektene som deltar i en bestemt interaksjon, og meldingene de utveksler, arrangert i en tidssekvens. Sikkerhetstest : Sikre systemet for inntrengere. Skalerbarhet : Hvor bra systemet takler dersom utallige brukere kopler til systemet samtidig. 51

55 Stabilitetstest: Tester systemet med høy trykk over lang tid, og i tekniske test så kjører man avbrudd på komponentene i koden for å sjekke hvordan applikasjonen reagerer. Stresstest : Tester hastigheten på mange samtidige transaksjoner. Systemtesting : Test av et system som en helhet, og grunnlaget for testingen er kravspesifikasjonen. Testcase : En testcase er et kravbasert dokument som beskriver en input, handling og forventet resultat (output), for å bestemme om en feature av et system fungerer riktig. Testlogg : Testlogg med beskrivelse av feil og deres løsning. Testplan : detaljert testplan som beskriver hver enkelt test som skal gjennomføres Hver enkelt test beskrives ved å angi hva som skal testes, inndata, kommandoer/håndgrep og ikke minst forventet resultat av testen Time-to-market: Tiden det tar fra å starte produktutviklingen til produktet er ferdigstilt og tilgjengelig på markedetonent. TRIUMF: TRInnvis UtviklingsMetode For programsystemer. UML : Er et modelleringsspråk som blant annet brukes til å designe og dokumentere programmer i java. Usability test: Usability testing er et verktøy for å finne ut hvor lett systemet er å forstå og bruke (og hva som kan forbedres), ved å observere sluttbrukere i mest mulig realistiske brukssituasjoner 52

56 Use Case : Et use case er en oppgave som brukeren vil utføre ved hjelp av systemet. Et use case beskriver hendelser i systemet. Validering: Validering er å finne ut om vi har laget det rette produktet. Verifikasjon : Verifikasjon er om man har laget produktet på riktig måte. Websystem : Websystemer innebærer klienter, og en eller flere fysiske servere som bidrar til flere typer av service. Web-browser : Et program som brukes til å vise innhold ifra internett, og nettleserens jobb er å oversette HTML-kodene som angir posisjon av tekst og bilder og vise dette i henhold til koden. Web-server : Er en spesiell internett-tjeneste som lar et firma eller en person benytte et tilpasset domenenavn på Internett. Web-service : Er en samling av protokoller og standarder som brukes for å dele data mellom applikasjoner. White-box testing : White box er en metode der testene bygger på kunnskap om programvarestrukturen og implementasjonen. XP : Extreme Programming. Ytelsestest : Tester hastigheten for en transaksjon. 53

57 Referanser [1] Ash, Lydia, The Web Testing Companion - The Insider s Guide to Efficient and Effective Tests, Wiley [2] Debugging, explorer 1, URL: [3] Developing software test cases, explorer 1, URL: org/conference/wtst3_collard1.pdf. [4] Dnv - iso 9001, explorer 1, URL: dnv.no/sertifisering/ systemsertifisering/kvalitet/. [5] Falk, Jack, Testing Computer Software, Wiley [6] Flere uml-modeller, explorer 1, URL: systemutvikling/slides2005/15_uml2.ppt. [7] Fulp, E. W., Testing - Wake Forest Univerity, Vår [8] Glossary, explorer 1, URL: html. [9] Hutcheson, Marnie L., Software Testing Fundamentals - Methods and Metrics, Wiley [10] Hva er rup, explorer 1, URL: [11] Interaksjonsdiagrammer, explorer 1, URL: tdt4140/losninger.htm. [12] Johansen, Trond, TRIUMF, Spartacus Oslo [13] Konfigurasjonsstyring og systembygging, explorer 1, URL: uio.no/ronnyw/in219/kap33.html. [14] Lereng, Furuseth, Testing of Web Systems, NTNU [15] Nguyen, Hung Q., Testing Application on the Web - Test Planning for Mobiule and Internet-Based Systems, Wiley [16] Norsk nettskole, ressurssider, explorer 1, URL: no. [17] Note om systemudvikling, explorer 1, URL: Kurser/Noter/Systemudvikling.pdf. [18] Om systemutvikling og modeller, explorer 1, URL: www2.hit.no/af/ifim/ kurs/kurs853/foreles/repetisjon.ppt. [19] Prosjektplanlegging, explorer 1, URL: [20] Proxycom, systemutviklingsmetodikk, explorer 1, URL: 54

58 [21] Rausand, Marvin, Risikoanalyse, Tapir forlag [22] Sidestruktur, explorer 1, URL: pages/sidestruktur.html. [23] Sparebank1, explorer 1, URL: [24] Stålhane, Tor, Gjennomgang av IEEE Std 829,. [25] System-utviklingsmetodikk, explorer 1, URL: teknologihovedstaden.net/it-nett/psmaler. [26] Test design for web, explorer 1, URL: rosscollard1.pdf. [27] Testdokumentasjon, explorer 1, URL: dokumenter/testdokumentasjon.doc. [28] Testguide for saus, explorer 1, URL: testguide/. [29] Testprosessen - sum, explorer 1, URL: test. [30] Uml, explorer 1, URL: doc. [31] Usability-testing, explorer 1, URL: home.hia.no/~ledokked/is3410/f_6_ 16_11_Usabilitytesting.ppt. [32] Validering og verifisering, explorer 1, URL: ~stalhane/sif8054/notater/validering.pdf. [33] Validering og verifisering, explorer 1, URL: ~kirstenr/systemutvikling/slides2005/11_validering_verifisering.ppt. [34] Verification and validation, explorer 1, URL: ~gusloek/skole/in140/verificationandvalidation.doc. [35] Verifikasjon og validering, explorer 1, URL: folk.uio.no/ronnyw/in219/ kap22.html. [36] Verifikasjon og validering vedlikehold, explorer 1, URL: www2.hit.no/af/ ifim/kurs/kurs853/foreles/su_test_vedlikehold.ppt. [37] Webtest-test af webapplikation, explorer 1, URL: Appendiks/stappWebtest.htm. [38] What is a good test case?, explorer 1, URL: GoodTest.pdf. [39] What is extreme programming?, explorer 1, URL: xpmag/whatisxp.htm. 55