Agile metodik i softwaretestning

Hvad er agil metodologi i test?

Agile Metodologi betyder en praksis, der fremmer kontinuerlig iteration udvikling og test gennem hele projektets softwareudviklingslivscyklus. I den agile model i softwaretest er både udviklings- og testaktiviteter samtidige, i modsætning til Waterfall-modellen.

Hvad er agil softwareudvikling?

Agile softwareudvikling metodologi er en af de enkleste og mest effektive processer til at omdanne en vision for et forretningsbehov til softwareløsninger. Agile er et udtryk, der bruges til at beskrive softwareudviklingstilgange, der anvender løbende planlægning, læring, forbedring, teamsamarbejde, evolutionær udvikling og tidlig levering. Det tilskynder til fleksible reaktioner på forandringer.

Den agile softwareudvikling lægger vægt på fire kerneværdier.

Individuelle og teaminteraktioner over processer og værktøjer
Fungerende software over omfattende dokumentation
Kundesamarbejde om kontraktforhandling
Reagerer på skift efter en plan

Agile model vs vandfaldsmodel

Agile og vandfaldsmodel er to forskellige metoder til softwareudviklingsproces. Selvom de er forskellige i deres tilgang, er begge metoder til tider nyttige, afhængigt af kravet og typen af projektet.

Agile model	Vandfaldsmodel
Agile metodologi i definition af softwaretest: Agile metodologier foreslår inkrementel og iterativ tilgang til softwaredesign	Vandfaldsmodel: Udvikling af softwaren flyder sekventielt fra startpunkt til slutpunkt.
Agile proces i softwaretest er opdelt i individuelle modeller, som designere arbejder på	Designprocessen er ikke opdelt i individuelle modeller
Kunden har tidlige og hyppige muligheder for at se på produktet og træffe beslutninger og ændringer i projektet	Kunden kan først se produktet i slutningen af projektet
Agile model i test anses for ustruktureret sammenlignet med vandfaldsmodellen	Vandfaldsmodeller er mere sikre, fordi de er så planorienterede
Små projekter kan implementeres meget hurtigt. For store projekter er det svært at estimere udviklingstiden.	Alle slags projekter kan estimeres og gennemføres.
Fejl kan rettes midt i projektet.	Først til sidst testes hele produktet. Hvis kravfejlen findes, eller der skal foretages ændringer, skal projektet starte fra begyndelsen
Udviklingsprocessen er iterativ, og projektet udføres i korte (2-4) ugers iterationer. Planlægning er meget mindre.	Udviklingsprocessen er etapevis, og fasen er meget større end iteration. Hver fase afsluttes med en detaljeret beskrivelse af den næste fase.
Dokumentation har mindre prioritet end softwareudvikling	Dokumentation er en topprioritet og kan endda bruges til at træne personale og opgradere softwaren med et andet team
Hver iteration har sin egen testfase. Det tillader implementering af regressionstest hver gang nye funktioner eller logik frigives.	Først efter udviklingsfasen udføres testfasen, fordi separate dele ikke er fuldt funktionsdygtige.
Ved agil testning, når en iteration slutter, leveres produktets funktioner, der kan sendes, til kunden. Nye funktioner kan bruges lige efter forsendelse. Det er nyttigt, når du har god kontakt med kunderne.	Alle udviklede funktioner leveres på én gang efter den lange implementeringsfase.
Testere og udviklere arbejder sammen	Testere arbejder adskilt fra udviklere
Ved slutningen af hver sprint udføres brugeraccept	Brugeraccept er udføres i slutningen af projektet.
Det kræver tæt kommunikation med udviklere og sammen analyserer krav og planlægning	Udvikler involverer ikke i krav og planlægningsproces. Normalt er der forsinkelser mellem test og kodning

Tjek også:- Agile vs vandfald: Kend forskellen mellem metoder

Agile proces

Tjek nedenstående Agile metodologi proces for at levere succesfulde systemer hurtigt.

Der er forskellige Agile metoder til stede i agile test, og disse er anført nedenfor:

Scrum

SCRUM er en agil udviklingsmetode, som fokuserer specifikt på, hvordan man håndterer opgaver i et teambaseret udviklingsmiljø. Grundlæggende er Scrum afledt af aktivitet, der opstår under en rugbykamp. Scrum tror på at styrke udviklingsteamet og går ind for at arbejde i små teams (f.eks. 7 til 9 medlemmer). Agile og Scrum består af tre roller, og deres ansvarsområder er forklaret som følger:

Scrum Master
- Scrum Master er ansvarlig for opsætning af holdet, sprintmøde og fjerner forhindringer for fremgang
Produkt ejer
- Produktejeren opretter produkt backlog, prioriterer backlog og er ansvarlig for leveringen af funktionaliteten ved hver iteration
Scrum Team
- Team styrer sit eget arbejde og organiserer arbejdet for at gennemføre spurten eller cyklen

Produkt backlog

Dette er et lager, hvor krav spores med detaljer om antallet af krav (brugerhistorier), der skal udfyldes for hver udgivelse. Det bør vedligeholdes og prioriteres af Product Owner, og det bør distribueres til scrum-teamet. Team kan også anmode om et nyt krav tilføjelse eller ændring eller sletning

Scrum øvelser

Praksis er beskrevet detaljeret:

Procesflow af Scrum-metoder:

Procesflow af scrum test er som følger:

Hver iteration af et scrum er kendt som Sprint
Produkt backlog er en liste, hvor alle detaljer indtastes for at få slutproduktet
Under hver Sprint, topbrugerhistorier om produktbacklog er udvalgt og omdannet til Sprint efterslæb
Team arbejder på den definerede sprint-backlog
Teamtjek til det daglige arbejde
I slutningen af spurten leverer teamet produktfunktionalitet

Ekstrem programmering (XP)

Ekstrem programmeringsteknik er meget nyttig, når der er konstant skiftende krav eller krav fra kunderne, eller når de ikke er sikre på systemets funktionalitet. Det går ind for hyppige "udgivelser" af produktet i korte udviklingscyklusser, hvilket i sagens natur forbedrer systemets produktivitet og også introducerer et kontrolpunkt, hvor eventuelle kundekrav let kan implementeres. XP udvikler software, der holder kunden i målet.

Forretningskrav er samlet i form af historier. Alle disse historier er gemt på et sted kaldet parkeringspladsen.

I denne type metodologi er udgivelser baseret på de kortere cyklusser kaldet iterationer med en tidsperiode på 14 dage. Hver iteration inkluderer faser som kodning, enhedstest og systemtest, hvor der i hver fase vil blive indbygget en mindre eller større funktionalitet i applikationen.

Faser af eXtreme programmering:

Der er 6 faser tilgængelige i Agile XP-metoden, og de er forklaret som følger:

Planlægning

Identifikation af interessenter og sponsorer
Infrastrukturkrav
Sikkerhed relateret information og indsamling
Service Level Agreements og dets betingelser

Analyse

Optagelse af historier på parkeringsplads
Prioriter historier på parkeringspladsen
Skrubning af historier for estimering
Definer iteration SPAN (tid)
Ressourceplanlægning for både udviklings- og QA-teams

Design

Opdeling af opgaver
Testscenarieforberedelse for hver opgave
Regression Automation Framework

Udførelse

Kodning
Enhedstest
Udførelse af manuelle testscenarier
Generering af fejlrapporter
Konvertering af Manual til Automation regressionstest cases
Mid Iteration gennemgang
End of iteration review

Indpakning

Små udgivelser
Regressionstest
Demoer og anmeldelser
Udvikle nye historier baseret på behovet
Procesforbedringer baseret på kommentarer til slutningen af iterationen

Lukning

Pilotstart
Kurser
Produktionsstart
SLA-garanti
Review SOA-strategi
Produktionsstøtte

Der er to storyboards til rådighed til at spore arbejdet på daglig basis, og dem er anført nedenfor som reference.

Story pap
- Dette er en traditionel måde at samle alle historierne på en tavle i form af stiksedler for at spore daglige XP-aktiviteter. Da denne manuelle aktivitet kræver mere indsats og tid, er det bedre at skifte til en onlineformular.
Online Storyboard
- Onlineværktøj Storyboard kan bruges til at gemme historierne. Flere hold kan bruge det til forskellige formål.

Krystalmetoder

Krystalmetoden er baseret på tre koncepter

Chartering: Forskellige aktiviteter involveret i denne fase er at oprette et udviklingsteam, udføre en foreløbig gennemførlighedsanalyse, udvikle en indledende plan og finjustere udviklingsmetoden
Cyklisk levering: Hovedudviklingsfasen består af to eller flere leveringscyklusser, hvorunder
1. Team opdaterer og forfiner udgivelsesplanen
2. Implementerer en delmængde af kravene gennem en eller flere programtestintegreringer
3. Integreret produkt leveres til rigtige brugere
4. Revoverblik over projektplanen og vedtaget udviklingsmetodik
Indpakning: De aktiviteter, der udføres i denne fase, er udrulning i brugermiljøet, gennemgange efter implementering og refleksioner udføres.

Dynamisk softwareudviklingsmetode (DSDM)

DSDM er en Hurtig applikationsudvikling (RAD) tilgang til softwareudvikling og giver en agil projektleveringsramme. Det vigtige aspekt ved DSDM er, at brugerne skal involveres aktivt, og at teamene får magten til at træffe beslutninger. Hyppig levering af produkt bliver det aktive fokus med DSDM. De teknikker, der bruges i DSDM er

Tid BoxING
MOSKVA regler
Prototyping

DSDM-projektet består af 7 faser

Forprojekt
Forundersøgelsen
Business Studie
Funktionel model iteration
Design og byg iteration
Implementering
Efterprojekt

Funktionsdrevet udvikling (FDD)

Denne metode er fokuseret omkring "designe og bygge" funktioner. I modsætning til andre agile metoder inden for softwareudvikling, beskriver FDD meget specifikke og korte faser af arbejde, der skal udføres separat pr. funktion. Det inkluderer domænegennemgang, designinspektion, promovering til at bygge, kodeinspektion og design. FDD udvikler produktholding efter ting i målet

Domæneobjektmodellering
Udvikling efter funktion
Komponent/klasseejerskab
Feature-hold
Inspektioner
Configuration Management
Regelmæssige byggerier
Synlighed af fremskridt og resultater

Lean Softwareudvikling

Lean softwareudviklingsmetode er baseret på princippet "Just in time production". Det sigter mod at øge hastigheden af softwareudvikling og reducere omkostningerne. Lean udvikling kan opsummeres i syv trin.

Eliminering af spild
Forstærker læring
Udskyd engagement (beslutning så sent som muligt)
Tidlig levering
Styrkelse af teamet
Bygning Integrity
Optimer helheden

Kanban

Kanban oprindeligt opstået fra det japanske ord, der betyder, et kort, der indeholder alle de oplysninger, der skal gøres på produktet på hvert trin langs dets vej til færdiggørelse. Denne ramme eller metode er ret vedtaget i softwaretestmetoden, især i Agile-koncepter.

Scrum vs Kanban

Scrum	Kanban
I scrum teknik skal test nedbrydes, så de kan gennemføres inden for en sprint	Der er ikke foreskrevet nogen bestemt varestørrelse
Foreskriver et prioriteret produktefterslæb	Prioritering er valgfri
Scrum-teamet forpligter sig til en bestemt mængde arbejde for iterationen	Engagement er valgfrit
Nedbrændingsdiagram er foreskrevet	Der er ikke foreskrevet nogen bestemt varestørrelse
Mellem hver sprint nulstilles et scrum board	Et Kanban-tavle er vedvarende. Det begrænser antallet af elementer i arbejdsprocestilstand
Det kan ikke tilføje elementer til igangværende iteration	Det kan tilføje elementer, når kapacitet er tilgængelig
WIP begrænset indirekte	WIP begrænset direkte
Timeboxede iterationer foreskrevet	Timeboxede iterationer valgfri

Tjek også:- Kanban vs. Scrum: Hvad er forskellen?

Agile målinger

Målinger, der kan indsamles for effektiv brug af Agile, er:

Træk faktor
- Indsats i timer, som ikke bidrager til sprintmål
- Trækfaktor kan forbedres ved at reducere antallet af delte ressourcer, reducere mængden af ikke-bidragende arbejde
- Nye estimater kan øges med procentdelen af trækfaktor -Nyt estimat = (gammelt estimat+trækfaktor)
Velocity
- Mængden af efterslæb (brugerhistorier) konverteret til sprintfunktionalitet, der kan sendes
Antal enhedstests tilføjet
Tidsinterval det tager at fuldføre daglige opbygning
Fejl opdaget i en iteration eller i tidligere iterationer
Produktionsfejl lækage

Du kan lide: