Овај чланак ће бити од интереса за оне који се, попут нас, суочавају са проблемом избора одговарајућег специјалисте у области тестирања.
Чудно је да са повећањем броја ИТ компанија у нашој републици расте само број достојних програмера, али не и тестера. Многи људи желе да се упусте у ову професију, али многи не разумеју њено значење.
Не могу да говорим у име свих ИТ компанија, али смо доделили улогу КА/КЦ нашим стручњацима за квалитет. Они су део развојног тима и учествују у свим фазама развоја, од истраживања до објављивања нове верзије.
Тестер у тиму, чак иу фази планирања, мора да размисли о свим функционалним и нефункционалним захтевима за прихватање корисничке приче. Он мора разумети оперативне карактеристике производа као и програмере, па чак и боље, и помоћи тиму да не доноси погрешне одлуке чак и у фази планирања. Тестер мора имати јасно разумевање како ће имплементирана функционалност функционисати и које замке могу бити. Наши тестери сами креирају планове тестирања и тест случајеве, као и припремају све потребне тестне столове. Тестирање према готовој спецификацији попут мајмунског кликера није наша опција. Радећи у тиму, он мора помоћи у пуштању достојног производа и огласити аларм на време ако нешто крене наопако.
На шта смо наишли када смо тражили тестере
У фази проучавања многих животописа, чинило се да постоје стручњаци са одговарајућим искуством за нас и да неће бити проблема са одабиром тестера за наш тим. Али, током личних састанака, све чешће смо наилазили на кандидате који су заправо били прилично удаљени од света информационих технологија (на пример, нису знали принципе интеракције између претраживача и веб сервера, основе безбедности, релационе и не- релационих база података, нису имали појма о виртуелизацији и контејнеризацији), али су се у исто време процењивали на нивоу Сениор КА. Након што смо обавили десетине интервјуа, дошли смо до закључка да је број специјалиста који нам одговарају у региону занемарљив.
Даље ћу вам рећи које смо кораке предузели и на које грешке смо крочили да бисмо пронашли те дуго очекиване борце за квалитет.
Како смо покушали да поправимо ситуацију
Пошто смо се исцрпили тражењем готових стручњака, почели смо да циљамо оближња подручја:
- Покушали смо да применимо праксе процене да бисмо међу многим људима који су "оставили то" идентификовали управо оне од којих можемо развити јаке стручњаке.
Замолили смо групу потенцијалних кандидата са приближно истим нивоом знања да ураде задатке. Посматрајући њихов мисаони процес, покушали смо да идентификујемо кандидата који највише обећава.
Конкретно, осмислили смо задатке за тестирање пажње, разумевања могућности технологије и карактеристика мултикултуралности:
- Одржали смо састанке за тестере да проширимо границе разумевања професије међу постојећим контингентом.
Рећи ћу вам понешто о сваком од њих.
Уфа Софтваре КА анд Тестинг Меетуп #1 је наш први покушај да окупимо оне којима је стало до професије и да у исто време схватимо да ли ће јавност бити заинтересована за оно што желимо да им пренесемо. У суштини, наши извештаји су били о томе где је боље почети ако сте одлучили да постанете тестер. Помозите почетницима да отворе очи и да гледају на тестирање као одрасли. Разговарали смо о корацима које тестери почетници треба да предузму да би се придружили професији. О томе шта је квалитет и како га постићи у реалним условима. И такође, шта је аутоматско тестирање и где га је прикладније користити.
Затим смо у размаку од 1-2 месеца одржали још два састанка. Већ је било дупло више учесника. На „Уфа Софтваре КА анд Тестинг Меетуп #2“ заронили смо дубље у предметну област. Разговарали су о системима за праћење грешака, УИ/УКС тестирању, дотакнули су се Доцкер, Ансибле, а говорили су и о могућим сукобима између програмера и тестера и начинима њиховог решавања.Наш трећи састанак, „Уфа Софтваре КА анд Тестинг Меетуп #3“, индиректно се односио на рад тестера, али је био користан јер је благовремено подсетио програмере на њихове техничке и организационе обавезе: тестирање оптерећења, е2е тестирање, Селен у аутоматском тестирању, рањивости веб апликација .
Све ово време смо учили како да створимо нормално светло и звук у преносима са наших догађаја:
→
→
→ - И на крају смо одлучили да покушамо да одржимо хакатон за тестере
Како смо припремили и спровели хакатон за тестере
За почетак, покушали смо да схватимо каква је то "звер" и како се обично изводи. Како се испоставило, овакви догађаји се нису много пута одржавали у Руској Федерацији, а идеје нема где да се позајми. Друго, нисам желео да одмах уложим много средстава у догађај који је на први поглед изгледао сумњив. Због тога смо одлучили да радимо кратке мини хакатоне, не за цео КА циклус рада, већ за појединачне фазе.
Наша главна главобоља је недостатак праксе међу локалним тестерима у креирању јасних мапа тестирања. Они не троше време на истраживање корисничких прича пре имплементације и креирање критеријума прихватања који су јасни програмерима за функционалне и нефункционалне захтеве, УИ/УКС, безбедност, радна оптерећења и вршна оптерећења. Стога смо по први пут одлучили да прођемо кроз најинтересантнији и најкреативнији део њиховог рада – анализу и формирање захтева током претпројектног истраживања.
Проценили смо потенцијални број учесника и одлучили да нам је потребно најмање 5 заосталих задатака за МВП издања, 5 производа и 5 људи који ће деловати као власници производа, дешифровати пословне потребе и доносити одлуке о ограничењима.
Ево шта смо добили: .
Основна идеја је била да се осмисле теме које су што удаљеније од свакодневног рада свих учесника и да им се пружи простор за креативан лет маште.
Које смо грешке направили и шта бисмо могли боље?
Употреба пракси процене, тако популарне у области запошљавања продаваца и менаџера нижег нивоа, захтевала је огроман напор, али нам није омогућила да посветимо довољно пажње сваком учеснику и проценимо његове способности. Генерално, ова опција одабира ствара негативну слику о компанији, јер доста људи добија недовољно повратних информација и последично код себе и код других ствара ефекат тираније послодавца (комуникације у ИТ заједницама су веома развијене). Као резултат тога, остала су нам буквално два потенцијална кандидата са веома далеком будућношћу.
Састанци су добра ствар. Ствара се обимна основа за разраду, а општи ниво учесника се повећава. Компанија постаје све препознатљивија на тржишту. Али интензитет рада таквих подухвата није мали. Морате јасно да схватите да ће одржавање састанака трајати отприлике 700-800 радних сати годишње.
Што се тиче тестирања хакатона. Овакви догађаји још нису постали досадни, јер се, за разлику од хакатона за програмере, одржавају много ређе. Предност ове идеје је у томе што на опуштен начин можете разменити велику количину практичних знања и прилично прецизно одредити ниво сваког учесника.
Након анализе резултата догађаја, схватили смо да смо направили много грешака:
- Најнеопростивија грешка је била веровање да ће нам 4-5 сати бити довољно. Као резултат тога, само упознавање и упознавање са заосталим предметима трајало је скоро 2 сата.
Рад са власницима производа у почетној фази и време за урон у предметну област је трајало исто толико времена. Дакле, преостало време очигледно није било довољно за свеобухватан развој тестних мапа. - Није било довољно времена и енергије за детаљне повратне информације о свакој мапи, пошто је већ била ноћ. Дакле, очигледно смо пали у овом делу, али је у почетку требало да буде највреднији на хакатону.
- Одлучили смо да оценимо квалитет израде једноставним гласањем свих учесника, доделивши по 3 гласа за сваки тим, које би они могли да дају за што квалитетнији рад. Можда би било боље да се организује жири.
Шта сте постигли?
Делимично смо решили наш проблем и сада имамо 4 храбра, згодна мушкарца који раде за нас, који покривају задњи део 4 развојна тима. Значајан скуп потенцијалних јаких кандидата и опипљиве промене на нивоу градске заједнице квалитета још увек нису примећене. Али неки напредак има и то не може а да не радује.
Извор: ввв.хабр.цом