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

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Begynne med side:

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

Transkript

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

2 Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet fungerer testes på datamaskin Derfor er testing en viktig del av arbeidet med å utvikle programmet Testingen og testdokumentasjonen er en viktig del av dokumentasjonen som skal vise at programmet fyller kravene som er satt

3 Testing er Systematisk kjøring av programmet under kontrollerte betingelser for å Finne feil Dokumentere korrekt implementasjon Øke tiltroen til programmet Analysere program, dokumentasjon og andre beskrivelser

4 Terminologi noen ord og uttrykk Confidens Defect Debug Error Fail Failure Reliability Testing Validation Verification Debugging Terminologilisten Tiltro, tillit Feil eller Mangel Finne, analysere og rette, fjerne feil Feil, Avvik Å feile Problem, Avvik Pålitelighet Hele testprosessen Validere Bekrefte mot forventet bruk riktig system Verifisere - Bekrefte at krav er oppfylt systemet er riktig Finne, analysere og rette, fjerne feil

5 Testing og debuging Hensikten med testing er å Kjøre programmet for å påvise/finne feil Kjøre programmet for å vurdere kvaliteten Kjøre programmet for å vurdere tiltroen til det (confidens) Analysere program eller dokumentasjon for å finne svakheter (defects) Hensikten med debuging er å: Lokalisere og rette feil Lokalisere feilen - hvor finnes den? Analysere feilen - hva består feilen i? Rette og fjerne feilen Teste rettingen slik at ikke nye feil er introdusert

6 Debugging

7 Testing Systematisk kjøring av programmet under kontrollerte betingelser for å Dokumentere at systemet er korrekt implementert Øke tilliten til programmet Finne feil Analysere program, dokumentasjon og andre beskrivelser En fullstendig testing av systemet er umulig Testing kan derfor aldri dokumentere fravær av feil, bare at de ikke har opptrådt under testingen

8 Programkvalitet summen av alle kvalitetskriteriene Funksjonalitet Oppfylle kravene, alle funksjoner Sikkerhet Pålitelighet - stabilitet - Reliability Brukervennlighet - Usability Nytte - Efficiency Drift, Vedlikehold og Maskinplattform Det er nødvendig å prioriter mellom kriteriene

9 Den grunnleggende testprosessen Kronologisk beskriving av alle testoppgavene som skal gjennomføres Hver testoppgave må splittes i mindre oppgaver og spesifiseres nøyaktig Planlegging og kontroll Analyse og design Implementasjon og gjennomføring Evaluering Rapportering Avslutning

10 Teststrategi Lag en testspesifikasjon Avklar hvilke testteknikker som skal brukes Finn testtilfeller Test logikk og lag konkrete tilfeller Ikke glem grenseverdiene!!

11 Teststrategi 1. Prioriter mellom delsystemene De viktigste delsystemene testes først og mest inngående 2. Prioriter mellom funksjonene De viktigste funksjonene testes først og mest inngående 3. Bruk verdier som ligger i området som er mest benyttet

12 Testtilfeller Logisk testtilfelle Definer betingelser Definer forventet resultat Virkelig testtilfelle Velg en verdi Vurder hvilket logisk tilfelle verdien tilhører Utfør testen Vurder om forventet virkelig resultat stemmer med forventet logisk resultat i testtilfellet

13 Eksempel Logisk og virkelig Testnummer Inputverdi Forventet verdi (%) 1 X <= < X <= < X <= X >

14 Testpsykologi Verken vi eller systemene er feilfrie If anything can go wrong it will Murphys lov Systemutvikling vurderes som positivt Testing - finne feil vurderes som negativt Den som utvikler ser ikke egne svakheter Da ville ikke svakheten vært der Vurderer alltid eget arbeid som riktig Utvikling skjer i utviklingsmiljø som er forskjellig fra test- og bruks- og driftsmiljø

15 Testingens 7 grunnregler 1. Tester påviser feil, ikke feilfrihet 2. Fullstendig testing er umulig 3. Testing skal starte så tidlig som mulig 4. Feilene hoper seg opp 5. Tester mister effekten 6. Tester er kontekstavhengige 7. Et feilfritt system trenger ikke være et nyttig system

16 Oppsummering Terminologi er viktig omforent forståelse Testing er viktig for å kvalitetssikre utviklingsprosessen Grunnleggende testprosessen begynner med planlegging og slutter med rapport Et testtilfelle består av input, forventet resultat og virkelig resultat Mennesker gjør feil Testingens 7 grunnregler er viktige retningslinjer

