Smidig metodikk i programvaretesting

Hva er smidig metodikk i testing?

Agil metodikk betyr en praksis som fremmer kontinuerlig iterasjon utvikling og testing gjennom prosjektets livssyklus for programvareutvikling. I Agile-modellen i programvaretesting er både utviklings- og testaktiviteter samtidige, i motsetning til Waterfall-modellen.

Hva er smidig programvareutvikling?

Ocuco Agil programvareutvikling metodikk er en av de enkleste og effektive prosessene for å gjøre en visjon for et forretningsbehov til programvareløsninger. Agile er et begrep som brukes for å beskrive programvareutviklingstilnærminger som bruker kontinuerlig planlegging, læring, forbedring, teamsamarbeid, evolusjonær utvikling og tidlig levering. Det oppmuntrer til fleksible reaksjoner på endringer.

Den smidige programvareutviklingen legger vekt på fire kjerneverdier.

Individuelle og teamsamhandlinger over prosesser og verktøy
Arbeidsprogramvare over omfattende dokumentasjon
Kundesamarbeid om kontraktforhandling
Reagere på endring etter en plan

Smidig modell vs fossemodell

Agile og Waterfall-modellen er to forskjellige metoder for programvareutviklingsprosesser. Selv om de er forskjellige i sin tilnærming, er begge metodene nyttige til tider, avhengig av kravet og typen prosjekt.

Agil modell	Fossmodell
Smidig metodikk i definisjon av programvaretesting: Smidig metodikk foreslår inkrementell og iterativ tilnærming til programvaredesign	Fossmodell: Utvikling av programvaren flyter sekvensielt fra startpunkt til sluttpunkt.
Ocuco Smidig prosess i programvaretesting er delt inn i individuelle modeller som designere jobber med	Designprosessen er ikke delt inn i individuelle modeller
Kunden har tidlige og hyppige muligheter til å se på produktet og ta beslutninger og endringer i prosjektet	Kunden kan kun se produktet på slutten av prosjektet
Smidig modell i testing anses som ustrukturert sammenlignet med fossefallsmodellen	Fossmodellen er sikrere fordi de er så planorienterte
Små prosjekter kan gjennomføres veldig raskt. For store prosjekter er det vanskelig å anslå utviklingstiden.	Alle slags prosjekter kan estimeres og fullføres.
Feil kan rettes midt i prosjektet.	Først på slutten blir hele produktet testet. Hvis kravfeilen blir funnet eller det må gjøres endringer, må prosjektet starte fra begynnelsen
Utviklingsprosessen er iterativ, og prosjektet gjennomføres i korte (2-4) ukers iterasjoner. Planlegging er veldig mindre.	Utviklingsprosessen er faset, og fasen er mye større enn iterasjon. Hver fase avsluttes med en detaljert beskrivelse av neste fase.
Dokumentasjon blir mindre prioritert enn programvareutvikling	Dokumentasjon er en topp prioritet og kan til og med brukes til opplæring av ansatte og oppgradering av programvaren med et annet team
Hver iterasjon har sin egen testfase. Den tillater implementering av regresjonstesting hver gang nye funksjoner eller logikk slippes.	Først etter utviklingsfasen utføres testfasen fordi separate deler ikke er fullt funksjonelle.
I smidig testing når en iterasjon avsluttes, leveres funksjoner som kan sendes til kunden. Nye funksjoner kan brukes rett etter forsendelse. Det er nyttig når du har god kontakt med kunder.	Alle funksjoner som utvikles leveres på en gang etter den lange implementeringsfasen.
Testere og utviklere jobber sammen	Testere jobber separat fra utviklere
På slutten av hver sprint utføres brukeraksept	Brukers aksept er utført på slutten av prosjektet.
Det krever tett kommunikasjon med utbyggere og sammen analysere krav og planlegging	Utbygger involverer ikke i krav og planleggingsprosess. Vanligvis er det tidsforsinkelser mellom tester og koding

Sjekk også: - Smidig vs Foss: Kjenn forskjellen mellom metoder

Smidig prosess

Sjekk nedenfor Agile metodikk prosess for å levere vellykkede systemer raskt.

Det finnes ulike Agile metoder tilstede i smidig testing, og de er listet opp nedenfor:

Scrum

SCRUM er en smidig utviklingsmetode som konsentrerer seg spesifikt om hvordan man håndterer oppgaver innenfor et teambasert utviklingsmiljø. I utgangspunktet er Scrum avledet fra aktivitet som oppstår under en rugbykamp. Scrum tror på å styrke utviklingsteamet og tar til orde for å jobbe i små team (f.eks. 7 til 9 medlemmer). Agile og Scrum består av tre roller, og deres ansvar er forklart som følger:

Scrum Master
- Scrum Master har ansvar for å sette opp laget, sprintmøte og fjerner hindringer for fremgang
Produkt eier
- Produkteieren oppretter produktbacklog, prioriterer backlog og er ansvarlig for levering av funksjonaliteten ved hver iterasjon
Scrum Team
- Team styrer sitt eget arbeid og organiserer arbeidet for å fullføre sprinten eller syklusen

Product Backlog

Dette er et arkiv hvor krav spores med detaljer om antall krav (brukerhistorier) som skal fullføres for hver utgivelse. Den bør vedlikeholdes og prioriteres av Product Owner, og den bør distribueres til scrum-teamet. Teamet kan også be om et nytt kravtilføyelse eller endring eller sletting

Scrum-øvelser

Praksis er beskrevet i detalj:

Prosessflyt av Scrum-metoder:

Prosessflyt av scrum testing er som følger:

Hver iterasjon av en scrum er kjent som Sprint
Produktbacklog er en liste der alle detaljer legges inn for å få sluttproduktet
Under hver Sprint, toppbrukerhistorier om produktbacklog er valgt og omgjort til Sprint backlog
Teamet jobber med den definerte sprintbacklogen
Teamsjekker for det daglige arbeidet
På slutten av sprinten leverer teamet produktfunksjonalitet

Ekstrem programmering (XP)

Ekstrem programmeringsteknikk er svært nyttig når det er stadig skiftende krav eller krav fra kundene eller når de ikke er sikre på funksjonaliteten til systemet. Den tar til orde for hyppige "utgivelser" av produktet i korte utviklingssykluser, noe som iboende forbedrer produktiviteten til systemet og også introduserer et sjekkpunkt der eventuelle kundekrav enkelt kan implementeres. XP utvikler programvare som holder kunden i målet.

Forretningskrav er samlet i form av historier. Alle disse historiene er lagret på et sted som kalles parkeringsplassen.

I denne typen metodikk er utgivelser basert på de kortere syklusene kalt iterasjoner med en tidsperiode på 14 dager. Hver iterasjon inkluderer faser som koding, enhetstesting og systemtesting, hvor det i hver fase vil bygges noe mindre eller større funksjonalitet i applikasjonen.

Faser av eXtreme programmering:

Det er 6 faser tilgjengelig i Agile XP-metoden, og de er forklart som følger:

Planlegging

Identifisering av interessenter og sponsorer
Krav til infrastruktur
Trygghet relatert informasjon og innsamling
Service Level Agreements og deres betingelser

Analyse

Fangst av historier på parkeringsplassen
Prioriter historier på parkeringsplassen
Skrubbing av historier for estimering
Definer iterasjon SPAN (tid)
Ressursplanlegging for både utviklings- og QA-team

Utforming

Nedbryting av oppgaver
Test Scenario forberedelse for hver oppgave
Regresjonsautomatiseringsrammeverk

Gjennomføring

Koding
Enhetstesting
Utførelse av manuelle testscenarier
Generering av feilrapporter
Konvertering av manuell til automatisering regresjonstesttilfeller
Mid Iteration anmeldelse
End of iteration review

Innpakning

Små utgivelser
Regresjonstesting
Demoer og anmeldelser
Utvikle nye historier basert på behovet
Prosessforbedringer basert på kommentarer fra slutten av iterasjonen

Closure

Pilotoppskyting
Kurs
Produksjonsstart
SLA-garanti
Review SOA-strategi
Produksjonsstøtte

Det er to storyboards tilgjengelig for å spore arbeidet på daglig basis, og de er oppført nedenfor for referanse.

Historiepapp
- Dette er en tradisjonell måte å samle alle historiene på en tavle i form av pinnelapper for å spore daglige XP-aktiviteter. Siden denne manuelle aktiviteten krever mer innsats og tid, er det bedre å bytte til et nettskjema.
Online Storyboard
- Onlineverktøy Storyboard kan brukes til å lagre historiene. Flere lag kan bruke den for forskjellige formål.

Krystallmetoder

Krystallmetodikk er basert på tre konsepter

Befraktning: Ulike aktiviteter involvert i denne fasen er å opprette et utviklingsteam, utføre en foreløpig mulighetsanalyse, utvikle en innledende plan og finjustere utviklingsmetodikken
Syklisk levering: Hovedutviklingsfasen består av to eller flere leveringssykluser, der
1. Teamet oppdaterer og avgrenser utgivelsesplanen
2. Implementerer et undersett av kravene gjennom en eller flere programtestintegrerte iterasjoner
3. Integrert produkt leveres til reelle brukere
4. Revoversikt over prosjektplanen og vedtatt utviklingsmetodikk
Pakk opp: Aktivitetene som utføres i denne fasen er distribusjon i brukermiljøet, gjennomganger og refleksjoner etter distribusjon utføres.

Dynamisk programvareutviklingsmetode (DSDM)

DSDM er en Rask applikasjonsutvikling (RAD) tilnærming til programvareutvikling og gir et smidig rammeverk for prosjektlevering. Det viktige med DSDM er at det kreves at brukerne involveres aktivt, og at teamene får makt til å ta beslutninger. Hyppig levering av produkt blir det aktive fokuset med DSDM. Teknikkene som brukes i DSDM er

Tid Boxing
MOSKVA regler
Prototyping

DSDM-prosjektet består av 7 faser

Forprosjekt
Mulighetsstudie
Business Studie
Funksjonell modell iterasjon
Design og bygg iterasjon
Gjennomføring
Etterprosjekt

Funksjonsdrevet utvikling (FDD)

Denne metoden er fokusert rundt "designe og bygge" funksjoner. I motsetning til andre smidige metoder innen programvareteknikk, beskriver FDD veldig spesifikke og korte faser av arbeid som må utføres separat per funksjon. Det inkluderer domenegjennomgang, designinspeksjon, promotering for å bygge, kodeinspeksjon og design. FDD utvikler produktholding som følger ting i målet

Domeneobjektmodellering
Utvikling etter funksjon
Komponent/klasseeierskap
Funksjonsteam
Inspeksjoner
Configuration Management
Vanlige bygg
Synlighet av fremgang og resultater

Lean programvareutvikling

Lean programvareutviklingsmetode er basert på prinsippet "Just in time production". Den tar sikte på å øke hastigheten på programvareutvikling og redusere kostnadene. Lean utvikling kan oppsummeres i syv trinn.

Eliminering av avfall
Forsterker læring
Utsett engasjement (beslutning så sent som mulig)
Tidlig levering
Styrke laget
Bygning Integrity
Optimaliser helheten

Kanban

Kanban opprinnelig dukket opp fra det japanske ordet som betyr et kort som inneholder all informasjonen som må gjøres på produktet på hvert trinn langs veien til ferdigstillelse. Dette rammeverket eller metoden er ganske vedtatt i programvaretestmetoden, spesielt i Agile-konsepter.

Scrum vs Kanban

Scrum	Kanban
I scrumteknikk må tester brytes ned slik at de kan gjennomføres innen en sprint	Ingen spesiell varestørrelse er foreskrevet
Foreskriver et prioritert produktetterslep	Prioritering er valgfritt
Scrum-teamet forplikter seg til en bestemt mengde arbeid for iterasjonen	Engasjement er valgfritt
Nedbrenningsdiagram er foreskrevet	Ingen spesiell varestørrelse er foreskrevet
Mellom hver sprint tilbakestilles et scrumbrett	Et Kanban-brett er vedvarende. Det begrenser antall elementer i arbeidsflyttilstand
Den kan ikke legge til elementer i pågående iterasjon	Den kan legge til elementer når kapasitet er tilgjengelig
WIP begrenset indirekte	WIP begrenset direkte
Timebox-iterasjoner foreskrevet	Tidsrammede iterasjoner valgfritt

Sjekk også: - Kanban vs. Scrum: Hva er forskjellen?

Smidige beregninger

Beregninger som kan samles inn for effektiv bruk av Agile er:

Drafaktor
- Innsats i timer som ikke bidrar til sprintmål
- Drafaktor kan forbedres ved å redusere antall delte ressurser, redusere mengden av ikke-bidragende arbeid
- Nye estimater kan økes med prosentandel av dragfaktor -Nytt estimat = (Gamle estimat+dragfaktor)
Velocity
- Mengde etterslep (brukerhistorier) konvertert til sprintfunksjonalitet som kan sendes
Antall enhetstester lagt til
Tidsintervall tatt for å fullføre daglig bygging
Feil oppdaget i en iterasjon eller i tidligere iterasjoner
Produksjonsfeillekkasje