IN3240 - Kapittel 2 Testing Throughout the Software Life Cycle

Hva er Software Development Life Cycle?

Software Development Life Cycle (SDLC) beskriver hvordan et program utvikles fra start til slutt.

Lengere svar:

Når et program skal lages, følger utviklingen en plan eller modell.

Denne modellen beskriver hvilke aktiviteter som skjer, for eksempel:

• planlegging

• krav

• design

• programmering

• testing

• vedlikehold

Testing er en viktig del av hele denne prosessen, ikke bare noe som skjer til slutt.

Hvorfor er testing en del av hele livssyklusen?

Fordi feil kan oppstå i alle faser av utviklingen. Ved å teste underveis kan vi oppdage feil tidligere og redusere kostnader.

Sequential Model

Sequential betyr at utviklingen skjer trinn for trinn i en fast rekkefølge.

lengere svar:

I en sekvensiell modell må én fase være ferdig før neste fase starter.

Typisk rekkefølge:

• Need, wish, policy, law (behov, ønsker, regler eller lover)

• User requirements (brukerkrav)

• System requirements (systemkrav)

• Global design (overordnet design)

• Detailed design (detaljert design)

• Implementation (implementasjon/programmering)

• Testing

Enkelt forklart

Programmet blir utviklet steg for steg:

• Først finner man ut hva brukeren trenger.

• Deretter skriver man kravene.

• Så lager man design.

• Etter det programmerer man.

• Til slutt tester man.

Dette er grunnen til at modellen kalles en Sequential Model – man går sekvensielt, altså ett steg om gangen.

Sequential Model (fordeler og ulemper)

Fordeler

• Enkel å planlegge.

• God dokumentasjon.

• Passer når kravene er stabile.

Ulemper

• Feil kan oppdages sent.

• Endringer er vanskelige og kostbare.
  

Når passer en sekvensiell modell best?

Når kravene er godt kjent og ikke forventes å endre seg.

Iterative-Incremental Model

En Iterative-Incremental Model betyr at programvaren ikke lages på én gang, men litt om gangen i flere korte utviklingssykluser.

Figuren viser

I stedet for å gjøre hele systemet ferdig én gang, deles utviklingen opp i flere faser (Phase 1, Phase 2, Phase 3).

I hver fase gjør man:

1. Define

2. Develop

3. Build

4. Test

5. Implement

Etter hver fase leveres en ny versjon av systemet (Live Implementation).

I en Sequential Model lager man hele systemet først, og tester det til slutt.

I en Iterative-Incremental Model lager man litt av systemet om gangen.

Hver gang gjør man:

• definere

• utvikle

• bygge

• teste

• implementere

Deretter starter man en ny runde med mer funksjonalitet.

Hva er forskjellen mellom Sequential Model og Iterative-Incremental Model?

• Sequential Model: Hele systemet utvikles steg for steg, og testing skjer mot slutten.

• Iterative-Incremental Model: Systemet utvikles i flere korte sykluser. Hver syklus inneholder definering, utvikling, bygging, testing og implementering.

Hva betyr iterative?

Vi gjør den samme prosessen flere ganger.

Altså:

Definere → Utvikle → Bygge → Teste → Implementere

Så gjør vi den samme prosessen igjen.

Og igjen.

Hva betyr incremental?

Vi legger til litt mer funksjonalitet hver gang.

Altså:

Versjon 1

👉 Kan bare logge inn.

↓

Versjon 2

👉 Kan logge inn + sende penger.

↓

Versjon 3

👉 Kan logge inn + sende penger + betale regninger.

Systemet vokser litt etter litt.

Hva er en Iterative-Incremental Model?

En Iterative-Incremental Model er en utviklingsmodell der programvaren utvikles i flere korte utviklingssykluser. I hver syklus definerer, utvikler, bygger, tester og implementerer man en del av systemet. Hver nye versjon legger til mer funksjonalitet, slik at systemet blir større og bedre over tid.

Hva er V- model?

V-Model viser at hver fase i utviklingen har en test som hører til.

Det betyr at når vi lager systemet, planlegger vi også hvordan det skal testes.

hvorfor heter den V - model?

Den ser ut som en V.

Venstre side = utvikling

Bunnen = implementasjon (koding)

Høyre side = testing

Hvordan fungerer den?

Venstre side (utvikling)

Her lager vi systemet.

• User requirements

• System requirements

• Global design

• Detailed design

• Implementation

↓

Når programmeringen er ferdig...

↓

Høyre side (testing)

Nå testes det som ble laget på venstre side.

Hvilken test hører til hvilken fase?

Utviklingsfase	Testfase
User requirements	Acceptance testing
System requirements	System testing
Global design	Integration testing
Detailed design	Component testing

Hva er hovedideen bak V-Model?

V-Model viser at hver utviklingsfase har en tilhørende testfase. Testingen planlegges tidlig og knyttes til krav og design.

Hva betyr "Preparation"?

På figuren står det:

• Preparation Acceptance test

• Preparation System test

• Preparation Integration test

Det betyr at testene planlegges mens utviklingen pågår, ikke etter at systemet er ferdig.

For eksempel:

• Når vi skriver User requirements, begynner vi samtidig å planlegge Acceptance test.

• Når vi lager System requirements, planlegger vi System test.

Hvorfor er V-Model bra?

• Testing blir planlagt tidlig.

• Det blir lettere å kontrollere at alle krav blir testet.

• Feil kan oppdages tidligere.

Hva er V-Model?

V model er en utvinklingsmodell der hver utviklingsfase har en tilhørende testfase. Testene planlegges under utviklingen og utføres etter implementasjonen.

Hva viser venstre side av V-modellen?

Venstre side viser utviklingsfasene

Hva viser høyre side?

Høyre side viser testfasene

Hvorfor planlegges testene tidlig?

for å sikre at alle krav blir testet og for å oppdage feil tidligere.

Hva er Test Levels?

Test Levels beskriver på hvilket nivå programvaren testes.

Hvert testnivå har sitt eget mål og tester forskjellige deler av systemet.

1. Every development activity has a corresponding testing activity.

Enkel forklaring:

Hver utviklingsaktivitet har en testaktivitet som hører til.

Eksempel:

• Skriver krav → planlegger Acceptance Test.

• Lager design → planlegger Integration Test.

2. Each test level has test objectives specific to that level.

Enkel forklaring:

Hvert testnivå har sitt eget mål.

For eksempel:

• Unit Testing → teste én komponent.

• System Testing → teste hele systemet.

3. The analysis & design of tests for a given test level should begin during the corresponding development activity.

Enkel forklaring:

Testene skal planlegges under utviklingen, ikke etterpå.

4. Testers should be involved in reviewing documents as soon as drafts are available.

Enkel forklaring:

Testere bør være med tidlig og lese gjennom krav og dokumenter før systemet er ferdig.

1. Unit Testing (test levels)

Hva testes?

Én liten del av programmet.

Eksempel:

• én klasse

• én metode

• én funksjon

Fra lysbildet:

any module, program, object seperstely testable.

2. Integration Testing (test levels)

Hva testes?

Hvordan flere komponenter fungerer sammen.

Fra lysbildet:

interface between components: interaction with other systems (OS, Hw, …)

Enkelt sagt:

Vi tester at delene kommuniserer riktig med hverandre.

3. System Testing (test levels)

Hva testes?

Hele systemet.

Fra lysbildet:

the behavior of the whole product (system) as defines by the scope of the project.

enkelt sagt:

vi tester hele programmet slik brukeren skal bruke det

4. Acceptance Testing (test levels)

Hva testes?

Om kunden godkjenner systemet.

Fra lysbildet:

is the responsibility of the customer.

Målet er:

Å få tillit til at systemet fungerer slik kunden forventer.

Hva er forskjellen mellom Unit Testing og Integration Testing?

• Unit Testing tester én komponent alene.

• Integration Testing tester hvordan flere komponenter fungerer sammen.

Hvem har ansvar for Acceptance Testing?

Kunden (customer) har vanligvis ansvaret for Acceptance Testing.

Hva testes i System Testing?

Hele systemet testes for å kontrollere at det fungerer som forventet.

Hva er Test Types?

Enkel forklaring

Test Types beskriver hva vi tester i systemet.

Mens Test Levels handler om hvor vi tester (unit, integration, system, acceptance), handler Test Types om hvilke egenskaper vi tester.

1. Functional Testing

Hva testes?

Om systemet gjør det det skal gjøre.

Man tester funksjonene i systemet.

Eksempel

En nettbank skal:

• logge inn ✅

• overføre penger ✅

• vise saldo ✅

Hvis dette fungerer, består funksjonell testing.

2. Non-functional Testing

Hva testes?

Hvordan systemet fungerer.

Man tester ikke funksjonene, men kvaliteten.

Eksempler:

• Ytelse (Performance)

• Sikkerhet (Security)

• Brukervennlighet (Usability)

• Pålitelighet (Reliability)

Eksempel

En nettside skal laste på under 2 sekunder.

Det er ikke-funksjonell testing.

3. Confirmation Testing (Re-testing)

Hva testes?

En feil er rettet.

Man tester den samme feilen på nytt for å kontrollere at den faktisk er fikset.

Eksempel

En knapp krasjet programmet.

Utvikleren retter feilen.

Testeren prøver den samme knappen igjen.

4. Regression Testing

Hva testes?

Man sjekker at nye endringer ikke har ødelagt noe som fungerte før.

Eksempel

Utvikleren retter innloggingen.

Etterpå tester man også:

• betaling

• handlekurv

• profil

for å sikre at de fortsatt fungerer.

Forskjellen mellom Confirmation og Regression

Dette er et veldig vanlig eksamensspørsmål.

Confirmation Testing

👉 Tester den feilen som ble rettet.

Regression Testing

👉 Tester andre deler av systemet for å se at de fortsatt virker.

Hva er Functional Testing?

functional testing tester om systemet utfører funksjonene det skal

Hva er Non-functional Testing?

Non - functional testing tester kvalitetsegenskaper som ytelse, sikkerhet og brukervennlighet

Hva er forskjellen mellom Confirmation Testing og Regression Testing?

• Confirmation Testing kontrollerer at en rettet feil faktisk er rettet.

• Regression Testing kontrollerer at rettingen ikke har skapt nye feil i andre deler av systemet.

Hva er forskjellen mellom Functional og Non-functional Testing?

• Functional Testing tester hva systemet gjør.

• Non-functional Testing tester hvordan systemet fungerer, for eksempel ytelse og sikkerhet.

Testing Related to Change

Når et system blir endret, må vi teste på nytt.

Det finnes to viktige testtyper:

1. Confirmation Testing

2. Regression Testing

Hvorfor må vi teste etter en endring?

Tenk deg at en utvikler retter én feil.

Selv om den feilen er borte, kan endringen ha ødelagt noe annet.

Derfor tester vi alltid etter endringer.

Confirmation Testing

Hva er det?

Vi tester den feilen som ble rettet.

Eksempel

Feil:

• Programmet krasjer når brukeren logger inn.

Utvikleren retter feilen.

Testeren prøver å logge inn igjen.

Hvis innlogging fungerer, er Confirmation Testing vellykket.

Regression Testing

Hva er det?

Vi tester andre deler av systemet etter en endring.

Hvorfor?

For å kontrollere at endringen ikke har laget nye feil.

Eksempel

Utvikleren retter innlogging.

Etterpå tester vi også:

• betaling

• handlekurv

• profil

for å se at de fortsatt virker.

Hva er forskjellen mellom Confirmation Testing og Regression Testing?

Kort svar:

• Confirmation Testing tester den rettede feilen.

• Regression Testing tester andre deler av systemet for å sikre at de fortsatt fungerer.

Hva er Maintenance Testing?

Enkel forklaring

Maintenance Testing er testing som utføres etter at programmet er tatt i bruk.

Programvaren er altså allerede levert til brukerne, men den blir fortsatt endret og forbedret.

Maintenance Testing er testing som utføres etter at programvaren er levert. Den brukes når systemet endres, for eksempel ved feilrettinger, nye funksjoner eller tilpasninger.

Hvorfor gjør vi Maintenance Testing?

Et system blir ikke ferdig for alltid.

Etter at det er tatt i bruk kan man:

• rette feil

• legge til nye funksjoner

• forbedre eksisterende funksjoner

• tilpasse systemet til nye krav eller nytt utstyr

Hver gang systemet endres, må det testes igjen.

Eksempel

En bank har en mobilapp.

Etter ett år ønsker banken å legge til BankID med ansiktsgjenkjenning.

Utviklerne lager funksjonen.

Deretter må appen testes før den slippes til kundene.

Dette er Maintenance Testing.

Hva kan føre til Maintenance Testing?

Typiske årsaker er:

• Feilretting (bug fixes)

• Nye funksjoner

• Endrede krav

• Nye operativsystemer eller maskinvare

• Endringer i lover eller regler

Hva tester vi?

Når systemet endres, utfører vi ofte:

• Confirmation Testing

  • Sjekker at den rettede feilen faktisk er rettet.

• Regression Testing

  • Sjekker at endringen ikke har ødelagt andre deler av systemet.

Når utføres Maintenance Testing?

Etter at programvaren er tatt i bruk og det blir gjort endringer.

Hvorfor er Maintenance Testing viktig?

Fordi endringer kan skape nye feil. Derfor må vi kontrollere at den nye funksjonaliteten virker, og at resten av systemet fortsatt fungerer.