in3240

Hvorfor er testing nødvendig?

Software systems er en viktig del og en essensiell del av livet.

Hvis et system ikke fungerer slik det skal kan det lede til:

• frustrasjon
• tap av penger
• tap av business reputation
• skader / død

VI MÅ FOREBGYGGE DE FEILENE VI KAN, og det kan vi gjøre med testing

Defects/defekter vs Failures/feil

Defekter:
Problemer i koden som potensielt kan skape en failure/feil.
=bugs, issues, errors.

Failures/feil:
Problemer som oppstår når SW ikke oppfører seg som forventet. Failures kan skje pga defeker/bugs men kan også oppstå på grunn av feil bruk eller eksterne faktorer.

Grunner til software defekter

Menneskelige faktorer:

• Tretthet
• Mangel på trening
• Mangel på forståelse
• Mangel på interesse
• Tidspress
• Kompleks kode
• Mange system interaksjoner
• Forandret teknologier

Andre miljø faktorer

Alle disse faktorene produserer defekter i koden. Defekter kan resultere i svikt av/feil i SW systemet.

Rollen til testing i SW

I alle stadier av produkt life cycle:

• planlegging
• development
• vedlikehold
• operations

Brukes for:

• fange defekter tidlig
  = redusere risiskoen av at problemer oppstår under operations
  = reduserer repair kost, kosten for å reparere vokser eksponensielt for hvert steg i syklusen
• sjekker om SW møter kravene (legal, standard)
• lære om systemet

Testing og kvalitet

Testing måler kvaliteten til SW basert på defekter funnet

• funksjonelle aspekter
• ikke-funksjonelle aspekter (reliability, usability, portability)

Testing skaper tillit til kvaliteten til SW-en

• hvis den er testen ordentlig og et minimum av defekter har blitt funnet

Testing gir oss lærdom til fremtidige prosjekter

• Forstå kjerne årsakene av defekter = normal prosesser kan forbedres i framtiden

Hvor mye testing?

Basert på:
Level av risk (teknisk risk, business risk. Risk = sannsynlighet + konsekvensene)
Prosjekt begrensninger (tid, budsjett)

Det er umulig å teste alt og finne alle defekter!
Viktig å prioritere riktig, og teste de riktig tingene for å gi tilstrekkelig informasjon til videre avgjørelser.

Hva er testing?

Prosessen av testing alle SW life-cycle aktiviteter:
Både statisk og dynamisk testing
i sammenheng med planlegging, forberedelse og evaluering
av software produktene og relaterte produkter for å avgjøre om kravene er tilfredstilt, demonstrere at de passer til formålet sitt og fange opp defekter

Ulike fokus under testing

Avhengig av målene for testprosessen kan testingen fokuseres på:

• å bekrefte at SW-systemet oppfyller kravene
• forårsake så mange feil som mulig == finne feil/forebygge feil
• kontrollere at det ikke har blitt introdusert defekter under endringer
• vurdere kvaliteten på SW == skape tillit til kvalitetsnivået.

The seven test principles

P1: Testing shows presence of defects / Testing viser tilstedeværelsen av defekter
P2: Exhaustive testing is impossible / Fullstendig testing er umulig
P3: Early testing / Tidlig testing
P4: Defect clustering / defekt klynge
P5: Pesticide paradox / Pesticid paradokset
P6: Testing is context dependent / Testing er kontekstavhengig
P7: Absence-of-errors fallacy / Feilslutning om fravær av feil

Test principle 1

P1: Testing shows presence of defects/ Testing viser tilstedeværelsen av defekter

Testing kan vise forekomst av defekter, MEN kan ikke vise at defekter ikke er der.

Testing kan redusere sannsynligheten for defekter, men er ikke bevis for at programmet er defektfritt.

Hvordan bruke dette prinsippet:
Være bevisst over at systemet fortsatt kan ha defekter gjør at vi er mer ydmyke = lage feilrapportering system for brukere, være klar for å rette opp i feil som kommer underveis

Test principle 2

P2: Exhaustive testing is impossible / Fullstendig testing er umulig

Testing av alt er ikke mulig/ikke realistisk (unntatt i noen spesifikke saker). I store programmer skjer det kombinatorisk eksplosjon, antall kombinasjoner som kan oppstå vokser eksponentielt slik at det ikke lenger er mulig å teste for hvert eneste tilfelle.

