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 til å fokusere på alle aspekter av programvareproduktutviklingen som kvalitet, ytelse, brukervennlighet og så videre. Det gir gjennomsiktighet, inspeksjon og tilpasning under programvareutviklingen for å unngå kompleksitet.
Scrum Testing
Scrum Testing er en test utført i scrummetodikk for å verifisere at programvarekravene er oppfylt. Det innebærer å sjekke ikke-funksjonelle parametere som sikkerhet, brukervennlighet, ytelse osv. Det er ingen aktiv rolle som tester i prosessen, så det blir vanligvis utført av utviklere med Unit Test. Noen ganger er det nødvendig med dedikerte testteam avhengig av prosjektets art og kompleksitet.
I denne veiledningen vil du lære-
- Hva er Scrum?
- Nøkkelfunksjoner i Scrum Methodology
- Roller i Scrum
- Scrum-gjenstander
- Seremonier (prosesser) i Scrum
- Testerens rolle i Scrum
- Testing av aktiviteter i Scrum
- Testrapportering
Nøkkelfunksjoner i Scrum Methodology
Følgende er hovedtrekk ved Scrum-
- Scrum har en kort fast plan for utgivelsessykluser med justerbart omfang kjent som sprints for å imøtekomme raskt skiftende utviklingsbehov. Hver utgivelse kan ha flere sprinter. Hvert Scrum-prosjekt kan ha flere utgivelsessykluser.
- En gjentatt sekvens av møter, arrangementer og milepæler
- En praksis med å teste og implementere nye krav, kjent som historier , for å sikre at noe arbeid slippes klart etter hver sprint
Scrum er basert på følgende 3 søyler-
La oss se på den ene etter den andre
1. Roller i Scrum
Det er tre hovedroller i Scrum Testing - Produkteier, Scrum Master og The Development Team. La oss studere dem i detalj
|
Produkteier |
Scrum Master |
Teamet |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Scrum-gjenstander
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."
- Produktet etterslep: Det er en samling brukerhistorier fanget for et scrum produkt. Produkteieren forbereder og vedlikeholder produktetterslepet. Det prioriteres av produkteieren, og alle kan legge til det med godkjenning fra produkteieren.
- Release Backlog: En release er en tidsramme der antall iterasjoner er fullført. Produkteieren koordinerer med scrum-mesteren for å bestemme hvilke historier som skal målrettes for en utgivelse. Historier i frigjøringsetterslepet er målrettet mot å bli fullført i en utgivelse.
- Sprints: Det er en angitt tidsperiode å fullføre brukerhistoriene, bestemt av produkteier og utviklerteam, vanligvis 2-4 uker.
- Sprint Backlog: Det er et sett med brukerhistorier som skal fullføres i en sprint. Under sprintforsinkelse tildeles aldri arbeid, og teamet registrerer seg på jobb alene. Det eies og administreres av teamet mens estimert gjenværende arbeid oppdateres daglig. Det er listen over oppgaver som må utføres i Sprint
- Blokkeliste: Det er en liste over blokker og ubesvarte avgjørelser som eies av scrum master og oppdateres daglig
- Nedbruddskart: Nedbrentdiagram representerer den totale fremdriften for pågående arbeid og fullført arbeid gjennom hele prosessen. Den representerer i et grafformat historiene og funksjonene som ikke er fullført
3. Seremonier (prosesser) i Scrum
- Sprintplanlegging: En sprint begynner med at teamet importerer historier fra frigjøringsetterslepet til sprintforsvaret; det er vert for scrum master. Testerne estimerer innsatsen for å teste de forskjellige historiene i Sprint Backlog.
- Daily Scrum: Det er vert for scrum master, det varer i omtrent 15 minutter. Under Daily Scrum vil medlemmene diskutere arbeidet som er fullført forrige dag, det planlagte arbeidet for neste dag og spørsmål som møter en sprint. I løpet av daglig stand-up-møte spores teamets fremgang.
- Sprint Review / Retrospective: Det er også vert for scrum master, det varer i 2-4 timer og diskuterer hva teamet har oppnådd i den siste sprinten og hvilke leksjoner som ble lært.
Testerens rolle i Scrum
Det er ingen aktiv rolle som Tester i Scrum- prosessen. Vanligvis blir testingen utført 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 art og kompleksitet .
Det neste spørsmålet er, hva tester gjør i en scrum? Følgende merknad vil svare
Testing av aktiviteter i Scrum
Testere følger aktiviteter i de forskjellige stadiene av Scrum-
Sprintplanlegging
- I sprintplanlegging, bør en tester velge en brukerhistorie fra produktets forsinkelse som skal testes.
- Som tester bør han / hun bestemme hvor mange timer (Effort Estimation) det skal ta å fullføre testingen for hver av de valgte brukerhistoriene.
- Som tester må han / hun vite hva sprintmål er.
- Bidra til prioriteringsprosessen som tester
Sprint
- Støtte utviklere i enhetstesting
- Test brukerhistorien når den er fullført. Testutførelse utføres i et laboratorium der både tester og utvikler jobber hånd i hånd. Defekter blir logget inn i Defect Management-verktøyet som spores daglig. Mangler kan tildeles og analyseres under scrummøtet. Mangler testes på nytt så snart de er løst og distribuert for testing
- Som tester deltar han / hun på hvert daglige standup-møte for å si fra
- Som tester kan han / hun ta med seg et hvilket som helst forsinkelseselement som ikke kan fullføres i gjeldende sprint og settes til neste sprint
- Tester er ansvarlig for å utvikle automatiseringsskript. Han planlegger automatiseringstesting med Continuous Integration (CI) -system. Automatisering får viktigheten på grunn av korte leveringstider. Testautomatisering kan oppnås ved å bruke forskjellige open source eller betalte verktøy som er tilgjengelige i markedet. Dette viser seg å være effektivt for å sikre at alt som trenger å bli testet ble dekket. Tilstrekkelig testdekning kan oppnås med tett kommunikasjon med teamet.
- Gjennomgå CI-automatiseringsresultatene og send rapporter til interessentene
- Utføre ikke-funksjonell testing for godkjente brukerhistorier
- Koordinere med kunde og produkteier for å definere akseptkriterier for aksepttester
- På slutten av sprinten utfører testeren i noen tilfeller også akseptatestesting (UAT) og bekrefter testens fullstendighet for den nåværende sprinten.
Sprint Retrospective
- Som tester vil han finne ut hva som gikk galt og hva som gikk riktig i den nåværende sprinten
- Som tester identifiserer han leksjoner og beste praksis
Testrapportering
Scrum Test-beregninger gir gjennomsiktighet og synlighet for interessenter om prosjektet. Beregningene som rapporteres tillater et team å analysere fremdriften og planlegge sin fremtidige strategi for å forbedre produktet. Det er to beregninger som ofte brukes til å rapportere.
Nedbrent diagram: Hver dag registrerer Scrum Master estimert gjenværende arbeid for sprinten. Dette er ingenting annet enn Burn Down Chart. Den oppdateres daglig.
Et nedbruddskart gir en rask oversikt over prosjektfremdriften, dette diagrammet inneholder informasjon som den totale mengden arbeid i prosjektet som må fullføres, mengden arbeid som er fullført i løpet av hver sprint og så videre.
Hastighetshistorikkgraf: Hastighetshistorikkgrafen forutsier hastigheten til laget som oppnås i hver sprint. Det er et søylediagram og representerer hvordan lagets produksjon har endret seg over tid.
De ekstra beregningene som kan være nyttige er tidsplanforbrenning, budsjettforbrenning, temaprosent fullført, historier fullført - historier som er igjen og så videre.
Har du noen tips eller erfaringer å dele for Scrum Testing? Legg igjen en kommentar nedenfor-