is there any start stop boundary qa s role scrum
Koja je uloga osiguranja osiguranja u Scrumu: Scrum aktivnosti za testere
Ovaj članak nije samo vodič o nekim procesima ili metodama ili uputama o tome kako raditi kao QA. Umjesto toga, ovo je članak u kojem želim podijeliti vlastito iskustvo rada kao viši QA u SCRUM-u.
Moj prethodni tehnički direktor uvijek je to govorio ‘Sa slobodom dolazi i odgovornost’. Ako vam je dana sloboda da svoj posao obavljate na svoj način, onda ste vi i samo vi odgovorni za svoj rad ili zadatke ili aktivnosti.
O ovome se radi u Scrumu !! Dopustite mi da vam dam osnovnu ideju o Scrumu dok nastavljamo dalje.
Što ćete naučiti:
Pregled Scruma
Scrum je podskup agilna metodologija i lagan je procesni okvir koji se široko koristi.
Scrum nam pomaže da kupce učinimo sretnima dajući im proizvod u malim modulima, a također drži kupca svjesnim da njihovi često mijenjajući zahtjevi mogu usporiti aktivnosti. Izdanja su kratka i radi se prema kapacitetu uključenog tima, stoga su šanse za neuspjehe ili nesretne kupce u velikoj mjeri smanjene.
S druge strane, zahtjevi (u ovom slučaju Korisničke priče) finaliziraju se prije nego što Sprint počne kako bi se izbjegla ponovna obrada, što rezultira odgođenim ili neuspjelim Sprintom (iznimke su uvijek tu).
No, najveći izazov za QA je taj što je izdanje kratko, a Sprint je uglavnom 15-dnevni ciklus. Stoga isporuka proizvoda bez grešaka u najviše 4-5 dana (uzimanje vremena za razvoj) zahtijeva puno truda i pametnog razmišljanja.
Ja sam QA svog tima:
O da, ja sam QA svoje momčadi i važan sam igrač svoje momčadi. Zašto?? Budući da su kupci, BA, Scrum Master i svi ostali mutni u pogledu kvalitete, izgleda i osjećaja te izvedbe aplikacije ili proizvoda.
U Scrumu, budući da je trajanje sprinta kratko, QA mora nastupiti na pametan način, pa stoga potreba QA-a da od samog početka bude uključen 'Planiranje' postaje vrlo važna. Postoje slučajevi kada QA može igrati ulogu vlasnika proxy proizvoda kada narudžbenica nije dostupna, pomažući tako BA-u u stvaranju scenarija / slučajeva ispitivanja kriterija prihvaćanja.
Programeri također pristupaju provjeri kvalitete u trenucima kada se suočavaju s problemima s funkcionalnošću ili poslovnim pravilima. U Scrumu je fokus samo na glatkom i uspješnom izdanju Sprinta, a ne radi se o tome da „Moj rad“ ili „Vaš rad“ pruže ruku kada vam se tim obraća za pomoć.
U vezi Scrum tima, zdravi odnosi između članova tima igraju vrlo presudnu ulogu i budući da ste QA, trebali biste biti vrlo oprezni dok priopćavate svoje mišljenje o korisničkim pričama koje testirate. Vaša komunikacija trebala bi se odnositi na korisničku priču ili funkcionalnost, a ne na osobu koja je na tome radila.
U Scrumu se QA ne ocjenjuje niti cijeni zbog broja bugova koje otkrije, ali i zbog toga kako on / ona komunicira s timom, pomaže timu i motivira tim čak iu teškim trenucima.
Osim testiranja zadataka sprinta, pisanje planova ispitivanja / test slučajeva / dokumenata o izdanju također pokušava uključiti više, jer je izdanje Sprinta kratko, a cilj svima jednak „Uspješno isporučiti radni proizvod bez grešaka pomažući jedni drugima“.
QA je uključen u gotovo sve aktivnosti koje se provode u Sprintu, a tehnički ne postoji granica za početak ili zaustavljanje QA aktivnosti. Za razliku od tradicionalnog modela Waterfall gdje je QA ograničen samo na testiranje izdanja, ovdje QA ima puno više odgovornosti. Dakle, predlažem da isprobate i napravite više sljedećih aktivnosti.
Aktivnosti koje treba slijediti
Slijedi nekoliko aktivnosti koje bih vam predložio da slijedite kao QA u Scrumu.
intervju pitanja o testiranju web usluga
# 1) Stanujte dublje:
Pod tim mislim na to da kada su korisničke priče i njihovi kriteriji prihvaćanja temeljito ih proučite i razmislite dublje o ovisnostima, skrivenim ishodima i postoji li bolji način za to.
O tome komunicirajte i surađujte s BA-om i razvojnim timom, jer se može dogoditi da oni možda nisu o tome razmišljali. Podijelite svoje ideje i nalaze s timom.
Ako otkrijete da postoje skrivene zapreke ili negativni utjecaji, podizanje istih pomoću Scrum Master-a i razvojnih ljudi dat će im vremena da razmisle i djeluju u skladu s tim. Ova aktivnost u Scrumu postaje vrlo kritična kada je projekt velikog opsega i kada postoje moduli raspoređeni po timovima.
Dok proučavamo ovisnosti, utjecaj je vrlo važan za osiguranje kvalitete i čak i razvojni tim čini svjesnim istog. Da biste to učinili, razgovarajte s QA-ima ostalih timova i od njih preuzmite podatke.
# 2) Uključite se u procjene:
Uobičajena je praksa uključiti QA u procjene, ali puno puta zbog malog sprinta QA možda neće biti zatražen za procjenu za testiranje zadataka i ostavljanje 3/4/5 dana za rad na testiranju.
Nikad ne prihvaćaj ovo. Podignite glas ako morate, ali pripazite da dajete procjenu testiranja koja bi trebala uključivati vrijeme potrebno za svaki rad.
Može uključivati vrijeme za istraživanje, vrijeme za postavljanje, vrijeme za prikupljanje povijesnih podataka itd., Ali budite strogi i precizni u pogledu vremena potrebnog za provođenje aktivnosti testiranja i dodajte ove vremenske vrijednosti u korisničku priču zajedno s vremenom razvojnih zadataka .
To je vrlo važno jer ako svoj posao pokušate obaviti u predviđenom vremenu i ako ne uspijete dovršiti, samo ćete vi biti odgovorni za neuspjeh. Kad se doda QA vrijeme, Scrum Master, PO će biti svjestan uključenih QA aktivnosti i potrebnog vremena.
# 3) Uparivanje QA za razvoj:
U idealnom slučaju, u Scrumu se Sprint User Stories predaju na testiranje nakon što se razvoj završi i nakon što se izvrši razvojno testiranje, ali problem je ovdje u tome što do trenutka predaje QA-u na testiranje jedva 4-5 dana na demo ili recenziju ostaju.
Sada, ako kao QA otkrijete čak 4 blokatora ili funkcionalne greške, morat ćete raditi kasno navečer ili vikendom kako biste ispunili datum izlaska, jer će biti potrebno funkcionalno testiranje, regresije itd. To se čini kao tradicionalni model vodopada, što nije najbolji način za napraviti, u Scrumu je to najpametniji način 'Spriječite nedostatke, a ne pronalazite nedostatke'.
Stoga je rješenje izvršiti uparivanje QA za razvoj i izvršiti osnovni krug testiranja na postavkama razvojnog programa čim programeri budu spremni za priče čak i prije službenog izdanja za testiranje.
Sljedeći kriteriji mogu se uzeti u obzir za izradu BVT-a na postavkama programa za korisničke priče:
- Kriteriji prihvaćanja za svaku korisničku priču: BVT korisničkih priča u skladu s kriterijima prihvaćanja.
- Nedostatak povjerenja u programere: Ponekad programeri nisu sigurni u neke implementacije i stoga raspravljaju o takvim implementacijama i rade BVT za one na istim postavkama razvojnog programa.
- Ovisnosti / ispitivanje utjecaja: BVT ovisnosti ili utjecaja na / od ostalih modula novih implementacija.
- Jedinstveno testiranje: Napravite BVT s programerom Unit testova koje su stvorili, ako je potrebno pomozite im dodavanjem ili ažuriranjem unit testova.
To će vam pomoći u smanjenju pogrešaka i tamo, uštedjeti svima vrijeme jer je prije puštanja u QA većina otklonjenih ili funkcionalnih grešaka već ispravljena. Ne zaboravite prijaviti te nedostatke u alate prije pregleda sprinta i premjestiti ih do stanja „zatvoreno“.
# 4) QA na Bijeloj ploči:
Uvijek sam osobno poticao svoj tim da na tablu White Scrum uključi zadatke osiguranja kvalitete uključujući i bugove. To pomaže Scrum Masteru da shvati QA status korisničke priče jednostavnim gledanjem ploče.
Ne. grešaka na popisu obveza, grešaka na popisu u tijeku, QA aktivnosti na popisu obveza, u tijeku i na popisu gotovih govore same za sebe. Stvarno mi je bolno kada netko dođe pitati o statusu testiranja pojedinih priča za Sprint, jer moram potrošiti dodatno vrijeme da izvadim svoj status iz alata za kompajliranje i pokažem ih ili izradim e-poštu.
Jednostavno više volim osobu uputiti na Scrum Board i pustiti je da to sama razabere. Dajte prednost sjajnoj izvanrednoj boji za QA Sticky listiće.
# 5) Dokumentacija:
Ovo je jedan od nedostataka ili nedostataka Scruma jer zbog male veličine Sprinta nema puno vremena za dokumentaciju i nikada nisam vidio tehničkog pisca u Scrum timu. Scrum Master / BA možda neće i neće uvijek ažurirati dokumente o informacijama o proizvodu.
Problem dolazi ako se pridruže novi članovi ili u najgorem slučaju ako se promijene poslovna pravila, funkcionalnosti i kako ih pratiti, jer potraga za informacijama u korisničkim pričama 'Gotovo' bit će poput traženja igle u plastu sijena.
Rješenje je da se u sprintu kreira zasebni zadatak kad god je to moguće (uglavnom u labavim vremenima ili kada je radno opterećenje vrlo malo) za dokumentaciju, tako da možete pregledati dokumente i ažurirati ih ili učiniti da ih Scrum Master ili BA ažuriraju.
QA je prava osoba koja će vam pomoći u ažuriranju dokumenata jer ste vi ta koja testira, provjerava korisničke priče i zna funkcionalnost unutar i izvan. Učinite to sami ako nema BA i ako je vaš Scrum Master zauzet ažuriranjem.
# 6) Pregled sprinta / demonstracija sprinta:
Uglavnom se događa da je QA taj koji je odabran za davanje demonstracije PO-u i dionicima. ali ako ne nagovorite svog Scrum Master-a da to učini. QA je prava osoba koja daje demonstraciju jer je testirala korisničku priču unutar i izvan nje.
QA može demonstrirati s poslovnog stajališta jer znaju funkcionalnosti, tijekove i poslovna pravila. Dobro se pripremite za demonstraciju i pokušajte odgovoriti na svako pitanje koje imaju proizvođačka organizacija i dionici. To će vam pomoći da im postanete kontaktna točka u odsustvu Scrum Master-a i BA-a.
# 7) Ponašajte se kao BA:
To nije redovan zadatak, a niti se očekuje od QA-a, ali pokušajte ući u ovu ulogu kad se ukaže šansa jer QA je najbolja osoba koja treba biti BA. Na primjer, pokušajte razmisliti i vizualizirati mogu li se tokovi, funkcionalnosti ili poslovna pravila izmijeniti na način koji će koristiti kupcu.
Razmislite i potražite trenutne trendove u korisničkom sučelju, izgled i dojam aplikacije i kako je možete proglasiti blaženom, učiniti je lakšom za upotrebu itd. Ako je tim zaglavljen u nekom problemu, uključite se i pokušajte dati jednostavan i pametan riješenje. To će dati poticaj vašoj ulozi i bit će čimbenik koji će doprinijeti vašem rastu u karijeri.
Šanse dolaze tijekom poziva s brojem naručilaca kada se raspravlja o nekim problemima ili u pregledu / demonstraciji gdje možete dati prijedloge.
Zaključak
Scrum je vrlo različita metodologija od uobičajene metode vodopada, a Scrum Master je voditelj. Stoga nemojte očekivati da on / ona definira vaše aktivnosti umjesto vas.
U Scrumu nema početne i krajnje granice uloge QA-a. QA treba i mora biti uključen u svaku aktivnost od samog početka do kraja, odmah od predplaniranja pa sve do sprint pregleda / demonstracije i mora sudjelovati u svim aktivnostima.
To će vam pomoći razumjeti proizvod ili aplikaciju jer (kao što sam već rekao) ne postoji odgovarajuća dokumentacija dostupna tijekom rada u Scrumu. Od vas se očekuje da budete odgovorni, motivirani i proaktivni. Stoga nemojte čekati da netko dođe i kaže vam što ili kako biste trebali učiniti.
Trebali biste sami preuzimati inicijative, pomagati timu na svaki mogući način, održavati zdrav odnos, voditi evidenciju o tekućim stvarima u timu i najvažnije biti jasni oko svojih zadataka u danom sprintu.
Ovdje nema menadžera koji će vas nadgledati ili pratiti vaše aktivnosti. Uvijek budite spremni s rukom pomoći za svoj tim i dobit ćete najbolje mogućnosti.
Slobodno iznesite svoje misli / prijedloge o ovom informativnom članku u odjeljku za komentare u nastavku.
Preporučena literatura
- Uloga poslovnih analitičara u SCRUM-u i zašto je QA najbolji za ovu ulogu?
- Internetski kviz Agile Scrum: testirajte svoje znanje o Agile Scrumu
- Instalirajte svoju aplikaciju na uređaj i započnite testiranje iz Eclipsea
- Kanban vs Scrum vs Agile: Detaljna usporedba za pronalaženje razlika
- Kako isporučiti značajke softvera visoke vrijednosti u kratkom vremenskom razdoblju pomoću Agile Scrum procesa
- Agile Manifesto: Razumijevanje agilnih vrijednosti i principa
- Triaging s nedostacima u Scrumu: kako je to organizirano u Scrum programu
- Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)