is there any start stop boundary qa s role scrum
Care este rolul QA în Scrum: activități Scrum pentru testeri
Acest articol nu este doar un tutorial despre unele procese sau metode sau instrucțiuni despre cum să funcționeze ca un QA. Mai degrabă, acesta este un articol în care vreau să împărtășesc propria mea experiență de a lucra ca senior QA în SCRUM.
CTO-ul meu anterior spunea mereu asta „Cu libertatea vine responsabilitatea”. Dacă ți se oferă libertatea de a-ți face munca în felul tău, atunci tu și numai tu ești responsabil pentru munca, sarcinile sau activitățile tale.
Despre asta este vorba Scrum !! Permiteți-mi să vă dau o idee de bază despre Scrum pe măsură ce continuăm.
Ce veți învăța:
Prezentare generală a Scrum
Scrum este un subset al metodologie agilă și este un cadru de proces ușor care este utilizat pe scară largă.
Scrum ne ajută să menținem clienții fericiți oferindu-le produsul în module mici, de asemenea, îl conștientizează pe client că cerințele lor care se schimbă frecvent pot încetini activitățile. Lansările sunt scurte și se lucrează în funcție de capacitatea echipei implicate, prin urmare șansele de eșecuri sau de clienți nefericiți sunt reduse în mare măsură.
Pe de altă parte, cerințele (în acest caz User Stories) sunt finalizate înainte ca Sprint-ul să înceapă pentru a evita relucrarea și astfel rezultă Sprint întârziat sau eșuat (excepțiile sunt întotdeauna acolo).
Dar cea mai mare provocare pentru un QA este că intervalul de lansare este scurt, un Sprint este în mare parte un ciclu de 15 zile. Prin urmare, livrarea unui produs „gratuit” în maximum 4-5 zile (eliminarea timpului de dezvoltare) necesită multe eforturi și o gândire inteligentă.
Sunt QA-ul echipei mele:
Da, sunt calitatea echipei mele și sunt un jucător important al echipei mele. De ce?? Deoarece clienții, BA-urile, Scrum Master și toți ceilalți sunt neclintiți în ceea ce privește calitatea, aspectul și senzația și performanța aplicației sau a produsului.
În Scrum, deoarece durata sprintului este scurtă, QA trebuie să funcționeze într-un mod inteligent și, prin urmare, nevoia de la QA de a fi implicat chiar de la început „Planificarea” devine foarte importantă. Există momente în care un QA poate juca rolul unui proprietar de produs proxy atunci când PO nu este disponibil, ajutând astfel BA să creeze scenarii / cazuri de testare a criteriilor de acceptare.
De asemenea, dezvoltatorii abordează QA în momentele în care se confruntă cu probleme cu funcționalitatea sau regulile de afaceri. În Scrum, accentul este pus doar pe o lansare Sprint lină și reușită și nu este vorba despre „Munca mea” sau „Munca ta” pentru a da o mână de ajutor atunci când echipa ta se apropie de tine pentru ajutor.
În legătura echipei Scrum, relațiile sănătoase dintre membrii echipei joacă un rol foarte crucial și fiind un QA, ar trebui să fiți foarte atenți în timp ce vă comunicați părerea despre poveștile utilizatorilor pe care le testați. Comunicarea dvs. ar trebui să se refere la povestea sau funcționalitatea utilizatorului și nu la persoana care a lucrat la aceasta.
În Scrum, QA nu este judecat sau apreciat pentru numărul de erori pe care le descoperă, ci și despre modul în care interacționează cu echipa, ajutând echipa și motivând echipa chiar și în momente dificile.
În afară de testarea sarcinilor de sprint, scrierea planurilor de testare / cazurile de testare / documentele de lansare încearcă, de asemenea, să implice mai mult, deoarece durata de lansare a Sprintului este scurtă, iar obiectivul este același pentru toată lumea „Să livreze cu succes un produs care funcționează fără erori, ajutându-se reciproc”
Un QA este implicat în aproape toate activitățile desfășurate într-un Sprint și tehnic nu există limite pentru începerea sau oprirea activităților QA. Spre deosebire de modelul tradițional Waterfall, unde QA este limitat doar la testarea lansării, aici QA are mult mai multe responsabilități. Așadar, aș sugera să încercați și să faceți mai multe dintre următoarele activități.
Activități de urmat
Mai jos sunt câteva activități pe care v-aș sugera să le urmăriți ca un QA în Scrum.
instrument de reparare și optimizare a computerului Windows 10
# 1) Locuiește mai adânc:
Prin aceasta, vreau să spun că, atunci când poveștile utilizatorilor și criteriile lor de acceptare sunt gata, studiați-le cu atenție și gândiți-vă mai profund la dependențe, la rezultatele ascunse și dacă există o modalitate mai bună de a o face.
Comunicați și colaborați cu BA și echipa de dezvoltare despre acest lucru, deoarece se poate întâmpla să nu se fi gândit la acest lucru. Împărtășiți-vă ideile și descoperirile cu echipa.
Dacă descoperiți că există obstacole ascunse sau impacturi negative, atunci ridicarea lor cu Scrum Master și cu cei din programele de dezvoltare le va oferi timp să se gândească și să acționeze în consecință. Această activitate în Scrum devine foarte critică atunci când proiectul este unul la scară largă și când există module răspândite între echipe.
Acum, în timp ce studiați despre dependențe, un impact este foarte important pentru un QA și chiar face echipa de dezvoltare conștientă de același lucru. Pentru a face acest lucru, discutați cu QA-urile celorlalte echipe și luați contribuții de la acestea.
# 2) Implică-te în estimări:
Practica obișnuită este de a implica un QA în estimări, dar de multe ori din cauza sprintului mic, este posibil ca QA să nu fie solicitată estimarea pentru testarea sarcinilor și lăsarea acestora cu 3/4/5 zile pentru testarea lucrărilor.
Nu accepta niciodată acest lucru. Ridicați-vă vocea dacă trebuie, dar asigurați-vă că furnizați estimarea testării, care ar trebui să includă timpul de care aveți nevoie pentru fiecare lucrare.
Poate include timp pentru cercetare, timp pentru configurări, timp pentru colectarea datelor istorice etc., dar să fie strict și specific cu privire la timpul necesar desfășurării activităților de testare și să aibă aceste valori de timp adăugate la povestea utilizatorului împreună cu timpul sarcinilor de dezvoltare .
Acest lucru este foarte important, deoarece dacă încercați să vă faceți munca în timpul alocat și dacă nu puteți finaliza, doar dvs. veți fi responsabil pentru eșec. Când se adaugă timpul QA, Scrum Master, PO va fi conștient de activitățile QA implicate și de timpul necesar.
# 3) Asocierea QA Dev:
În mod ideal, în Scrum, Povestirile utilizatorilor Sprint sunt predate pentru testare după finalizarea dezvoltării și odată ce testarea dev a fost făcută, dar problema aici este că până când este predată QA pentru testarea cu greu 4-5 zile la Demo sau recenzie rămân.
Acum, dacă în calitate de QA descoperiți chiar și 4 blocante sau eșecuri funcționale, va trebui să lucrați noaptea târziu sau în weekend pentru a vă îndeplini data lansării, deoarece vor exista teste funcționale, regresii etc. Acest lucru pare a fi modelul tradițional de cascadă, care nu este cel mai bun mod de a face, în Scrum cel mai inteligent mod este „Preveniți defectele mai degrabă decât să găsiți defecte”.
Prin urmare, soluția este să faceți împerecherea QA-ului dev și să efectuați o rundă de bază de testare pe configurarea dev, de îndată ce dezvoltatorii sunt gata cu poveștile chiar înainte de o lansare formală pentru testare.
Următoarele criterii pot fi luate în considerare pentru a face un BVT pe setarea de dezvoltare pentru poveștile utilizatorului:
- Criterii de acceptare pentru fiecare poveste de utilizator: BVT a poveștilor utilizatorilor în conformitate cu criteriile de acceptare.
- Lipsa de încredere în dezvoltatori: Uneori dezvoltatorii nu au încredere în unele implementări și, prin urmare, discută despre astfel de implementări și fac un BVT pentru cei de pe aceeași configurare pentru dezvoltatori.
- Dependențe / Testarea impactului: BVT a dependențelor sau impactul asupra / celorlalte module ale noilor implementări.
- Testarea unitara: Faceți un BVT cu dezvoltatorul testelor unitare pe care le-au creat, dacă este necesar, ajutați-le adăugând sau actualizând testele unitare.
Acest lucru vă va ajuta să reduceți defectele, să economisiți timpul tuturor, deoarece înainte de lansarea la QA, majoritatea bug-urilor care se blochează sau funcționale sunt deja remediate. Nu uitați să înregistrați aceste defecte în instrumentele dvs. înainte de revizuirea sprintului și să le mutați până la starea „închis”.
# 4) QA în White Board:
Întotdeauna mi-am încurajat personal echipa să includă sarcini QA pe placa White Scrum, inclusiv bug-urile. Acest lucru îl ajută pe Scrum Master să descopere starea QA a unei povești a utilizatorului, uitându-se pur și simplu la tablă.
Nu-ul. de bug-uri din lista De făcut, de bug-uri din lista În curs de desfășurare, activitățile QA din lista De făcut, În curs de realizare și Gata vorbește de la sine. Mi se pare foarte dureros când cineva vine să întrebe despre starea testării poveștilor individuale pentru un Sprint, pentru că trebuie să petrec timp suplimentar pentru a-mi scoate statutul din instrumentele de compilare și pentru a le arăta sau a redacta un e-mail.
Pur și simplu prefer să indic persoana către Scrum Board și să-i las să o facă singură. Preferați o culoare remarcabilă strălucitoare pentru slipurile QA Sticky.
# 5) Documentație:
Acesta este unul dintre dezavantajele sau dezavantajele Scrum că, din cauza dimensiunii reduse a Sprintului, nu există prea mult timp pentru documentare și nu am văzut niciodată un scriitor tehnic într-o echipă Scrum. Scrum Master / BA poate să nu actualizeze și nu întotdeauna documentele despre informațiile despre produs.
Problema apare dacă membrii noi se alătură sau, în cel mai rău caz, dacă regulile de afaceri, funcționalitățile se schimbă și cum să țineți o evidență a acestora, deoarece căutarea în poveștile utilizatorului „Terminat” pentru informații va fi ca și cum ați căuta un ac într-un fân.
Soluția constă în crearea unei sarcini separate într-un sprint ori de câte ori este posibil (mai ales în perioade slabe sau când volumul de lucru este foarte redus) pentru documentare, astfel încât să puteți revizui documentele și să le actualizați sau să le actualizați Scrum Master sau BA.
Un QA este persoana potrivită pentru a ajuta la actualizarea documentelor, deoarece tu ești cel care testează, verifică poveștile utilizatorilor și cunoaște funcționalitatea în interior și în exterior. Faceți-o singur dacă nu există BA și dacă Scrum Master este ocupat să actualizeze.
# 6) Sprint Review / Sprint Demo:
În cea mai mare parte se întâmplă ca QA să fie cel care este ales să dea demo-ul PO și părților interesate. dar dacă nu, convinge-ți Scrum Master să facă acest lucru. Un QA este o persoană potrivită pentru a da demonstrația, deoarece a testat povestea utilizatorului în interior și în afara acestuia.
Un QA poate demonstra din punct de vedere al afacerii deoarece cunoaște funcționalitățile, fluxurile și regulile de afaceri. Pregătește-te bine pentru demonstrație și încearcă să răspunzi la fiecare întrebare pe care OP și părțile interesate o au. Acest lucru vă va ajuta să deveniți punctul de contact pentru ei în absența Scrum Master și BA.
# 7) Acționați ca un BA:
Aceasta nu este o sarcină obișnuită și nici măcar nu se așteaptă de la un QA, dar încercați să intrați în acest rol atunci când există o șansă, deoarece un QA este cea mai bună persoană pentru a fi BA. De exemplu, încercați să vă gândiți și să vizualizați dacă fluxurile, funcționalitățile sau regulile de afaceri pot fi modificate într-un mod care să beneficieze clientul.
Gândiți-vă și căutați tendințele actuale în interfața de utilizare, aspectul și simțul aplicației și modul în care poate fi beatificată, făcută mai ușor de utilizat etc. Dacă echipa este blocată de o problemă, implicați-vă și încercați să oferiți un instrument simplu și inteligent soluţie. Acest lucru va da un impuls rolului tău și va fi un factor care să contribuie la creșterea carierei tale.
Șansele vin în timpul apelurilor cu PO atunci când sunt discutate unele probleme sau în revizuire / demonstrație, unde puteți oferi sugestii.
Concluzie
Scrum este o metodologie foarte diferită de metoda normală Waterfall, iar Scrum Master este un facilitator. Prin urmare, nu vă așteptați ca el / ea să vă definească activitățile.
În Scrum, nu există o limită de început și de sfârșit pentru rolul unui QA. QA are nevoie și trebuie să fie implicat în fiecare activitate chiar de la început până la sfârșit, chiar de la Planificare prealabilă până la revizuirea / demo-ul sprintului și trebuie să participe la toate activitățile.
Acest lucru vă va ajuta să înțelegeți produsul sau aplicația, deoarece (așa cum am spus mai devreme) nu există o documentație adecvată disponibilă atunci când lucrați în Scrum. Vă așteptați să fiți responsabil, motivat și proactiv. Prin urmare, nu așteptați să vină nimeni și să vă spună ce sau cum trebuie să faceți.
Ar trebui să luați inițiative pe cont propriu, să ajutați echipa în toate modurile posibile, să mențineți o relație sănătoasă, să țineți o evidență a lucrurilor în desfășurare în echipă și cel mai important să fiți clar cu privire la sarcinile dvs. într-un sprint dat.
Aici, nu există manageri care să vă monitorizeze sau să țină evidența activităților dvs. Fiți întotdeauna gata cu o mână de ajutor pentru echipa dvs. și veți obține cele mai bune oportunități.
Simțiți-vă liber să vă exprimați gândurile / sugestiile despre acest articol informativ în secțiunea de comentarii de mai jos.
Lectură recomandată
- Rolul analiștilor în afaceri în SCRUM și de ce este un QA cel mai bun pentru acest rol?
- Test online Agile Scrum: testați-vă cunoștințele despre Agile Scrum
- Instalarea aplicației pe dispozitiv și începeți testarea de la Eclipse
- Kanban vs Scrum vs Agile: o comparație detaliată pentru a găsi diferențe
- Cum să livrați funcții software de înaltă valoare într-o perioadă scurtă de timp, utilizând procesul Agile Scrum
- Manifest Agile: Înțelegerea valorilor și principiilor Agile
- Defect Triaging în Scrum: Cum este organizat într-o configurare Scrum
- Cele mai bune instrumente de testare software 2021 [Instrumente de automatizare a testelor de calitate]