17 Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om beskrivelsen er gyldig Evaluere Vurdere hvordan systemet passer til bruk i en organisasjonen i forhold til en beskrivelse Hensikten er å dokumentere at et datasystem fungerer slik det er forutsatt

18 To viktige spørsmål Bygger vi det riktige systemet - validering? Snakke med brukerne Lese kravspesifikasjonene og bestillinger Virksomhetsanalyse Bygger vi systemet riktig - verifisering? Inspisere kode Teste funksjoner Teste delsystemer Systemtest Akseptansetesten Kundens systemtest Evalueringen I hvor stor grad kan vi si at de to spørsmålene er oppfylte?

19 Forskjellige typer feil Kategori 1: Kritiske feil som MÅ rettes Lansering holdes igjen til feilen er rettet Kategori 2: Kritiske feil som bør rettes Betydelig reduksjon av kvaliteten Kategori 3: Ikke-kritiske feil kosmetiske feil Kategori 4: Ubetydelige feil Skrivefeil, feil fargenyanser,..

20 Systemets livsløp Strategsk behov Hva vil vi? Hvor går vi? Analyse og spesifikasjon Hvordan lager vi veien Utvikling Verktøyet for å komme dit Implementering Datakonvertering Forvaltning Drift og vedlikehold Systemavslutning Fase ut systemet og fjerne det

21 V-modellen Forutsetter at utvikling og testing er likeverdige aktiviteter Til hvert steg i utviklingen hører en test Kundespesifikasjon Kravspesifikasjon Funksjonell systemdesign Teknisk systemdesign Programmering

22 Testing i et uviklingsløp Review Kundespesifikasjon Prosjekttid Akseptansetesting Plan&Spesifiser Forbered Utfør Avslutt Review Kravspesifikasjon Plan&Spesifiser Systemtesting Forbered Utfør Avslutt Design Review Integrasjonstesting Plan&Spesifiser Forbered Utfør Avslutt Review Modul implementasjonmodultesting + MIT P&S Forbered Utfør Avslutt

23 Komponent- Klasse- Modul- Enhets-test Laveste testnivå Tester at modulen (klassen) virker isolert Forsikre oss om at kode eksekverer uten kjørefeil Simulerer omgivelsene til komponenten Utføres av utviklere Skrives ofte som automatiske tester Hva testes? dataflyt grenseverdier feilhåndteringsmekanismer

24 Integrasjonstest Teste samspillet mellom enheter. Målet er å rette feil knyttet til funksjoner som enhetene bare kan utføre sammen og som dermed ikke kan avdekkes under enhetstesting. Tester at komponenten (klassen) virker sammen med andre komponenter Simulerer ofte andre sub-systemer Bruker konstruerte testdata Utføres ofte av utviklere Gjøres ofte manuelt, men kan med fordel automatiseres

25 Systemtest Forsikre oss om at systemet fungerer i henhold til kravspesifikasjon, de avtalte kravene Tester at systemet oppfører seg korrekt i samspill med omgivelsene Systemtest kjøres etter at hele systemet er satt sammen, og i et testmiljø som skal simulere et driftsmiljø.

26 Akseptansetest - Mottakstest Kunden har ansvaret for å gjennomføre testen Tester at systemet lar brukerne gjøre det de trenger Tester med reelle data Utføres gjerne i samarbeid mellom kunder og testere Avklarer om kunden aksepterer systemet

27 Andre testtyper Funksjonstester - Black Box testing Hvordan systemet fungerer Strukturtester - White Box testing Ikke-funksjonelle tester Testing av alt annet enn funksjonalitet Pålitelighet, robusthet, brukskvalitet, brukervennlighet, dokumentasjon, vedlikehold. Endringstester Gjennomføres når det gjennomføres endringer i softwaren

28 Black-box testing - funksjonstesting Kildekoden er ukjent Black-box testing betrakter programvaren som en svart boks og kjenner bare grensesnittet mot omverdenen. Brukes til integrasjonstester, systemtester og akseptansetesten Testene utledes fra spesifikasjonen Kan brukes på alle systemer og nivåer Gi systemet inndata, kontroller utdata Viktig å finne inndata som fører til feil eller bekrefter at funksjonen fungerer riktig Bruke kunnskaper om anvendelsesområdet Gjennomføre systematiske testdatautvalg

29 Utfordringer ved Black-box testing Parametere kan ha feil rekkefølge og type Feil kan oppstå på grunn av feil i testomgivelsene test bed altså utenfor modulen som testes for eksempel i en driver eller en stub

