Validering og verifisering

1. Validering og verifisering Kirsten Ribu 2005

2. I dag • Validering og verifisering • Inspeksjon • Testing

3. Noen ord om prosjektet • Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) • Hvordan fungerer gruppene? • Fungerer arbeidsfordelingen? • Fungerer møtene? • Hvordan gjør dere rapportering? • Kom med spørsmål! • Husk å logge alle problemer/løsninger = skal inn i prosessrapporten • Samle alle filer i ett dokument etter hvert

4. Innlevering i dag • Leveranse III • Oppdatert prosjektplan (husk versjonsnummer) • Oppdatert use case modell med beskrivelser • Sekvensdiagram for 2 sentrale use case • Estimat over forventet tidsbruk (antall timer) • Tidsplan (aktivitetsplan)

5. Tilbakemeldinger • Tirsdager kl 0940 og onsdag kl 1210 • Ta ellers kontakt med Kirsten på mail og kom på kontoret for samtale • Husk: Dette er et praktisk fag, og øvelse gjør mester! • Men det er en del teori som skal på plass også ;-) • Endelig leveranse: Systemet må ikke være ferdig! • En protoyp med noe funskjonalitet er godt nok, men BESKRIVELSENE er viktige!

6. Validering og verifisering • Å sørge for at et datasystem tilfredsstiller brukerens behov

7. Hvorfor validering og verifisering? • For å kunne vurdere hva vi gjør og hvorfor vi gjør det • Behov for verifisering øker med størrelsen på systemet • Ca 1/3 av utviklingstiden brukes å testing • Noen ganger opp til 50% • Systemutvikling er en industriell prosess!

8. Statisk og dynamisk verifisering • Inspeksjoner (statisk verifisering) • Analyse av systemet • kodeinspeksjon og gjennomgang av dokumentasjon for å oppdage probelemer • Testing (dynamic verifisering) • Observasjon av systemoppførsel • Systemet kjøres med testdata

9. V&V: • Validering: “Bygger vi det riktige systemet?” • Snakke med brukerne • Bruke use case modellen • Verifikasjon: “Bygger vi systemet riktig?” • Manuelle inspeksjonsmetoder • Automatisert testing

10. Mennesker gjør feil • Det vi lager er ikke det vi burde laget • Det vi lager har defekter • Vi trenger ikke nødvendigvis ”best mulig” kvalitet: Godt nok er bra nok. • Jo senere en feil oppdages, desto mer alvorlig er det • Feil kan være forretningskritisk (i ytterste konsekvens kan menneskeliv gå tapt)

11. Hva slags feil?

12. Hvorfor finnes feil i ferdige produkter? • Det som er laget er feil (ikke det kunden vil ha) • Ikke alle feil prioriteres rettet: • 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)

13. Forts. • I praksis umulig å få verifisert alle kombinasjoner av input til et system • Tendens til å teste og vektlegge bekreftelser, i motsetning til å prøve å falsifisere. • NB! Det er en vesentlig forskjell i holdning mellom det å utvikle og det å teste. • En god utvikler er ”konstruktiv”, mens en god tester er ”destruktiv”. • Mange organisasjoner velger derfor å skille rollene, dvs. å ha egne testere. • Tendens til å tro at sist funnet feil er “siste feil”.

14. Hvordan verifisere? • Finn ut om vi har laget systemet riktig: • Sammenlign produktet med kravspesifikasjonen • Kravspek er visualisert i use case modellen beskrevet i use case’ne

15. Hensikten med testing • Finne feil • Vurdere kvaliteten på systemet i forhold til kravene • Riktig kvalitet ( ikke nødvendigvis ’beste kvalitet’) • Vite når systemet er ferdig!

16. Kvalitetssikringsstandarder • ISO 9000 – familien • ISO 9001 standarden beskriver kvalitetssikringsarbeidet i hele livssyklusen • Utviklingsprosesse (for eksempel RUP) er også en kvalitetssikringsprosess

17. 3 måter: • Prototyping • Benyttes tidlig i utviklingsprosessen • Lage et utkast til hvordan det endelige systemet kan se ut. • Testes mot sluttbruker • Inspeksjoner • Benyttes i alle faser av utviklingsprosessen • Gjennomgang av leveranser • Utføres hovedsakelig mennesker, men kan være programmer • Testing • Gjøres sent i utviklingsprosessen • Sjekke hvor godt systemet oppfyller kravene • Resultatet av kjøringer sammenlignes med fasit

18. Ikke motsetninger • Inspeksjoner og testing bør brukes sammen under programvareutviklingen • Test casene bør også inspiseres! • Inspeksjoner avdekker feil ved test casene • Dermed kan det lages mer effektive måter å teste systemet på

19. 1.Prototyping • Utkast til hvordan systemet kan se ut • Tegninger (storyboarding) • Skjermbilder uten funksjonalitet • Brukes til validering av systemet i krav/analyse-fasen • Enkelt for brukere å forholde seg til (i forhold til modeller og dokumenter) • Avdekker effektivt manglende/feil krav og forretningsregler • Ulemper: • Gode prototyper kan gi falske forventninger i forhold til hvor langt prosjektet har kommet • Brukere kan bli opphengt i irrelevante detaljer

