Scrum-testmetodeopplæring

Scrum i programvaretesting

Scrum i programvaretesting er en metodikk for å bygge komplekse programvareapplikasjoner. Det gir enkle løsninger for å utføre kompliserte oppgaver. Scrum hjelper utviklingsteamet med å fokusere på alle aspekter av programvareproduktutviklingen som kvalitet, ytelse, brukervennlighet og så videre. Det gir åpenhet, inspeksjon og tilpasning under programvareutviklingen for å unngå kompleksitet.

Scrum testing

Scrum testing er en testing utført i scrum-metodikk for å bekrefte at kravene til programvareapplikasjonen er oppfylt. Det innebærer å sjekke ikke-funksjonelle parametere som sikkerhet, brukervennlighet, ytelse osv. Det er ingen aktiv rolle som tester i prosessen, så den utføres vanligvis av utviklere med Unit Test. Noen ganger trengs dedikerte testteam avhengig av prosjektets natur og kompleksitet.

Hovedtrekk ved Scrum-metodikk

Følgende er nøkkelfunksjonene til Scrum-

• Scrum har en kort fast tidsplan for utgivelsessykluser med justerbart omfang kjent som sprints for å møte raskt skiftende utviklingsbehov. Hver utgivelse kan ha flere spurter. Hvert Scrum-prosjekt kan ha flere utgivelsessykluser.
• En repeterende sekvens av møter, arrangementer og milepæler
• En praksis med å teste og implementere nye krav, kjent som historier, for å sikre at noe arbeid er utgitt klar etter hver sprint

Scrum er basert på følgende 3 pilarer-

La oss se på en etter en

1. Roller i Scrum

Det er tre hovedroller i Scrum Testing – Product Owner, Scrum Master og The Development Team. La oss studere dem i detalj

Produkteier	Scrum Master	Teamet
Han/hun definerer egenskapene til produktet.	Han/hun leder teamet og ser etter teamets produktivitet	Laget er vanligvis rundt 5-9 medlemmer
Produkteier bestemmer utgivelsesdatoen og tilhørende funksjoner	Han/hun opprettholder blokkeringslisten og fjerner barrierer i utviklingen	Det inkluderer utviklere, designere og noen ganger testere, etc.
De prioriterer funksjonene i henhold til markedsverdien og lønnsomheten til produktet	Han/hun koordinerer med alle roller og funksjoner	Teamet organiserer og planlegger arbeidet på egen hånd
Han/hun er ansvarlig for lønnsomheten til produktet	Han/hun beskytter teamet mot eksterne forstyrrelser	Har rett til å gjøre alt innenfor prosjektets grenser for å nå sprintmålet
Han/hun kan godta eller avvise arbeidselementresultatet	Inviterer til daglig scrum, sprintgjennomgang og planleggingsmøter	Delta aktivt i daglige seremonier

2. Scrum-artefakter

En scrum-prosess inkluderer

• Brukerhistorier: De er en kort forklaring på funksjonene til systemet som testes. Eksempel for forsikringsleverandør er - "Premium kan betales ved hjelp av det elektroniske systemet."
• Produktbacklog: Det er en samling av brukerhistorier fanget for et scrum-produkt. Produkteieren forbereder seg og opprettholder produktreserven. Det er prioritert av produktets eier, og hvem som helst kan legge til det med godkjenning fra produktets eier.
• Release Backlog: En utgivelse er en tidsramme der antall iterasjoner er fullført. Produkteieren koordinerer med scrum-mesteren for å bestemme hvilke historier som skal være målrettet for en utgivelse. Historier i utgivelsesetterslepet er målrettet for å bli fullført i en utgivelse.
• Sprints: Det er en fastsatt tidsperiode for å fullføre brukerhistoriene, bestemt av produkteieren og utviklerteamet, vanligvis 2-4 uker.
• Sprint Etterslep: Det er et sett med brukerhistorier som skal fullføres i en sprint. Under sprintbacklog blir det aldri tildelt arbeid, og teamet melder seg på arbeid på egenhånd. Det eies og administreres av teamet, mens estimert gjenværende arbeid oppdateres daglig. Det er listen over oppgaver som må utføres i Sprint
• Blokkeringsliste: Det er en liste over blokker og ufattede avgjørelser som eies av scrum master og oppdateres daglig
• Nedbrenningsdiagram: Nedbrenningsdiagram representerer den samlede fremdriften for det pågående arbeidet og utført arbeid gjennom hele prosessen. Den representerer i et grafformat historiene og funksjonene som ikke er fullført

3. Seremonier (Prosesser) i Scrum

• Sprint Planlegger: En sprint begynner med at teamet importerer historier fra utgivelsesetterslepet til sprintbackloggen; det arrangeres av scrum master. Testerne anslår innsatsen for å teste de forskjellige historiene i Sprint Etterslep.
• Daglig Scrum: Den arrangeres av scrum master, den varer i omtrent 15 minutter. Under Daily Scrum vil medlemmene diskutere arbeidet som ble fullført dagen før, det planlagte arbeidet for neste dag og problemer som ble møtt under en sprint. Under daglige stand-up-møter spores teamets fremgang.
• Sprint Review/ tilbakeblikk: Det er også arrangert av scrum master, det varer i ca. 2-4 timer og diskuterer hva laget har oppnådd i den siste spurten og hvilke lærdommer som ble tatt.

Rolle som tester i Scrum

Det er ingen aktiv rolle som tester i Scrum Behandle. Vanligvis utføres testing av en utvikler med Unit Test. Mens produkteier også ofte er involvert i testprosessen under hver sprint. Noen Scrum-prosjekter har dedikerte testteam avhengig av prosjektets natur og kompleksitet.

Det neste spørsmålet er, hva tester gjør i en scrum? Følgende notat vil svare

Testing av aktiviteter i Scrum

Testere gjør følgende aktiviteter under de ulike stadiene av Scrum-

Sprint Planlegging

• I sprintplanlegging bør en tester velge en brukerhistorie fra produktreserven som skal testes.
• Som tester bør han/hun bestemme hvor mange timer (Effort Estimation) det skal ta å bli ferdig testing for hver av utvalgte brukerhistorier.
• Som tester må han/hun vite hva sprintmål er.
• Bidra som tester i prioriteringsprosessen

Sprint

• Støtte utviklere i enhetstesting
• Test brukerhistorien når den er fullført. Testutførelse utføres i et laboratorium hvor både tester og utvikler jobber hånd i hånd. Defekten er pålogget Defekthåndteringsverktøy som spores på daglig basis. Mangler kan gis og analyseres under scrum-møtet. Mangler testes på nytt så snart de er det løst og utplassert for testing
• Som tester deltar han/hun på alle daglige standup-møter for å si fra
• Som tester kan han/hun ta med ethvert etterslepelement som ikke kan fullføres i gjeldende sprint og settes til neste sprint
• Tester er ansvarlig for å utvikle automatiseringsskript. Han planlegger automatiseringstesting med System for kontinuerlig integrasjon (CI).. Automatisering får viktigheten på grunn av korte leveringstidslinjer. Testautomatisering kan oppnås ved å bruke forskjellige åpen kildekode eller betalte verktøy tilgjengelig på markedet. Dette viser seg effektivt for å sikre at alt som må testes ble dekket. Tilstrekkelig testdekning kan oppnås med tett kommunikasjon med teamet.
• Revse CI-automatiseringsresultater og send rapporter til interessentene
• Utføre ikke-funksjonell testing for godkjente brukerhistorier
• Koordinere med kunde og produkteier for å definere akseptkriterier for akseptansetester
• På slutten av sprinten utfører testeren også aksepttesting (UAT) i noen tilfeller og bekrefter testfullstendighet for gjeldende sprint

Sprint Retrospective

• Som tester vil han finne ut hva som gikk galt og hva som gikk riktig i den aktuelle spurten
• Som tester identifiserer han lærdom og beste praksis

Testrapportering

Scrum Test-rapportering gir åpenhet og synlighet til interessenter om prosjektet. Beregningene som rapporteres lar et team analysere fremgangen sin og planlegge sin fremtidige strategi for å forbedre produktet. Det er to beregninger som ofte brukes til å rapportere.

Brenn ned diagram: Hver dag registrerer Scrum Master det estimerte gjenværende arbeidet for sprinten. Dette er ingenting annet enn Burn Down Chart. Den oppdateres daglig.

Et nedbrenningsdiagram gir en rask oversikt over fremdriften i prosjektet, dette diagrammet inneholder informasjon som total mengde arbeid i prosjektet som må fullføres, mengde arbeid utført under hver sprint og så videre.

Hastighetshistorikk: Hastighetshistoriegrafen forutsier hastigheten til laget nådd i hver sprint. Det er et søylediagram og representerer hvordan teamets produksjon har endret seg over tid.

De ekstra beregningene som kan være nyttige er tidsplanbrenning, budsjettbrenning, temaprosent fullført, historier fullført – historier gjenstår og så videre.

Dette handler om Scrum i programvareutvikling