30 White-box testing - strukturtesting Kildekoden er kjent White-box testing forutsetter kjennskap til den indre struktur og virkemåte til programmet som testes. Brukes mest i enhetstestene av de ulike modulene. Enhetstesten for egenutviklede moduler bør være whitebox testing Enhetstester for hyllevare og gjenbrukmoduler bør være black-box tester. Dermed testes grensesnittet til modulen som er de ulike funksjonene som er tilgjengelige i grensesnittet til modulen. For enhetstesten er utvikleren testansvarlig og bør utføre testen.

31 White-box testing - strukturtesting Andre navn Glass-box, Clear-box Målet er å teste alle programsetninger Egnet for små programmoduler Analysere kode for å identifisere ekvivalensklasser

32 Ekvivalensklasser Systemets inndata deles i grupper (klasser) En ekvivalensklasse er en datamengde der alle elementene behandles likt ekvivalensklasser kan identifiseres fra spesifikasjonen Tommelfingerregel Velg data som ligger godt inne i ekvivalensklassen og på grensen Grenseverdier blir ofte behandlet feil av programmet.

33 Black- og white-box testing Komponent Inndata Utdata Black box: Gir input forventet output? Komponent Inndata Xxxxx xxxxx Utdata White box: Følger hvert trinn i komponenten. Midlertidige utskrifter.

34 Kvalitet av programvare Kvalitet i hvilken grad en samling av iboende egenskaper oppfyller krav Krav behov eller forventninger som er angitt, vanligvis underforstått eller obligatoriske Krav kan fremsettes av forskjellige personer

35 Kvalitet en subjektiv vurdering Kvalitet er å oppfylle krav Den som formulerer kravet vurderer om produktet oppfyller kravet Forskjellige personer med ulike krav vurderer derfor kvalitet ulikt Krav er det samme som behov og forventninger Derfor er Kvalitet er en subjektiv vurdering Kvalitet tidsavhengig

36 Kvalitet av et IT-system Systemets evne til å oppfylle krav, ønsker og forventninger Hvor godt systemet stemmer med med de opprinnelige skriftlige spesifikasjoner Forholdet mellom forventet og opplevd ytelse og funksjon av systemet Opplevd kvalitet Subjektiv vurdering av den enkelte bruker som kommer i kontakt med systemet

37 Kvalitetsegenskap Generelle kvalitetsattributter Korrekthet Utfører det som er spesifisert i kravene Pålitelighet Du kan stole på programmet Robusthet Tåler at det skjer uforutssette ting

38 Når har et program riktig kvalitet? Når det har høyest mulig kvalitet? Når det har få feil? Når det oppfyller våre ønsker best mulig? Når det er utviklet etter bestemte kvalitetskrav? Når det er utviklet i land med menneskerettigheter? Når virksomheten har etiske retningslinjer? Når det er utviklet etter anerkjente metoder? Når det er utviklet med anerkjente verktøy? Når det ikke gjør skade på brukere eller andre?

39 Innhold i en kravspesifikasjon Innledning Oppdragsgiver, prosjekt- og brukergrupper Overordnet systembeskrivelse Hensikten, grafer med dataflyt, konsekvenser Rammebetingelser Tilgjengelighet, datasikkerhet, kapasitet Funksjonelle egenskaper Spesifisere skjermbilder, rapporter, inndata. Logisk datamodell Sammenhengen mellom datasettene,

40 Evaluering av systemkvaliteten Vurdert ut fra kravspesifikasjonen Hva har brukerne bedt om? Hva er det brukerne ønsker eller forventer Vurdert ut fra hvordan systemet fungerer i bruk Hva er det brukerne faktisk trenger Vurdert ut fra systemets plass/rolle i organisasjonen

41 Objektive og subjektive kvalitetskrav Objektive krav Funksjonskrav Ytelseskrav Tekniske krav Subjektive Bruksmessige krav Estetiske krav Symbolske krav

42 Akseptansetest Akseptansetesten utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med spesifikasjonen og annen dokumentasjon. Akseptansetesten er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. En godt gjennomført akseptansetest kan beskytte kunden mot tap som skyldes dårlige produkter

43 Plass i V-modellen Kundespesifikasjon Akseptansetesting Kravspesifikasjon Systemtesting Design Integrasjonstesting Modul implementasjonmodultesting + MIT

44 Planlegging av testen Akseptansetesten består av fem faser: 1. Bestemme hvor kritisk systemet er (Analyser krav til testen) 2. Bestemme hvilke kvaliteter som skal testes eller evalueres (Spesifiser detaljerte krav til testen) 3. Designe testen 4. Utfør testen 5. Rapporter resultatene De første tre fasene tilhører planleggingen og er først og fremst kundens ansvar. De siste to fasene krever sterk deltakelse av leverandøren.

