Ĉi tiu artikolo estos interesa por tiuj, kiuj, kiel ni, alfrontas la problemon elekti taŭgan specialiston en la kampo de testado.
Sufiĉe strange, kun la pliiĝo de la nombro de IT-kompanioj en nia respubliko, nur la nombro de indaj programistoj pliiĝas, sed ne testistoj. Multaj homoj deziras eniri ĉi tiun profesion, sed ne multaj komprenas ĝian signifon.
Mi ne povas paroli por ĉiuj IT-kompanioj, sed ni asignis la rolon de QA/QC al niaj kvalitaj specialistoj. Ili estas parto de la disvolva teamo kaj partoprenas en ĉiuj etapoj de evoluo, de esplorado ĝis publikigo de nova versio.
Testisto en teamo, eĉ en la planadstadio, devas pripensi ĉiujn funkciajn kaj nefunkciajn postulojn por akcepti uzantan rakonton. Li devas kompreni la funkciajn karakterizaĵojn de la produkto same kiel programistoj, kaj eĉ pli bone, kaj helpi la teamon ne fari malĝustajn decidojn eĉ en la planadstadio. La testilo devas havi klaran komprenon pri kiel funkcios la efektivigita funkcieco kaj kiaj malfacilaĵoj povas esti. Niaj testistoj mem kreas testplanojn kaj testkazojn, kaj ankaŭ preparas ĉiujn necesajn testbenkojn. Testi laŭ preta specifo kiel simioklakilo ne estas nia elekto. Laborante ene de la teamo, li devas helpi liberigi indan produkton kaj sonigi la alarmon ĝustatempe se io misfunkcias.
Kion ni renkontis serĉante testistojn
En la etapo de studado de multaj resumoj, ŝajnis, ke ekzistas specialistoj kun taŭga sperto por ni kaj ne estus problemoj por elekti testilon por nia teamo. Sed, dum personaj renkontiĝoj, ni ĉiam pli renkontis kandidatojn, kiuj fakte estis sufiĉe malproksimaj de la mondo de informa teknologio (ekzemple, ili ne povis diri la principojn de interago inter retumilo kaj retservilo, la bazojn de sekureco, interrilata kaj ne- interrilataj datumbazoj, ili havis neniun ideon pri virtualigo kaj kontenerigo), sed samtempe taksis sin ĉe la Senior QA-nivelo. Farinte dekojn da intervjuoj, ni alvenis al la konkludo, ke la nombro de specialistoj taŭgaj por ni en la regiono estas nekonsiderinda.
Poste, mi rakontos al vi, kiajn paŝojn ni faris kaj kiajn erarojn ni paŝis por trovi tiujn longe atenditajn batalantojn por kvalito.
Kiel ni provis ripari la situacion
Elĉerpiĝinte nin per provizado de pretaj specialistoj, ni komencis celi proksimajn areojn:
- Ni provis apliki taksajn praktikojn por identigi inter la multaj "forlasitaj" homoj, tiuj mem el kiuj ni povas evoluigi fortajn specialistojn.
Ni petis grupon de eblaj kandidatoj kun proksimume la sama nivelo de scio plenumi taskojn. Observante ilian pensoprocezon, ni provis identigi la plej promesplenan kandidaton.
Aparte, ni elpensis taskojn por testi atentemon, komprenon de la kapabloj de teknologio kaj la trajtoj de multkulturismo:
- Ni okazigis renkontiĝojn por testantoj por vastigi la limojn de kompreno de la profesio inter la ekzistanta kontingento.
Mi rakontos al vi iom pri ĉiu el ili.
Ufa Software QA kaj Testing Meetup #1 estas nia unua provo kolekti tiujn, kiuj zorgas pri la profesio kaj samtempe kompreni ĉu la publiko interesiĝos pri tio, kion ni volas transdoni al ili. Esence, niaj raportoj temis pri kie estas pli bone komenci, se vi decidis fariĝi testisto. Helpu komencantojn malfermi la okulojn kaj rigardi testadon kiel plenkreskulo. Ni parolis pri la paŝoj, kiujn novulaj testistoj devas fari por aliĝi al la profesio. Pri kio estas kvalito kaj kiel atingi ĝin en realaj kondiĉoj. Kaj ankaŭ, kio estas aŭtomata testado kaj kie pli taŭgas uzi ĝin.
Poste, kun intervalo de 1-2 monatoj, ni okazigis du pliajn renkontiĝojn. Jam estis duoble pli da partoprenantoj. Ĉe "Ufa Software QA and Testing Meetup #2" ni plonĝis pli profunde en la temon. Ili parolis pri cimspuraj sistemoj, UI/UX-testado, tuŝis Docker, Ansible, kaj ankaŭ parolis pri eblaj konfliktoj inter programisto kaj testilo kaj manieroj solvi ilin.Nia tria renkontiĝo, "Ufa Software QA and Testing Meetup #3", nerekte rilatis al la laboro de testantoj, sed estis utila por ĝustatempe memorigi programistojn pri iliaj teknikaj kaj organizaj devoj: ŝarĝo-testado, e2e-testado, Selenium en aŭtotestado, ret-aplikaĵoj vundeblecoj. .
Dum ĉi tiu tempo ni lernis kiel krei normalan lumon kaj sonon en elsendoj de niaj eventoj:
→
→
→ - Kaj finfine ni decidis provi okazigi hakatonon por testantoj
Kiel ni preparis kaj faris hakatonon por testantoj
Komence, ni provis kompreni kia "besto" ĉi tio estas kaj kiel ĝi kutime efektiviĝas. Kiel evidentiĝis, tiaspecaj eventoj ne multfoje okazis en la Rusa Federacio, kaj estas nenie por prunti ideojn. Due, mi ne volis tuj investi multajn rimedojn en eventon, kiu unuavide ŝajnis dubinda. Tial ni decidis, ke ni faros mallongajn mini-hakatonojn, ne por la tuta laborciklo de QA, sed por individuaj etapoj.
Nia ĉefa kapdoloro estas la manko de praktiko inter lokaj testantoj pri kreado de klaraj testaj mapoj. Ili ne pasigas tempon esplorante antaŭ-efektivigajn uzantrakontojn kaj kreante akceptajn kriteriojn, kiuj estas klaraj por programistoj por funkciaj kaj ne-funkciaj postuloj, UI/UX, sekureco, laborŝarĝoj kaj pintaj ŝarĝoj. Tial ni decidis unuafoje trairi la plej interesan kaj krean parton de ilia laboro - analizon kaj formadon de postuloj dum antaŭprojekta esplorado.
Ni taksis la eblan nombron da partoprenantoj kaj decidis, ke ni bezonas almenaŭ 5 restarojn por MVP-eldonoj, 5 produktoj kaj 5 homoj, kiuj agus kiel produktposedantoj, deĉifris komercajn bezonojn kaj farus decidojn pri limigoj.
Jen kion ni ricevis: .
La ĉefa ideo estis elpensi temojn kiel eble plej malproksimajn de ĉiuj ĉiutagaj laboroj de la partoprenantoj kaj doni al ili eblon por kreiva fantazio.
Kiajn erarojn ni faris kaj kion ni povus fari pli bone?
La uzo de taksaj praktikoj, tiel popularaj en la kampo de dungado de vendistoj kaj malsuperaj manaĝeroj, postulis grandegan penon, sed ne permesis al ni prunti sufiĉan atenton al ĉiu partoprenanto kaj taksi liajn kapablojn. Ĝenerale, ĉi tiu elekta opcio kreas negativan bildon de la kompanio, ĉar multe da homoj ricevas nesufiĉajn reagojn kaj poste kreas en si mem kaj aliajn la efikon de tiraneco de la dunganto (komunikadoj en IT-komunumoj estas tre evoluintaj). Kiel rezulto, ni restas kun laŭvorte du eblaj kandidatoj kun tre malproksima estonteco.
Renkontiĝoj estas bona afero. Ampleksa bazo por ellaborado estas kreita, kaj la ĝenerala nivelo de la partoprenantoj pliiĝas. La kompanio fariĝas pli kaj pli rekonebla en la merkato. Sed la laborintenso de tiaj entreprenoj ne estas malgranda. Vi devas klare kompreni, ke okazigo de renkontiĝoj daŭros proksimume 700-800 homhorojn jare.
Koncerne la testan hakatonon. Tiaj eventoj ankoraŭ ne enuiĝis, ĉar, male al hakatonoj por programistoj, ili okazas multe malpli ofte. La avantaĝo de ĉi tiu ideo estas, ke malstreĉite vi povas interŝanĝi grandan kvanton da praktikaj scioj kaj sufiĉe precize determini la nivelon de ĉiu partoprenanto.
Analizinte la rezultojn de la evento, ni konstatis, ke ni faris multajn erarojn:
- La plej nepardonebla eraro estis kredi, ke 4-5 horoj sufiĉus al ni. Kiel rezulto, nur la enkonduko kaj konatiĝo kun la postrestintoj daŭris preskaŭ 2 horojn.
Labori kun produktposedantoj en la komenca etapo kaj tempo por plonĝi en la temon prenis la saman tempon. Do la restanta tempo klare ne sufiĉis por ampleksa disvolviĝo de la testaj mapoj. - Ne estis sufiĉe da tempo kaj energio por detalaj rimarkoj pri ĉiu mapo, ĉar jam estis nokto. Tial, ni klare malsukcesis ĉi tiun parton, sed komence celis esti la plej valora en la hakatono.
- Ni decidis taksi la kvaliton de evoluo per simpla voĉdono de ĉiuj partoprenantoj, asignante 3 voĉojn por ĉiu teamo, kiujn ili povus doni por la plej altkvalita laboro. Eble estus pli bone organizi ĵurion.
Kion vi atingis?
Ni parte solvis nian problemon kaj nun ni havas 4 kuraĝajn, belajn virojn laborantajn por ni, kovrante la malantaŭon de 4 evoluaj teamoj. Signifa aro de eblaj fortaj kandidatoj kaj percepteblaj ŝanĝoj en la nivelo de la QA-komunumo de la urbo ankoraŭ ne estis rimarkitaj. Sed estas iom da progreso kaj ĉi tio ne povas ne ĝoji.
fonto: www.habr.com