is there any start stop boundary qa s role scrum
Kakšna je vloga QA v Scrumu: Scrum aktivnosti za preizkuševalce
Ta članek ni le vadnica o nekaterih procesih ali metodah ali navodila o tem, kako delati kot QA. Namesto tega gre za članek, v katerem želim deliti lastne izkušnje dela kot višji nadzornik kakovosti v SCRUM-u.
Moj prejšnji tehnični direktor je to vedno govoril „S svobodo prihaja tudi odgovornost“. Če vam je dana svoboda, da svoje delo opravljate na svoj način, potem ste vi in samo vi tisti, ki ste odgovorni za svoje delo ali naloge ali dejavnosti.
Za to gre v Scrumu !! Naj vam predstavim osnovno idejo o Scrumu, ko nadaljujemo.
Kaj se boste naučili:
Pregled Scruma
Scrum je podmnožica agilna metodologija in je lahek procesni okvir, ki se pogosto uporablja.
Scrum nam pomaga, da so stranke zadovoljne, saj jim daje izdelke v majhnih modulih, poleg tega pa se zaveda, da lahko njihove pogosto spreminjajoče se zahteve upočasnijo dejavnosti. Izdaje so kratke in dela se upošteva glede na zmogljivost vpletene ekipe, zato se možnosti za okvare ali nesrečne stranke v veliki meri zmanjšajo.
Po drugi strani pa se zahteve (v tem primeru Zgodbe uporabnikov) dokončajo pred zagonom Sprinta, da bi se izognili predelavi, kar povzroči zakasnjen ali neuspešen Sprint (izjeme so vedno tam).
Toda največji izziv za QA je, da je razpon izdaje kratek, Sprint je večinoma 15-dnevni cikel. Dostava izdelka brez napak v največ 4-5 dneh (odvzem časa za razvoj) zahteva veliko truda in pametnega razmišljanja.
Jaz sem QA svoje ekipe:
Oh Ja, sem QA svoje ekipe in sem pomemben igralec svoje ekipe. Zakaj ?? Ker so kupci, BA, Scrum Master in vsi ostali nejasni glede kakovosti, videza in občutka ter učinkovitosti aplikacije ali izdelka.
Ker je sprint kratkotrajen, mora biti QA na pameten način, zato mora biti QA že od samega začetka vključen v 'načrtovanje' zelo pomembno. Včasih lahko QA igra vlogo lastnika posredniškega izdelka, ko naročilnica ni na voljo, s čimer BA pomaga pri ustvarjanju scenarijev / primerov preskusnih meril sprejemljivosti.
Razvijalci pristopijo tudi k preverjanju kakovosti v trenutkih, ko imajo težave s funkcionalnostjo ali poslovnimi pravili. V Scrumu je poudarek le na gladki in uspešni izdaji Sprinta in ne gre za 'Moje delo' ali 'Vaše delo', ki vam pomaga, ko se vaša ekipa obrne po pomoč.
Pri povezovanju ekipe Scrum imajo zdravi odnosi med člani ekipe zelo pomembno vlogo in ker ste QA, bodite zelo previdni, ko posredujete svoje mnenje o uporabniških zgodbah, ki jih preizkušate. Vaša komunikacija mora biti o uporabniški zgodbi ali funkcionalnosti in ne o osebi, ki je delala na njej.
V Scrumu QA ne ocenjujejo in ne cenijo glede na število napak, ki jih odkrije, temveč tudi glede tega, kako sodeluje z ekipo, pomaga ekipi in motivira ekipo tudi v težkih trenutkih.
Poleg preizkušanja sprinterskih nalog poskušate pri pisanju testnih načrtov / testnih primerov / dokumentov o izdaji vključiti tudi več, ker je trajanje izdaje Sprinta kratko in cilj za vse enak 'Za uspešno zagotavljanje delujočega izdelka brez napak z medsebojno pomočjo'.
QA je vključen v skoraj vse dejavnosti, ki se izvajajo v Sprintu, tehnično pa ni meje za začetek ali zaustavitev QA dejavnosti. Za razliko od tradicionalnega modela Waterfall, kjer je QA omejen le na preizkušanje izdaje, ima QA veliko več odgovornosti. Predlagam, da poskusite in naredite več naslednjih dejavnosti.
Dejavnosti, ki jim je treba slediti
Spodaj je nekaj dejavnosti, za katere bi vam predlagal, da jih spremljate kot QA v Scrumu.
kako izbrati izbirni gumb v selenu -
# 1) Zadrževanje globlje:
S tem mislim, da ko bodo zgodbe uporabnikov in njihova merila za sprejem pripravljene, jih temeljito preučite in poglobite razmišljanja o odvisnostih, skritih izidih in če obstaja boljši način za to.
O tem komunicirajte in sodelujte z BA in razvojno skupino, ker se lahko zgodi, da tudi o tem morda niso razmišljali. Delite svoje ideje in ugotovitve z ekipo.
Če ugotovite, da obstajajo skrite ovire ali negativni vplivi, jih bodo vzgojili s Scrum Masterjem in bodo razvijalci imeli čas, da bodo razmišljali in ustrezno ukrepali. Ta aktivnost v Scrumu postane zelo kritična, če je projekt obsežen in ko obstajajo moduli, razporejeni po skupinah.
Zdaj je med preučevanjem odvisnosti vpliv zelo pomemben za preverjanje kakovosti in celo ozavešča razvojno skupino o tem. Če želite to narediti, se pogovorite z vprašanji o kakovosti drugih skupin in od njih pridobite prispevke.
# 2) Vključite se v ocene:
Običajna praksa je, da se v ocene vključi QA, vendar velikokrat zaradi majhnega sprinta QA morda ne bo zahteval ocene za preizkušanje nalog in jim bo ostalo 3/4/5 dni za testiranje.
Nikoli ne sprejmi tega. Če morate, zvišajte svoj glas, vendar se prepričajte, da podajate oceno testiranja, ki mora vključevati čas, ki ga potrebujete za vsako delo.
Lahko vključuje čas za raziskave, čas za nastavitve, čas za zbiranje zgodovinskih podatkov itd., Vendar mora biti strog in natančen glede časa, potrebnega za izvajanje preskusnih dejavnosti, in te časovne vrednosti se dodajo v zgodbo uporabnika skupaj s časom razvojnih nalog .
To je zelo pomembno, ker če poskušate svoje delo opraviti v določenem času in če ne morete dokončati, boste za napako odgovorni samo vi. Ko se doda čas za zagotavljanje kakovosti, bo Scrum Master, PO, seznanjen z zadevnimi dejavnostmi za zagotavljanje kakovosti in potrebnim časom.
# 3) Seznanjanje kakovosti za razvijalce:
Idealno je, da se v Scrumu uporabniške zgodbe Sprint predajo v testiranje po zaključku razvoja in po opravljenem preizkusu razvijalca, vendar je težava v tem, da do predaje QA na testiranje komaj 4-5 dni. na predstavitev ali pregled ostanejo.
Če kot QA ugotovite celo 4 blokatorje ali funkcionalne napake, boste morali delati pozno zvečer ali ob koncu tedna, da boste izpolnili datum izdaje, saj bodo na voljo funkcionalna testiranja, regresije itd. To se zdi kot tradicionalni model slapa, kar ni najbolje, v Scrumu je to najpametneje 'Preprečite napake, namesto da bi jih našli.'
Zato je rešitev, da opravite seznanjanje QA za razvijalce in izvedete osnovni krog testiranja na namestitvi razvijalca, takoj ko so razvijalci pripravljeni na zgodbe še pred uradno objavo za testiranje.
Za izdelavo BVT-ja pri nastavitvi programa za uporabniške zgodbe lahko upoštevamo naslednja merila:
- Merila sprejemljivosti za vsako uporabniško zgodbo: BVT uporabniških zgodb v skladu z merili sprejemljivosti.
- Pomanjkanje zaupanja v razvijalce: Včasih razvijalci niso prepričani o nekaterih izvedbah, zato razpravljajo o takšnih izvedbah in naredijo BVT za tiste, ki imajo isto nastavitev razvijalca.
- Preskušanje odvisnosti / vpliva: BVT odvisnosti ali vpliva na / druge module novih izvedb.
- Enotno testiranje: Naredite BVT z razvijalcem enotnih testov, ki so jih ustvarili, če jim je treba pomagati z dodajanjem ali posodabljanjem enotnih testov.
To bo pomagalo zmanjšati število napak med seboj in prihranilo čas vsakomur, saj je bila pred izdajo QA večina napak, ki se zrušijo, ali funkcionalnih že odpravljena. Te napake ne pozabite zapisati v orodje pred pregledom sprinta in jih premakniti do stanja »zaprto«.
# 4) QA na beli tabli:
Vedno sem osebno spodbujal svojo ekipo, naj na tablo White Scrum vključi naloge za zagotavljanje kakovosti, vključno z napakami. To pomaga Scrum Masterju, da s preprostim pogledom na tablo ugotovi stanje kakovosti uporabniške zgodbe.
Št. napak na seznamu opravkov, napake na seznamu v teku, dejavnosti preverjanja kakovosti na seznamu opravkov, v teku in na seznamu dokončano govorijo same zase. Zdi se mi res boleče, ko pride kdo vprašati o statusu testiranja posameznih zgodb za Sprint, ker moram porabiti dodaten čas, da iz orodja sestavim in pokažem svoj status ali pripravim e-poštno sporočilo.
Preprosto osebo raje usmerim na Scrum Board in jo pustim, da si jo sama izbere. Raje držite svetle barve za lepljive lističe QA.
# 5) Dokumentacija:
To je ena od slabosti ali slabosti Scruma, ker zaradi majhnosti Sprinta ni veliko časa za dokumentacijo in tehničnega pisca nisem nikoli videl v skupini Scrum. Scrum Master / BA morda ne bo in ne bo vedno posodabljal dokumentov o informacijah o izdelku.
Težava nastane, če se pridružijo novi člani ali v najslabšem primeru, če se spremenijo poslovna pravila, funkcionalnosti in kako jim slediti, kajti iskanje po informacijah v uporabniških zgodbah »Končano« bi bilo podobno iskanju igle v kozolcu.
Rešitev je, da v sprintu ustvarite ločeno nalogo, kadar je to mogoče (večinoma v času ohlapnosti ali kadar je delovna obremenitev zelo majhna) za dokumentacijo, tako da lahko dokumente pregledate in posodobite ali naredite, da jih Scrum Master ali BA posodobi.
Služba za zagotavljanje kakovosti je prava oseba, ki pomaga pri posodabljanju dokumentov, ker vi preizkušate, preverjate uporabniške zgodbe in poznate funkcionalnost znotraj in zunaj. Naredite sami, če ni BA in če je vaš Scrum Master zaposlen s posodobitvijo.
# 6) Pregled sprinta / demonstracija sprinta:
Večinoma se zgodi, da je QA tisti, ki je izbran za predstavitev PO in zainteresiranim stranem. če pa ne, prepričajte svojega Scrum Masterja, da to stori. QA je prava oseba, ki bo predstavila predstavitev, saj je preizkusila uporabniško zgodbo znotraj in zunaj.
QA lahko s poslovnega vidika predstavi, ker pozna funkcionalnosti, pretoke in poslovna pravila. Dobro se pripravite na predstavitev in poskusite odgovoriti na vsa vprašanja, ki jih imajo organizacija proizvajalcev in zainteresirane strani. To vam bo pomagalo, da postanete kontaktna točka zanje, če ne bosta Scrum Master in BA.
# 7) Obnašajte se kot BA:
To ni redna naloga, ki je niti ne pričakuje QA, vendar poskusite vstopiti v to vlogo, ko se vam ponudi priložnost, ker je QA najboljša oseba, ki je BA. Poskusite na primer razmisliti in si zamisliti, ali je mogoče tokove, funkcionalnosti ali poslovna pravila spremeniti tako, da bodo koristili kupcu.
Razmislite in poiščite trenutne trende v uporabniškem vmesniku, videz in občutek aplikacije in kako jo je mogoče razglasiti za blaženo, narediti uporabniku prijaznejšo itd. Če se ekipa zatakne pri kakšni težavi, se vključite in poskusite dati preprosto in pametno rešitev. To bo spodbudilo vašo vlogo in bo prispevalo k vaši karierni rasti.
Pri razpisih o težavah ali v pregledu / predstavitvi, kjer lahko dajete predloge, obstaja možnost med klicem s ponudnikom naročil.
Zaključek
Scrum je zelo drugačna metodologija od običajne metode Slap, Scrum Master pa je pospeševalec. Zato ne pričakujte, da vam bo sam določil vaše dejavnosti.
V Scrumu ni meje začetka in konca za vlogo preverjanja kakovosti. QA potrebuje in mora biti vključen v vsako aktivnost že od samega začetka do konca, vse od predhodnega načrtovanja do pregleda / predstavitve sprinta in mora sodelovati pri vseh aktivnostih.
To bo pomagalo razumeti izdelek ali aplikacijo, saj (kot sem že povedal) pri delu v Scrumu ni na voljo ustrezne dokumentacije. Od vas se pričakuje, da ste odgovorni, motivirani in proaktivni. Zato ne čakajte, da kdo pride in vam pove, kaj ali kako naj bi počeli.
Pobude bi morali prevzeti sami, pomagati ekipi na vse možne načine, ohranjati zdrave odnose, spremljati tekoče stvari v ekipi in kar je najpomembneje, biti jasni glede svojih nalog v danem sprintu.
Tu ni upraviteljev, ki bi vas spremljali ali spremljali vaše dejavnosti. Vedno bodite pripravljeni, da pomagate svoji ekipi in izkoristili boste najboljše priložnosti.
V spodnjem oddelku za komentarje lahko izrazite svoje misli / predloge glede tega informativnega članka.
Priporočeno branje
- Vloga poslovnih analitikov v SCRUM-u in zakaj je QA najboljši za to vlogo?
- Spletni kviz Agile Scrum: preizkusite svoje znanje Agile Scrum
- Namestite svojo aplikacijo v napravo in začnite testirati iz Eclipse
- Kanban vs Scrum vs Agile: podrobna primerjava za iskanje razlik
- Kako v kratkem času uporabiti funkcije programske opreme visoke vrednosti s pomočjo Agile Scrum procesa
- Agile Manifesto: Razumevanje okretnih vrednot in načel
- Triaging napak v Scrumu: kako je organiziran v Scrum Setup
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)