45 Utarbeide testkrav Beskriv scenarier og dokumenter hver funksjon Beskrivelsene skal vise hvordan en bruker utfører funksjonene. Oppstår situasjoner som ikke passer med tidligere beskrivelser så lag nye scenarier. Sjekk alt som er spesifisert Se etter situasjoner ikke er spesifisert, men allikevel er viktige. Eksempler: registrering av motstridende opplysninger slutt på papir midt i en jobb som krever utlisting duplisert registrering av opplysninger som ikke skal dupliseres generelle betjeningsfeil oppnår ikke kontakt med database, server etc.

46 Hva skal testes alt eller prioritet? Risiko for feil og viktighet i praktisk bruk. Vektlegger at testen skal finne maksimalt antall feil. Prioriterer komplekse systemdeler Deler hvor en vet at det har vært usikkerhet, der det har vært strid, endringer, og der det har vært mye feil i tidligere tester. Slike systemdeler kan (men må ikke) gi trøbbel senere. Finne feilene som er viktigst i drift Teste funksjoner som brukes oftest i praksis. Sjeldne situasjoner og sjeldent brukte funksjoner testes kuttes ut. Det finnes statistiske metoder til å evaluere testen beregne forventet pålitelighet i drift.

47 Valg av testdata For hvert scenario finnes fram til variasjonsbredden i input- og outputdata og det velges forskjellige data som dekker denne variasjonen. Valg av testdata medfører ekvivalensklasseinndeling, grenseverdianalyse, årsaks-virkningsanalyse og bruk av parvise kombinasjoner Hvert scenario bør utføres flere ganger med ulike testdatasett.

48 Oppsummering Kunden bør forberede testscenarier samtidig med spesifikasjonen. Kundens testansvarlige skal arbeide med test på heltid (i spesifikasjons- og testfasen). Testen gjøres grundig, men skal ikke finne for mange feil. Testen inkluderer vurdering av brukerhåndbok og andre dokumenter. En må avtale tidlig hva som er feil og hva som er endringsønsker. Testen (eller deler av den) bør kjøres om igjen etter feilretting.

49 Metrikker og målinger Vi vil gjerne vite: Hvor stort er programmet? Hvor godt er programmet? Hvor lett er det å vedlikeholde? Hvor mange feil er det i programmet? Hva vil testingen koste? Hvor lang tid tar det å utvikle et lignende program?

50 Grunnlaget for å bruke metrikker Behov for på en objektiv måte kunne Beskrive funksjonalitet Sammenligne systemer Evaluere systemer Forutsi Programkompleksitet Utviklingstider Utviklingskostnader

51 Hva er en metrikk? En metrikk er en målbar egenskap både for et system eller en prosess målbar egenskap eller størrelse i en eller flere deler av et informasjonssystem beregnet eller komponert indikator basert på to eller flere målinger karakteristikk av et produkt eller prosess En metrikk bør være en objektiv størrelse som ikke påvirkes av personen som utfører målingene

52 Typer av metrikker Produktmetrikker Antall kodelinjer Størrelse på installert program Mengden av dokumentasjon Prosessmetrikker Utviklingstid, Planlagt og virkelig Ressursbruk, Planlagt og virkelig Produktivitet, Kodelinjer, funksjonspoeng Kvalitet, feil/kodelinjer Metode for utviklingen Kompetanse til utviklingsteamet

53 Metrikker for ikke-funksjonelle krav Egenskap Hastighet Størrelse Brukbarhet Brukskvalitet (Usability) Pålitelighet Robusthet Portabilitet Mål Utførte transaksjoner per sekund, Behandlede hits/s Bruker/hendelsesresponstid, Skjermoppfriskningstid kb, MB Treningstid, Antall hjelpesider Gjennomsnittlig betjeningstid per transaksjon MTBF Gjennomsnittstid mellom svikt Oppetid MTTR Gjenstarttid etter svikt Andel av hendelser som fører til svikt Andel av målavhengige setninger Antall mål

54 Hva er statisk testing? Analyser utført på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene Resultatene kan brukes til å optimalisere utviklingsprosessen og gi innspill til den dynamiske testingen

55 Testtyper Strukturerte gruppegjennomganger Reviews Gjennomganger, inspeksjoner Statiske analyser Bruke compilere for å kontrollere syntaks og variabler Teste konvensjoner og standarder Utføre dataflytanalyse Utføre kontrollstrukturanalyse Definere metrikker

