Testplan (Software Test Plan)

Like dokumenter
Testdokumentasjon (Test Documentation)

GJENNOMGANG UKESOPPGAVER 9 TESTING

Software Test Plan. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

Livsløpstesting av IT-systemer

Inf1055 Modul B 26 april 2017:

Systemdokumentasjon. (System Documentation) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Gruppe 43. Hoved-Prosjekt Forprosjekt

Grunnleggende testteori

Testing av programvare. INF1050: Gjennomgang, uke 08

Testing av programvare

Grunnleggende testteori. Etter Hans Schaefer

References Hovedprosjekt ved Høgskolen i Oslo 2010 Testrapport

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

Ansvarlig: Faglig ansvarlig for innhold og revisjon, Testseksjonen TestiT, Avd. for Tjenesteproduksjon HN IKT

Testbilag til IT kontrakter

Løsningsforslag Sluttprøve 2015

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse

UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Testrapport for Sir Jerky Leap

Testrapport Prosjekt nr Det Norske Veritas

1. Introduksjon. Glis 13/02/2018

Grunnleggende testteori

Testdekning og automatisering - Er 100% testdekning et mål?

SOFTWARE DEVELOPMENT PLAN. Home Automation System. Nickolas Helgeland, Jon Erik Nordskog og Kristian Sande Sjølyst

ISTQB Foundation Level Prøveeksamen

Software Development Plan

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet

Gårsdagens testroller takler ikke dagens utfordringer. Magnus Halvorsen og Erik Rogstad

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Retningslinjer for akseptansetest

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

Retningslinjer for akseptansetest

INSTALLASJONSVEILEDNING FOR KALK2010 KALKULASJONSPROGRAM

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS

Finansportalen Historiske bankdata

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Automatisert Robusthetstesting. Erik Arisholm Testify AS

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

Modernisering av IKT i NAV

Erfaring med funksjonell testing i en integrert ALM prosess

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

Test i Praksis. NTNU Februar Copyright 2014 Accenture All Rights Reserved.

Modellering IT konferanse

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Pillbox Punchline

Testrapport Prosjekt nr SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

Kravspesifikasjon MetaView

De fleste kjenner Tomras pantemaskiner, som er godt utbredt i store deler av verden.

Overordnet Testplan. MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt. Page 1 of 11

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Kravhåndtering. INF1050: Gjennomgang, uke 03

PROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning

Kravspesifikasjon. Forord

RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON

Prosjektlogg Samfunnet Bislet (Gr. 44)

Prosess for systemutvikling i Difi. Versjon 1.0

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter

Software Development Plan (1. utkast)

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Test i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Veiledning for oppdatering av Extensor 05 - versjon 1.16.

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Public 2013 Aker Solutions Page 1 of 5

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren Testrapport

Hvis du gjenkjenner ett av disse to bildene over så er dere på vår ASP-server.

Konfigurasjonsstyring

TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Verdien av god leverandørtesting i konstruksjonsfasen i smidige prosjekter

HOVEDPROSJEKT I DATA VÅR 2011

Repetisjon av testing. Vi undersøker om systemet virker slik det skal

Installasjonsveiledning

Repetisjon av testing. Vi undersøker om systemet virker slik det skal

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

BlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009

Generelt om operativsystemer

Brukerveiledning. Madison Møbler Administrasjonsside

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

K-Nett. Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon. av Erik Mathiessen

Eksamen 2013 Løsningsforslag

UNIVERSITETET I OSLO

Team2 Requirements & Design Document Værsystem

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Installasjon enbruker

Installasjonsveiledning, CGM Vision Installasjonskrav. 1 Innhold. 1 Formål. 2.1 Windows. 2.2 Oracle. 2.3 CGM Vision. Oppgradering v4.7 til v4.

Dette bilaget inkluderes i Avtalen for kunder som har et høyere Servicenivå enn standard leveringsvilkår.

2. Beskrivelse av installasjon av SQL Server 2005 og hvordan lage databasen som trengs av administrasjonsprogrammet:

Test og kvalitet To gode naboer. Børge Brynlund

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan

Vedlegg Brukertester INNHOLDFORTEGNELSE

Forord Dette er brukerdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken

Installasjonsveiledning Visma Avendo Lønn, versjon 7.60 Oktober 2011

Transkript:

Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen

Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 1.2 Antagelser ved testing av produktet... 3 2.. Testprosessen... 4 2.1 Testkategorier... 4 2.1.1 Black-box testing... 4 2.1.2 White-box testing... 4 2.2 Testnivåer... 4 2.2.1 Enhetstest... 4 2.2.2 Regresjonstest... 4 2.2.3 Integrasjonstest... 5 2.2.4 Systemtest... 5 2.2.5 Godkjenningstest... 5 2.3 Testmetoder... 5 2.3.1 GUI-test... 5 2.3.2 Funksjonell test... 5 2.3.3 Ikke-funksjonell test... 5 3.. Ressurser... 7 4.. Risiko... 8 4.1 Prioriteringsliste... 10 5.. Testplan... 11 6.. Referanser... 12 BetaKey Payment System 2

1 Introduksjon Introduksjon Dette dokumentet omhandler testingen som skal utføres på produktet BetaKey. Dette for å finne ut om det tilfredsstiller kravene til kunden og utviklerne, og løse eventuelle feil. Å utføre grundige tester beviser ikke at systemet er feilfritt, men det reduserer sjansen for å finne feil etter at produktet er tatt i bruk. Ressurser, risiko ved testing og en testplan blir fremstilt i dette dokumentet. Alle utførte tester dokumenters i testdokumentasjonen. STP samt testdokumentasjonen skal publiseres på hjemmesiden. 1.1 Definisjoner Under følger en tabell over begrep og beskrivelse av disse. Tabell 1.1: Definisjoner Begrep GUI RC RFID RTM Software SQL STP VSTS VSUTF VTE Beskrivelse Graphical User Interface Release Candidate Radio Frequency Identification Release to manufacturing Systemprogramvare Structured Query Language Software Test Plan Visual Studio Team Server Visual Studio Unit Test Framework Virtuelt Test Environment 1.2 Antagelser ved testing av produktet Ved testing av dette produktet vil det oppdages/oppstå feil som skal rapporteres i VSTS. Ved rapportering i VSTS skal det registreres navnet til utvikleren som har jobbet med delen det har oppstått feil på, og en kommentar som beskriver så godt som mulig hva som er feil og en eventuell løsning. BetaKey Payment System 3

2 Testprosessen Testprosessen Dette kapittelet beskriver kort de to hoved testkategoriene samt testnivåene og testmetodene som blir tatt i bruk i testprosessen. Alle feil som blir oppdaget skal bli registrert i VSTS. Hvis en test avdekker feil, må en rette feilen og deretter ta testen på nytt. 2.1 Testkategorier Utviklingsteamet velger å teste funksjonalitet, kodestruktur og implementering ved hjelp av to testkategorier. Både Black-box testing og White-box testing blir forklart under. 2.1.1 Black-box testing Black box testing er en testmetode som fokuserer på funksjonaliteten til systemet, uten å se på kodestrukturen og implementeringen. Testingen er basert kun på programvarekravene. [1] Fordelen med denne testmetoden er at det er lett å fokusere på og teste funksjonaliteten, og det er lett å sammenligne med kravspesifikasjonen. En ulempe med Black-box testing er at den ikke finner feil i koden. 2.1.2 White-box testing White box er en testmetode som tester kodestrukturen og implementeringen. Den fokuserer primært på å styrke sikkerheten, innganger og utganger i programmet, design og brukervennlighet. [2] Fordeler med denne testmetoden er at den tester «alle» veier og implementasjonen. Ulemper er at det er lett å fokusere for mye på implementasjonen og glemme funksjonaliteten. 2.2 Testnivåer Det er flere testnivåer, dette gjør at systemet blir testet grundig både hver del for seg og sammen som et system. 2.2.1 Enhetstest Enhetstestene er skrevet av utviklerne som en del av programmering. Det opprettes et klassebibliotek som heter enhetstesting, i dette biblioteket vil det bli laget klasser hvor enhetstestene blir implementert. Hver del (klasser og metoder) blir testet separat. Ved testingen av dette systemet skal ikke alle klasser og metoder testes som en enhetstest, det skal velges ut noen få metoder. Enhetstestene skal bli utført i Visual Studio Unit Test Framework. Ingen installasjon er nødvendig for å bruke VSUTF. 2.2.2 Regresjonstest Regresjonstesting er testing av systemet for å se om endringer har ødelagt tidligere skrevet kode. Dette kan gjøres ved å utføre funksjonell testing på nytt etter at dette er utført en gang. BetaKey Payment System 4

