Scrum-testmetodevejledning

Scrum i softwaretest

Scrum i softwaretest er en metode til at bygge komplekse softwareapplikationer. Det giver nemme løsninger til at udføre komplicerede opgaver. Scrum hjælper udviklingsteamet med at fokusere på alle aspekter af softwareproduktudviklingen som kvalitet, ydeevne, brugervenlighed og så videre. Det giver gennemsigtighed, inspektion og tilpasning under softwareudviklingen for at undgå kompleksitet.

Scrum test

Scrum test er en test udført i scrum-metodologi for at verificere, at softwareapplikationskravene er opfyldt. Det involverer kontrol af ikke-funktionelle parametre som sikkerhed, brugervenlighed, ydeevne osv. Der er ingen aktiv rolle som tester i processen, så den udføres normalt af udviklere med Unit Test. Nogle gange er der brug for dedikerede testhold afhængigt af projektets art og kompleksitet.

Nøgletræk ved Scrum-metoden

Følgende er nøglefunktioner i Scrum-

Scrum har en kort fast tidsplan for udgivelsescyklusser med justerbart omfang kendt som sprints at imødekomme hurtigt skiftende udviklingsbehov. Hver udgivelse kan have flere sprints. Hvert Scrum-projekt kan have flere udgivelsescyklusser.
En gentagende sekvens af møder, begivenheder og milepæle
En praksis med at teste og implementere nye krav, kendt som historier, for at sikre, at noget arbejde er frigivet klar efter hver sprint

Scrum er baseret på følgende 3 søjler-

Lad os se på én efter én

1. Roller i Scrum

Der er tre hovedroller i Scrum Testing – Product Owner, Scrum Master og The Development Team. Lad os studere dem i detaljer

Product Owner	Scrum Master	Teamet
Han/hun definerer produktets egenskaber.	Han/hun leder holdet og passer på holdets produktivitet	Holdet er normalt omkring 5-9 medlemmer
Produktejer bestemmer udgivelsesdatoen og tilhørende funktioner	Han/hun vedligeholder blokeringslisten og fjerner barrierer i udviklingen	Det inkluderer udviklere, designere og nogle gange testere osv.
De prioriterer funktionerne efter produktets markedsværdi og rentabilitet	Han/hun koordinerer med alle roller og funktioner	Teamet organiserer og planlægger deres arbejde på egen hånd
Han/hun er ansvarlig for produktets rentabilitet	Han/hun beskytter teamet mod eksterne forstyrrelser	Har ret til at gøre alt inden for projektets grænser for at nå sprintmålet
Han/hun kan acceptere eller afvise arbejdsemneresultat	Inviterer til den daglige scrum, sprintgennemgang og planlægningsmøder	Deltag aktivt i daglige ceremonier

2. Scrum-artefakter

En scrum-proces omfatter

Brugerhistorier: De er en kort forklaring af funktionaliteterne i det system, der testes. Eksempel på forsikringsudbyder er - "Premium kan betales ved hjælp af onlinesystemet."
Produkt Backlog: Det er en samling af brugerhistorier, der er fanget til et scrum-produkt. Produktejeren forbereder sig og opretholder produktbacklog. Det prioriteres af produktejeren, og alle kan tilføje det med godkendelse fra produktejeren.
Release Backlog: En udgivelse er en tidsramme, hvor antallet af iterationer er gennemført. Produktejeren koordinerer med scrum masteren for at beslutte, hvilke historier der skal målrettes for en udgivelse. Historier i udgivelsesefterslæbet er målrettet til at blive afsluttet i en udgivelse.
Sprints: Det er en fastlagt periode at færdiggøre brugerhistorierne, bestemt af produktejeren og udviklerteamet, normalt 2-4 ugers tid.
Sprint Efterslæb: Det er et sæt brugerhistorier, der skal gennemføres i en sprint. Under sprint-efterslæb tildeles der aldrig arbejde, og holdet melder sig til arbejde på egen hånd. Det ejes og administreres af teamet, mens det anslåede resterende arbejde opdateres dagligt. Det er listen over opgaver, der skal udføres i Sprint
Blokeringsliste: Det er en liste over blokeringer og ufattede beslutninger, der ejes af scrum master og opdateres dagligt
Nedbrændingsdiagram: Nedbrændingsdiagram repræsenterer det overordnede fremskridt for det igangværende arbejde og det udførte arbejde gennem hele processen. Det repræsenterer i et grafformat de historier og funktioner, der ikke er afsluttet

3. Ceremonier (Processer) i Scrum