Hvordan bruker dette prinsipper:
Være bevisst på dette, dermed må vi prioritere basert på risiko og andre faktorer. I tillegg kan vi velge testcases som kan gi oss ganske god og omfattende testing.

Test principle 3

P3: Early testing / Tidlig testing

Testing aktiviteter bør starte så tidlig som mulig i SW eller system utvikling life cycle og burde være fokusert på definerte mål

Hvordan bruke dette prinsippet?
Starte å teste tidlig, og ha god testing underveis hele tiden. Tidlig innsats er gull verdt

Test principle 4

P4: Defect clustering / Defekter klumper seg sammen

Et lite nummer av moduler inneholder mesteparten av defektene oppdaget under testing før utgivelse.
Hvorfor? samme omstendigheter (samme utvikler, samme fase under tidspress) + følgedefekter, defekter genererer nye defekter

Hvordan bruke dette?
Hvis man finner en defekt et sted bør man teste dette området enda mer for å finne andre defekter. Konsentrer der man har spor å følge enn å søke i hele programmet

Test principle 5

P5: Pesticide paradox / Ugressmiddel paradokset

Hvis den samme testen er repetert mange ganger, vil det samme settet med test cases slutte å finne nye bugs.
For eksempel første middel dreper de første bugsa men nå er det nye som tåler dette middelet, dermed vil ikke det ha samme effekt lenger og man må bytte metode.

Hvordan bruke dette prinsippet?
Vi kan lures til å tro at det ikke lenger er defekter der, men det er bare testen vår som ikke lenger finner defekter dermed må vi:
revurdere test caser ofte, og nye og forskjellige tester må skrives for å undersøke samme sted

Test principle 6

P6: Testing is context dependent / Testing er kontekstavhengig

Hvor mye man tester, hvordan man tester, krav til testing er alt avhengig av konteksten SW utvikles (hvor stor risiko det har, hvem skal bruke produktet, hva er produktet, hvor strenge krav er det til feltet)

Hvordan bruke dette prinsippet?
Vite hva man utvikler og konteksten, teste deretter.
For eksempel en sikkerhets-kritisk software vil ha strengere teste regler enn et skoleprosjekt der målet er å lære å programmere.

Test principle 7

P7: Absence-of-errors fallacy / Feilslutning om fravær av feil

Å finne og fikse defekter hjelper ikke hvis software systemet ikke tilfredsstiller behovene og forventningene til brukerne

Hvordan bruke dette?
Finne ut om det vi lager faktisk vil bli brukt og nyttig. Er ikke vits å levere et feilfritt system som ingen trenger eller vil ha. Acceptance testing! Usability testing!

Testing aktiviteter

• Planlegging (plan the testing)
• Kontroll (control that we are following the plan / plan is working)
• Analyse ( choose what should be tested, the scope)
• Design ( design of test. what is the input and output of the test)
• Implementasjon ( implement the test design)
• Utførelse (do the tests)
• Ferdigstillelse (sjekke resultater, evaluere exit criteria, rapportere)

Test prosess: Planlegging og kontroll

Lage en plan: hva, hvordan, når og hvem?

• scope, mål og risk analyse (avgrense hva vi skal fokusere på, bruke mål og risk analyse for å prioritere)
• test nivåer og typer som vil bli brukt (unittesting, integrasjontesting, systemtesting, brukertesting)
• dokumentasjon som vil bli produsert (hvor formelt er det)
• alloker ressurser for forskjellige test aktiviteter
• lage tidsplan for implementasjon, utførelse og evaluering

Kontroll og tilpass planleggingen for å reflektere ny info og nye utfordringer under prosjektet

Test prosess: Analyse og design

Review test basis:

• krav
• produkt arkitektur
• produkt design
• grensesnitt
• risk analyse rapport

Analyse: generelle test mål er gjort om til test conditions(forhold), noe som kan testes.
Et test forhold: sjekke innlogging informasjon på en pc, dette må deles inn i mange ulike tester igjen fordi denne aktiviteten inneholder mye

Design:

• test caser (et test forhold kan lede til mange test caser)
• test miljø (ha riktig miljø for å utføre testen)
• test data (mange typer input typ)
• create tracebility (en forbindelse fra kravene til de aktuelle testene og tilbake)

Test prosess: Implementasjon og utførelse

Implementasjon:

• gruppere tester inn i scripts
• prioritere scripts
• forberede test oracles (forventet svar! eller vite hva som er feil innenfor en ramme)
• skrive automatiske test scenarioer

Eksekvering:

• Kjøre testene og sammenligne med oracles
• Report hendelser
• Repeter test aktivitetene for hver korrekt feil
• Logge utfallet av test eksekveringen

Test prosess: Ferdigstilling

Evaluere:

• Vurder test eksekveringen imot definerte mål
  sjekk om det trengs flere tester eller om exit criteria burde forandres.

Rapportere:
Skriv et sammendrag om testen og resultatene for stakeholders

Test closure aktiviteter:
Gjøre test delene tilgjengelig for senere bruk

En god tester kvaliteter

• Nysgjerrighet
• Profesjonell pessimisme
• Oppmerksom på detaljer
• Gode kommunikasjonsevner
• Erfaring med å gjette bugs
• Å kommunisere mangler og bugs på en konstruktiv måte: fakta fokuserte rapporter og gjennomgang av resultater

Independence/Uavhengighet i testing

En viss grad av uavhengighet er ofte mer effektivt når det kommer til å finne defekter og feil
FORDI det er vanskelig å se sine egne bugs (hjernen ser det den forventer å se + motivasjonen for at alt er riktig er høy)
MEN en utvikler kan veldig effektivt finne bugs i sin egen kode (fordi de kjenner koden bedre og hvordan den er satt sammen, hvis man ser defektene så tar det mindre tid)

Nivåer av uavhengighet
1- Tester laget av samme person som skrev koden
2- Tester laget av en annen person på samme team
3- Tester laget av et separat teste team
4- Tester laget av en utside organisasjon (outsource)

Nivået av uavhengighet i testing er basert på målet med testingen.

Testing basert på SW development modeller

Basert på hvilken SW development modell det er vil life syklusen ha ulike utviklings aktiviteter som vil avgjøre hvordan testingen er organisert.

Sekvensielle modellen, iterative-inkrementel (agile) modellen

Verification

Bevise/teste/verifisere at det vi har laget stemmer i forhold til kravene/spesifikasjonene.

Validation

Finne ut av/validere om at det man har laget er en løsning / har den funksjonen den trenger for et gitt formål.

Noen ganger kan produktet være helt riktig i forhold til kravene som er satt, men fortsatt ikke egentlig egne seg for det formålet som var tiltenkt.

Testing i sekvensiell modell

I en waterfall model vil testing skje på et bestemt tidspunkt i prosessen. Dette er ofte sent i prosessen, noe som gjør at defekter er mye mer kostbart å rette opp i og kanskje i noen tilfeller ikke mulig i det hele tatt. Samtidig er det noen ganger nødvendig å ha kontrollen man får ved å bruke fossefall metoden.

Kan bruke V-modellen for bedre testing på hvert steg

Testing i iterative-inkrementel modeller

Iterativ-inkrementel utvikling er prosessen av å etablere krav, designe, bygge og teste et system ved å ha en serie av korte utviklings sykler som resulterer i inkrementer.

Testing er ofte mindre formell, som er bra fordi det blir mindre overhead osv.
MEN Vanlig problemer:

• mer regression testing (testing delen øker for hver fase fordi vi må teste hele systemet hver gang, se at endringene vi har introdusert ikke har skapt nye problemer)
• defekter utenfor skopet av iterasjonen/inkrementet kan glemmes
• mindre grunding testing

Mange ulike iterative og inkrementelle modeller:
Rational Unified Process, Scrum, Kanban, Spiral

Kan bruke V-modellen innen for hver sykel

V-model

need, wish, policy, law ->

5. user requirements -> (prep acceptance test)
6. system requirements -> (prep system test)
7. global design, arkitektur -> (prep integration test)
8. detailed design ->
9. IMPLEMENTATION ->
10. component test execution ->
11. integration test execution ->
12. system test execution ->
13. acceptance test execution ->
    operational system

Testing må begynne så tidlig som mulig, integrert og planlagt i hver eneste fase.
validation = reviewing user requirements and user acceptance testing
verification = review system requirements, alle de andre testene

Karakteristikker av god testing

• Alle utviklings aktivitetene/fasene har en korresponderende teste aktivitet
• Hvert test nivå har et test mål spesifisert til det nivået
  -Analyse og designet av en test for et gitt test nivå bør begynne under den korresponderende utviklings aktiviteten
  -Testere burde være involvert i gransking/analyse av dokumentene/kravspesifikasjonene så tidlig som mulig i utviklingen for å forhindre at defekter forplanter seg videre.

Test nivåer

Unit-testing (moduler, program, objekt som kan testes separat)
Integrasjons-testing (grensesnitt mellom komponenter, interaksjon med andre systemer, OS, HW)
System-testing (Oppførsel av hele systemet, definert av prosjektets skop)
Acceptance-testing (Teste tillit til systemet blant brukere)

For hvert test nivå må man tenke på:

• Ulike generiske mål
• Test basis (produkter brukt for å finne test cases)
• Test objekter (hva som skal bli testet)
• Vanlig defekter og feil
• Spesifikke tilnærminger

Unit testing: objective/mål

Teste en liten modul/komponent av systemet, den må være helt separat testbar (rekkefølgen testene kjøres i skal ikke spille en rolle). Testing av funksjonalitet, eller spesifikke ikke-funksjonelle karakteristikker (kvalitetskrav: memory leaks, robustness, structural).

Unit testing: test basis

Spesifikasjonen av komponenten, SW design, data modellen, koden i seg selv.

Unit testing: tilnærminger

Hvordan?

• Skrive koden for å teste koden
• Stubs, drivers og simulators kan bli brukt
• Unit testing inkluderer ofte utvikleren som skrev koden.
• Defekter blir fikset så fort som de blir funnet

Stubs

Kode som erstatter en komponent som blir kalt av komponenten som blir testet, for å kunne simulere dens formål (hard kodet data for å erstatte data fra en database)

Drivers

Kode som erstatter en komponent som kaller komponenten som blir testet, på denne måten så kan man kjøre koden slik at komponenten som blir testet er isolert fra resten av programmet og ikke blir kalt av noe annet.

Integrasjons testing: objectives/mål

Tester grensesnittet mellom komponenter, tester interaksjoner mellom ulike deler av et system, grensesnitt mellom moduler som GUI, database, OS, filsystemet og HW.

Typer:
component integrasjon: teste interaksjonen mellom SW komponenter etter unit testing

system integrasjon: teste interaksjonene mellom ulike systemer etter system testingen

Integrasjons testing: test basis & test objects

Test basis:
SW og system design, System arkitektur og Workflow/ use case

Test objects:
builds of the system, database elements, system infrastruktur, grensesnitt mellom komponenter, system konfigurasjonen og dataen

Integrasjons testing: tilnærminger

• Start integreringen med de komponentene som man tror vil skape mest problemer
• Reduser risikoen av en sen defekt oppdagelse ved å gjøre testingen inkrementell
• Både funksjonelle og strukturelle tilnærminger, altså både white box og black box
• Ideelt bør testeren skjønne arkitekturen og kunne påvirke integrasjons planleggingen
• Kan gjøres av utviklerene eller et eget team

System testing: objectives/mål

Teste oppførselen til hele systemet (definert av skopet til prosjektet).

System testing: test basis

• System krav spesifikasjon, skrevet + modeller, funksjonell og ikke-funksjonell
• Bedrift prosesser
• Risk analyse
• Use cases
• Andre høy-nivå beskrivelser av systemets oppførsel, interaksjon med OS

Problemer: ukomplette eller udokumenterte krav

System testing: test objekter

• Hele systemet
• Bruker manualer
• Operasjons manualer
• System konfigurasjons informasjon

System testing: tilnærminger

• Godt testmiljø: bør imitere/stemme overens med produksjon mijøet så mye som mulig.
• Uavhengig testere: et uavhengig test team kan være best
• Black box teknikk
• White box teknikk

Acceptance testing: objectives, mål

Etablere tillit til systemet og ikke-funksjonelle karakteristikker av systemet.

Acceptance testing: test basis

• Bruker krav spesifikasjon
• Use case
• System krav spesifikasjon
• Bedrift prosess
• Risk analyse

Acceptance testing: typer

User: om systemet funker for bruker
Operational(admin): teste backup, disaster recovery, bruker håndtering, vedlikehold gjøremål, periodiske sjekker av sårbarheter.
Contract/regulation: testing imot kontraktens aksept kriterier (government, legal, safety)
Alpha: testing gjort hos utviklerens organisasjon
Beta: testing gjort av folk på sin egen lokalisasjon
(Både alpha og beta er gjort av potensielle kunder)

Test typer

Functional: hva systemet gjør (suitability, interoperability, security, accuracy, compliance)
Non-functional: how the system works (performance, reliability, usability, efficiency, maintainability, portability)
Related to changes (confirmation testing, regression testing)
Structural (code coverage)

Funksjonell testing (mål + nivå + basis)

Mål: Teste hva et system bør gjøre og vurdere den eksterne oppførselen til softwaret.

Test nivå:
Alle test nivå.

Test basis:
Den forventete oppførsel beskrivelsen (funnet i krav spesifikasjon, bedrift prosessen, use case, funksjonalitet spesifikasjon)

Ikke-funksjonell testing (mål + nivå + basis)

Mål:
Måle karakteristikkene av et software som kan kvantifiseres på en varierende skala (respons tid på ytelse test)

Test nivå:
Alle test nivåer

Strukturell testing (mål + nivå + basis)

Mål:
Måle grundigheten av testingen i form av test coverage/dekning.

Test nivå:
Kan utføres på alle nivåer, men spesielt i unit testing og unit integrasjons testing.
Skjer gjerne etter andre tester.

Test basis:
Basert på strukturen i koden / arkitekturen til systemet

Change testing

Mål: verifisere at modifikasjonene gjort på SW eller miljøet ikke har skapt utilsiktede konsekvenser, og at systemet fortsatt møter kravene

Test nivå: alle test nivåer, relatert til alle de andre typene testing

Typer: Confirmation, Regression

Confirmation testing

Etter en defekt er funnet og fikset, teste SW igjen for å bekrefte at defekten er fjernet suksessfullt

Regression testing

Repetert testing av et allerede testet program, etter modifikasjon, for å finne defekter som kan ha blitt introdusert som en konsekvens av forandringen

Finne defekter i SW som tidligere funket. Regression test suites blir kjørt mange ganger. Sterk kandidat for automatisering.

Maintenance/Vedlikehold testing

Testing gjort på et eksisterende driftende system på grunn av modifikasjon, migrasjon eller utfasing av SW eller system.

Typer:
Modifikasjon (planlagte forbedrings forandringer, korrigering og emergency forandringer, forandring av miljø)
Migrasjon (tester av nytt miljø, tester av det forandrete SW)
Utfasing (testing av data migrasjon eller arkivering, hvis lang data retention perioder er nødvendig)

TDD (Test Driven Development)

En metode der test cases er definert, laget og automatisere før hoved koden som skal passere testen blir laget.

Brukt i XP (extreme programming)

TDD prosessen

Rød fase

1. Skriv en test (som definerer en funksjon eller en forbedring du vil gjøre i koden)
   2.Kjør alle tester og se at testen failer (bekrefte at bare din test blir feil, og dermed se at den funker)

Grønn fase

3. Skriv koden som skal passere testen
4. Sjekke om koden passerer testen + forandre den til den gjør det

Refactor fase

5. Refactor/Omarbeid koden så den er enklere å lese
6. Kjør testen og se den passere

Hvorfor bruke TDD?

Støtte til omarbeiding/refactoring:
Gjør endringer med selvtillit

Design fordeler:
Isolerte units bør ha lav kobling (hver modul bør være så uavhengig som mulig) og høy kohesjon (relatert kode / kode som utfører lignende oppg bør være samlet i samme modul)

Design verification:
Koden gjør det du forventer/tror den gjør

Inkrementell jobbing:
Dele dine forandringer ofte, opprettholde en flow

== Følelse av frihet og produktivitet

TDD negative sider

TDD er ikke alltid den beste tilnærmingen, men har situasjoner/problemer der den kan fungere godt.

Negative sider:
Krever mye å lære TDD, å teste mye kan øke tids og ressurs forbruk, fokuserer for mye på tester enn selve programvaren

MEN hvis man kan det godt og bruker det i riktig situasjoner så kan det være veldig verdt det

TDD Skill

Designe test caser
Designe testbar kode
Drive utvikling med tester
Refactor/Omskrive på en sikker måte

Self-testing kode

Selv-testende kode er når du kan kjører en serie automatiserte tester mot kode basen og har tillit til at hvis testen passerer så er koden fri for betydelige defekter

Kjennetegn på en god unit test

Readability:

• Optimer for den personen som må forstå feilen
• Gode test navn som forklarer hva testen er
• 3 deler: Arrange, Act, Assert (Tommelregel: bare en assert per test)
• Samle tester som gjør det samme inn i en felles funksjon

Speed
En unit test bør være rask, er ikke en unit test hvis den rører filsystemet, nettverk, databasen, spesiell HW

Robustness
Isolasjon:
Feil oppstår ikke i kaskade, rekkefølgen på test utførelsen er irrelevant og samme test utføres gjentatte ganger
Feilene er ikke intermitterende:
Er konsistente og reproduserbare

Test automatisering

Bruken og utviklingen av spesiell SW (separat fra SW som skal testes) for å kunne kontrollere kjøringen av tester og sammenligningen faktisk output med forventet output, automatisk istedenfor manuelt

Test automatisering: Fordeler/ hvorfor bruke det

Redusert testtid: testene kjører mye raskere

Økt testdekning: Kan utføre de samme testene om og om igjen, dermed øke test dekningen. Regression testing. Testing på flere nettlesere og enheter.

Redusert kostnad: krever mindre ressurser å kjøre. Genererer og validerer test data.

Mer pålitelig tester: utføres alltid på samme måte dermed mer nøyaktige svar

Raskere feilretting: Oppdager feil raskere, rask feedback på feil

Test automatisering: Brukstilfeller

Når skal man ikke bruke de:

• systemer som forandrer seg ofte og drastisk (da må også testene forandres ofte og drastisk, ikke vits å ha de automatisert)
• systemer som er på vei ut (testene vil bare brukes en liten stund, heller ikke nødvendig)
• små eller kort prosjekter (samme grunn som over)

Krever en viss overhead når man setter opp automatiserte tester, så jo lenger de blir brukt uendret jo større fordel/utbytte gir de

Test automatisering: Nivåer

((Manual))
GUI
Integration
Unit

Oppover pil: Tillit i hele systemet
Nedover pil: Tillit i en enkelt komponent

Test automatisering: hvem?

Utvikler

• Lite eller ingen test kompetanse
• Utviklings ekspert
• Kan sette opp rammeverk
• Test automation vil være en del av utviklingen

Test-automatiserings ingeniør

• Sterk test kunnskap
• Sterk utviklings kunnskap
• Kan sette opp rammeverk
• Ofte den eneste eieren til automatiserings innsatsen

Tester

• Test ekspert
• Ingen / lite utviklings kunnskap
• Vanskelig å sette opp rammeverk
• Sterkere samarbeid med utviklere og eierskap til tester

Test automatisering: prosessen

Integrert del av SDLC, kontinuerlig prosess, raskere utgivelser med automatiserte tester.

1. Analysere skopet og forventinger
2. Definere tilnærmingen
3. Velge verktøy
4. Designe arkitekturen
5. Lage automatiserings rammeverk
6. Lage tester, rapportering, integrasjon
7. Vedlikehold

Testing frameworks

Et sett med verktøy, biblioteker og konvensjoner som brukes til å skrive og automatisere tester for programvareapplikasjoner.
Standardisert måte å opprette og utføre tester på, sikrere at programvaren oppfyller ønsket kvalitet og funksjonalitet.

Mange ulike rammeverk for ulike programmerings språk:
JUnit, Protractor, Serenity BDD, Cucumber, NightWatch..

Hvordan velge?
Ingen one fits all løsning.
Paid eller open source? Skal det ha kontinuerlig support? Er community aktivt? Hva har teamet erfaring med?

Cypress

Et JavaScript-basert rammeverk for ende-til-ende testing.
Front-end testing verktøy bygget for det moderne web.
Gratis og open-source.

Funksjonalitet:

• Time travel (se hvordan koden oppførte seg på alle tidspunkter i utviklingen)
• Automatic waiting (automatisk venter for at elementer loader og blir synlig før den interagerer med dem)
• Stubs and clocks
• Screenshot and videos
• Cross browser testing (kjøre testene i flere browsers samtidig)

Cypress vs Selenium

Executes in browser vs Prosess utenfor browser
Open source vs open source
Automatic waiting vs manuell legge til wait/sleep
All-in-one pakke vs kombinert med andre
Innebygd test runner med rapportering vs bygge rapport selv

Statisk testing

Manuell undersøkelse og automatisert analyse av koden eller dokumentasjonen uten kjøringen av SW under testen

Mål:

• Identifisere defekter
• Finner grunner til defekter istedenfor defektene selv

Et eksempel på statisk testing kan være kompilatoren. Den analyserer koden uten å faktisk kjøre den.

Dynamisk testing

Finne defekter i koden ved å kjøre SW under en test.

Mål:

• Identifisere defekter

Behøver source kode for å bli gjort

Statisk analyse: typiske feil

• Referering til en variabel med udefinert verdi
• Inkonsistent grensesnitt mellom moduler og komponenter
• Variabler som aldri blir brukt
• Utilgjengelig (død) kode
• Programmeringstandard brudd
• Sikkerhets sårbarheter
• Syntax brudd av kode og SW modeller

Statisk analyse: hvorfor?

• Finner defekter tidlig før kjøring
• Tidlig advarsel av mistenksomme aspekter av koden eller designe (kalkulering av metrikker, high complexity measure)
• Identifisering av defekter som ikke lett blir oppdaget dynamisk
• Finne dependencies/avhengigheter og inconsistencies i SW modellene
• Forbedre vedlikeholdbarheten av koden og design
• Forhindre defekter

Statisk analyse: Kode standard

Ved å analysere om koden følger en viss standard så kan det spare mye tid.

Kode standard:

• programmerings regler (eks boundaries på en array)
• navn konvensjoner (klasser med stor bokstav)
• tilgangs konvensjoner (public/private)
• layout spesifikasjon (innrykk)

Statisk analyse: Kode metrikker

• Kommentar hyppighet
• Dybde av nøsting
• Kompleksitets metrikk
  Dette kan bli testet på ulike måter, basert på antall avgjørelser i programmet.

Statisk analyse: Kode struktur

• Kontroll flow struktur
  Sekvensen instruksjonene er eksekvert
• Data flow struktur
  følger stien til dataen ved tilgang og endring gjort på den i koden
• Data struktur
  Organisasjonen av dataen selv

Reviews / Vurderinger

Manuell undersøkelse av koden eller dokumentasjonen for å identifisere defekter og foreslå forbedringer.

Dette gjøres tidlig i life cycelen og finne defekter her er mye billigere å fjerne enn i senere testing.

Reviews: objekter

• kravspesifikasjoner
• designspesifikasjoner
• koden
• test planer
• bruker guides
• web sider

Reviews: fordeler

• tidlig defekt oppdagelse og korrigering
• utviklings produktivitets forbedring
• redusert utviklingstid
• redusert testkostnader og tid
• redusert levetidskostnader
• færre defekter
• forbedret kommunikasjon

Reviews: vanlig defekter funnet

-avvik fra standarder
-krav defekter

• design defekter
• utilstrekkelig vedlikeholdbarhet
• feilaktige grensesnitt spesifikasjoner
• inkonsekvenser, tvetydigheter, selvmotsigelser, utelatelser(omissions), unøyaktigheter og redundanser i kravene

Review prosess: Phases

1. Planlegging
   (velg folk og roller, definer entry og exit kriterier, velg del av dokument å se på)

2. Initiate review (kick off)
   (dele ut dokumenter, forklare objektivene/prosessen/dokumentene, sjekke og diskuter entry/exit)

3. Individuell review
   (egen notater, severity proposal: critical, major, minor)

4. Problem kommunikasjon og analyse
   (Review møte, logging og diskusjon, notere defekter og forslag til å fjerne de, avgjørelser basert på exit kriteriet)

5. Fikse og rapportere
   (Fikse defekter, sjekke at defekter blir håndtert, metrics: num of defect..)

Review prosess: Roller

• Forfatter (den som skrev / har ansvar for dokumentet)
• Ledelse (avgjør at review skal skje, allokerer ressurser)
• Review leder
  (ansvar for review, bestemmer roller)
• Fasilitator
  (leder, planlegger review og møter)
• Reviewers
  (individer med teknisk bakgrunn, identifiserer og beskriver funn)
• transkribent
  (dokumenterer alle problemer under møter)

Review process: Typer (mål + form)

1. Uformell
   Mål: Lite kost,
   Form: pair review
2. Walkthrough
   Mål: lære, forståelse, finne defekter, feedback
   Form: ledet av forfatter, varierer i praksis
3. Teknisk
   Mål: diskutere, ta avgjørelser, evaluere alternativer, finne defekter, løse tekniske problemer
   Form: veldig formell til veldig uformell. Ideelt ledet av fasilitator, dokumentert, før møte preparasjon, checklists
4. Inspeksjon
   Mål: finne defekter
   Form: peer undersøkelse ledet av fasilitator. Formell prosess basert på regler/checklist med entry og exit kriterier. Definerte roller. Metrics. Inspeksjons rapport.

Review process: teknikker

• Ad hoc review
• Checklist review
• Senario review
• Rolle review
• Perspektiv review

Review prosess: Faktorer for suksess

Organisasjon faktorer:

• klart mål
• velg riktig type review
• oppdatert review materiale
• limit scope størrelse
• sørg for nok tid
• ledelse støtte

Menneskebasert faktorer:

• riktig folk (bruk testere)
• alle gjør jobben grundig
• defekt funn bør bli sett som positivt
• godt ledet møter
• tillit og god kommunikasjon
• trening av deltakere

Test development prosess

Før testing må vi vite: hva prøver vi å teste, hvilket input, hvilke resultater, hvordan forbereder vi testen, hvordan kjører vi testen

For å gjøre testing planleggingen mer oversiktlig deler vi det inn i 3 faser:

1. Test analyse
2. Test design
3. Test implementasjon

Test development prosess: Analyse

Analyse av dokumentasjon = bestem hva som skal testes (identifiser test conditions)

Identifiser så mange test conditions som mulig, velg en for å utvikle i mer detalj. Vi kan ikke teste alt, så vi må velge et subset av alle mulige tester med høyest sannsynlighet for å finne defekter.

Test conditions

En ting eller hendelse som kan bekreftes av en eller flere test caser

Eksempler:

• en funksjon
• en transaksjon
• kvalitets karakteristikk
• strukturelle elementer

Test development prosess: Design

Gjennom test design er test cases + test data opprettet og spesifisert.

For å gjøre sette må vi vite hva systemet bør/skal gjøre for å vite hva riktig oppførsel er (oracle) og hva forventet resultater er.

Test case

Set av pre-conditions, inputs, forventet resultat og post-conditions utviklet for å dekke noen test conditions.

Test development prosess: Implementasjon

Under en test implementasjon er test casene organisert inn i test prosedyrer/procedures.

Lager en test execution schedule:

• rekkefølgen på execution av test procedyrer
• når de vil bli eksekvert
• av hvem de vil bli eksevert

Å skrive test prosedyrer er en god mulighet for å prioritere, best testing er gjort i tiden tilgjengelig

Test procedures

En test prosedyre outliner sekvensen av steg som trengs for å eksekvere en test case eller en gruppe av relaterte test cases.

Hvis test prosedyren er automatisert så spesiferer den i et test script

Black-box teknikk

Spesifikasjons-basert teknikk

Bruker modeller (formelle og informelle) for å spesifisere problemet som skal løses, i tillegg til SW og komponentene deres.
Finner test cases ved bruk av disse ulike modellene.

Typer:

• Equivalence partitioning
• Boundary value analysis
• Use case testing
• Decision tables
• State transitions

Equivalence partitioning

Black-box teknikk.

1. Del inn conditions i deler der alle elementene i hver del kan ses på som samme / har samme oppførsel
2. Teste en condition fra hver del

Typisk problem:
Konto i bank får forskjellige renter basert på mengde i konto.
Dele inn mengden inn i ulike deler basert på rangen som gjør at de får ulike renter

Valid data og invalid data (values som bør bli rejected)

Boundary value analysis

Black-box teknikk
Analyse av kanten av hver equivalence partition fordi det er større sannsynlighet at resultatet er feil der.

Finne boundary values (max og min values for en del) og teste for disse

• Brukes i alle testnivåer

Hvorfor equivalence partitioning og boundary value analysis sammen?

Boundary value analysis er en utvidelse av equivalence partitioning.

I tillegg er boundary value analysis bare de ekstreme verdiene, for å få tillit i systemet må vi også teste det under normale omstendigheter.

Tommelregel:

• Velg max og min (boundary)
• Og en value fra midten av delen

Decision table testing

A black-box teknikk
Et decision table er en årsak-virkning tabell, der inputs og actions utrykker med boolean verdier.

Identifisere effekten av kombinasjoner av forskjellig inputs

Istedenfor å ha alle actions på bunnen kan man bare skrive hvilken action som vil skje + slå sammen noen regler fordi en condition alltid leder til en action feks

State transition testing

Black-box teknikk for å finne defekter når et system beveger seg fra en state til en annen state ved hjelp av et state diagram

Når:
Et system der du får forskjellig output for samme input avhengig av hva som har skjedd før er et finite state system.

Hvorfor:

• Transitions mellom states
• Se hvilke inputs som gir state forandringer
• Hva resultatet av disse kan være

Use case testing

En black-box teknikk der test cases er designet ut i fra scenarioene i use cases.

Et use case bør bruke hele systemet fra start til slutt, interaksjon mellom bruker og system fra bruker sin side.

• pre-conditions
• post-condtions
• a mainstream (most likely) and alternative branches

Bruk:
acceptance test with user