56 Hva er dynamisk testing? Kjøring av testobjektet på en datamaskin Hensikten er å finne avvik fra forventede verdier eller bekrefte verdier Uferdige deler av programmet erstattes av testomgivelser, driver og stub Enkle moduler testes som White-box Kompliserte moduler testes som Black-box Testdataene deles i ekvivalensklasser

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

Repetisjon av testing. Vi undersøker om systemet virker slik det skal Repetisjon av testing Vi undersøker om systemet virker slik det skal Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende testteori. Etter Hans Schaefer Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,

Detaljer

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

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene

Detaljer

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Error-Fault-Failure 2 Error : når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til

Detaljer

Metrikker og målte størrelser. Vi måler fakta for å bestemme systemets egenskaper

Metrikker og målte størrelser. Vi måler fakta for å bestemme systemets egenskaper Metrikker og målte størrelser Vi måler fakta for å bestemme systemets egenskaper Hva vil vi vite? Hvor stort er programmet? Hvor godt er programmet? Hvor lett er det å vedlikeholde? Hvor mange feil er

Detaljer

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

BlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009 BlackBox, WhiteBox og andre testmetoder Etter ønske fra studentene 26. november 2009 Hva er testing? Testing er å undersøke IT-systemer eller deler av det for å vurdere om kravene til det som testes er

Detaljer

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

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

Validering og verifisering. Kirsten Ribu

Validering og verifisering. Kirsten Ribu Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer

Detaljer

ISTQB Foundation Level Prøveeksamen

ISTQB Foundation Level Prøveeksamen ISTQB Foundation Level Prøveeksamen Svar på følgende spørsmål For hvert spørsmål er der ETT og BARE ETT rett svar! (Unntak er avmerket spesielt). Spørsmål til Kap 1 ("Fundamentals") 1.1. (K2) Hva er betydningen

Detaljer

Inf1055 Modul B 26 april 2017:

Inf1055 Modul B 26 april 2017: Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting

Detaljer

Testing av programvare. INF1050: Gjennomgang, uke 08

Testing av programvare. INF1050: Gjennomgang, uke 08 Testing av programvare INF1050: Gjennomgang, uke 08 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet

Detaljer

Prosjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning?

Prosjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning? Testing og evaluering av systemer Kirsten Ribu 23.10.2007 Prosjektet - leveranser Utfyll prosjektplanen etterhvert: Estimat Risikoplan Kravspesifikasjon Roller og arbeidsoppgaver Lag mappe med gruppenavn,

Detaljer

Kirsten Ribu

Kirsten Ribu Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Validering og verifisering Prototyping Inspeksjon Testing 2 Validering og verifisering Å sørge for at et datasystem tilfredsstiller brukerens behov

Detaljer

Krav som bør stilles til leverandørens verifikasjon og test

Krav som bør stilles til leverandørens verifikasjon og test Krav som bør stilles til leverandørens verifikasjon og test Av Hans Schaefer Versjon 1.2, 14.9.2005 Dette dokument beskriver krav en bør stille til verifikasjon under utviklingen og test hos en seriøs

Detaljer

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

UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 14 Versjonshåndtering og testing Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKENE FREMOVER OBS! Ikke forelesning 17. mai ikke gruppetime 19. og 23. mai Felles gruppetime for alle fredag

Detaljer

Testplan (Software Test Plan)

Testplan (Software Test Plan) 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

Detaljer

Retningslinjer for akseptansetest

Retningslinjer for akseptansetest Retningslinjer for akseptansetest 1 Akseptansetest i DGI Akseptansetest (AT) er kundens egen test for å verifisere at leveransen er i henhold til bestillingen. Ifølge V-modellen som knytter testnivå til

Detaljer

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

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Input Output Hvordan kan vi fastslå om systemet er testbart? Hvordan kan vi lære mer om systemet? Hvordan kan vi bli bedre

Detaljer

Grunnleggende om Evaluering av It-systemer

Grunnleggende om Evaluering av It-systemer Grunnleggende om Evaluering av It-systemer Hva er å evaluere? Foreta en vurdering av systemet og avklare nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien

Detaljer

Retningslinjer for akseptansetest

Retningslinjer for akseptansetest Bilag 5 Kundens godkjenningsprøve Retningslinjer for akseptansetest 1 Akseptansetest i DGI Akseptansetest (AT) er kundens egen test for å verifisere at leveransen er i henhold til bestillingen. Ifølge

Detaljer

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering 1 2 Læringsmål og pensum TDT4110 Informasjonsteknologi grunnkurs: Uke 38 Utvikling av informasjonssystemer Læringsmål Kunne seks faser for systemanalyse og design Kunne femstegs prosedyre for programmering

Detaljer

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

Testdekning og automatisering - Er 100% testdekning et mål? Testdekning og automatisering - Er 100% testdekning et mål? Shomaila Kausar, Senior prosjektleder/testleder Ole Fingal Harbek, Senior Testleder Testdagen Odin 2017 Kort om oss Shomaila Kausar - cand scient

Detaljer

Finansportalen Historiske bankdata

Finansportalen Historiske bankdata Bilag 5: Testing og godkjenning For Finansportalen Historiske bankdata Bilag 5 Testing og godkjenning Innholdsfortegnelse 1.1 OMFANG... 3 1.1.1 Systemtest 3 1.1.2 Godkjenningsprøve 3 1.2 GJENNOMFØRING...

Detaljer

Automatisert Robusthetstesting. Erik Arisholm Testify AS

Automatisert Robusthetstesting. Erik Arisholm Testify AS Automatisert Robusthetstesting Erik Arisholm Testify AS 21. september Robusthetstesting Robusthetstesting er testing som avslører sårbarheter i et system overfor uventede (kombinasjoner av) input stressende

Detaljer

Testing av programvare

Testing av programvare Inf1050 07 mars 2017: Testing av programvare Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting

Detaljer

Testbilag til IT kontrakter

Testbilag til IT kontrakter Testbilag til IT kontrakter Grunner til å lage dette testbilaget Unngår å diskutere de samme problemstillingene i hver kontrakt testfaglige selvfølgeligheter blir landet av testfaglig personell en gang

Detaljer

Repetisjon om evaluering av It-systemer. Hvordan vurdere og verdsette?

Repetisjon om evaluering av It-systemer. Hvordan vurdere og verdsette? Repetisjon om evaluering av It-systemer Hvordan vurdere og verdsette? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme om Verdsette Vurdere,

Detaljer

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravhåndtering. INF1050: Gjennomgang, uke 03 Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle

Detaljer

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

Overordnet Testplan. MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt. Page 1 of 11 Overordnet Testplan MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt Page 1 of 11 Innhold 1 Innledning... 4 1.1 Hensikten med dette dokumentet... 4 1.2 Grensesnitt.... 4 1.3 Omfang av dokumentet... 4 1.4

Detaljer

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Kirsten Ribu

Kirsten Ribu Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Om prosjektet Validering og verifisering Prototyping Inspeksjon Testing 2 Prosjektet Status: Bra framgang Solid arbeid Roller: Definer rollene tydelig.

Detaljer

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11 Konfigurasjonsstyring INF1050: Gjennomgang, uke 11 Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering Del

Detaljer

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

Test i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti Test i smidig Laila Sandbæk Testrådgiver og testleder Sogeti 03.03.2016 Produktkøen til foredraget Sprintrytme Plassering av testaktivitetene i sprintrytmen Teamet Test som en integrert del av gjennomføringsmodellen

Detaljer

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

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet JigZaw Verifiser Forventet Funksjonalitet Teststategi utviklet av Erik Drolshammer Bård Lind Bård Lind Java siden 1997 Arkitekt siden 2000 JavaBin siden 1999 Enterprise Domain Repository og JigZaw-teststrategi

Detaljer

Evaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet

Evaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet Evaluering av It-systemer i et forvaltningsperspektiv Drift, vedlikehold og videreutvikling av IT-systemet Bakgrunnen IT-systemer har ofte lenger levetid enn forventet er ofte forretningskritiske utvikler

Detaljer

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette?

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette? Introduksjon til evaluering av It-systemer Hvordan vurdere og verdsette? Bør jeg gå på forelesning i dag? Kriterier for eller imot: Interessant/kjedelig tema God/dårlig foreleser Kan lese forelesningene

Detaljer

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:

Detaljer

Test og kvalitet To gode naboer. Børge Brynlund

Test og kvalitet To gode naboer. Børge Brynlund Test og kvalitet To gode naboer Børge Brynlund To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig

Detaljer

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

Test i Praksis. NTNU Februar 2014. Copyright 2014 Accenture All Rights Reserved. Test i Praksis NTNU Februar 2014 Hvem er vi? Erik Gjerdrum Master i Kommunikasjonssystemer fra IFI UiO Jobbet med test i siden 2006 Markus Living Master i Industriell Økonomi fra Linköping, Sverige Jobbet

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Mellom barken og veden Smidig testing i krevende terreng TTC 2015 Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway

Detaljer

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 12. sept. 06 Forholdet mellom informasjonssystemet og virkeligheten Hva innebærer utvikling av et IS (systemutvikling: SU) Å utvikle et IS det

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

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

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

Forslag til ny læreplan for informatikk studieretningsfag