Testprosessen 2.2.3 Integrasjonstest Integrasjonstesting betyr at systemet er satt sammen og testet for å være sikker på at alt fungerer sammen. Sjekker at komponentene er kompatible, at komponentene samhandler korrekt og at de sender riktig data til riktig tid. 2.2.4 Systemtest Systemtesting er typisk Black-box tester som validerer hele systemet mot kravene. Sjekker om systemet møter kravene i SRD. 2.2.5 Godkjenningstest Kunden må teste og godkjenne produktet før produktet blir tatt i bruk. 2.3 Testmetoder Følgende testmetoder vil bli brukt under testing av programmet, samt testene under 2.2. 2.3.1 GUI-test GUI-testing er prosessen å teste det grafiske brukergrensesnittet av systemet. [3] Eksempler på hva som kan analyseres: Plassering og størrelse på knapper, bilder, tekstbokser osv. Skriftstørrelse Farger og bakgrunner Plassering på feilmeldinger 2.3.2 Funksjonell test Funksjonell testing bekrefter at hver funksjon i programmet opererer i samsvar med kravspesifikasjonen. Innebærer hovedsakelig black-box testing. Sammenligner faktiske resultater med forventede resultater. [4] 2.3.3 Ikke-funksjonell test Ikke-funksjonell testing er vanskeligere å gjennomføre enn funksjonell testing. Ikkefunksjonelle tester undersøker hvor godt produktet er. 2.3.3.1 Stresstest Stresstesting anvendes for å teste stabiliteten og påliteligheten til systemet. Denne testen avgjør systemets robusthet og feilhåndtering under press. [5] 2.3.3.2 Sikkerhetstest Sikkerhetstesting handler om å finne alle smutthull og svakheter i systemet som kan føre til at informasjonen som ligger lagret i systemet havner i feil hender. Målet med sikkerhetstesting er å identifisere trusler i systemet og måle dens sårbarhet. Testingen hjelper også med å oppdage alle mulige sikkerhetstrusler i systemet, slik at utviklerne kan løse dette problemet gjennom koding. [6] BetaKey Payment System 5

Testprosessen 2.3.3.3 Test av brukervennlighet Test av brukervennligheten fokuserer på å hvor enkelt det er å bruke programmet, fleksibilitet og om systemet møter sine mål. Test om systemet er lett å lære seg og bruke, og om en brukermanual er lett tilgjengelig ved behov. 2.3.3.4 Installasjonstest Installasjonstest går ut på å prøve å laste ned programmet på en datamaskin som ikke har systemet fra før av. Samt at installasjonsveiledningen er lett å forstå, og at den stemmer med hvordan installasjonen faktisk foregår. BetaKey Payment System 6

3 Ressurser For å utføre testingen er det nødvendig med følgende utstyr: Datamaskin med nødvendig software Internett Strekkode-skriver Strekkode-leser RFID-leser RFID-kort Ressurser Testene skal utføres i VTE. VTE er et testmiljø som skal lastes ned og fungerer som en egen datamaskin, uavhengig av det som allerede ligger på datamaskinen fra før av. VMware Workstation Player blir brukt fordi det er gratis og lett å bruke. Etter at VMware er lastet ned og installert skal Windows 10, VMware tools og SQL Server lastes ned og installeres i testmiljøet. Deretter skal software til BetaKey kopieres og gjøres klart til testing. Personene som skal utføre testene er oppgitt i Tabell 3.1: Testpersoner. Tabell 3.1: Testpersoner Tester Ansvar Testerfaring Amanuel K. Tedla Utvikler og tester Medium Eleonora Ntreska Utvikler og tester Medium Ingrid Vik Hansen Utvikler og testleder Medium Joakim Moen Utvikler og tester Medium Testlederen sitt hovedansvar er å følge med på at testerne utfører testingen i henhold til STP. Testlederen bestemmer også hvem som skal utføre hvilken tester. Godkjenningstestingen skal utføres av kunden Halvorsen & Co, personene er oppgitt i Tabell 3.2: Godkjenningstestpersoner. Tabell 3.2: Godkjenningstestpersoner Tester Hans Petter Halvorsen Olav Dæhli Bedrift Halvorsen & Co Halvorsen & Co BetaKey Payment System 7

4 Risiko Ved testing av et produkt er det viktig å se for seg mulige risikoer som kan oppstå, innvirkning på testingen og hvordan dette skal håndteres. Hvordan risikoer håndteres er viktig å vite for å være forberedt på alle senarioer. Risiko Utsatt start: Defekter/Feil er funnet rett før testingen skal startes. Dette kan eventuelt ta tid å rette opp, og testingen vil derfor bli utsatt. Det er viktigere å fikse problemet enn å teste produktet, og problemet kan også hindre at testingen kan bli utført. Stram timeplan: Timeplanen er stram, noe som gjør at det er stor risiko for at en ikke klarer å holde tidsfristene. For eksempel at en ikke er ferdig med en test når en allerede skal ha startet på neste. Utsettinger i testingen: Det kan fort forekomme nye problemer i testprosessen, da må dette fikses før testingen kan fortsette. Dette fører til utsettinger i timeplanen. Ikke nok ressurser: Eksempler på ikke nok ressurser kan være at sykdom hos testerne, ferie i testperioden og ikke nok teknisk kunnskap hos testerne. Uforutsigbare hendelser: Uventede naturlige problemer kan være strømbrudd, dataproblemer eller problemer med internett. I Tabell 4.1: Risiko er de forskjellige risikoene satt opp, sammen med sannsynligheten for at de inntreffer, innvirkningen de har på testingen og en skadebegrensning. Sannsynligheten og innvirkningen er rangert med lav, medium og høy. I skadebegrensningen er det forklart hva som kan gjøres for at risikoen ikke har for stort negativt utfall på testingen. BetaKey Payment System 8

Risiko Tabell 4.1: Risiko Risiko Sannsynlighet Innvirkning Skadebegrensning Utsatt start Medium Høy Hvis dette er tilfelle må teamet prøve å «ta igjen» timeplanen, og prøve å holde denne. Stram timeplan Høy Medium Timeplanen bør holdes, hvis en bruker lengre tid på en test enn planlagt, må en prøve å gjøre neste test på kortere tid. Hvis det er umulig å bli ferdig med alle testene før tidsfristen, er det laget en prioriteringsliste, der de nederste testene må bli nedprioritert. Utsettinger i testingen Høy Medium Timeplanen vil bli påvirket her. Problemet må løses før testingen kan fortsette. Ikke nok ressurser Medium Medium Ferier skal være med i timeplanen, og det skal ikke være satt opp tester innenfor denne tidsperioden. Ved sykdom hos en av testerne må en annen tester gjøre testene for han/hun. Ved manglende teknisk kunnskap, kan testerne samarbeide og dermed styrke kunnskapen. Uforutsigbare hendelser Lav Medium Ved strøm- eller internettbrudd må testerne vente til dette fungerer igjen. Ved dataproblemer kan en samarbeide med en annen tester på dens fungerende datamaskin. BetaKey Payment System 9

Risiko 4.1 Prioriteringsliste Dersom det er umulig å få gjort alle testene er det laget en prioriteringsliste slik at testerne kan følge denne, og de nederste testene må bli nedprioritert ved utløpt tidsfrist. 1. Enhetstester 2. Funksjonell testing 3. Ikke-funksjonell testing a) Brukervennlighet b) Sikkerhetstest c) Stresstest d) Installasjonstest 4. Systemtest 5. Regresjonstest 6. GUI-testing a) Logg inn b) Administratorside c) Kassasystem d) Ansatt e) Produkt f) Leverandør g) Rapport h) Web-søk BetaKey Payment System 10

5 Testplan Testplan I dette kapittelet blir det presentert en timeplan for testingen av produktet BetaKey, se Tabell 5.1: Testplan. Hele prosjektet er delt opp i fire iterasjoner, Alpha, Beta, RC og RTM. All testing foregår i iterasjon RC. Tabell 5.1: Testplan Testplan for BetaKey AS Uke Dag Hva skal gjøres? Hvem? 13 Tirsdag, 28.3 Lage software test plan (STP) Ingrid Vik Hansen, med innspill fra resten av BetaKey AS 13 14 14 Fredag, 31.3 Lage virtuell test miljø (VTE) Testerne Tirsdag, 04.4 Teste software, utføre testtilfeller Testerne Fredag, 07.4 Lage enhetstester i VS Testerne 15 Påskeferie Alle 16 16 Tirsdag, 18.4 Enhetstester Testerne Fredag, 21.4 Enhetstester Testerne 18 og 19 Torsdag, 4.5 og Mandag, 8.5 Regresjonstest Joakim Moen og Amanuel Tedla 20 Mandag, 15.5 Godkjenningstest Halvorsen & Co BetaKey Payment System 11

Referanser 6 Referanser [1] http://www.guru99.com/black-box-testing.html [2] http://www.guru99.com/white-box-testing.html [3] http://www.guru99.com/gui-testing.html [4] http://www.guru99.com/functional-testing.html [5] http://www.guru99.com/stress-testing-tutorial.html [6] http://www.guru99.com/what-is-security-testing.html BetaKey Payment System 12