is there any start stop boundary qa s role scrum
Hvad er QA's rolle i Scrum: Scrum-aktiviteter for testerne
Denne artikel er ikke kun en tutorial om nogle processer eller metoder eller instruktioner om, hvordan man arbejder som en kvalitetssikring. Dette er snarere en artikel, hvor jeg vil dele min egen erfaring med at arbejde som Senior QA i SCRUM.
Min tidligere CTO plejede altid at sige det 'Med frihed kommer ansvar'. Hvis du får friheden til at udføre dit arbejde på din måde, er det dig og kun dig, der er ansvarlig for dit arbejde eller dine opgaver eller aktiviteter.
Dette er hvad Scrum handler om !! Lad mig give dig en grundlæggende idé om Scrum, når vi går videre.
Hvad du lærer:
Oversigt over Scrum
Scrum er en delmængde af agil metode og er en letvægts procesramme, der bruges bredt.
Scrum hjælper os med at holde kunderne glade ved at give dem produktet i små moduler, det holder også kunden opmærksom på, at deres ofte skiftende krav kan bremse aktiviteterne. Udgivelserne er korte, og arbejdet tages i henhold til kapaciteten hos det involverede team, hvorfor chancerne for fejl eller ulykkelige kunder reduceres i høj grad.
På den anden side er kravene (i dette tilfælde brugerhistorier) færdige inden Sprint starter for at undgå omarbejde, og det resulterer således i forsinket eller mislykket Sprint (undtagelser er altid der).
Men den største udfordring for en QA er, at frigivelsesspændingen er kort, en Sprint er for det meste en 15-dages cyklus. Derfor kræver levering af et 'gratis' produkt i maksimalt 4-5 dage (udtagning af udviklingstid) en masse indsats og smart tænkning.
Jeg er kvalitetsstyrelsen for mit team:
Åh Ja, jeg er mit holds kvalitetssikring, og jeg er en vigtig spiller i mit hold. Hvorfor?? Fordi kunderne, BA'erne, Scrum Master og alle andre er uklare over kvaliteten, look & feel og applikationens eller produktets ydeevne.
I Scrum, da sprintvarigheden er kort, skal QA udføre på en smart måde, og derfor bliver behovet fra QA for at være involveret lige fra begyndelsen 'Planning' meget vigtigt. Der er tidspunkter, hvor en kvalitetssikring kan spille rollen som en proxyproduktindehaver, når PO ikke er tilgængelig, hvilket hjælper BA med at oprette acceptscriterier testscenarier / tilfælde.
Udviklerne nærmer sig også QA til tider, når de står over for problemer med funktionaliteten eller forretningsreglerne. I Scrum er fokus kun på at have en jævn og vellykket Sprint-frigivelse, og det handler ikke om 'Mit arbejde' eller 'Dit arbejde' for at give en hjælpende hånd, når dit team henvender dig til hjælp.
I Scrum-teambinding spiller sunde relationer mellem teammedlemmerne en meget afgørende rolle, og når du er en QA, skal du være meget forsigtig, mens du kommunikerer din mening om de brugerhistorier, du tester. Din kommunikation skal handle om brugerhistorien eller funktionaliteten og ikke om den person, der har arbejdet med den.
I Scrum vurderes eller værdsættes ikke QA for antallet af bugs, han / hun opdager, men også om, hvordan han / hun interagerer med holdet, hjælper teamet og motiverer holdet selv i vanskelige tider.
Bortset fra at teste sprintopgaverne, prøver skrivning af testplaner / testcases / frigivelsesdokumenter også at involvere mere, fordi sprintens varighed er kort og målet er det samme for alle “At levere et fungerende fejlfrit produkt med succes ved at hjælpe hinanden”.
En kvalitetssikring er involveret i næsten alle de aktiviteter, der udføres i en Sprint, og teknisk set er der ingen grænser for start eller stop af kvalitetsaktiviteter. I modsætning til den traditionelle vandfaldsmodel, hvor QA kun er begrænset til at teste frigivelsen, har QA her meget mere ansvar. Så jeg vil foreslå at prøve og udføre flere af følgende aktiviteter.
Aktiviteter, der skal følges
Nedenfor er der få aktiviteter, som jeg vil foreslå, at du følger som en kvalitetssikring i Scrum.
hvordan man åbner et nyt projekt i formørkelse
# 1) Bebo dybere:
Med dette mener jeg, at når brugerhistorierne og deres acceptkriterier er klar, skal du studere dem grundigt og tænke dybere over afhængigheder, skjulte resultater, og om der er en bedre måde at gøre det på.
Kommuniker og samarbejde med BA og udviklingsteamet om dette, fordi det kan ske, at de måske heller ikke har tænkt over dette. Del dine ideer og fund med teamet.
Hvis du finder ud af, at der er skjulte forhindringer eller negative påvirkninger, så vil hæve dem med Scrum Master og dev-folkene give dem tid til at tænke og handle i overensstemmelse hermed. Denne aktivitet i Scrum bliver meget kritisk, når projektet er i stor skala og når der er moduler fordelt på holdene.
Nu mens man studerer om afhængighederne, er en indvirkning meget vigtig for en kvalitetssikring, og det gør endda udviklingsholdet opmærksom på det samme. For at gøre dette skal du diskutere med QA'erne fra de andre hold og tage input fra dem.
# 2) Inddrag i skøn:
Den sædvanlige praksis er at involvere en QA i estimationerne, men mange gange på grund af den lille sprint bliver QA muligvis ikke bedt om estimering til test af opgaverne og efterlader dem med 3/4 / 5 dage til testarbejdet.
Accepter aldrig dette. Løft din stemme, hvis du er nødt til det, men sørg for, at du giver dit testestimat, som skal omfatte den tid, du har brug for til hvert arbejde.
Det kan omfatte tid til forskning, tid til opsætninger, tid til at indsamle historiske data osv., Men være streng og specifik med hensyn til den tid, der kræves til at udføre testaktiviteterne, og få disse tidsværdier tilføjet til brugerhistorien sammen med udviklingsopgaverne tid .
Dette er meget vigtigt, for hvis du forsøger at udføre dit arbejde inden for den tildelte tid, og hvis du ikke er i stand til at fuldføre, er det kun dig, der er ansvarlig for fejlen. Når QA-tiden er tilføjet, vil Scrum Master, PO'en være opmærksom på de involverede QA-aktiviteter og den krævede tid.
# 3) Parring af Dev QA:
Ideelt set i Sprint afleveres Sprint User Stories til test, efter at udviklingen er afsluttet, og når dev-testingen er udført, men problemet her er, at når det er afleveret til QA til test næppe 4-5 dage til Demo eller anmeldelse forblive.
Hvis du som QA finder ud af, at der endda er 4 blokerings- eller funktionssvigt, bliver du nødt til at arbejde sent om aftenen eller i weekenden for at opfylde din udgivelsesdato, da der vil være funktionstest, regressioner osv., Der skal udføres. Dette virker som den traditionelle vandfaldsmodel, som ikke er den bedste måde at gøre, i Scrum er den smarteste måde “Forhindre defekter snarere end at finde defekter”.
Derfor er løsningen at foretage dev QA-parring og udføre en grundlæggende testrunde på dev-opsætningen, så snart udviklerne er klar med historierne, selv før en formel frigivelse til test.
Følgende kriterier kan tages i betragtning for at lave en BVT på dev-opsætningen for brugerhistorierne:
- Acceptkriterier for hver brugerhistorie: BVT af brugerhistorierne i overensstemmelse med acceptkriterierne.
- Manglende tillid til udviklere: Nogle gange er udviklerne ikke sikre på nogle implementeringer, og derfor diskuterer de sådanne implementeringer og laver en BVT for dem, der har samme dev-opsætning.
- Afhængighed / stødtest: BVT af afhængigheder eller indflydelse på / af de andre moduler i de nye implementeringer.
- Enhedstest: Lav en BVT med udvikleren af de enhedstest, de har oprettet, hvis det er nødvendigt, hjælp dem ved at tilføje eller opdatere enhedstestene.
Dette vil hjælpe med at reducere frem og tilbage af fejl, sparer alles tid, som før frigivelsen til QA, et flertal af de nedbrudte eller funktionelle fejl er allerede rettet. Husk at logge disse defekter i dine værktøjer inden sprintanmeldelsen og få dem flyttet til 'lukket' tilstand.
# 4) QA på White Board:
Jeg har altid personligt opfordret mit team til at medtage QA-opgaver på White Scrum-tavlen inklusive bugs også. Dette hjælper Scrum Master med at finde ud af QA-status for en brugerhistorie ved blot at se på tavlen.
Nej. af bugs i To To Do-listen, bugs på In Progress-listen, QA-aktiviteterne i To To Do, In Progress og Done-listen taler for sig selv. Jeg finder det virkelig smertefuldt, når nogen kommer og spørger om status for test af individuelle historier til en Sprint, fordi jeg er nødt til at bruge ekstra tid på at tage min status ud af værktøjets kompilering og vise dem eller udarbejde en e-mail.
Jeg foretrækker simpelthen at pege personen til Scrum Board og lade dem gøre det for sig selv. Foretrækker en lys enestående farve til QA Sticky-glider.
# 5) Dokumentation:
Dette er en af ulemperne ved eller ulemperne ved Scrum, at på grund af den lille størrelse af Sprint er der ikke meget tid til dokumentation, og jeg har aldrig set en teknisk forfatter i et Scrum-team. Scrum Master / BA opdaterer muligvis ikke og ikke altid dokumenterne om produktoplysningerne.
Problemet kommer, hvis nye medlemmer tilmelder sig eller i værste fald, hvis forretningsreglerne, funktionaliteterne ændres, og hvordan man holder styr på disse, fordi søgning i 'Udført' brugerhistorier efter information vil være som at kigge efter en nål i en høstak.
Løsningen er at få en separat opgave oprettet i en sprint, når det er muligt (for det meste i slanke tider, eller når arbejdsbelastningen er meget mindre) til dokumentation, så du kan gennemse dokumenterne og opdatere eller få Scrum Master eller BA til at opdatere dem.
En kvalitetssikring er den rigtige person til at hjælpe med at opdatere dokumenterne, fordi det er dig, der tester, verificerer brugerhistorierne og kender funktionaliteten ind og ud. Gør det selv, hvis der ikke er BA, og hvis din Scrum Master har travlt med at opdatere.
# 6) Sprint Review / Sprint Demo:
For det meste sker det, at QA er den, der vælges til at give demoen til PO og interessenter. men hvis ikke overtale din Scrum Master til at gøre det. En kvalitetssikring er den rigtige person til at give demoen, da han / hun har testet brugerhistorien ind og ud.
En kvalitetssikring kan demonstrere fra forretningssynspunktet, fordi de kender funktionaliteterne, flowene og forretningsreglerne. Forbered dig godt på demoen, og prøv at besvare hvert spørgsmål, som PO og interessenter har. Dette hjælper dig med at blive kontaktpunktet for dem i fravær af Scrum Master og BA.
# 7) Opfør dig som en BA:
Dette er ikke en regelmæssig opgave og forventes ikke engang af en QA, men prøv at komme i denne rolle, når en chance kastes, fordi en QA er den bedste person til at være BA. Prøv for eksempel at tænke og visualisere, om strømme, funktionaliteter eller forretningsregler kan ændres på en måde, der kommer kunden til gode.
Tænk og søg efter de aktuelle tendenser i brugergrænsefladen, look & feel af applikationen, og hvordan den kan beatificeres, gøres mere brugervenlig osv. Hvis teamet sidder fast på et eller andet problem, bliv involveret og prøv at give en enkel og smart opløsning. Dette vil give et løft til din rolle og vil være en faktor, der bidrager til din karrierevækst.
Chancerne kommer under opkald med PO, når nogle problemer diskuteres eller i gennemgang / demo, hvor du kan give forslag.
Konklusion
Scrum er en meget anden metode end den normale Waterfall-metoden, og Scrum Master er en facilitator. Forvent derfor ikke, at han / hende definerer dine aktiviteter for dig.
I Scrum er der ingen start- og slutgrænse for en QA's rolle. QA har brug for og er nødt til at være involveret i enhver aktivitet lige fra starten til slutningen, lige fra Pre-planning til sprint review / demo og skal deltage i alle aktiviteterne.
Dette hjælper med at forstå produktet eller applikationen, da (som jeg sagde før) der ikke er nogen korrekt dokumentation tilgængelig, når du arbejder i Scrum. Det forventes, at du er ansvarlig, motiveret og proaktiv. Vent derfor ikke på, at nogen kommer og fortæller dig, hvad eller hvordan du skal gøre.
Du skal tage initiativer alene, hjælpe holdet på alle mulige måder, opretholde et sundt forhold, holde styr på de igangværende ting i teamet og vigtigst af alt være klar over dine opgaver i en given sprint.
Her er der ingen ledere, der overvåger dig eller holder styr på dine aktiviteter. Vær altid klar med en hjælpende hånd til dit team, så får du det bedste ud af mulighederne.
Du er velkommen til at udtrykke dine tanker / forslag om denne informative artikel i kommentarfeltet nedenfor.
Anbefalet læsning
- Rolle af forretningsanalytikere i SCRUM, og hvorfor er en kvalitetssikring bedst for denne rolle?
- Agile Scrum Online Quiz: Test din viden om Agile Scrum
- Installation af din applikation på enheden og start test fra Eclipse
- Kanban vs Scrum vs Agile: En detaljeret sammenligning for at finde forskelle
- Sådan leveres softwarefunktioner af høj værdi på kort tid ved hjælp af Agile Scrum-processen
- Agilt manifest: Forståelse af smidige værdier og principper
- Defektforsøg i Scrum: Hvordan er det organiseret i en Scrum-opsætning
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)