Forslag til ny læreplan for informatikk studieretningsfag Forslag til ny læreplan for informatikk studieretningsfag Jens Kaasbøll, undervisningsleder, Institutt for Informatikk Foredrag på Faglig-pedagogisk dag Universitetet i Oslo, 4. januar 2000 1 Behov for

Detaljer

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

Gårsdagens testroller takler ikke dagens utfordringer. Magnus Halvorsen og Erik Rogstad Gårsdagens testroller takler ikke dagens utfordringer Magnus Halvorsen og Erik Rogstad Eksempel: Testutlysning fra fortiden Arbeidsoppgaver Utarbeide testtilfeller basert på kravspesifikasjon Gjennomføring

Detaljer

Eksamen 2013 Løsningsforslag

Eksamen 2013 Løsningsforslag Eksamen 2013 Løsningsforslag Oppgave 1. Multiple choice 1b# 2a# 3b# 4c# 5b# 6a# 7a# 8b# 9d# 10b# Oppgave 2 - Bibliotek - Utlån av bøker a) Måle størrelse eller mengde funksjonalitet Denne oppgaven ser

Detaljer

TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer TDT4735 Systemutvikling, fordypning Metoder for systemtest av websystemer Hong Trang Thi Nguyen Veileder: Tor Stålhane Høst 20-12-2005 Norges teknisk-naturvitenskapelige universitet Forord Dette prosjektet

Detaljer

Effektiv testing med rike anonymiserte testdata

Effektiv testing med rike anonymiserte testdata Effektiv testing med rike anonymiserte testdata 20. september 2016 Helene Aune Skatteetaten Erik Rogstad 21. september 2016 Skatteetatens IT- og Servicepartner Skatteetatens leverandør av IT- og administrative

Detaljer

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Verifikasjon og validering

Verifikasjon og validering Verifikasjon og validering 19. oktober 2006 - INF3120 Nils Christian Haugen & Stein Grimstad Hvem er vi? Nils Christian Haugen Chief Scientist i Objectnet Utdannelse fra NTNU E-post: nch@objectnet.no Stein

Detaljer

Brukskvalitet. Lett å bruke og samtidig nyttig

Brukskvalitet. Lett å bruke og samtidig nyttig Brukskvalitet Lett å bruke og samtidig nyttig Fem grunner til at systemer kan være vanskelige å bruke Systemet er ikke tilpasset brukeren, men maskin og arbeidsoppgave Arbeidsoppgaver endres raskt - systemer

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

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

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

Effektiv testing. Per Otto Bergum Christensen. 9.-10. September, JavaZone. Bergum Christensen Consulting

Effektiv testing. Per Otto Bergum Christensen. 9.-10. September, JavaZone. Bergum Christensen Consulting Effektiv testing Per Otto Bergum Christensen 9.-10. September, JavaZone Bergum Christensen Consulting Om meg Per Otto Bergum Christensen (33) Siv.ing, Datateknikk, NTNU Jobbet med utviklingsprosjekter

Detaljer

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

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Manager at Lånekasse 21.mars.2013 Heza Wasfy Hvem er Sogeti? Sogeti Norge er et heleid datterselskap

Detaljer

Løsningsforslag Sluttprøve 2015

Løsningsforslag Sluttprøve 2015 Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2015.05.27 Time: 09:00-12:00

Detaljer

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300 EKSAMEN Emnekode: ITL24006 Dato: 4. desember 2007 Hjelpemidler: Emne: Evaluering av IT-systemer Eksamenstid: kl 0900 til kl 1300 Faglærer: Ingen, heller ikke kalkulator eller mobiltelefon Kåre Sorteberg

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Kvalitet i programvaresystemer Dokumentasjon av tester

Kvalitet i programvaresystemer Dokumentasjon av tester Kvalitet i programvaresystemer Dokumentasjon av tester Dette notatet handler om dokumentasjon av tester. Gjennom utforming og gjennomføring av tester søker man å avdekke så mange feil i et program som

Detaljer

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette?

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette? Introduksjon til evaluering av It-systemer Hvordan vurdere og verdsette? Bør jeg gå på forelesning i dag? Grunner for eller imot: Interessant/kjedelig tema God/dårlig foreleser Kan lese forelesningene

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Kravspesifikasjon MetaView

Kravspesifikasjon MetaView Kravspesifikasjon MetaView BACHELOROPPGAVE VÅREN 2014 1. Presentasjon Tittel: MetaView Oppgave: Lage en applikasjon og api som skal kommunisere med MetaVision slik at det skal bli enklere for leger og

Detaljer

UKE 10 Kravhåndtering. Gruppetime INF1055

UKE 10 Kravhåndtering. Gruppetime INF1055 UKE 10 Kravhåndtering Gruppetime INF1055 Hva skal vi i dag? Kravhåndtering - kapittel 4 Ukesoppgaver: Smidig programvareutvikling og kravhåndtering Krav KRAV KOMPETANSEMÅL: Kravhåndtering: anvende metoder

Detaljer

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt Why Desperate Houswives make Excellent Managers prosjektet som suksessfaktor i et hvert prosjekt dagen ODIN 21.November 2012 Hvem er jeg Astrid Notø Larsen Cand Scient i Informatikk fra UiO 15 års erfaring

Detaljer

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

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

DRI2001 forelesning

DRI2001 forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 6.10.04 Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer for SU-arbeidet Ulike SU-metoder Perspektiver i SU-arbeidet SU er

Detaljer

Konfigurasjonsstyring

Konfigurasjonsstyring INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

Oppsummering. Thomas Lohne Aanes Thomas Amble Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt

Detaljer

Modernisering av IKT i NAV

Modernisering av IKT i NAV Modernisering av IKT i NAV Test, Leverandørperspektiv Vedtaksløsningen 28.05.13 Kristian Bjerke-Gulstuen Innhold Kort introduksjon til Moderniseringsprogrammet i NAV Overordnet oversikt over test i NAV

Detaljer

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

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

Presentasjon Test. Møte med Systemleverandører 5.desember 2014

Presentasjon Test. Møte med Systemleverandører 5.desember 2014 Presentasjon Test Møte med Systemleverandører 5.desember 2014 Agenda Informasjon om status og planer for videre arbeid i Elhubprosjektet Informasjon om organisering av testaktiviteter Presentasjon av kravspesifikasjoner

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Generelt om operativsystemer

Generelt om operativsystemer Generelt om operativsystemer Hva er problemet? Styring av maskinvare og ressurser tilknyttet en datamaskin er komplisert, detaljert og vanskelig Maskinvare, komponenter og programvare endres og forbedres

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

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

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne.

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne. A KRAVSPESIFIKASJON Dette notat er en generell beskrivelse av en kravspesifikasjon for et (teknisk) datasystem. Den er basert på «The STARTS Purchasers Handbook» kap.4 og Appendix B, oversatt til norsk

Detaljer

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 1 Ulike typer prosessmodeller De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Why Desperate Houswives make Excellent Test Managers En gjennomgang av testfaser i prosjekt

Why Desperate Houswives make Excellent Test Managers En gjennomgang av testfaser i prosjekt Why Desperate Houswives make Excellent Test Managers En gjennomgang av testfaser i prosjekt NFP s Arena for Prosjektledere 19.April 2012 Hvem er jeg Astrid Notø Larsen Cand Scient i Informatikk fra UiO

Detaljer

Brukersentert design Kapittel 3 i Shneiderman

Brukersentert design Kapittel 3 i Shneiderman Brukersentert design Kapittel 3 i Shneiderman ISO 9241-210 Iterativ og brukernær systemutvikling. Kriterier for valg av metode. Brukersentrert design vs. RUP. Deltagende design Den skandinaviske arven.

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Automatisert test som leveransekrav

Automatisert test som leveransekrav Automatisert test som leveransekrav Testdagen Odin 2015 Marianne Rynning, Skatteetaten Magnus Halvorsen, Testify Skatteetatens IT- og servicepartner (SITS) Skatteetatens leverandør av IT- og administrative

Detaljer

Testing i smidigavtalen (SSA-S) Seniorrådgiver Mari Vestre, Difi. Testdagen ODIN 24. september 2014.

Testing i smidigavtalen (SSA-S) Seniorrådgiver Mari Vestre, Difi. Testdagen ODIN 24. september 2014. Testing i smidigavtalen (SSA-S) Seniorrådgiver Mari Vestre, Difi Testdagen ODIN 24. september 2014. Mari Vestre: Cand Real i informatikk fra UiO 1985 Jobbet som prosjektleder, testleder, linjeleder Laget

Detaljer

Diskusjonsoppgaver Hvilke fordeler oppnår man ved analytisk evaluering sammenliknet med andre tilnærminger?

Diskusjonsoppgaver Hvilke fordeler oppnår man ved analytisk evaluering sammenliknet med andre tilnærminger? Definisjonsteori Hva er de tre hovedtilnærmingene til evaluering? Nevn de seks stegene i DECIDE. (blir gjennomgått neste uke) Gi et eksempel på en måte å gjøre indirekte observasjon. Hva ligger i begrepene

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer