is there any start stop boundary qa s role scrum
Hva er QAs rolle i Scrum: Scrum-aktiviteter for testerne
Denne artikkelen er ikke bare en veiledning om noen prosesser eller metoder eller instruksjoner om hvordan du fungerer som en kvalitetssikring. Snarere er dette en artikkel der jeg vil dele min egen erfaring med å jobbe som Senior QA i SCRUM.
Min tidligere CTO pleide alltid å si det ‘Med frihet kommer ansvar '. Hvis du får friheten til å gjøre arbeidet ditt på din måte, er det bare du som er ansvarlig for arbeidet ditt eller oppgavene eller aktivitetene dine.
Dette er hva Scrum handler om !! La meg gi deg en grunnleggende ide om Scrum når vi fortsetter videre.
Hva du vil lære:
Oversikt over Scrum
Scrum er en delmengde av smidig metodikk og er et lett prosessrammeverk som brukes mye.
Scrum hjelper oss med å holde kundene fornøyde ved å gi dem produktet i små moduler, det holder også kunden oppmerksom på at deres ofte skiftende krav kan redusere aktivitetene. Utgivelsene er korte og arbeidet blir tatt i henhold til kapasiteten til teamet som er involvert, og sjansene for feil eller ulykkelige kunder reduseres i stor grad.
På den annen side blir kravene (i dette tilfellet User Stories) ferdigstilt før Sprint starter for å unngå omarbeid, og dermed resulterer det i forsinket eller mislykket Sprint (unntak er alltid der).
Men den største utfordringen for en kvalitetssikring er at utgivelsesspennet er kort, en Sprint er stort sett en 15-dagers syklus. Derfor krever det mye innsats og smart tenking å levere et feilfritt produkt på maksimalt 4-5 dager (tar ut utviklingstiden).
Jeg er kvalitetssikring i teamet mitt:
Oh Ja, jeg er teamets kvalitetssikring og jeg er en viktig spiller i laget mitt. Hvorfor?? Fordi kundene, BA-ene, Scrum Master og alle andre er uklare om kvaliteten, utseendet og ytelsen til applikasjonen eller produktet.
I Scrum, da sprintvarigheten er kort, må QA utføre på en smart måte, og derfor blir behovet fra QA for å være involvert helt fra begynnelsen ‘Planning’ veldig viktig. Det er tider når en kvalitetssikring kan spille rollen som en proxyprodukteier når PO ikke er tilgjengelig, og dermed hjelpe BA med å lage akseptkriteriene testscenarier / tilfeller.
Utviklerne nærmer seg også QA til tider når de møter problemer med funksjonaliteten eller forretningsreglene. I Scrum er fokuset bare å ha en jevn og vellykket Sprint-utgivelse, og det handler ikke om 'Mitt arbeid' eller 'Ditt arbeid' for å gi en hjelpende hånd når teamet ditt nærmer deg for å få hjelp.
I Scrum team bonding spiller sunne forhold mellom teammedlemmene en veldig viktig rolle og å være en kvalitetssikring, bør du være veldig forsiktig når du kommuniserer din mening om brukerhistoriene du tester. Kommunikasjonen din skal handle om brukerhistorien eller funksjonaliteten og ikke om personen som jobbet med den.
I Scrum blir ikke QA bedømt eller verdsatt for antall feil han / hun oppdager, men også om hvordan han / hun samhandler med laget, hjelper teamet og motiverer laget selv i vanskelige tider.
Bortsett fra å teste sprintoppgavene, prøver å skrive testplaner / testtilfeller / utgivelsesdokumenter også å involvere mer fordi sprintvarigheten til Sprint er kort og målet er det samme for alle “Å levere et fungerende feilfritt produkt med suksess ved å hjelpe hverandre”.
En kvalitetssikring er involvert i nesten alle aktivitetene som utføres i en Sprint, og teknisk sett er det ingen grense for start eller stopp av kvalitetsaktiviteter. I motsetning til den tradisjonelle Waterfall-modellen der QA bare er begrenset til å teste utgivelsen, har QA her mye mer ansvar. Så jeg vil foreslå å prøve å gjøre flere av følgende aktiviteter.
Aktiviteter som skal følges
Nedenfor er det få aktiviteter som jeg vil foreslå at du følger som kvalitetssikring i Scrum.
etl testing intervju spørsmål og svar for erfaren pdf
# 1) Dwell Deeper:
Med dette mener jeg at når brukerhistoriene og deres akseptkriterier er klare, studer dem grundig og tenk dypere om avhengighetene, skjulte resultater og om det er en bedre måte å gjøre det på.
Kommuniser og samarbeid med BA og utviklingsteamet om dette fordi det kan hende at de heller ikke har tenkt på dette. Del dine ideer og funn med teamet.
Hvis du oppdager at det er skjulte hindringer eller negative konsekvenser, vil det å heve dem med Scrum Master og dev-folket gi dem tid til å tenke og handle deretter. Denne aktiviteten i Scrum blir veldig kritisk når prosjektet er i stor skala og når det er moduler fordelt på lagene.
Nå mens du studerer om avhengighet, er en innvirkning veldig viktig for en kvalitetssikring, og den gjør til og med utviklingsteamet oppmerksom på det samme. For å gjøre dette, diskuter med kvalitetssikringene til de andre lagene og ta innspill fra dem.
# 2) Involver In Estimations:
Vanlig praksis er å involvere en kvalitetssikring i beregningene, men mange ganger på grunn av den lille sprinten, kan det hende at kvalitetssikringsselskapet ikke blir bedt om estimering for å teste oppgavene og gi dem 3/4 / 5 dager for testarbeidet.
Aldri godta dette. Løft stemmen din hvis du må, men sørg for at du gir testestimasjonen din som skal inkludere tiden du trenger for hvert arbeid.
Det kan omfatte tid for forskning, tid for oppsett, tid for innsamling av historiske data etc., men vær streng og spesifikk med hensyn til tiden det tar å utføre testaktivitetene, og få disse tidsverdiene lagt til brukerhistorien sammen med utviklingsoppgavene tid .
Dette er veldig viktig, for hvis du prøver å gjøre arbeidet ditt i den tildelte tiden, og hvis du ikke klarer å fullføre, er det bare du som er ansvarlig for feilen. Når QA-tiden er lagt til, vil Scrum Master, PO være oppmerksom på involverte QA-aktiviteter og hvor lang tid det tar.
# 3) Parring av Dev QA:
Ideelt sett, i Scrum, blir Sprint User Stories overlevert for testing etter at utviklingen er fullført, og når dev-testingen er gjort, men problemet her er at når den blir overlevert til QA for testing knapt 4-5 dager til Demo eller anmeldelse forbli.
Hvis du som QA finner ut til og med fire blokkerings- eller funksjonsfeil, må du jobbe sent på kvelden eller i helgen for å møte utgivelsesdatoen, siden det vil være funksjonstesting, regresjoner etc. som skal gjøres. Dette virker som den tradisjonelle fossemodellen som ikke er den beste måten å gjøre, i Scrum er den smarteste måten “Forhindre feil i stedet for å finne feil”.
Derfor er løsningen å gjøre dev QA-paring og utføre en grunnleggende testrunde på dev-oppsettet så snart utviklerne er klare med historiene, selv før en formell utgivelse for testing.
Følgende kriterier kan tas i betraktning for å gjøre en BVT på dev-oppsettet for brukerhistoriene:
- Akseptkriterier for hver brukerhistorie: BVT av brukerhistoriene i samsvar med akseptkriteriene.
- Mangel på tillit til utviklere: Noen ganger er utviklerne ikke sikre på noen implementeringer, og derfor diskuterer de slike implementeringer og gjør en BVT for de som har samme dev-oppsett.
- Avhengighet / påvirkningstest: BVT av avhengighet eller innvirkning på / av de andre modulene i de nye implementeringene.
- Enhetstesting: Gjør en BVT med utvikleren av enhetstestene de har opprettet, om nødvendig hjelp dem ved å legge til eller oppdatere enhetstestene.
Dette vil bidra til å redusere frem og tilbake på feil, og spare alles tid som før utgivelsen til QA, et flertall av de krasjende eller funksjonelle feilene er allerede løst. Husk å logge disse feilene i verktøyene dine før sprintgjennomgangen, og få dem flyttet til “lukket” tilstand.
# 4) QA i White Board:
Jeg har alltid personlig oppmuntret teamet mitt til å inkludere QA-oppgaver på White Scrum-kortet, inkludert feilene også. Dette hjelper Scrum Master til å finne ut QA-statusen til en brukerhistorie ved å bare se på tavlen.
Nei. av bugs i To Do-listen, bugs i In Progress-listen, QA-aktivitetene i To To Do, In Progress og Done-listen taler for seg selv. Jeg synes det er veldig smertefullt når noen kommer og spør om statusen for testing av individuelle historier for en Sprint, fordi jeg må bruke ekstra tid på å ta ut statusen min fra verktøyene som er samlet, og vise dem eller lage en e-post.
Jeg foretrekker rett og slett å peke personen til Scrum Board og la dem gjøre det for seg selv. Foretrekker en lys enestående farge for QA Sticky-glidene.
# 5) Dokumentasjon:
Dette er en av ulempene eller ulempene med Scrum at på grunn av den lille størrelsen på Sprint er det ikke mye tid for dokumentasjon, og jeg har aldri sett en teknisk skribent i et Scrum-team. Scrum Master / BA oppdaterer kanskje ikke alltid dokumentene om produktinformasjonen.
Problemet kommer hvis nye medlemmer blir med eller i verste fall hvis forretningsreglene, funksjonalitetene endres og hvordan man kan holde oversikt over disse fordi det å søke i ‘Ferdig’ brukerhistorier for informasjon vil være som å lete etter en nål i en høystak.
Løsningen er å lage en egen oppgave i en sprint når det er mulig (for det meste i svake tider eller når arbeidsmengden er veldig mindre) for dokumentasjon, slik at du kan se gjennom dokumentene og oppdatere eller få Scrum Master eller BA til å oppdatere dem.
En kvalitetssikring er den rette personen til å hjelpe til med å oppdatere dokumentene fordi det er du som tester, verifiserer brukerhistoriene og kjenner funksjonaliteten inn og ut. Gjør det selv hvis det ikke er BA, og hvis Scrum Master er opptatt med å oppdatere.
# 6) Sprintanmeldelse / Sprintdemo:
For det meste hender det at QA er den som er valgt å gi demoen til PO og interessentene. men hvis ikke overtale Scrum Master til å gjøre det. En kvalitetssikring er en riktig person til å gi demoen ettersom han / hun har testet brukerhistorien ut og inn.
En kvalitetssikring kan demonstrere fra forretningssynspunktet fordi de kjenner funksjonalitetene, strømningene og forretningsreglene. Forbered deg godt på demoen og prøv å svare på hvert spørsmål som PO og interessentene har. Dette vil hjelpe deg å bli kontaktpunktet for dem i fravær av Scrum Master og BA.
# 7) Oppfør deg som en BA:
Dette er ikke en vanlig oppgave og ikke engang forventet av en kvalitetssikring, men prøv å komme i denne rollen når en sjanse blir kastet fordi en kvalitetssikring er den beste personen til å bli en BA. For eksempel, prøv å tenke og visualisere om flyt, funksjonalitet eller forretningsregler kan endres på en måte som vil være til fordel for kunden.
Tenk og søk etter de aktuelle trendene i brukergrensesnittet, se og følg applikasjonen og hvordan den kan bli bedre, gjort mer brukervennlig osv. Hvis teamet sitter fast på noen problemer, kan du involvere deg og prøve å gi en enkel og smart løsning. Dette vil gi deg et løft og vil være en faktor som kan bidra til karriereveksten din.
Sjansene kommer under samtaler med PO når noen problemer blir diskutert eller i gjennomgang / demo der du kan komme med forslag.
Konklusjon
Scrum er en helt annen metode enn den vanlige Waterfall-metoden, og Scrum Master er en tilrettelegger. Derfor må du ikke forvente at han / hun definerer aktivitetene dine for deg.
I Scrum er det ingen start- og sluttgrense for en QAs rolle. QA trenger og må være involvert i enhver aktivitet helt fra begynnelsen til slutten, helt fra forhåndsplanlegging til sprintgjennomgang / demo, og må delta i alle aktivitetene.
Dette vil bidra til å forstå produktet eller applikasjonen ettersom (som jeg sa tidligere) det ikke er noen riktig dokumentasjon tilgjengelig når du arbeider i Scrum. Det forventes at du er ansvarlig, motivert og proaktiv. Derfor må du ikke vente på at noen skal komme og fortelle deg hva eller hvordan du skal gjøre.
Du bør ta initiativ på egen hånd, hjelpe teamet på alle mulige måter, opprettholde et sunt forhold, holde oversikt over de pågående tingene i teamet og viktigst av alt være tydelig med oppgavene dine i en gitt sprint.
Her er det ingen ledere som vil overvåke deg eller holde oversikt over aktivitetene dine. Vær alltid klar med en hjelpende hånd for teamet ditt, så får du det beste ut av mulighetene.
Uttrykk gjerne dine tanker / forslag om denne informative artikkelen i kommentarfeltet nedenfor.
Anbefalt lesing
- Rollen for forretningsanalytikere i SCRUM og hvorfor er en kvalitetssikring best for denne rollen?
- Agile Scrum Online Quiz: Test din kunnskap om Agile Scrum
- Installere applikasjonen din på enheten og start testing fra Eclipse
- Kanban vs Scrum vs Agile: En detaljert sammenligning for å finne forskjeller
- Hvordan levere programvareegenskaper av høy verdi på kort tid ved hjelp av Agile Scrum Process
- Agile Manifesto: Forstå smidige verdier og prinsipper
- Defect Triaging In Scrum: Hvordan er det organisert i et Scrum Setup
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)