Зошто одржавме хакатон за тестери?

Оваа статија ќе биде од интерес за оние кои, како нас, се соочуваат со проблемот да изберат соодветен специјалист во областа на тестирањето.

Доволно чудно, но со зголемувањето на бројот на ИТ компании во нашата република се зголемува само бројот на достојни програмери, но не и на тестери. Многу луѓе се желни да влезат во оваа професија, но не многумина го разбираат нејзиното значење.
Зошто одржавме хакатон за тестери?
Не можам да зборувам за сите ИТ компании, но им ја доделивме улогата на QA/QC на нашите специјалисти за квалитет. Тие се дел од тимот за развој и учествуваат во сите фази на развој, од истражување до објавување на нова верзија.

Тестер во тим, дури и во фазата на планирање, мора да размисли низ сите функционални и нефункционални барања за прифаќање на корисничка приказна. Тој мора да ги разбере оперативните карактеристики на производот, како и програмерите, па дури и подобро, и да му помогне на тимот да не донесува погрешни одлуки дури и во фазата на планирање. Тестерот мора да има јасно разбирање за тоа како ќе функционира имплементираната функционалност и какви стапици може да има. Нашите тестери сами креираат планови за тестирање и тест случаи, како и ги подготвуваат сите потребни тест клупи. Тестирањето според готова спецификација како кликер на мајмун не е наша опција. Работејќи во тимот, тој мора да помогне да се ослободи достоен производ и навреме да се огласи алармот ако нешто тргне наопаку.

Што наидовме кога баравме тестери

Во фазата на проучување на многу резимеа, се чинеше дека има специјалисти со соодветно искуство за нас и нема да има проблеми со изборот на тестер за нашиот тим. Но, за време на личните состаноци, сè почесто наидувавме на кандидати кои всушност беа доста далеку од светот на информатичката технологија (на пример, тие не можеа да ги кажат принципите на интеракција помеѓу прелистувачот и веб-серверот, основите на безбедноста, релационите и не- релациони бази на податоци, немаа поим за виртуелизација и контејнеризација), но во исто време се оценуваа на ниво на Senior QA. По извршените десетици интервјуа, дојдовме до заклучок дека бројот на специјалисти погодни за нас во регионот е занемарлив.

Следно ќе ви кажам какви чекори презедовме и на какви грешки нагазивме за да ги најдеме тие долгоочекувани борци за квалитет.

Како се обидовме да ја поправиме ситуацијата

Откако се исцрпивме со набавка на готови специјалисти, почнавме да таргетираме области во близина:

  1. Се обидовме да примениме практики за оценување за да ги идентификуваме меѓу многуте луѓе „остави го“, токму оние од кои можеме да развиеме силни специјалисти.

    Побаравме група потенцијални кандидати со приближно исто ниво на знаење да ги завршат задачите. Набљудувајќи го нивниот мисловен процес, се обидовме да го идентификуваме најперспективниот кандидат.

    Конкретно, дојдовме до задачи за тестирање на вниманието, разбирањето на можностите на технологијата и карактеристиките на мултикултурализмот:

    Зошто одржавме хакатон за тестери?
    Зошто одржавме хакатон за тестери?

  2. Одржавме состаноци за тестери за да ги прошириме границите на разбирање на професијата меѓу постоечкиот контингент.

    Ќе ви кажам малку за секој од нив.

    Ufa Software QA and Testing Meetup #1 е нашиот прв обид да ги собереме оние кои се грижат за професијата и во исто време да разбереме дали јавноста ќе биде заинтересирана за она што сакаме да им го пренесеме. Во основа, нашите извештаи беа за тоа каде е подобро да започнете ако сте решиле да станете тестер. Помогнете им на почетниците да ги отворат очите и да гледаат на тестирањето како возрасни. Разговаравме за чекорите што треба да ги преземат тестерите-почетници за да се приклучат на професијата. За тоа што е квалитет и како да се постигне во реални услови. И, исто така, што е автоматско тестирање и каде е посоодветно да се користи.

    Зошто одржавме хакатон за тестери?

    Потоа, со интервал од 1-2 месеци, одржавме уште две средби. Веќе имаше двојно повеќе учесници. На „Ufa Software QA and Testing Meetup #2“ навлеговме подлабоко во предметната област. Тие зборуваа за системите за следење грешки, UI/UX тестирање, ги допреа Docker, Ansible, а исто така зборуваа и за можни конфликти помеѓу програмер и тестер и начините за нивно решавање.

    Нашиот трет состанок, „Ufa Software QA and Testing Meetup #3“, индиректно поврзан со работата на тестерите, но беше корисен за навремено потсетување на програмерите за нивните технички и организациски должности: тестирање на оптоварување, тестирање e2e, селен во автоматско тестирање, пропусти на веб-апликации .

    Сето ова време учиме како да создаваме нормална светлина и звук во преносите од нашите настани:

    → Први чекори во тестирањето – Ufa Software QA и Тестирање состанок #1
    → Тестирање на UI/UX – Ufa Software QA и состанок за тестирање #2
    → Безбедносно тестирање, тестирање на оптоварување и автоматско тестирање – Ufa QA и Testing Meetup #3

  3. И на крајот решивме да се обидеме да одржиме хакатон за тестери

Како подготвивме и спроведовме хакатон за тестери

За почеток, се обидовме да разбереме каков вид „ѕвер“ е ова и како обично се изведува. Како што се испостави, настани од ваков вид не се одржани многу пати во Руската Федерација и нема каде да се позајмуваат идеи. Второ, не сакав веднаш да вложам многу ресурси во настан што изгледаше сомнително на прв поглед. Затоа, решивме да правиме кратки мини-хакатони, не за целиот работен циклус на QA, туку за поединечни фази.

Нашата главна главоболка е недостатокот на пракса кај локалните тестери за создавање јасни мапи за тестирање. Тие не трошат време на истражување на приказни за корисници пред имплементација и создавање критериуми за прифаќање што им се јасни на програмерите за функционални и нефункционални барања, UI/UX, безбедност, оптоварување и максимални оптоварувања. Затоа, решивме, за прв пат, да го поминеме најинтересниот и најкреативниот дел од нивната работа - анализата и формирањето на барањата при пред-проектното истражување.

Го проценивме потенцијалниот број на учесници и одлучивме дека ни се потребни најмалку 5 заостанати изданија за MVP изданија, 5 производи и 5 луѓе кои ќе дејствуваат како сопственици на производи, ќе ги дешифрираат деловните потреби и ќе донесуваат одлуки за ограничувања.

Еве што добивме: заостанати за хакатон.

Главната идеја беше да се изнајдат теми што беа што подалеку од секојдневната работа на сите учесници и да им се даде простор за креативен лет на имагинацијата.

Зошто одржавме хакатон за тестери?

Зошто одржавме хакатон за тестери?

Какви грешки направивме и што можевме подобро?

Употребата на практики за оценување, толку популарни во областа на ангажирање продавачи и менаџери од пониско ниво, бараше огромен напор, но не ни дозволи да посветиме доволно внимание на секој учесник и да ги оцениме неговите способности. Општо земено, оваа опција за избор создава негативна слика за компанијата, бидејќи доста луѓе добиваат недоволни повратни информации и последователно создаваат кај себе и кај другите ефект на тиранија на работодавачот (комуникациите во ИТ заедниците се многу развиени). Како резултат на тоа, остануваме со буквално двајца потенцијални кандидати со многу далечна иднина.

Состаноците се добра работа. Се создава обемна основа за елаборација и се зголемува општото ниво на учесниците. Компанијата станува се попрепознатлива на пазарот. Но, интензитетот на трудот на ваквите зафати не е мал. Треба јасно да разберете дека одржувањето на состаноци ќе трае приближно 700-800 работни часови годишно.

Што се однесува до хакатонот за тестирање. Ваквите настани сè уште не станаа здодевни, бидејќи, за разлика од хакатоните за програмери, тие се одржуваат многу поретко. Предноста на оваа идеја е што на опуштен начин можете да разменувате голема количина на практично знаење и сосема точно да го одредите нивото на секој учесник.

Откако ги анализиравме резултатите од настанот, сфативме дека направивме многу грешки:

  1. Најнепростлива грешка беше да веруваме дека ќе ни бидат доволни 4-5 часа. Како резултат на тоа, само воведувањето и запознавањето со заостанатите траеше скоро 2 часа.
    Работата со сопствениците на производи во почетната фаза и времето за нурнување во предметната област траеше исто толку време. Значи, преостанатото време очигледно не беше доволно за сеопфатен развој на мапите за тестирање.
  2. Немаше доволно време и енергија за детални повратни информации за секоја карта, бидејќи веќе беше ноќ. Затоа, очигледно не успеавме во овој дел, но првично беше наменет да бидеме највредните на хакатонот.
  3. Решивме да го оцениме квалитетот на развојот со едноставно гласање на сите учесници, издвојувајќи по 3 гласа за секој тим, кои тие би можеле да ги дадат за најквалитетна работа. Можеби би било подобро да се организира жири.

Што постигнавте?

Делумно го решивме нашиот проблем и сега имаме 4 храбри, згодни мажи кои работат за нас, покривајќи го задниот дел од 4 развојни тимови. Сè уште не се забележани значителен фонд на потенцијални силни кандидати и опипливи промени во нивото на заедницата за квалитет во градот. Но, има одреден напредок и ова не може а да не се радува.

Извор: www.habr.com

Додадете коментар