Softwaretestmetoder og -modeller forklaret

Perfekt software findes ikke, og hvert program har potentielle fejlpunkter. Softwaretest er et livscyklusstadium for softwareudvikling, hvor teamet opdager uønskede fejl i et program eller system.

Forskellige testmetoder hjælper med at lokalisere flere typer softwarefejl. At vide, hvordan hver softwaretestmodel fungerer, er afgørende for at opbygge, implementere og vedligeholde en teststrategi og -software af høj kvalitet.

Hvorfor er test vigtigt i SDLC?

Testfasen er et kritisk trin i softwareudviklingens livscyklus. Det kommer efter softwareimplementering, og test har til formål at opdage og rette softwarefejl.

Softwaretest er afgørende, fordi produktet går i produktion efter test. Ethvert softwareudviklingsteam skal levere kvalitetssoftware af to grunde:

• Slutbrugeren drager fordel af at få et produkt af høj kvalitet bygget efter ønsker og specifikationer.
• Udviklingsteamets integritet og muligheden for nye projekter afhænger af softwarens kvalitet.

Et softwaretestteam udfører forskellige kontroller for forskellige problemer adskilt fra udviklere. Denne tilgang hjælper med at have et team, der udelukkende fokuserer på at opdage problemer og giver mulighed for at implementere løbende udvikling.

Softwaretestmetoder

Softwaretest er en formel proces, der udføres af et testhold for at hjælpe med at bekræfte, at et program er logisk korrekt og værdifuldt. Test kræver brug af specifikke testprocedurer og oprettelse af testcases.

Softwaretest udføres i to trin:

• Verifikation - Er systemet bygget korrekt?
• Validering - Er systemet konstrueret i overensstemmelse med brugernes krav?

Softwaretestning bruger flere metoder og modeller til at besvare disse to spørgsmål.

Black Box test

I black box-testmetoden er et program en lukket (sort) boks med ukendte detaljer. De eneste synlige komponenter for en tester er programmets input og output.

En tester kan afgøre, om et program er funktionelt, ved at observere de resulterende output for forskellige input. Black box-test tager ikke hensyn til et programs specifikationer eller kode, kun den forventede adfærd for forskellige testcases. Black box testere behøver ikke nødvendigvis at være meget dygtige, da de ikke interagerer med nogen kode.

Black box-test kommer med både fordele og ulemper. Den kritiske fordel ved black box-test er, at der ikke er noget krav om at arbejde med kode og programmeringslogik. Det er dog umuligt at teste alle inputkombinationer.

Tre typer test er baseret på black box-testmetoden: funktionstest, ikke-funktionel test og regressionstest.

Funktionstest

Funktionstest kontrollerer, om softwaren udfører en bestemt funktion uden at overveje, hvilken komponent i systemet, der er ansvarlig for driften.

Testteamet tjekker funktionaliteter for både gode og dårlige input. Et eksempel på en funktion er en brugerloginsideadfærd. En funktionstest kontrollerer, om en bruger kan logge ind med de korrekte legitimationsoplysninger eller ikke logge ind med forkerte legitimationsoplysninger.

Efterhånden som softwarens kompleksitet øges, stiger antallet af funktioner i softwaren også. Rækkefølgen af testfunktioner er afgørende for en effektiv og funktionel teststrategi. Da funktionaliteter ofte er indlejret, afhænger softwarens adfærd af rækkefølgen af trin, en person tager, når han bruger softwaren.

Den største fordel ved funktionel test er, at testteamet kan kontrollere individuelle funktionaliteter, før alle softwarekomponenter er færdige. Sandsynligheden for at opdage fejl i funktionstest er usædvanlig høj, da det viser problemer ved brug af software fra en brugers perspektiv.

Ikke-funktionel test

Den ikke-funktionelle testmetode verificerer softwareaspekter bortset fra funktionaliteter og funktioner. Denne testmetode fokuserer på, hvordan et program udfører bestemte handlinger under specifikke forhold.

Ikke-funktionel test hjælper med at afdække, om et program er brugbart fra en brugers perspektiv. Metoden kontrollerer for brugervenlighedsproblemer, såsom krydskompatibilitet på tværs af forskellige enheder, browsere eller operativsystemer.

Regressionstest

Regressionstest er en softwaretestmetode, der sikrer, at alle nye kodeændringer ikke forårsager problemer i tidligere testede komponenter og påvirker systemstabiliteten negativt. Testmetoden gentager tests fra tidligere iterationer og sikrer, at de seneste ændringer ikke forårsager uønskede effekter på eksisterende kode.

Regressionstest er nødvendig efter enhver programhandling, der resulterer i ændringer af den originale kode, såsom:

• Implementering af nye krav.
• Tilføjelse af nye funktioner til programmet.
• Fjernelse af eksisterende funktioner.
• Udbedring af eventuelle defekter.
• Optimering for bedre ydeevne.

Hvis softwaren ofte ændres, er den bedste tilgang at bruge automatiserede testværktøjer og oprette genanvendelige tests til flere iterationer og cyklusser af regressionstest.

White Box Test

Den hvide boks testmetode er det modsatte af sort boks test. I denne metode er programmet en åben (hvid) boks, hvis indre funktion er kendt af testeren.

White box test analyserer kildekoden og kræver følgende færdighedssæt:

• Kendskab til kodning og scripting.
• Kendskab til det specifikke programmeringssprog, der er i brug.
• Designet af bestemte komponenter.

Testere laver en plan baseret på programmets struktur. For eksempel kan test af hvide bokse omfatte oprettelse af scriptede test, som går gennem hele koden og kører hver funktion. Specifikke test kan kontrollere, om der er uendelige loops eller tilfælde, hvor koden ikke kører.

Den største ulempe ved white box test er antallet af test iterationer, som stiger, efterhånden som applikationen bliver mere kompleks. Metoden kræver at skabe en strategi, hvor rekursioner eller loops udføres færre gange for nøje udvalgte og repræsentative værdier

Tre typer test er baseret på den hvide boks-testmetode: sætningstest, stitest og grentest.

Test af erklæringer

Statement testing er en testteknik indenfor white box test. Metoden vurderer alle eksekverbare sætninger i koden mindst én gang. For eksempel, hvis en kodeblok indeholder flere betingede sætninger, involverer sætningstestteknikken at gennemgå alle input-iterationer for at sikre, at alle dele af koden udføres.

Udsagnstestteknikken opdager ubrugte dele af kode, manglende refererede udsagn og resterende kode fra tidligere revisioner. Som et resultat hjælper sætningstest med at rydde op i den eksisterende kode og reducerer redundant kode eller tilføjer manglende komponenter.

Stitestning

Stitest skaber uafhængige lineære stier gennem hele koden. Testteamet opretter et kontrolflowdiagram af koden, som hjælper med at designe enhedstests til at evaluere alle kodestier.

At analysere forskellige stier hjælper med at opdage en applikations ineffektive, ødelagte eller redundante flows.

Afdelingstest

Afdelingstest kortlægger betingede udsagn i koden og identificerer grenene til enhedstestning. Filialtyperne er:

• Betinget: Udføres, når en betingelse er opfyldt.
• Ubetinget: Udføres uanset omstændighederne.

For eksempel indeholder følgende kode flere indlejrede udsagn:

if condition 1:
    W
else if condition 2:
    X
    Y
else:
    Z

En tester identificerer alle betingede grene. I eksempelkoden er betingede grene W, X og Z kode> fordi sætningerne kun kører under en bestemt betingelse. På den anden side er Y en ubetinget gren, fordi den altid udføres efter X-sætningen.

Afgreningstest har til formål at udføre så mange grene som muligt og teste for alle forgreningsforhold.

Funktionel test

Funktionel test er en undertype af sort boks-test, som overvejer softwarespecifikationerne for en given funktion eller et givet program. Testmetoden giver forskellige input og analyserer output uden at tage hensyn til den interne softwarestruktur.

Funktionel test involverer 4 forskellige trin, der starter fra mere mindre dele af koden og forgrener sig til at evaluere hele systemet. Modellen har til formål at analysere en komponent eller programmets compliance og kontrollere, om et system gør, hvad det skal ifølge specifikationerne.

Trin 1: Enhedstest

Unit testing er en softwaretestmetode, der validerer individuelle dele af kildekoden. En enhedstest hjælper med at bestemme funktionaliteten af et bestemt modul (enhed), og processen isolerer individuelle dele for at afgøre, om de fungerer korrekt.

En enhed er en individuel funktion, procedure eller objektorienteret programmeringsklasse. Typisk hjælper enhedstest med at validere front-end-grænsefladen.

Den største fordel ved enhedstestning er tidlig problemopdagelse i udviklingens livscyklus. I testdrevet udvikling, såsom scrum eller ekstrem programmering, opretter testere enhedstests, før der eksisterer nogen kode.

Den største ulempe ved anvendelse af enhedstest er behovet for at evaluere komplekse udførelsesstier i et program. Enhedstests er lokaliserede og inkompatible til at opdage integration eller systemomspændende fejl.

Trin 2: Integrationstest

Integrationstest er en fase, der kommer efter enhedstest. Metoden kombinerer tidligere vurderede individuelle programenheder (moduler) i større grupper og udfører test på aggregaterne.

Der er flere forskellige tilgange til integrationstest:

• bottom-up-strategien evaluerer og integrerer først komponenter på lavt niveau, før de flyttes til mere komplekse grupper.
• top-down-tilgangen bruger reverse engineering til at vurdere komponenter fra mere komplekse grupper og forenkler dem til mindre enheder.
• Sandwich (hybrid)-testning kombinerer bottom-up- og top-down-strategien ved samtidig at teste komponenter på lavt og højt niveau.
• Big bang-testning kombinerer alle komponenter i en enkelt stor enhed til test. Metoden har ikke en inkrementel tilgang sammenlignet med andre testmetoder.

Integrationstest validerer forbindelserne mellem front-end-grænsefladen og en applikations backend.

Trin 3: Systemtest

Systemtest udfører test på et fuldstændigt integreret system. Trinet analyserer adfærden og sammenligner dem med forventede krav (kvalitetssikring), og validerer en fuldt integreret software.

Systemtest har til formål at opdage problemer, der er gået glip af integration og enhedstest og at give et omfattende overblik over, om softwaren er klar til udgivelse. De forskellige testmetoder i systemtest overvejer, hvor godt softwaren fungerer i forskellige miljøer, og hvor brugbar softwaren er.

Hovedudfordringen ved systemtest er at designe en strategi, der passer inden for de tilgængelige tids- og ressourcebegrænsninger, samtidig med at den giver en omfattende analyse af hele systemet efter integration.

Trin 4: Accepttest

Den sidste del af funktionstest er accepttesten. Testmetoden har til formål at vurdere godkendelsen af applikationens slutbruger. Fremgangsmåden engagerer slutbrugere i testprocessen og indsamler brugerfeedback for potentielle brugervenlighedsproblemer eller mistede fejl under tidligere testfaser.

Accepttest falder ind under en af de to følgende kategorier:

• Brugeraccept-test giver målbrugere mulighed for at evaluere og bruge softwaren gennem beta-testning eller en lignende strategi. Brugerbasen afgør, om softwaren fungerer som forventet.
• Operationel accept test kontrollerer, om softwaren er funktionel og fungerer som forventet. Testen undersøger forskellige softwarekomponenter, såsom sikkerhed, backup og disaster recovery og failover-test.

Efter accepttest er softwaren klar til produktion, hvis resultaterne opfylder acceptkriterierne. Ellers bliver softwaren skubbet tilbage til tidligere udviklings- og testfaser, hvis testen ikke passerer tærsklen.

