PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! Quhem Yulia dhe jam testuese. Vitin e kaluar ju tregova pĂ«r â njĂ« aktivitet qĂ« organizohet nĂ« kompaninĂ« tonĂ« pĂ«r pastrimin e backlog-ut tĂ« bug-eve. ĂshtĂ« njĂ« mĂ«nyrĂ« krejtĂ«sisht efektive pĂ«r ta ulur ndjeshĂ«m atĂ« (nga 10 deri nĂ« 50% nĂ« ekipe tĂ« ndryshme) brenda vetĂ«m njĂ« dite.
Sot dua tâju tregoj pĂ«r formatin tonĂ« pranveror tĂ« Punishtes sĂ« bug-eve â BUgHunting (BUH). KĂ«tĂ« herĂ« nuk rregulluam bug-et e vjetra, por kĂ«rkuam tĂ« reja dhe propozuam ide pĂ«r veçori. MĂ« poshtĂ« ka shumĂ« detaje pĂ«r organizimin e aktiviteteve tĂ« tilla, rezultatet tona dhe pĂ«rshtypjet e pjesĂ«marrĂ«sve.
Pasi e menduam dhe e dokumentuam rregulloren, dërguam në të gjitha kanalet në Slack-un e kompanisë një ftesë pa asnjë kufizim:
NĂ« fund u regjistruan rreth 30 persona â si zhvillues, ashtu edhe specialistĂ« jo teknikĂ«. PĂ«r aktivitetin u rezervua i gjithĂ« njĂ« ditĂ« pune, u prenotua njĂ« sallĂ« e madhe mbledhjesh, ndĂ«rsa drekat u organizuan pĂ«rmes mensĂ«s sĂ« zyrĂ«s.
PĂ«rse?
Në pamje të parë, çdo ekip teston funksionalitetin e vet. Përdoruesit na raportojnë bug-e. Atëherë pse duhet organizuar fare një aktivitet i tillë?
Kishim disa objektiva.
- Tâi afrojmĂ« mĂ« shumĂ« kolegĂ«t me projektet/produktet pĂ«rkatĂ«se.
Aktualisht nĂ« kompani tĂ« gjithĂ« punojnĂ« nĂ« ekipe tĂ« veçanta â njĂ«si. KĂ«to janĂ« grupe projekti qĂ« zhvillojnĂ« pjesĂ«n e tyre tĂ« funksionalitetit dhe jo gjithmonĂ« janĂ« plotĂ«sisht nĂ« dijeni tĂ« asaj qĂ« ndodh nĂ« projektet e tjera. - Thjesht tâi njohim kolegĂ«t me njĂ«ri-tjetrin.
Në zyrën tonë të Moskës kemi pothuajse 800 punonjës dhe jo të gjithë kolegët e njohin njëri-tjetrin nga fytyra. - Të rrisim aftësinë e zhvilluesve për të gjetur bug-e në produktet e tyre.
Aktualisht po promovojmë Agile Testing dhe po i zhvillojmë kolegët në këtë drejtim. - Të përfshijmë në testim jo vetëm specialistët teknikë.
PĂ«rveç departamentit teknik, kemi shumĂ« kolegĂ« tĂ« profesioneve tĂ« tjera, tĂ« cilĂ«ve donim tâu tregonim mĂ« shumĂ« pĂ«r testimin dhe si tĂ« raportojnĂ« saktĂ« bug-et, nĂ« mĂ«nyrĂ« qĂ« tĂ« marrim mĂ« pak mesazhe tĂ« tipit «Aaaa⊠asgjĂ« nuk funksionon». - Dhe, sigurisht, tĂ« gjejmĂ« bug-e tĂ« ndĂ«rlikuara dhe jo tĂ« dukshme.
Donim tâi ndihmonim ekipet me testimin e veçorive tĂ« reja dhe tĂ« krijonim mundĂ«sinĂ« pĂ«r ta parĂ« funksionalitetin e zbatuar nga njĂ« kĂ«ndvĂ«shtrim tjetĂ«r.
Implementimi
Dita jonë përbëhej nga disa blloqe:
- briefing;
- Një leksion i shkurtër për testimin, ku prekëm vetëm pikat kryesore (qëllimet dhe parimet e testimit etj.);
- një seksion mbi «rregullat e mirësjelljes» gjatë raportimit të bug-eve ( parimet janë shpjeguar mirë);
- katër sesione testimi për projekte me skenarë të përshkruar në nivel të lartë; para çdo sesioni pati një prezantim të shkurtër hyrës për projektin dhe ndarje në ekipe;
- një anketë e shkurtër për aktivitetin;
- përmbledhja e rezultateve.
(Nuk harruam as pushimet mes sesioneve dhe drekën).
Rregullat kryesore
- Regjistrimi për aktivitetet bëhet individualisht, gjë që zgjidh problemin që i gjithë ekipi të tërhiqet nga inercia nëse një person vendos të mos vijë.
- Në çdo sesion pjesëmarrësit ndërrojnë ekipin. Kjo u lejon pjesëmarrësve të largohen dhe të vijnë në çdo kohë, si edhe të njihen me më shumë njerëz.
- Komandat nga dy persona para çdo sesioni formohen në mënyrë të rastësishme, kështu gjithçka bëhet më dinamike dhe më e shpejtë.
- Për bug-et e raportuara jepen pikë (nga 3 deri në 10) në varësi të kriticitetit.
- Për duplikatet nuk jepen pikë.
- Bug-et duhet të raportohen nga një anëtar i ekipit sipas të gjitha standardeve të brendshme.
- Kërkesat për funksionalitete regjistrohen në një detyrë të veçantë dhe marrin pjesë në një kategori më vete.
- Pajtueshmëria me të gjitha rregullat monitorohet nga ekipi i auditimit.
Detaje të tjera
- Fillimisht donim të bënim një aktivitet «të avancuar» për testimin, por meqë u regjistruan mjaft persona nga ekipe jo-produkti (SMM, juristë, PR), na u desh ta thjeshtonim shumë përmbajtjen dhe të hiqnim rastet e ndërlikuara/specializuara.
- Për shkak se njësitë punojnë në Jira në projekte të ndryshme sipas flukseve të tyre, krijuam posaçërisht një projekt të veçantë ku konfiguruam një shabllon për raportimin e bug-eve.
- Për llogaritjen e pikëve planifikuam të përdornim një leaderboard që përditësohej përmes webhooks, por diçka shkoi keq dhe në fund llogaritja u desh të bëhej manualisht.
Kushdo qĂ« organizon aktivitete has pengesa dhe, qĂ« ta keni pak mĂ« tĂ« lehtĂ«, po pĂ«rshkruaj problemet tona qĂ« ju mund tâi shmangni.
Njëri nga folësit u sëmur papritur dhe na u desh të gjenim një tjetër.
Mua më eci jashtëzakonisht shumë që gjeta një zëvendësues nga i njëjti ekip në orën 9 të mëngjesit). Por është më mirë të mos mbështeteni te fati dhe të keni një rezervë. Ose të jeni vetë gati për të mbajtur prezantimin e nevojshëm.
Nuk arritëm ta nxirrnim funksionalitetin, ndaj u desh të ndërronim rendin e blloqeve.
Që të mos hidhni poshtë gjithë bllokun, është më mirë të keni një plan rezervë.
Një pjesë e përdoruesve testues ra, ndaj u desh të krijonim shpejt të rinj.
Kontrolloni paraprakisht pĂ«rdoruesit testues ose sigurohuni qĂ« tâi krijoni shpejt nĂ«se duhet.
Pothuajse askush nga ata për të cilët u thjeshtua formati nuk erdhi.
Nuk ka nevojë të tërhiqni askënd me zor. Pranojeni.
Një mundësi është ta përcaktoni qartë formatin e aktivitetit: «amator»/«i avancuar», ose të përgatisni menjëherë dy variante dhe më pas të vendosni sipas situatës se cilin do të zhvilloni.
Pika të dobishme organizative:
- rezervoni paraprakisht sallën e mbledhjeve;
- vendosni tavolinat, mos harroni zgjatuesit dhe filtrat e rrjetit (karikimi i laptopëve/telefonave për gjithë ditën mund të mos mjaftojë);
- automatizoni procesin e llogaritjes së pikëve;
- përgatisni tabelat e renditjes;
- përgatisni materiale të printuara me loginet dhe fjalëkalimet e përdoruesve testues, udhëzimet për përdorimin e Jira-s, si dhe skenarët;
- mos harroni të dërgoni kujtesa një javë para aktivitetit, dhe tregoni gjithashtu çfarë duhet të marrin me vete (laptopë/pajisje);
- flisni me kolegët për aktivitetin në demo, gjatë drekës, apo teksa pini një kafe;
- merruni vesh me DevOps që atë ditë të mos përditësojnë dhe të mos nxjerrin asgjë në prodhim;
- përgatisni prezantuesit;
- merruni vesh me pronarët e funksionaliteteve dhe përshkruani sa më shumë skenarë për testim;
- porosisni diçka të shijshme (biskota/karamele) për snack-e;
- mos harroni të ndani rezultatet e aktivitetit.
Rezultatet
Gjatë gjithë ditës, ekipi arriti të testojë 4 projekte dhe të raportojë 192 bug-e (nga të cilat 134 unike) si edhe 7 detyra me kërkesa për funksionalitete. Sigurisht, për një pjesë të këtyre bug-eve pronarët e projekteve tashmë ishin në dijeni. Por pati edhe zbulime të papritura.
Të gjithë pjesëmarrësit morën dhurata të ëmbla.
NdĂ«rsa fituesit â termosĂ«, badge dhe hoodie.
ĂfarĂ« doli interesante:
- për pjesëmarrësit ishte i papritur formati i sesioneve intensive, ku koha është e kufizuar dhe nuk mund të shpenzohet shumë kohë për mendim;
- u arrit të testoheshin versioni desktop, versioni mobil dhe aplikacionet;
- u panĂ« menjĂ«herĂ« shumĂ« projekte, nuk pati kohĂ« pĂ«r tâu mĂ«rzitur;
- u njohën me kolegë të ndryshëm dhe panë qasjet e tyre në raportimin e bug-eve;
- e ndien plotësisht gjithë vështirësinë e punës së testuesve.
ĂfarĂ« mund tĂ« pĂ«rmirĂ«sohet:
- të ketë më pak projekte dhe koha e sesionit të zgjatet në 1,5 orë;
- të përgatiten dhuratat/suveniret shumë herët paraprakisht (ndonjëherë miratimi/pagesa zgjatet deri në një muaj);
- të relaksoheni dhe të pranoni se diçka do të shkojë jo sipas planit dhe do të ketë situata force madhore.
Opinione
Anna Bystrikova, administratore sistemi: «PĂ«r mua, Bagodelnya ishte shumĂ« informuese. MĂ«sova procesin e testimit dhe e ndjeva plotĂ«sisht gjithĂ« âdhimbjenâ e testuesve.
NĂ« fillim, gjatĂ« procesit tĂ« testimit, si njĂ« pĂ«rdorues shembullor, kontrollon gjĂ«rat bazĂ«: a klikohet butoni, a tĂ« çon nĂ« faqe, a Ă«shtĂ« prishur layout-i. Por mĂ« vonĂ« kupton se duhet tĂ« mendosh mĂ« jashtĂ« kornizave dhe tĂ« pĂ«rpiqesh ta âthyeshâ aplikacionin. Testuesit kanĂ« njĂ« punĂ« tĂ« vĂ«shtirĂ«; nuk mjafton vetĂ«m tĂ« klikosh nĂ«pĂ«r tĂ« gjithĂ« ndĂ«rfaqen, duhet tĂ« pĂ«rpiqesh tĂ« mendosh nĂ« mĂ«nyrĂ« jo standarde dhe tĂ« jesh jashtĂ«zakonisht i vĂ«mendshĂ«m.
PĂ«rshtypjet mbetĂ«n vetĂ«m pozitive; edhe tani, pas njĂ«farĂ« kohe pas eventit, shoh se si po punohet me bug-et qĂ« gjeta unĂ«. ĂshtĂ« bukur tĂ« ndihesh pjesĂ« e pĂ«rmirĂ«simit tĂ« produktit ^_^».
Dmitry Seleznyov, zhvillues Frontend: «Testimi në regjim garues të motivon shumë të gjesh më shumë bug-e). Mendoj se të gjithë duhet të provojnë të marrin pjesë në Bughunting. Testimi eksplorues të lejon të gjesh ato raste që nuk përshkruhen në planin e testimit. Plus, njerëzit që nuk e njohin projektin mund të japin feedback për lehtësinë e përdorimit të shërbimit».
Antonina Tatchuk, redaktore e lartĂ«: «MĂ« pĂ«lqeu tĂ« provoja veten nĂ« rolin e testueses. ĂshtĂ« njĂ« stil krejt tjetĂ«r pune. PĂ«rpiqesh ta prishĂ«sh sistemin, jo tĂ« bĂ«hesh mik me tĂ«. Ne gjithmonĂ« kishim mundĂ«si tâu bĂ«nim pyetje kolegĂ«ve pĂ«r testimin. MĂ«sova mĂ« shumĂ« pĂ«r prioritizimin e bug-eve (pĂ«r shembull, unĂ« jam mĂ«suar tĂ« vĂ«rej gabime gramatikore nĂ« tekste, por âpeshaâ e njĂ« bug-u tĂ« tillĂ« Ă«shtĂ« shumĂ« e vogĂ«l; dhe anasjelltas, diçka qĂ« mua mâu duk jo shumĂ« e rĂ«ndĂ«sishme, nĂ« fund doli tĂ« ishte njĂ« bug kritik qĂ« u rregullua menjĂ«herĂ«).
NĂ« event, ekipi dha njĂ« pĂ«rmbledhje tĂ« teorisĂ« sĂ« testimit. Kjo ishte e dobishme pĂ«r specialistĂ«t jo teknikĂ«. Dhe disa ditĂ« mĂ« vonĂ« e kapa veten duke i shkruar support-it tĂ« njĂ« faqeje tjetĂ«r sipas formulĂ«s âçfarĂ«-ku-kurâ dhe duke pĂ«rshkruar me hollĂ«si pritshmĂ«ritĂ« e mia nga faqja dhe realitetin».
PĂ«rfundim
NĂ«se doni tâi jepni mĂ« shumĂ« larmi jetĂ«s sĂ« ekipit, tĂ« shihni funksionalitetin me njĂ« sy tĂ« freskĂ«t, tĂ« organizoni njĂ« mini «PĂ«rdorni produktin tuaj vetë», atĂ«herĂ« mund tĂ« provoni tĂ« organizoni njĂ« aktivitet tĂ« tillĂ«, e mĂ« pas mund ta diskutojmĂ« sĂ« bashku.
Të gjithë të mirat dhe sa më pak gabime!
Burimi: habr.com