20. Verktøy • • Penn og papir • • Whiteboard • • Tegneprogrammer • • HTML-editorer • • GUI-byggere • • Modellbaserte prototypingsverktøy • • Programmeringsspråk

21. Eksempel

22. 2. Inspeksjon • Dokumentgjennomgang • Kodegjennomgang

23. Dokumentgjennomgang • Gjennomgang av dokumenter med formål å finne feil og mangler • Forskjellige teknikker kan benyttes • ”parprogrammering” (kontinuerlig inspeksjon) • Forskjellige typer gjennomgangsmøter (dokumentet presenteres i møtet, distribueres på forhånd • Hvem bør gjennomgå dokumentet? • De som skal ha systemet • De som skal bruke dokumentet • De som har vært delaktige i utformingen av dokumentet • Eksperter (rollen / forretningsområdet)

24. Kodegjennomgang • Gjennomgang av kildekoden for å finne feil og mangler • Funksjonelle feil (avvik fra design og kravspesifikasjon) • Avvik fra kodestandard og retningslinjer (for eksempel navngiving av klasser) • Tekniske feil (for eksempel feil i en hashmap-funksjon) • Testbarhet (for eksempel dokumentasjonsmangler, muligheten for isolasjon, etc) • Forskjellige teknikker kan benyttes • Parprogrammering (kontinuerlig kodegjennomgang) • Distribusjon til en eller flere for gjennomlesning • Koden gjennomgås av en review-gruppe i et møte • Aspektbasert inspeksjon

25. Inspeksjons-team • Hvem bør gjennomgå kode? • Sjefsprogrammerer/designere • Juniorprogrammerere (opplæring) • Testere • Tekniske eksperter • Arkitekter • Minst 4 medlemmer i teamet: • Den som har laget koden • Inspektør som finner feil, uoverenstemmelser, mangel på konsistens • OPpleser som leser koden for teamet • Møteleder som noterer feilene som blir funnet

26. Fordeler • Mer enn 60% av alle feil kan oppdages ved kodeinspeksjon (Fagan) • Med matematisk verifisering kan 90% av feil i koden oppdages. • Mange ulike defekter oppdages under en enkelt inspeksjonsrund • (Ved testing: Kan ofte bare oppdage 1 feil - programmet kræsjer f.eks ved feil) • Gjenbruker kunnskap om domenet og programmeringsspråk • Inspektørene har sannsynligvis sett vanlig feil relatert til programmeringsspråket og i den type applikasjoner. • Derfor er det fokus på denne type feil under inspeksjonen

27. 3. Testing - Typer av test • V-modellen • Testplan • Testdata • Ekvivalensklasser • Enhetstesting (med verktøy og eksempler gjerne relatert til XP) • Testdrevet utvikling • Gjenbruk

28. Testing • En form for ”induktiv bevisføring”, dvs. å vise (sannsynliggjøre) at alle svaner er hvite ved å observere et representativt utvalg av alle svaner. • Test er både verifikasjon og validering • Testing kontrollerer ny funksjonalitet, samt at eksisterende funksjonalitet fortsatt virker (regresjonstesting) • Effektiv testing gjøres ved: • Testbare krav • Testbare programvarestrukturer • Bruk av ekvivalensklasser • Testverktøy • Gjenbruk

29. Testing vs. debugging • Testing er ikke det samme som debugging • Testing er å finne feil • Debugging er å rette feil • men begge deler gjøres ofte i test-fasen av prosjektet (noe uklare grenser)

30. Eksempel

31. Det første virkelige tilfelle av ”bug” 9. september 1945, kl. 3:45 p.m., fant forskere ved Harvard universitetet årsaken til at Mark II Aiken Relay kalkulatoren oppførte seg merkelig En møll ble funnet fanget mellom punkter på relé #70, panel F Maskinen ble ”debugget” med en pinsett! Dokumentert i loggen som ”First actual case of bug being found.” med møllen tapet inn ved siden av

32. Type test • Enhetstest/funksjonstest • Hvem tester: Programmerer • Integrasjons- og systemtest • Hvem tester: Tester • Akseptansetest • Hvem tester: Installatør og kunde • Drift: • Kunde

33. Typer testing • Enhetstest • Tester at komponenten (klassen) virker isolert • Simulerer omgivelsene til komponenten • Utføres av utviklere • Skrives ofte som automatiske tester • Integrasjonstest • 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

34. Typer testing forts. • Betatest • Utvalgte kunder tar i bruk systemet før offisiell lansering • Akseptansetest • Tester at systemet lar brukerne gjøre det de trenger • Tester med reelle data • Utføres gjerne i samarbeid mellom kunder og testere • Systemtest • Tester at systemet oppfører seg korrekt i samspill med omgivelsene

35. Type testing forts. • Ytelsestest (tester ytelse = hastigheten på én transaksjon) • Stresstest (overbelastningstest) (tester skalerbarhet = hastigheten på mange samtidige transaksjoner) • Recoverability-test (tester systemets håndtering av uforutsette avbrudd)

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

37. Neste gang Brukergrensesnitt: Haakon Aspelund fra Sosialdepartementet kommer i 1 time og snakker om Universell design (design for alle).