Ikke-funktionel test

Ikke-funktionel test evaluerer softwaren fra brugernes perspektiv med fokus på brugeroplevelsen. Testmetoden har til formål at fange eventuelle problemer, der ikke er relateret til en softwares funktionalitet, men er afgørende for brugerens oplevelse.

Ikke-funktionel test tager hensyn til parametre som:

• Sikkerhed
• Pålidelighed
• Skalerbarhed
• Anvendelighed
• Tilgængelighed

Fokus for ikke-funktionel test er på, hvordan et produkt fungerer, snarere end hvordan det opfører sig i specifikke brugssager. Denne testmodel udføres gennem ydelsestest, sikkerhedstest, brugervenlighedstest og kompatibilitetstest.

Performancetest

Ydelsestest kontrollerer softwarens hastighed, skalerbarhed og stabilitet. Der findes flere forskellige undertyper af præstationstest, såsom:

• Belastningstest kontrollerer, hvordan softwaren fungerer under almindelig brugerefterspørgsel.
• Stresstests undersøger, hvordan software opfører sig under en høj brugerbelastning eller andre komplekse omstændigheder.
• Spiketests kontrollerer, hvordan software opfører sig under pludselige høje brugerbelastningsspidser.
• Udholdenhedstests viser en applikations stabilitet over længere tid.

Alle præstationstests har til formål at fange og rette problemer med lav latenstid og ydeevne, der forringer en brugers oplevelse.

Sikkerhedstest

Sikkerhedstest kontrollerer for eventuelle sikkerhedsproblemer i software og er en af de mest kritiske softwaretestmetoder. Metoden tjekker for eventuelle sårbarheder i systemet og muligheder for cyberangreb.

Metoder som penetrationstest og sårbarhedsscanning hjælper med at opdage og sænke sikkerhedsrisici i softwaren, og der er også adskillige penetrationstestværktøjer til at automatisere testprocessen.

Test af brugervenlighed

Usability test evaluerer, hvor brugervenlig og praktisk software er for en bruger. Testene fremhæver, hvor hurtigt en uvejledt bruger kan gøre noget i programmet eller applikationen. Usability-testresultaterne viser, hvor hurtigt en ny bruger kan lære at bruge softwaren, og om det er nødvendigt med interfaceforbedringer.

Kompatibilitetstest

Kompatibilitetstest viser et systems adfærd i forskellige miljøer og med anden software. Metoden fokuserer på integration med eksisterende løsninger og teknologier.

Softwaretestmodeller

Testfasen i softwareudviklingens livscyklus er ikke det eneste sted, hvor fejl kan identificeres og rettes. Alle udviklingsstadier har gavn af at inkludere softwaretests.

Kontinuerlig softwareudvikling kræver også kontinuerlig softwaretest. Softwareudvikling bør arbejde sammen med testteamet for at opdage potentielle problemer tidligt eller for at bestemme steder, hvor test er umuligt. Tidlig opdagelse er bedre, og efterhånden som trinene skrider frem, stiger omkostningerne ved at finde og rette fejl. Ifølge IBM System Science Institute er de relative omkostninger ved at opdage og reparere defekter i vedligeholdelsesfasen omkring seks gange højere.

Derfor er det afgørende at se, hvordan test integreres i forskellige softwareudviklingsprocesser og -metoder. Nedenfor er en oversigt over velkendte softwareudviklingsmodeller og hvordan test integreres i hver metode.

Vandfaldsmodel

Vandfaldsmodellen er en softwareudviklingsmetode opdelt i sekventielle trin eller stadier. Holdet går først videre til den følgende fase efter at have afsluttet den forrige fase.

Testteamet begynder at lave en testplan og -strategi under kravfasen i vandfaldsmodellen. Når softwaren har gennemgået implementeringsfasen, verificerer testere, om softwaren fungerer korrekt og i overensstemmelse med specifikationerne.

Den største fordel ved vandfaldsmetoden i softwaretest er, at kravene er veldefinerede og lette at anvende i testfasen. Modellen er uegnet til projekter, hvor forholdene ofte ændrer sig, og der opstår uplanlagte hændelser.

Fordele

• Simpel: Et højt abstraktionsniveau forenkler kommunikationsprocessen med slutbrugeren, som ikke behøver at kende de tekniske procesdetaljer for at deltage i udviklingsprocessen.
• Nem at følge: Projektledere har adgang til kritiske punkter i projektudvikling, hvilket giver dem mulighed for at være opmærksomme på niveauet af fremskridt under udvikling.
• Nem at anvende: Modellen gennemgår en enkelt iteration, hvilket er praktisk til at erstatte eksisterende løsninger med ny software.

Ulempe

• Ingen feedback-loop: Vandfaldsmodellen mangler en feedback-mekanisme og flere iterationer. Det er umuligt at definere alle krav ved projektets start, og at vende tilbage til et hvilket som helst tidligere trin for at foretage ændringer er ikke en understøttet vej i modellen.
• Ingen tilsyneladende sammenhæng mellem faser: Modellen antager, at hver tidligere udviklingsfase er input til det følgende trin. Modellen definerer dog ikke, hvordan krav omdannes til et design.
• Ikke fokuseret på problemløsning: Vandfaldsmodellen nærmer sig softwaredesign som en hardware- eller produktionsmekanisme. På den anden side kræver softwaredesign at teste og prøve forskellige tilgange. Modellen begrænser enhver modulær og kreativ proces under softwareudvikling.
• Begrænset slutbrugerinteraktion: Vandfaldsmodellen kommunikerer kun med en bruger i det første trin af udviklingsfasen og i det sidste trin, når produktet er færdigt. Tilgangen begrænser brugerinteraktionen, hvilket gør udviklingsprocessen ineffektiv.

V model

V-modellen er en udvidelse og forbedring af vandfaldsmodellen. Modellen opdeles i sekventielle trin med yderligere testtrin for hver udviklingsfase. V-modellen gennemgår alle stadier i funktionel test for at verificere og validere softwaren.

V-modellens form viser de tilsvarende testfaser til udviklingens livscyklusfaser. Når den ses fra venstre mod højre, viser modellen rækkefølgen af trin, som tiden skrider frem, mens visning fra top til bund afslører abstraktionsniveauet.

Fordele

• Feedback-mekanisme: V-modellen er praktisk til simple og komplekse projekter på grund af muligheden for at vende tilbage til enhver af de tidligere faser.
• Verificerer og validerer: Modellen gør det muligt at kontrollere, om et projekt er udviklet godt, fuldt implementeret og opfylder brugerkravene.
• Produkter af høj kvalitet: Udviklingsprocessen er velorganiseret og kontrolleret, hvilket garanterer softwarens kvalitet.
• Test i tidlige faser: Testteamet deltager i de tidlige udviklingsfaser, hvilket resulterer i en bedre forståelse af projektet fra starten. Modellen sparer betydeligt tid og ressourcer på test i de senere udviklingsstadier.

Ulempe

• Ikke fleksibel: Når der opstår problemer, skal teamet opdatere alle faser skal tilpasse sig softwareændringerne og være opdateret, inklusive dokumentationen. Enhver ændring bremser udviklingsprocessen.
• Dyst: Implementering af V-modellen kræver betydelige ressourcer til at understøtte adskillige udviklingsteams. Modellen er bedre egnet til større projekter og virksomheder.

Agile model

Den agile metodologi er en hurtig og iterativ tilgang til udvikling af software, der følger principperne defineret i Agile Manifesto. Det opdeler softwareudvikling i små trin og flere iterationer. Den agile model tillader konstant interaktion med slutbrugere, og kravene ændrer sig konstant.

Test i den agile model sker i hver iteration. Softwaretest i dette miljø kræver, at man anvender løbende test i CI/CD-pipelinen gennem automatiserede testværktøjer og testrammer.

Fordele

• Hurtig udvikling: Installation af software sker hurtigere end i andre modeller. Modellen er adaptiv og lydhør over for ændringer, hvilket resulterer i kortere ekspeditionstid.
• Mindre gentagelser: Fejl og defekter er nemmere at opdage og analysere i mindre bidder. Levering af software tager mindre tid, og nye iterationer sker ofte.
• Højt niveau af brugerinteraktion: Konstant slutbrugerfeedback sikrer, at accepttest finder sted ofte. Som et resultat er produktet tættere på kravene med hver iteration.

Ulempe

• Uforudsigelig: Selvom testteamet indsamler brugerfeedback, er der ingen garanti for, at den næste iteration vil indeholde disse ændringer. Det høje tempo skaber en uforudsigelig produktkøreplan.
• Dyst: Løbende frigivelser til produktion og udvikling resulterer i højere omkostninger. Det bliver svært at forudsige den nødvendige indsats for hver ændring.
• Faseoverlap: Hver iteration gennemgår alle udviklingsfaserne. Efterhånden som spurterne skrider frem, bliver det sværere at skelne, hvem der er ansvarlig for hvilken opgave.

Scrum model

Scrum-modellen er en projektledelsestilgang, der bruger principper fra den agile model. Modellen er målorienteret og tidsbegrænset til iterationer kendt som sprints. Hver sprint består af møder, milepæle og begivenheder, der styres af en scrum master.

Scrum-modellen har ikke et testhold, og udviklere er ansvarlige for at konstruere og implementere enhedstests. Softwaren bliver også ofte testet af slutbrugeren i hver sprint.

Nogle scrum-teams har testere, i hvilket tilfælde testere skal give tidsestimater for hver testsession under scrum-møder.

Fordele

• Hurtigt: Scrum-modellen sikrer, at projektlevering sker hurtigt, hvilket gør den velegnet til projekter, der er under udvikling.
• Omkostningseffektiv: Hver sprint består af flere medlemmer, og det hurtige miljø sikrer, at projektets afslutning sker inden for en bestemt tidsramme.
• Højt niveau af brugerinteraktion: Ligesom Agile-modellen frigiver scrum ofte kode, hvilket resulterer i konstant brugerinteraktion. Kontinuerlig feedback resulterer i at tilfredsstille brugernes krav gennem hver sprint.

Ulempe

• Høj chance for fiasko: Scrum-modellen kræver et højt niveau af interaktion og engagement. Daglige møder er stressende, og et teammedlems forlader påvirker hele projektet. Softwaren har en højere risiko for fejl i et ikke-kompatibelt team.
• Mangler kvalitet: Når en model mangler et testhold, er kvaliteten af softwaren uacceptabel. Den resulterende software er af lavere kvalitet end dem, der gennemgår intensiv test.

DevOps model

DevOps-modellen kombinerer kontinuerlig test i hvert udviklingstrin, mens den også har en dedikeret testrolle i teamet. Målet med test i DevOps-pipelinen fokuserer på softwarekvalitet og risikovurdering.

Automatiseret test og testdrevet udvikling forbedrer kodens pålidelighed, hvilket hjælper med at minimere sandsynligheden for, at nye builds bryder eksisterende kode.

Fordele

• Hurtig softwarelevering: DevOps forbedrer leveringshastigheden for nye funktioner og fejlrettelser. Hurtige svartider på problemer forbedrer kundetilfredsheden med produktet.
• Kvalitetssoftware: Automatiseret test og kontinuerlig implementering forbedrer softwarekvaliteten. DevOps sikrer, at hver ændring testes, før softwaren implementeres i produktionen.
• Fejleffektiv: Ved at integrere test i de indledende stadier af udviklingen undgår du at skulle løse problemer senere i udviklingscyklussen.

Ulempe

• Svært at implementere: DevOps kræver integration af udvikling med drift og følgende DevOps-principper, hvilket er svært at opnå i store organisationer med komplekse systemer.
• Øget risici: DevOps er stærkt afhængig af automatisering, hvilket fører til problemer, hvis det ikke er konfigureret korrekt. Problemer er svære at spore, når de opstår.
• For store omkostninger: Modellen kræver betydelige investeringer i infrastruktur og DevOps-værktøjer. Et forkert konfigureret system skaber integrationsudfordringer, som er svære at håndtere.

Iterativ udvikling

Iterativ udvikling opdeler softwareudviklingstrin i undersystemer baseret på funktioner. Metoden er trinvis, og hver stigning leverer et færdigt system. Hver ny iteration forbedrer eksisterende processer inden for hvert delsystem.

Tidlige udgivelser giver en primitiv version af softwaren, mens hver efterfølgende udgivelse forbedrer kvaliteten af de eksisterende funktionaliteter. Testning er enklere i de tidlige faser og øges i kompleksitet, efterhånden som iterationer skrider frem.

Fordele

• Risikokontrol: Iterativ udvikling gør det muligt at starte med højrisikoopgaver først. Den kontrollerede karakter af udviklingsmetoden gør det muligt at forbedre eventuelle problemer gennem iterationer.
• Nem at følge: Hver iteration viser en forbedring fra den forrige. Måling af ændringer mellem iterationer bliver enkelt for projektledere.
• Tidlig træning: Da iterativ udvikling giver en enklere version af den fulde software, er brugerne engagerede og bruger softwaren tidligt. Brugerfeedback er baseret på hele systemet, og forbedringer er nemmere at implementere i de følgende iterationer.
• Specialiserede versioner: Versioneringssoftware bliver simpel, da udviklingsteams kan fokusere på specifikke forbedringer med hver iteration. For eksempel forbedrer én iteration brugergrænsefladen, mens den følgende iteration forbedrer softwarens ydeevne. Fremgangsmåden forenkler testdesignprocessen.

Ulempe

• Dyst: Hver iteration kræver tilstedeværelsen af hele softwareudviklingsteamet.
• Mangler fulde specifikationer: Den iterative udviklingstilgang begynder at skabe et system ud fra simple krav. Som tiden skrider frem, ændrer forholdene sig også. De flydende specifikationer gør det udfordrende at se, hvornår projektet slutter.
• Svær at administrere: Iterativ udvikling kræver intens projektstyring og risikovurdering for hver iteration. Efterhånden som projekter vokser, øges systemets kompleksitet.

Spiral model

Spiralmodellen er en agil model med fokus på risikovurdering. Modellen kombinerer de bedste kvaliteter fra top-down og bottom-up udviklingsmetoderne. Metoden bruger vandfaldsmodellens faser som stadig mere komplekse prototyper.

Da risikoanalyse er i fokus for hvert trin, muliggør spiralmodellen tidlig opdagelse af fejl og sårbarheder. Modellen udfører en tidlig vurdering af problemer, hvilket gør sikkerhedstest billigere i det lange løb.

Fordele

• Fleksibel; Spiralmodellen kan tilpasses til kravændringer, selv efter udvikling af en funktion. Der er mindre belastning af testteamet, når de rapporterer problemer.
• Sikker; Risikoanalyse er i hvert trin af udviklingsprocessen, og den iterative tilgang hjælper også med at styre risiko. Spiralmodellen fokuserer mere på softwaresikkerhed sammenlignet med andre udviklingsmodeller.
• Højt niveau af brugerinteraktion; Den iterative tilgang i spiralmodellen gør det muligt at engagere kunden i udviklingsprocessen og modtage løbende feedback. Udviklingsteamet laver hurtigt ændringer under udviklingen, hvilket sparer omkostninger og ressourcer i det lange løb.

Ulempe

• Dyst: Spiralmodellen passer bedst til store projekter og kompleks software.
• Specialiserede risikoanalytikere: Modellen afhænger af at have risikoanalytikere af høj kvalitet inkluderet i hvert udviklingstrin for effektiv risikovurdering.
• Kompleks: Modellen er svær at følge og kræver øget fokus på protokoller og dokumentation i alle udviklingstrin.
• Tidsstyring: Varigheden af hver fase er ukendt. Modellen er modtagelig for at overskride budgettet og komme bagud med tidsbegrænsninger.

RAD model

RAD-modellen (Rapid Application Development) er en agil metode, der kombinerer prototyping med iterativ udvikling. Metoden fokuserer på at indsamle brugerkrav, mens resten af udviklingsprocessen ikke har nogen specifik plan eller trin.

RAD er en hurtig teknik, der fokuserer på at skabe genanvendelige komponenter, der fungerer som skabeloner til følgende projekter eller prototyper. Testteamet vurderer alle prototyper i hver iteration og integrerer straks komponenterne i det endelige produkt.

Fordele

• Fleksibel: Modellen implementerer hurtigt kravændringer og imødekommer nye brugerkrav.
• Genbrugelig: At skabe genanvendelige prototyper giver en skabelontilgang til udvikling, hvilket øger kodegenanvendelighed og kræver mindre indsats i det lange løb.
• Hurtig: Udviklingstiden og korte iterationer muliggør kontinuerlig softwareintegration og hurtig levering. RAD-modellen inkorporerer forskellige automatiseringsværktøjer for at fremskynde udviklingsprocessen.

Ulempe

• Høj ekspertiseafhængighed: RAD-baserede teams er små, højt kvalificerede og teknisk stærke. RAD-modellen kræver et erfarent team af udviklere til at identificere og modellere brugerkrav.
• Kun egnet til modulære systemer: Ikke al software har entydige komponenter. RAD kræver oprettelse af mindre prototyper, som kan genbruges. Komplekse systemer kræver specialiserede funktioner, som ikke gælder for alle anvendelsestilfælde.

Ekstrem programmering

Ekstrem programmering (XP) er en agil metode til udvikling af software, der er bedst egnet til små til mellemstore teams (6-20 medlemmer). Teknikken fokuserer på testdrevet udvikling og korte iterationer, der giver brugerne direkte resultater.

XP har ingen streng metode for udviklingsteamet at følge. I stedet giver metoden en fleksibel ramme, hvor procedurer eller rækkefølgen af trin ændres afhængigt af aktiviteten. Principperne for Agile Manifesto og teknikker som parprogrammering er vitale komponenter i XP.

Fordele

• Fokus på softwareudvikling: Teamet skaber software frem for at fokusere på møder og dokumentation. Arbejdsmiljøet er behageligt for udviklere, med mange muligheder for at lære og forbedre færdigheder.
• Kort udviklingstid: Manglen på regler og procedurer gør softwareleveringen hurtig. Hurtige resultater er til gavn for kunderne.
• Testdrevet udvikling: Der findes enhedstests, før de skriver kode, og programmører ved, hvad der testes, før de opretter software. Denne tilgang stimulerer programmører til at tage bedre forholdsregler, mens de koder.

Ulempe

• Svær at implementere: Metoden er svær at implementere. XP kræver programmører med streng disciplin, som accepterer og følger de påkrævede principper og kan arbejde tæt sammen.
• Kundeafhængig: Kunden vælger selv, om han vil deltage i udviklingsprocessen. En ikke-deltagende klient fører ofte til utilfredsstillende software.

Konklusion

Softwaretest af høj kvalitet er det, der skelner mellem kvalitetssoftware og et glansløst projekt. Vigtigheden af softwaretest er afgørende for udviklingen, og derfor er der så mange testmetoder og -tilgange. Udviklingsteams bør følge trends inden for softwaretestning og være klar til fundamentalt at ændre deres tilgang til at drage fordel af nye softwaretestmetoder og -modeller.

Tjek derefter, hvordan automatiserede testrammer hjælper med at strømline testprocessen og forbedre testhastighederne i testfasen.