Scrum i softwaretest
Scrum i softwaretest er en metode til opbygning af komplekse softwareapplikationer. Det giver nemme løsninger til udførelse af komplicerede opgaver. Scrum hjælper udviklingsholdet 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 Testing
Scrum Testing er en test udført i scrummetodologi for at kontrollere, at softwareapplikationens krav er opfyldt. Det indebærer kontrol af ikke-funktionelle parametre som sikkerhed, brugervenlighed, ydeevne osv. Der er ingen aktiv rolle som tester i processen, så det udføres normalt af udviklere med Unit Test. Nogle gange er der behov for dedikerede testteam afhængigt af projektets art og kompleksitet.
I denne vejledning lærer du-
- Hvad er Scrum?
- Nøglefunktioner i Scrum Methodology
- Roller i Scrum
- Scrum artefakter
- Ceremonier (processer) i Scrum
- Testerens rolle i Scrum
- Test af aktiviteter i Scrum
- Testrapportering
Nøglefunktioner i Scrum Methodology
Følgende er nøglefunktioner i Scrum-
- Scrum har en kort fast tidsplan for frigivelsescyklusser med justerbart omfang kendt som sprints til at imødekomme hurtigt skiftende udviklingsbehov. Hver udgivelse kunne have flere sprints. Hvert Scrum-projekt kunne have flere frigivelsescyklusser.
- En gentagen 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 frigives klar efter hver sprint
Scrum er baseret på de følgende 3 søjler-
Lad os se på den ene efter den anden
1. Roller i Scrum
Der er tre hovedroller i Scrum Testing - Product Owner, Scrum Master og The Development Team. Lad os studere dem detaljeret
|
Produktejer |
Scrum Master |
Holdet |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Scrum-artefakter
En scrum-proces inkluderer
- Brugerhistorier: De er en kort forklaring af funktionerne i det testede system. Eksempel for forsikringsudbyder er - "Premium kan betales ved hjælp af online-systemet."
- Produktbacklog: Det er en samling brugerhistorier, der er taget til et scrumprodukt. Produktejeren forbereder og vedligeholder produktets efterslæb. Det prioriteres af produktejeren, og alle kan tilføje det med godkendelse fra produktejeren.
- Release Backlog: En release er en tidsramme, hvor antallet af iterationer er afsluttet. Produktejeren koordinerer med scrummasteren for at beslutte, hvilke historier der skal målrettes til en frigivelse. Historier i frigivelsesforsinkelsen er målrettet mod at blive afsluttet i en udgivelse.
- Sprints: Det er en bestemt periode at færdiggøre brugerhistorierne, der besluttes af produktejeren og udviklerteamet, normalt 2-4 uger.
- Sprint Backlog: Det er et sæt brugerhistorier, der skal udfyldes i en sprint. Under sprintforsinkelse tildeles arbejde aldrig, og holdet tilmelder sig arbejde alene. Det ejes og administreres af teamet, mens det estimerede resterende arbejde opdateres dagligt. Det er listen over opgaver, der skal udføres i Sprint
- Blokeringsliste: Det er en liste over blokke og ubesvarede beslutninger, der ejes af scrum master og opdateres dagligt
- Nedbrændingsdiagram: Nedbrændingsdiagram repræsenterer den samlede fremgang for det igangværende arbejde og det afsluttede arbejde gennem hele processen. Det repræsenterer i et grafformat historierne og funktionerne, der ikke er afsluttet
3. Ceremonier (processer) i Scrum
- Sprintplanlægning: En sprint begynder med holdet, der importerer historier fra frigivelsesforsinkelsen til sprintforsinkelsen; det hostes af scrum master. Testerne estimerer indsatsen for at teste de forskellige historier i Sprint Backlog.
- Daily Scrum: Det hostes af scrum master, det varer cirka 15 minutter. Under Daily Scrum vil medlemmerne diskutere det arbejde, der er afsluttet den foregående dag, det planlagte arbejde den næste dag og spørgsmål, der står over for under en sprint. Under det daglige stand-up-møde spores holdets fremskridt.
- Sprint Review / Retrospective: Det hostes også af scrum master, det varer omkring 2-4 timer og diskuterer, hvad holdet har opnået i den sidste sprint, og hvilke erfaringer der er draget.
Testerens rolle i Scrum
Der er ingen aktiv rolle som Tester i Scrum- processen. Normalt udføres test af en udvikler med Unit Test. Mens produktejeren også ofte er involveret i testprocessen under hver sprint. Nogle Scrum-projekter har dedikerede testteam afhængigt af projektets art og kompleksitet .
Det næste spørgsmål er, hvad tester gør i en scrum? Følgende note vil svare
Test af aktiviteter i Scrum
Testere følger aktiviteter i de forskellige faser af Scrum-
Sprintplanlægning
- I sprintplanlægning skal en tester vælge en brugerhistorie fra det produktforsinkelse, der skal testes.
- Som tester skal han / hun beslutte, hvor mange timer (Effort Estimation) det skal tage at afslutte testen for hver af de valgte brugerhistorier.
- Som tester skal han / hun vide, hvad sprintmål er.
- Bidrag som tester til prioriteringsprocessen
Sprint
- Support udviklere i enhedstest
- Test brugerhistorie, 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 værktøjet Defektstyring, der spores dagligt. Fejl kan tildeles og analyseres under scrummødet. Fejl testes igen, så snart den er løst og implementeret 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 udfyldes i den aktuelle sprint og sættes til næste sprint
- Tester er ansvarlig for at udvikle automatiseringsskripter. Han planlægger automatiseringstest med Continuous Integration (CI) system. Automation får vigtigheden 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 holdet.
- Gennemgå CI-automatiseringsresultater, og send rapporter til interessenterne
- Udførelse af ikke-funktionel test for godkendte brugerhistorier
- Koordiner med kunde- og produktejer for at definere acceptkriterier for accepttest
- I slutningen af sprinten udfører testeren i nogle tilfælde også acceptstest (UAT) og bekræfter testens fuldstændighed for den aktuelle sprint
Sprint Retrospective
- Som tester vil han finde ud af, hvad der gik galt, og hvad der gik rigtigt i den nuværende sprint
- Som tester identificerer han lektion og bedste praksis
Testrapportering
Scrum Test-metrics-rapportering giver gennemsigtighed og synlighed for interessenter om projektet. De rapporterede metrics 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.
Nedbrændt diagram: Hver dag registrerer Scrum Master det estimerede resterende arbejde for sprinten. Dette er intet andet end nedbrændingsdiagrammet. Det 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 afsluttes, mængden af arbejde, der er gennemført under hver sprint osv.
Hastighedshistorikgraf: Hastighedshistorikgrafen forudsiger hastigheden på holdet, der nås i hver sprint. Det er et søjlediagram og repræsenterer, hvordan holdets output har ændret sig over tid.
De yderligere metrics, der kan være nyttige, er tidsplanbrænding, budgetforbrænding, temaprocent fuldført, historier afsluttet - historier tilbage og så videre.
Har du nogle tip eller erfaringer, du kan dele til Scrum Testing? Efterlad en kommentar nedenfor-