Scrum-testmetodeopplæring
Thomas Hamilton
⚡ Smart oppsummering
Scrum-testing er en kontinuerlig valideringsmetode innebygd i Sprint sykluser, der utviklere, testere og produkteiere samarbeider for å verifisere funksjonelle og ikke-funksjonelle krav, samtidig som de opprettholder åpenhet, tilpasningsevne og rask levering gjennom hele prosjektets livssyklus.
Scrum i programvaretesting
Scrum i programvaretesting er en metode for å bygge komplekse programvareapplikasjoner. Den gir enkle løsninger for å utføre kompliserte oppgaver. Scrum hjelper utviklingsteamet med å fokusere på alle aspekter av programvareutvikling, inkludert kvalitet, ytelse og brukervennlighet. Den gir åpenhet, inspeksjon og tilpasning under programvareutvikling for å unngå kompleksitet.
Scrum testing
Scrum testing er testing utført i Scrum-metodikk for å bekrefte at kravene til programvaren er oppfylt. Det innebærer å sjekke ikke-funksjonelle parametere som sikkerhet, brukervennlighet og ytelse. Det er ingen aktiv rolle for en tester i prosessen, så den utføres vanligvis av utviklere med enhetstester. Noen ganger er det behov for dedikerte testteam avhengig av prosjektets art og kompleksitet. Moderne team koordinerer ofte dette arbeidet i Jira, Linear, Azure DevOps, eller Asana.
Hovedtrekk ved Scrum-metodikk
Følgende er hovedfunksjonene i Scrum:
- Scrum har en kort, fast tidsplan for utgivelsessykluser med justerbart omfang, kjent som Sprints, for å håndtere raskt skiftende utviklingsbehov. Hver utgivelse kan ha flere Sprints. 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 å sørge for at noe arbeid er klart for utgivelse etter hver Sprint.
Scrum er basert på følgende 3 søyler:
La oss se på dem én etter én.
1. Roller i Scrum
Det er tre hovedroller i Scrum-testing: Produkteier, Scrum Master og utviklingsteam. La oss studere dem i detalj.
| Produkteier | Scrum Master | Teamet |
|---|---|---|
| Han eller hun definerer produktets egenskaper. | Han eller hun leder teamet og ivaretar teamets produktivitet. | Teamet består vanligvis av 5–9 medlemmer. |
| Produkteieren bestemmer utgivelsesdatoen og tilhørende funksjoner. | Han eller hun vedlikeholder blokkeringslisten og fjerner barrierer i utviklingen. | Det inkluderer utviklere, designere og noen ganger testere. |
| De prioriterer funksjonene i henhold til markedsverdi og lønnsomhet for produktet. | Han eller hun koordinerer med alle roller og funksjoner. | Teamet organiserer og planlegger arbeidet sitt på egenhånd. |
| Han eller hun er ansvarlig for produktets lønnsomhet. | Han eller hun beskytter teamet mot ytre påvirkninger. | Har rett til å gjøre alt innenfor prosjektets rammer for å oppfylle Sprint mål. |
| Han eller hun kan godta eller avvise resultater av arbeidselementer. | Inviterer til den daglige Scrum, Sprint Revvisning og planleggingsmøter. | Deltar aktivt i daglige seremonier. |
2. Scrum-artefakter
En Scrum-prosess inkluderer:
- Brukerhistorier: Dette er en kort forklaring av funksjonaliteten til systemet som testes. Eksempel for en forsikringsleverandør er: «Premie kan betales ved hjelp av nettsystemet.»
- Produktbacklog: Det er en samling av brukerhistorier som er fanget for et Scrum-produkt. Produkteieren forbereder seg og vedlikeholder produktbackloggen. Den prioriteres av produkteieren, og alle kan legge til noe i den med godkjenning fra produkteieren. Moderne team vedlikeholder produktbackloggen i Jira, Linear, Azure DevOps, eller Asana.
- Release Backlog: En utgivelse er en tidsramme der en rekke iterasjoner fullføres. Produkteieren koordinerer med Scrum Masteren for å bestemme hvilke historier som skal målrettes for en utgivelse. Historier i utgivelsesbackloggen er målrettet mot å bli fullført i en utgivelse.
- Sprints: Det er en fastsatt tidsperiode for å fullføre brukerhistoriene, bestemt av produkteieren og utviklingsteamet, vanligvis 2–4 uker.
- Sprint Etterslep: Det er et sett med brukerhistorier som skal fullføres i en Sprint. I løpet av Sprint Etterslep, arbeid blir aldri tildelt, og teamet melder seg på arbeid på egenhånd. Det eies og administreres av teamet, mens det estimerte gjenværende arbeidet oppdateres daglig. Det er listen over oppgaver som må utføres i en Sprint.
- Blokkeringsliste: Det er en liste over blokkeringer og ufattelige beslutninger som eies av Scrum Masteren og oppdateres daglig.
- Nedbrenningsdiagram: Nedbrytningsdiagrammet representerer den generelle fremdriften for pågående arbeid og arbeid som er fullført gjennom hele prosessen. Det representerer i et grafformat historiene og funksjonene som ikke er fullført.
3. Seremonier (Prosesser) i Scrum
- Sprint Planlegger: A Sprint begynner med at teamet importerer historier fra utgivelsesbackloggen til Sprint Backlog; den drives av Scrum Masteren. Testere estimerer innsatsen som kreves for å teste de ulike historiene i Sprint Etterslep.
- Daglig stand-up: Også kalt Daily Scrum, arrangeres av Scrum Masteren og varer i omtrent 15 minutter. Under Daily Stand-up diskuterer medlemmene arbeidet som ble fullført dagen før, det planlagte arbeidet for neste dag og problemer som ble møtt under en SprintLagets fremgang er tracked her.
- Sprint Revvisning / Retrospektiv: Den ledes også av Scrum Masteren, varer i omtrent 2–4 timer og diskuterer hva teamet har oppnådd de siste årene. Sprint og hvilke lærdommer som ble lært.
Når Scrum-roller, artefakter og seremonier er etablert, er det viktig å avklare nøyaktig hvor testere passer inn i dette rammeverket.
Rolle som tester i Scrum
Det er ingen aktiv rolle som tester i Scrum prosess. Vanligvis utføres testing av en utvikler med enhetstester, mens produkteieren 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 en tester gjør i Scrum? Den følgende delen vil svare på det.
Testing av aktiviteter i Scrum
Testere utfører følgende aktiviteter i løpet av de ulike stadiene av Scrum:
Sprint Planlegging
- In Sprint I planleggingen bør en tester velge en brukerhistorie fra produktbackloggen som skal testes.
- Som tester bør han eller hun bestemme hvor mange timer (innsatsanslag) det skal ta å bli ferdig testing for hver av de valgte brukerhistoriene.
- Som tester må han eller hun vite hva Sprint målene er.
- Som tester, bidra til prioriteringsprosessen.
Sprint
- Støtte utviklere i enhetstesting.
- Test brukerhistorien når den er ferdig. Testutførelse utføres i et laboratorium hvor både tester og utvikler jobber hånd i hånd. Feil logges i en Defekthåndteringsverktøy og tracdaglig. Defekter kan konfereres og analyseres under Scrum-møtet. Defekter testes på nytt så snart de er løst og distribueres for testing. Moderne Scrum-team bruker vanligvis Jira, Linear, Azure DevOps, eller Asana for denne arbeidsflyten.
- Som tester deltar vedkommende på alle daglige stand-up-møter for å si ifra.
- Som tester kan han eller hun ta med seg ethvert etterslepsprosjekt som ikke kan fullføres i det nåværende Sprint og legg den inn i den neste Sprint.
- Testeren er ansvarlig for utviklingenping automatiseringsskript. Han eller hun planlegger automatiseringstesting med en System for kontinuerlig integrasjon (CI).Automatisering får betydning på grunn av korte leveringstider. Testautomatisering kan oppnås ved å bruke ulike åpen kildekode- eller betalte verktøy som er tilgjengelige på markedet. Dette viser seg å være effektivt for å sikre at alt som må testes er dekket. Tilstrekkelig testdekning kan oppnås med tett kommunikasjon innad i teamet.
- RevVis resultater fra CI-automatisering og send rapporter til interessentene.
- Utfør ikke-funksjonell testing for godkjente brukerhistorier.
- Koordinere med kunden og produkteier for å definere akseptkriterier for aksepttester.
- Ved slutten av den Sprint, testeren utfører også aksepttesting (UAT) i noen tilfeller og bekrefter testingens fullstendighet for den gjeldende Sprint.
Sprint Retrospective
- Som tester vil han eller hun finne ut hva som gikk galt og hva som gikk riktig i den nåværende Sprint.
- Som tester identifiserer han eller hun lærdommer og beste praksis.
Når disse testaktivitetene kjører hver Sprint, team er avhengige av tydelige målinger for å kommunisere fremgang, og det er her testrapportering blir viktig.
Testrapportering
Rapportering av Scrum-testmålinger gir interessenter åpenhet og synlighet om prosjektet. Målingene som rapporteres lar et team analysere fremdriften og planlegge sin fremtidige strategi for å forbedre produktet. Verktøy som Jira, Linear, Azure DevOps, og Asana genererer automatisk mange av disse rapportene. Det er to målinger som ofte brukes til rapportering.
Nedbrenningsdiagram: Hver dag registrerer Scrum Masteren det estimerte gjenværende arbeidet for SprintDette er nedbrenningsdiagrammet, som oppdateres daglig.
Et nedbrytningsdiagram gir en rask oversikt over prosjektets fremdrift. 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.
Hastighetshistorikk: Hastighetshistorikkgrafen forutsier hastigheten som laget når i hver SprintDet er et søylediagram og representerer hvordan teamets resultater har endret seg over tid.
Ytterligere målinger som kan være nyttige er planforbrenning, budsjettforbrenning, temaprosent fullført, historier fullført, historier som gjenstår og så videre.