Sprint Planlægning: En sprint begynder med, at holdet importerer historier fra udgivelsesefterslæbet til sprintefterslæbet; den er hostet af scrum master. Testerne estimerer indsatsen for at teste de forskellige historier i Sprint Efterslæb.
Daglig Scrum: Det er hostet af scrum master, det varer omkring 15 minutter. I løbet af Daily Scrum vil medlemmerne diskutere det udførte arbejde den foregående dag, det planlagte arbejde for den næste dag og problemer, man står over for under en sprint. Under det daglige stand-up møde følges teamets fremskridt.
Sprint Review/ retrospektiv: Det er også vært for scrum master, det varer omkring 2-4 timer og diskuterer, hvad holdet har præsteret i den sidste sprint, og hvilke erfaringer der blev draget.

Rolle som tester i Scrum

Der er ingen aktiv rolle som tester i Scrum Behandle. Normalt udføres test af en udvikler med Unit Test. Mens produktejer også ofte er involveret i testprocessen under hver sprint. Nogle Scrum-projekter har dedikerede testteams afhængigt af projektets art og kompleksitet.

Det næste spørgsmål er, hvad tester gør i et scrum? Følgende note vil besvare

Testaktiviteter i Scrum

Testere udfører følgende aktiviteter under de forskellige stadier af Scrum-

Sprint Planlægning

I sprintplanlægning bør en tester vælge en brugerhistorie fra produktbacklog, som skal testes.
Som tester bør han/hun bestemme, hvor mange timer (Effort Estimation) det skal tage at færdiggøre test for hver af udvalgte brugerhistorier.
Som tester skal han/hun vide, hvad sprintmål er.
Bidrag som tester til prioriteringsprocessen

Sprint

Support udviklere i enhedstest
Test brugerhistorien, når den er færdig. Testudførelse udføres i et laboratorium, hvor både tester og udvikler arbejder hånd i hånd. Defekt er logget ind Defekthåndteringsværktøj som følges på daglig basis. Defekter kan tildeles og analyseres under scrummødet. Defekter testes igen, så snart det sker løst og indsat til test
Som tester deltager han/hun i alle daglige standup-møder for at tale op
Som tester kan han/hun medbringe ethvert efterslæb, der ikke kan gennemføres i den aktuelle sprint, og sætte til næste sprint
Tester er ansvarlig for udvikling af automatiseringsscripts. Han planlægger automatiseringstest med Continuous Integration (CI) system. Automatisering får betydningen på grund af korte leveringstidslinjer. Testautomatisering kan opnås ved at bruge forskellige open source- eller betalte værktøjer, der er tilgængelige på markedet. Dette viser sig effektivt til at sikre, at alt, hvad der skal testes, blev dækket. Tilstrækkelig testdækning kan opnås med en tæt kommunikation med teamet.
Revse CI-automatiseringsresultater og send rapporter til interessenterne
Udførelse af ikke-funktionel test for godkendte brugerhistorier
Koordinere med kunde og produktejer for at definere acceptkriterier for accepttests
Ved afslutningen af spurten udfører testeren også accepttest (UAT) i nogle tilfælde og bekræfter testens fuldstændighed for den aktuelle sprint

Sprint Tilbagevirkende kraft

Som tester vil han finde ud af, hvad der gik galt, og hvad der gik rigtigt i den aktuelle sprint
Som tester identificerer han erfaringer og bedste praksis

Test rapportering

Scrum Test-metrikrapportering giver gennemsigtighed og synlighed for interessenter om projektet. De målinger, der rapporteres, giver et team mulighed for at analysere deres fremskridt og planlægge deres fremtidige strategi for at forbedre produktet. Der er to målinger, der ofte bruges til at rapportere.

Brænd ned diagram: Hver dag registrerer Scrum Master det estimerede resterende arbejde til spurten. Dette er intet andet end Burn Down Chart. Den opdateres dagligt.

Et nedbrændingsdiagram giver et hurtigt overblik over projektets fremskridt, dette skema indeholder information som den samlede mængde arbejde i projektet, der skal afsluttes, mængden af udført arbejde under hver sprint og så videre.

Hastighedshistoriegraf: Hastighedshistoriegrafen forudsiger hastigheden af holdet nået i hver sprint. Det er et søjlediagram og repræsenterer, hvordan teams output har ændret sig over tid.

De yderligere målinger, der kan være nyttige, er tidsplanbrænding, budgetforbrænding, temaprocent fuldført, historier afsluttet – historier tilbage og så videre.

Det hele handler om Scrum i softwareudvikling

Du kan lide: