Scrum-testmetodevejledning

Scrum i softwaretest

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

Scrum test

Scrum test Er test udført i Scrum-metoden for at verificere, at softwareapplikationens krav er opfyldt. Det involverer kontrol af ikke-funktionelle parametre som sikkerhed, brugervenlighed og ydeevne. Der er ingen aktiv rolle for en tester i processen, så den udføres normalt af udviklere med enhedstests. Nogle gange er der behov for dedikerede testteams afhængigt af projektets art og kompleksitet. Moderne teams koordinerer ofte dette arbejde i Jira, Linear, Azure DevOps, eller Asana.

Nøgletræk ved Scrum-metoden

Følgende er de vigtigste funktioner i Scrum:

• Scrum har en kort, fast tidsplan for releasecyklusser med justerbart omfang, kendt som Sprints, for 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 klar til udgivelse efter hver Sprint.

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

Lad os se på dem én efter én.

1. Roller i Scrum

Der er tre hovedroller i Scrum Testing: Produktejer, Scrum Master og Udviklingsteamet. Lad os studere dem i detaljer.

Product Owner	Scrum Master	Teamet
Han eller hun definerer produktets egenskaber.	Han eller hun leder teamet og tager sig af teamets produktivitet.	Holdet består typisk af 5-9 medlemmer.
Produktejeren bestemmer udgivelsesdatoen og tilhørende funktioner.	Han eller hun vedligeholder blokeringslisten og fjerner barrierer i udviklingen.	Det omfatter udviklere, designere og nogle gange testere.
De prioriterer funktionerne i henhold til produktets markedsværdi og rentabilitet.	Han eller hun koordinerer med alle roller og funktioner.	Teamet organiserer og planlægger selv deres arbejde.
Han eller hun er ansvarlig for produktets rentabilitet.	Han eller hun beskytter holdet mod ydre påvirkninger.	Har ret til at gøre alt inden for projektets rammer for at opfylde Sprint mål.
Han eller hun kan acceptere eller afvise resultater af arbejdselementer.	Inviterer til den daglige Scrum, Sprint Revvisning og planlægning af møder.	Deltager aktivt i daglige ceremonier.

2. Scrum-artefakter

En Scrum-proces omfatter:

• Brugerhistorier: De er en kort forklaring af funktionerne i det system, der testes. Eksempel for en forsikringsudbyder er: "Præmie kan betales via onlinesystemet."
• Produkt Backlog: Det er en samling af brugerhistorier, der er indsamlet for et Scrum-produkt. Produktejeren forbereder sig og vedligeholder Product Backlog. Den prioriteres af Product Owner, og alle kan tilføje til den med godkendelse fra Product Owner. Moderne teams vedligeholder Product Backlog i Jira, Linear, Azure DevOps, eller Asana.
• Release Backlog: En udgivelse er en tidsramme, hvor et antal iterationer gennemføres. Produktejeren koordinerer med Scrum Masteren for at beslutte, hvilke historier der skal målrettes mod en release. Historier i Release Backloggen er målrettet mod at blive færdiggjort i en release.
• Sprints: Det er en fastsat tidsperiode til at færdiggøre brugerhistorierne, som fastsættes af produktejeren og udviklingsteamet, normalt 2-4 uger.
• Sprint Efterslæb: Det er et sæt brugerhistorier, der skal færdiggøres i en Sprint. I løbet af Sprint Bagslæb, arbejde tildeles aldrig, og teamet tilmelder sig selv arbejde. Det ejes og administreres af teamet, mens det estimerede resterende arbejde opdateres dagligt. Det er listen over opgaver, der skal udføres i en Sprint.
• Blokeringsliste: Det er en liste over blokke og uoprettede beslutninger, der ejes af Scrum Masteren og opdateres dagligt.
• Nedbrændingsdiagram: Nedskæringsdiagrammet repræsenterer den samlede status for det igangværende arbejde og det udførte arbejde i løbet af processen. Det repræsenterer i grafformat de historier og funktioner, der ikke er færdiggjort.

3. Ceremonier (Processer) i Scrum

• Sprint Planlægning: A Sprint begynder med, at teamet importerer historier fra Release Backloggen til Sprint Backlog; den hostes af Scrum Masteren. Testere estimerer indsatsen for at teste de forskellige historier i Sprint Efterslæb.
• Daglig stand-up: Også kaldet Daily Scrum, afholdes af Scrum Masteren og varer cirka 15 minutter. Under Daily Stand-up diskuterer medlemmerne det arbejde, der er udført dagen før, det planlagte arbejde for den næste dag og problemer, der er stødt på under en SprintHoldets fremskridt er tracked her.
• Sprint RevUdsigt / Retrospektiv: Det afholdes også af Scrum Masteren, varer cirka 2-4 timer og diskuterer, hvad teamet har opnået i de seneste år. Sprint og hvilke lærdomme blev der lært.

Med etablerede Scrum-roller, artefakter og ceremonier er det vigtigt at afklare præcis, hvor testere passer ind i denne ramme.

Rolle som tester i Scrum

Der er ingen aktiv rolle som tester i Scrum proces. Normalt udføres testning af en udvikler med Unit Tests, mens produktejeren 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 laver en tester i Scrum? Det vil det følgende afsnit besvare.

Testaktiviteter i Scrum

Testere udfører følgende aktiviteter i de forskellige faser af Scrum:

Sprint Planlægning

• In Sprint I forbindelse med planlægningen bør en tester vælge en brugerhistorie fra Product Backloggen, som skal testes.
• Som tester bør han eller hun bestemme, hvor mange timer (indsatsestimat) det skal tage at færdiggøre testning for hver af de udvalgte brugerhistorier.
• Som tester skal han eller hun vide, hvad Sprint målene er.
• Som tester, bidrag til prioriteringsprocessen.

Sprint

• Supporter udviklere i enhedstestning.
• 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. Fejl logges i en Defekthåndteringsværktøj og trackontrolleres dagligt. Defekter kan diskuteres og analyseres under Scrum-mødet. Defekter testes igen, så snart de er løst og implementeret til test. Moderne Scrum-teams bruger typisk Jira, Linear, Azure DevOps, eller Asana for denne arbejdsgang.
• Som tester deltager vedkommende i alle Daily Stand-up-møder for at ytre sig.
• Som tester kan han eller hun medbringe ethvert efterslæb, der ikke kan færdiggøres i den nuværende fase. Sprint og læg den ind i den næste Sprint.
• Testeren er ansvarlig for udviklingenping automatiseringsscripts. Han eller hun planlægger automatiseringstest med en Continuous Integration (CI) systemAutomatisering får betydning på grund af korte leveringstider. 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, er dækket. Tilstrækkelig testdækning kan opnås med tæt kommunikation inden for teamet.
• RevSe resultater af CI-automatisering og send rapporter til interessenterne.
• Udfør ikke-funktionel testning af godkendte brugerhistorier.
• Koordiner med kunden og produktejeren for at definere acceptkriterier for accepttests.
• I slutningen af Sprint, 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 eller hun finde ud af, hvad der gik galt, og hvad der gik godt i den nuværende situation. Sprint.
• Som tester identificerer han eller hun de opnåede erfaringer og bedste praksis.

Når disse testaktiviteter kører hver Sprint, teams er afhængige af klare målinger for at kommunikere fremskridt, og det er her, testrapportering bliver afgørende.

Test rapportering

Rapportering af Scrum-testmålinger giver interessenter gennemsigtighed og synlighed om projektet. De rapporterede målinger giver et team mulighed for at analysere deres fremskridt og planlægge deres fremtidige strategi for at forbedre produktet. Værktøjer som Jira, Linear, Azure DevOps, og Asana genererer automatisk mange af disse rapporter. Der er to målinger, der ofte bruges til rapportering.

Nedbrændingsdiagram: Hver dag registrerer Scrum Masteren det forventede resterende arbejde for SprintDette er burndown-diagrammet, der opdateres dagligt.

Et burndown-diagram giver et hurtigt overblik over projektets fremskridt. Dette diagram indeholder oplysninger som den samlede mængde arbejde i projektet, der skal udføres, mængden af ​​arbejde udført i løbet af hver Sprint, og så videre.

Hastighedshistoriegraf: Hastighedshistorikgrafen forudsiger den hastighed, som holdet når i hver SprintDet er et søjlediagram og repræsenterer, hvordan holdets output har ændret sig over tid.

Yderligere målinger, der kan være nyttige, er tidsplanforbrug, budgetforbrug, temaprocent færdiggjort, færdiggjorte historier, resterende historier og så videre.

Ofte Stillede Spørgsmål