Acest articol va fi de interes pentru cei care, la fel ca noi, se confruntă cu problema selectării unui specialist potrivit în domeniul testării.
În mod ciudat, odată cu creșterea numărului de companii IT din republica noastră, crește doar numărul programatorilor demni, dar nu și al testatorilor. Mulți oameni sunt dornici să intre în această meserie, dar nu mulți îi înțeleg sensul.
Nu pot vorbi în numele tuturor companiilor IT, dar am atribuit rolul de QA/QC specialiștilor noștri în calitate. Ei fac parte din echipa de dezvoltare și participă la toate etapele de dezvoltare, de la cercetare până la lansarea unei noi versiuni.
Un tester dintr-o echipă, chiar și în etapa de planificare, trebuie să se gândească la toate cerințele funcționale și nefuncționale pentru acceptarea unei povești de utilizator. El trebuie să înțeleagă caracteristicile operaționale ale produsului, precum și programatorii, și chiar mai bine, și să ajute echipa să nu ia decizii greșite chiar și în etapa de planificare. Testerul trebuie să aibă o înțelegere clară a modului în care funcționalitatea implementată va funcționa și ce capcane pot exista. Testerii noștri creează ei înșiși planuri de testare și cazuri de testare, precum și pregătesc toate bancurile de testare necesare. Testarea conform unei specificații gata făcute, cum ar fi un clicker de maimuță, nu este opțiunea noastră. Lucrând în cadrul echipei, el trebuie să ajute la lansarea unui produs demn și să tragă un semnal de alarmă la timp dacă ceva nu merge bine.
Ce am întâlnit când căutăm testeri
La stadiul de studiu a multor CV-uri, părea că există specialiști cu experiență potrivită pentru noi și nu vor fi probleme în alegerea unui tester pentru echipa noastră. Dar, în timpul întâlnirilor personale, am întâlnit din ce în ce mai des candidați care erau de fapt destul de departe de lumea tehnologiei informației (de exemplu, nu puteau spune principiile interacțiunii dintre un browser și un server web, elementele de bază ale securității, relaționale și non-). baze de date relaționale, nu aveau idee despre virtualizare și containerizare), dar, în același timp, s-au evaluat la nivel Senior QA. După desfășurarea a zeci de interviuri, am ajuns la concluzia că numărul specialiștilor potriviti pentru noi în regiune este neglijabil.
În continuare, vă voi spune ce pași am făcut și ce greșeli am pășit pentru a găsi acei luptători mult așteptați pentru calitate.
Cum am încercat să remediam situația
După ce ne-am epuizat cu aprovizionarea cu specialiști gata pregătiți, am început să țintim zonele din apropiere:
- Am încercat să aplicăm practici de evaluare pentru a identifica printre numeroșii oameni „leave it”, tocmai aceia din care putem dezvolta specialiști puternici.
Am cerut unui grup de potențiali candidați cu aproximativ același nivel de cunoștințe să finalizeze sarcini. Observând procesul lor de gândire, am încercat să identificăm cel mai promițător candidat.
În special, am venit cu sarcini pentru a testa atenția, înțelegerea capacităților tehnologiei și a caracteristicilor multiculturalismului:
- Am organizat întâlniri pentru testeri pentru a extinde limitele de înțelegere a profesiei în rândul contingentului existent.
O să vă povestesc puțin despre fiecare dintre ele.
Ufa Software QA and Testing Meetup #1 este prima noastră încercare de a-i aduna pe cei cărora le pasă de profesie și, în același timp, să înțeleagă dacă publicul va fi interesat de ceea ce dorim să le transmitem. Practic, rapoartele noastre au fost despre unde este mai bine să începeți dacă ați decis să deveniți tester. Ajută-i pe începători să deschidă ochii și să privească testele ca un adult. Am vorbit despre pașii pe care trebuie să-i facă testerii începători pentru a se alătura profesiei. Despre ce este calitatea și cum să o atingi în condiții reale. Și, de asemenea, ce este testarea automată și unde este mai potrivit să o folosești.
Apoi, cu un interval de 1-2 luni, am mai ținut două întâlniri. Au fost deja de două ori mai mulți participanți. La „Ufa Software QA and Testing Meetup #2” ne-am afundat mai adânc în domeniul subiectului. Au vorbit despre sistemele de urmărire a erorilor, testarea UI/UX, s-au referit la Docker, Ansible și, de asemenea, au vorbit despre posibilele conflicte între un dezvoltator și un tester și modalități de a le rezolva.A treia noastră întâlnire, „Ufa Software QA and Testing Meetup #3”, a fost indirect legată de munca testatorilor, dar a fost utilă pentru a le aminti programatorilor în timp util sarcinile lor tehnice și organizaționale: testare de încărcare, testare e2e, Selenium în autotestare, vulnerabilități ale aplicațiilor web .
În tot acest timp am învățat cum să creăm lumină și sunet normale în emisiunile de la evenimentele noastre:
→
→
→ - Și până la urmă am decis să încercăm să organizăm un hackathon pentru testeri
Cum am pregătit și am organizat un hackathon pentru testeri
Pentru început, am încercat să înțelegem ce fel de „fiară” este aceasta și cum se desfășoară de obicei. După cum s-a dovedit, evenimente de acest fel nu au avut loc de multe ori în Federația Rusă și nu există de unde să împrumuți idei. În al doilea rând, nu am vrut să investesc imediat multe resurse într-un eveniment care părea dubios la prima vedere. Prin urmare, am decis că vom face mini-hackathon-uri scurte, nu pentru întreg ciclul de lucru QA, ci pentru etape individuale.
Principala noastră durere de cap este lipsa de practică în rândul testatorilor locali în a crea hărți clare de testare. Ei nu petrec timp cercetând poveștile utilizatorilor înainte de implementare și creând criterii de acceptare care sunt clare pentru dezvoltatori pentru cerințe funcționale și nefuncționale, UI/UX, securitate, încărcături de lucru și sarcini de vârf. Prin urmare, am decis, pentru prima dată, să trecem prin partea cea mai interesantă și creativă a muncii lor - analiza și formarea cerințelor în timpul cercetării pre-proiect.
Am estimat numărul potențial de participanți și am decis că avem nevoie de cel puțin 5 restanțe pentru lansările MVP, 5 produse și 5 persoane care să acționeze ca proprietari de produse, să descifreze nevoile de afaceri și să ia decizii cu privire la restricții.
Iată ce avem: .
Ideea principală a fost de a veni cu subiecte cât mai îndepărtate de munca zilnică a participanților și de a le oferi spațiu pentru un zbor creativ al imaginației.
Ce greșeli am făcut și ce am putea face mai bine?
Utilizarea practicilor de evaluare, atât de populare în domeniul angajării de agenți de vânzări și manageri de nivel inferior, a necesitat un efort enorm, dar nu ne-a permis să acordăm suficientă atenție fiecărui participant și să-i evaluăm abilitățile. În general, această opțiune de selecție creează o imagine negativă a companiei, deoarece destul de mulți oameni primesc feedback insuficient și, ulterior, creează în ei și în alții efectul de tiranie a angajatorului (comunicațiile în comunitățile IT sunt foarte dezvoltate). Drept urmare, am rămas cu literalmente doi potențiali candidați cu un viitor foarte îndepărtat.
Întâlnirile sunt un lucru bun. Se creează o bază extinsă de elaborare, iar nivelul general al participanților crește. Compania devine din ce în ce mai recunoscută pe piață. Dar intensitatea muncii a unor astfel de întreprinderi nu este mică. Trebuie să înțelegeți clar că organizarea întâlnirilor va dura aproximativ 700-800 de ore-om pe an.
Cât despre hackatonul de testare. Astfel de evenimente nu au devenit încă plictisitoare, deoarece, spre deosebire de hackathoanele pentru dezvoltatori, ele au loc mult mai rar. Avantajul acestei idei este că într-o manieră relaxată puteți face schimb de cunoștințe practice și puteți determina destul de precis nivelul fiecărui participant.
După ce am analizat rezultatele evenimentului, ne-am dat seama că am făcut multe greșeli:
- Cea mai de neiertat greșeală a fost să credem că 4-5 ore ne-ar fi suficiente. Ca urmare, doar introducerea și familiarizarea cu restanțele au durat aproape 2 ore.
Lucrul cu proprietarii de produse în stadiul inițial și timpul de abordare a subiectului a durat același timp. Deci, timpul rămas nu a fost suficient pentru o dezvoltare completă a hărților de testare. - Nu a fost suficient timp și energie pentru feedback detaliat pe fiecare hartă, deoarece era deja noapte. Prin urmare, am eșuat în mod clar această parte, dar inițial a fost intenționat să fie cea mai valoroasă din hackathon.
- Am decis să evaluăm calitatea dezvoltării printr-un simplu vot al tuturor participanților, alocand 3 voturi pentru fiecare echipă, pe care le-ar putea acorda pentru munca de cea mai înaltă calitate. Poate că ar fi mai bine să organizăm un juriu.
Ce ai realizat?
Ne-am rezolvat parțial problema și acum avem 4 bărbați curajoși și frumoși care lucrează pentru noi, acoperind spatele a 4 echipe de dezvoltare. Un număr semnificativ de potențiali candidați puternici și schimbări tangibile la nivelul comunității QA a orașului nu au fost încă observate. Dar există unele progrese și acest lucru nu poate decât să se bucure.
Sursa: www.habr.com