PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! UnĂ« quhem Julja dhe jam testuese. Vitin e kaluar ju tregova rreth â njĂ« ngjarje qĂ« organizojmĂ« nĂ« kompani pĂ«r tĂ« pastruar backlog-un e gabimeve. Kjo Ă«shtĂ« njĂ« mĂ«nyrĂ« tepĂ«r e efektshme pĂ«r ta zvogĂ«luar atĂ« (nĂ« ekipe tĂ« ndryshme nga 10 deri nĂ« 50%) nĂ« vetĂ«m njĂ« ditĂ«.
Sot dua t'ju tregoj rreth formatit tonĂ« pranveror tĂ« BashkĂ«punimit â BUgHunting (BUH). KĂ«tĂ« herĂ« nuk e rregulluam gabimet e vjetra, por kĂ«rkuam tĂ« rejat dhe ofruam ide pĂ«r veçori. Pas shkrimit ka shumĂ« detaje rreth organizimit tĂ« kĂ«tyre ngjarjeve, rezultatet tona dhe komente nga pjesĂ«marrĂ«sit.
Pas mendimit dhe hartimit të rregullave, dërguam një ftesë në të gjitha kanalet në Slack-in korporativ, në të cilin nuk kishte asnjë kufizim:
Si rezultat, regjistruan rreth 30 persona â si zhvillues ashtu edhe specialistĂ« jo teknikĂ«. Ngjarja zuri njĂ« ditĂ« tĂ« plotĂ« pune, rezervuam njĂ« dhomĂ« tĂ« madhe bisedash, dhe organizuam dreka nĂ« bazĂ« tĂ« kantinĂ«s sĂ« zyrĂ«s.
Pse?
Duket se secila ekip teston funksionalitetin e tij. Përdoruesit na raportojnë për gabime. Pse ta organizojmë një ngjarje të tillë?
QĂ«llimet tona ishin disa.
- Të njohim kolegët me projekte/produkte të ngjashme më afër.
Tani nĂ« kompaninĂ« tonĂ« tĂ« gjithĂ« punojnĂ« nĂ« ekipe tĂ« veçanta â njĂ«si. KĂ«to janĂ« grupe projektuale qĂ« punojnĂ« pĂ«r pjesĂ«n e tyre tĂ« funksionalitetit dhe nuk janĂ« gjithmonĂ« plotĂ«sisht nĂ« dijeni tĂ« asaj qĂ« po ndodh nĂ« projekte tĂ« tjera. - Thjesht tĂ« njohim kolegĂ«t me njĂ«ri-tjetrin.
Kemi pothuajse 800 punonjës në zyrën në Moskë, nuk janë të gjithë kolegët që e dinë njëri-tjetrin personalisht. - Të rrisim aftësinë e gjetjes së defekteve nga zhvilluesit në produktet e tyre.
Tani po promovojmĂ« Testimin Agile dhe po ŰȘۯ۱ÙŰšujem dje pĂ«r kĂ«tĂ« drejtim. - TĂ« angazhojmĂ« nĂ« testim jo vetĂ«m specialistĂ« teknikĂ«.
Përveç departamentit teknik, kemi shumë kolegë të profesionëve të tjerë, të cilëve do t'u pëlqente të dinin më shumë rreth testimit, se si të raportojnë defekte në mënyrë korrekte, në mënyrë që të marrim më pak mesazhe të këtij formati: "Aaaa⊠asgjë nuk funksionon". - Sigurisht, të gjejmë defekte të çuditshme dhe të padukshme.
Do të dëshironim të ndihmonim ekipet me testimin e veçorive të reja dhe të ofronim mundësinë të shohin funksionalitetin e realizuar nga një këndvështrim tjetër.
Realizimi
Dita jonë përbëhej nga disa blloqe:
- brifing;
- Një leksion të shkurtër mbi testimin, ku trajtuam vetëm piketat kryesore (qëllimet dhe parimet e testimit etj.);
- seksioni për 'rregullat e mira' të regjistrimit të defekteve ( parimet janë përshkruar mirë);
- katër seanca testimi për projekte me skenarë të përshkruar në një nivel të lartë; përpara çdo seance kishte një leksion të shkurtër intro mbi projektin dhe ndarjen në grupe;
- një anketë të shkurtër mbi aktivitetin;
- përfundimi.
(Nuk e kemi harruar as pushimin midis seancave dhe drekën).
Rregullat kryesore
- Regjistrimi për aktivitete është individual, që zgjidh problemin e shkarkimit të gjithë ekipit nëse një person vendosi të mos shkojë.
- Ădo seancĂ«, pjesĂ«marrĂ«sit ndĂ«rronin ekipin. Kjo u lejon pjesĂ«marrĂ«sve tĂ« largohen dhe tĂ« vijnĂ« nĂ« çdo kohĂ«, pĂ«r mĂ« tepĂ«r, mund tĂ« njihen me mĂ« shumĂ« njerĂ«z.
- Ekipet çdo dy njerëz para çdo seance formohen në mënyrë rastësore, kështu bëhet më dinamike dhe më e shpejtë.
- Për defektet e regjistruara jepen pikë (nga 3 deri në 10) në varësi të kriticitetit.
- Për dublikatat nuk jepen pikë.
- Defektet duhet të regjistrohen nga anëtarë të ekipit sipas standarteve të brendshme.
- Kërkesat për veçori hapen në një detyrë të veçantë dhe marrin pjesë në një nominim të veçantë.
- Një ekip auditimi kujdeset për respektimin e të gjitha rregullave.
Detaje të tjera
- Fillimisht doja të organizoja një aktivitet "të avancuar" për testimin, por pasi u regjistruan mjaft shumë njerëz nga ekipet jo produktive (SMM, avokatë, PR), u detyrova ta thjeshtoj përmbajtjen dhe të heq rastet e ndërlikuara/profili.
- Për shkak të punës së njësive në Jira në projekte të ndryshme sipas flukseve të tyre, ne e krijuam qëllimisht një projekt të veçantë, ku konfiguram një model për hapjen e gabimeve.
- Për të llogaritur pikët, planifikuam të përdorim një liderbord, i cilin përditësohej përmes webhooks, por diçka shkoi keq dhe në fund duhej të llogariteshin manualisht.
Ădo organizator i aktiviteteve has nĂ« vĂ«shtirĂ«si dhe pĂ«r t'ju bĂ«rĂ« disi mĂ« tĂ« lehtĂ«, do tĂ« pĂ«rshkruaj problemet tona qĂ« mund tĂ« shmangni.
Një nga folësit papritur u sëmur dhe duhej të kërkonim një të ri..
Kisha një fat të jashtëzakonshëm që gjetëm një zëvendës nga ekipi i njëjtë në orën 9 të mëngjesit). Por është më mirë të mos mbështetesh në fat dhe të kesh një rezervë. Ose të jesh vetë i gatshëm të tregosh prezantimin e nevojshëm.
Nuk e patët mundësinë të nxirrni funksionalitetin, duhej të ndryshonit blloket vend..
Për të mos hedhur një bllok të tërë, është më mirë të keni një plan rezervë.
Një pjesë e përdoruesve testues ranë, duhej të krijonim shpejt të rinjtë..
Kontrolloni paraprakisht përdoruesit testues ose shikoni mundësinë për t'i krijuar ata shpejt.
Gati asnjë nga djemtë, për të cilët ishte lehtësuar formati, nuk erdhën..
Nuk duhet të tërhiqni forcërisht askënd. Pranoni.
Ka mundësinë të përcaktoni ashpër formatin e aktivitetit: 'amator'/'i avancuar', ose të përgatisni menjëherë dy variante dhe më pas të vendosni se cili do të zhvillohet.
Momente organizative të dobishme:
- rezervoni sallën e bisedave paraprakisht;
- vendosni tavolat, mos harroni për lidhësit dhe filtrat e energjisë (karikimi i laptopëve/telefona për një ditë të tërë mund të mos mjaftojë);
- automatizoni procesin e llogaritjes së pikëve;
- përgatitni tabelat e klasifikimeve;
- bëni materialet e shpërndarjes me emrat dhe fjalëkalimet e përdoruesve testues, udhëzimin për përdorimin e Jira, skenarët;
- mos harroni një javë para aktivitetit të dërgoni kujtimet, gjithashtu sqaroni se çfarë duhet të merrni me vete (laptopë/dispositive);
- flisni me kolegët për ngjarjen në demo, gjatë drekave, mbi një filxhan kafeje;
- merrni përsipër me devops që të mos bëjnë përditësime ose lançime në atë ditë;
- përgatitni folësit;
- merrni dakord me pronarët e karakteristikave dhe përshkruani më shumë skenare për testim;
- porositni ushqime të shijshme (biskota/konditore) për kafetë;
- mos harroni të flisni për rezultatet e ngjarjes.
Rezultatet
Gjatë një dite të tërë, djemtë arritën të testojnë 4 projekte dhe të regjistronin 192 të dhëna të gabimeve (nga të cilat 134 ishin unike) dhe 7 detyra me kërkesa për karakteristika. Sigurisht, disa nga këto gabime pronarët e projekteve ishin tashmë në dijeni. Por kishte dhe gjetje të papritura.
Të gjithë pjesëmarrësit morën shpërblime të ëmbla.
Dhe fituesit â termos, simbole, hoodies.
ĂfarĂ« doli interesante:
- pjesëmarrësve iu duk si një format i papritur sesione të rrepta, kur koha është e kufizuar dhe nuk mund të humbasim shumë kohë për të menduar;
- mundëm të testojmë versionin desktop, versionin mobile dhe aplikacionet;
- shikuam shumë projekte menjëherë, nuk patëm kohë të mërziteshim;
- u njohëm me kolegë të ndryshëm, shikuam qasjet e tyre në regjistrimin e gabimeve;
- përjetuam të gjithë dhimbjen e testuesve.
ĂfarĂ« mund tĂ« pĂ«rmirĂ«sohet:
- të bëni më pak projekte dhe të rrisni kohën e seancës në 1.5 orë;
- të përgatitni dhurata/suvenire shumë më herët (ndonjëherë miratimi/pagimi zgjat një muaj);
- të relaksoheni dhe të pajtoheni me faktin se diçka do të shkojë ndryshe nga plani dhe do të ketë forca madhore.
Rishikimet
Anna Bystrikova, administratore sistemi: «Bagodelnya është shumë edukative për mua. Mësova procesin e testimit, ndjeva të gjithë "dhimbjen" e testuesve.
Fillimisht, në procesin e testimit, si një përdorues i zakonshëm, kontrolloni pikat kryesore: nëse butoni funksionon, nëse kalon në faqen tjetër, nëse dizajni është në rregull. Por më vonë kupton se duhet të mendosh në mënyrë më jo-standard dhe të provosh "ta thysh" aplikacionin. Puna e testuesve nuk është e lehtë, nuk mjafton thjesht të prekësh çdo gjë në ndërfaqe; duhet të përpiqesh të mendosh jashtë kutisë dhe të jesh shumë i vëmendshëm.
PĂ«rvoja ka qenĂ« vetĂ«m pozitive, edhe tani, pas njĂ« kohe pas ngjarjes, shoh se si po punohet mbi bug-at qĂ« i kam gjetur. ĂshtĂ« e mrekullueshme tĂ« ndihesh pjesĂ« e pĂ«rmirĂ«simit tĂ« produktit ^_^»
Dmitry Seleznyov, zhvillues frontend: «Testimi në modën konkurruese është shumë motivuese për të gjetur më shumë gabime. Më duket se gjithkush duhet të provojë të marrë pjesë në Bughunting. Testimi i kërkimit lejon gjetjen e rasteve që nuk janë përshkruar në planin e testimit. Plus, njerëzit që nuk e njohin projektin mund të japin feedback mbi përdorshmërinë e shërbimit».
Antonina Tatchuk, redaktore e lartĂ«: «MĂ« pĂ«lqeu tĂ« provoj vetĂ«n si tester. Ky Ă«shtĂ« njĂ« stil krejtĂ«sisht ndryshe pune. Ti pĂ«rpiqesh ta dĂ«shtosh sistemin, e jo tĂ« bĂ«sh miqĂ«si me tĂ«. Ne gjithmonĂ« kishim mundĂ«sinĂ« tĂ« pyesnim kolegĂ«t pĂ«r testimin. MĂ« mĂ«sova mĂ« shumĂ« rreth prioritizimit tĂ« gabimeve (pĂ«r shembull, unĂ« isha mĂ«suar tĂ« vĂ«rej gabimet gramatikore nĂ« tekste, por âpeshaâ e njĂ« gabimi tĂ« tillĂ« Ă«shtĂ« shumĂ« e vogĂ«l; dhe anasjelltas, diçka qĂ« mĂ« dukej e parĂ«ndĂ«sishme, pĂ«rfundoi si njĂ« gabim kritik qĂ« u rregullua menjĂ«herĂ«).
Në këtë ngjarje, djemtë dhanë një përmbledhje teorike mbi testimin. Ishte e dobishme për specialistët jo teknikë. Disa ditë më vonë, e kuptova se po shkruaja në mbështetje të një site tjetër sipas formulës "çfarë-ku-kur" dhe po përshkruaja në detaje pritshmëritë e mia nga siti dhe realitetin.
PĂ«rfundimi
Nëse dëshironi të pasuroheni jetën e ekipit, të shihni me një këndvështrim të ri funksionalitetin, organizoni një mini «Hani ushqimin e qenit tuaj», atëherë mund të provoni të organizoni një ngjarje të tillë dhe pastaj mund ta diskutojmë së bashku.
Të gjithëve paqe dhe më pak bug-e!
Burimi: habr.com
