Тази статия ще бъде от интерес за тези, които като нас са изправени пред проблема с избора на подходящ специалист в областта на тестването.
Колкото и да е странно, с увеличаването на броя на ИТ компаниите в нашата република се увеличава само броят на достойните програмисти, но не и тестерите. Много хора са нетърпеливи да влязат в тази професия, но малко хора разбират нейния смисъл.
Не мога да говоря от името на всички ИТ компании, но сме възложили ролята на QA/QC на нашите специалисти по качеството. Те са част от екипа за разработка и участват във всички етапи на разработката, от изследването до пускането на нова версия.
Тестерът в екип, дори на етапа на планиране, трябва да обмисли всички функционални и нефункционални изисквания за приемане на потребителска история. Той трябва да разбира оперативните характеристики на продукта, както и програмистите, дори по-добре, и да помага на екипа да не взема грешни решения дори на етапа на планиране. Тестерът трябва да има ясно разбиране за това как ще работи внедрената функционалност и какви клопки може да има. Нашите тестери сами създават тестови планове и тестови случаи, както и подготвят всички необходими тестови стендове. Тестване по готова спецификация като маймунски кликер не е нашата опция. Работейки в екипа, той трябва да помогне за пускането на достоен продукт и да алармира навреме, ако нещо се обърка.
Какво срещнахме, когато търсихме тестери
На етапа на изучаване на много автобиографии изглеждаше, че има специалисти с подходящ опит за нас и няма да има проблеми с избора на тестер за нашия екип. Но по време на лични срещи все по-често срещахме кандидати, които всъщност бяха доста далеч от света на информационните технологии (например не можеха да кажат принципите на взаимодействие между браузър и уеб сървър, основите на сигурността, релационните и не- релационни бази данни, те нямаха представа за виртуализация и контейнеризация), но в същото време се оцениха на ниво Senior QA. След проведени десетки интервюта стигнахме до извода, че броят на подходящи за нас специалисти в региона е нищожен.
След това ще ви разкажа какви стъпки предприехме и на какви грешки стъпихме, за да намерим онези дългоочаквани борци за качество.
Как се опитахме да поправим ситуацията
След като се изчерпахме с намирането на готови специалисти, започнахме да се насочваме към близките райони:
- Опитахме се да приложим практики за оценяване, за да идентифицираме сред многото „отпуснати“ хора точно тези, от които можем да развием силни специалисти.
Помолихме група потенциални кандидати с приблизително еднакво ниво на знания да изпълнят задачите. Наблюдавайки мисловния им процес, се опитахме да идентифицираме най-обещаващия кандидат.
По-специално, излязохме със задачи за тестване на вниманието, разбирането на възможностите на технологиите и характеристиките на мултикултурализма:
- Проведохме срещи за тестери, за да разширим границите на разбиране на професията сред съществуващия контингент.
Ще ви разкажа малко за всеки от тях.
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 тестване, Selenium при автоматично тестване, уязвимости на уеб приложения .
През цялото това време се учим как да създаваме нормална светлина и звук в предавания от нашите събития:
→
→
→ - И в крайна сметка решихме да се опитаме да проведем хакатон за тестери
Как подготвихме и проведохме хакатон за тестери
Като начало се опитахме да разберем какъв вид „звяр“ е това и как обикновено се извършва. Както се оказа, събития от този вид не са се провеждали много пъти в Руската федерация и няма откъде да се вземат идеи. Второ, не исках веднага да инвестирам много ресурси в събитие, което на пръв поглед изглежда съмнително. Затова решихме да правим кратки мини-хакатони не за целия работен цикъл на QA, а за отделни етапи.
Нашето основно главоболие е липсата на практика сред местните тестери за създаване на ясни карти за тестване. Те не прекарват време в проучване на потребителски истории преди внедряване и създаване на критерии за приемане, които са ясни на разработчиците за функционални и нефункционални изисквания, UI/UX, сигурност, натоварвания и пикови натоварвания. Затова решихме за първи път да преминем през най-интересната и креативна част от тяхната работа – анализ и формиране на изисквания по време на предпроектно проучване.
Преценихме потенциалния брой участници и решихме, че се нуждаем от поне 5 неизпълнени задачи за издания на MVP, 5 продукта и 5 души, които да действат като собственици на продукти, да дешифрират бизнес нуждите и да вземат решения относно ограниченията.
Ето какво получихме: .
Основната идея беше да се измислят теми, които са възможно най-далеч от ежедневната работа на всички участници и да им се даде поле за творчески полет на въображението.
Какви грешки направихме и какво бихме могли да направим по-добре?
Използването на практики за оценка, толкова популярни в областта на наемането на продавачи и мениджъри от по-ниско ниво, отне огромни усилия, но не ни позволи да обърнем достатъчно внимание на всеки участник и да оценим неговите способности. Като цяло тази опция за избор създава негативен имидж на компанията, тъй като доста хора получават недостатъчна обратна връзка и впоследствие създават у себе си и другите ефекта на тирания на работодателя (комуникациите в ИТ общностите са много развити). В резултат на това оставаме буквално с два потенциални кандидата с много далечно бъдеще.
Срещите са хубаво нещо. Създава се широка база за усъвършенстване и се повишава общото ниво на участниците. Компанията става все по-разпознаваема на пазара. Но трудоемкостта на подобни начинания не е малка. Трябва ясно да разберете, че провеждането на срещи ще отнеме приблизително 700-800 човекочаса годишно.
Колкото до тестовия хакатон. Този вид събития все още не са станали скучни, тъй като, за разлика от хакатоните за разработчици, те се провеждат много по-рядко. Предимството на тази идея е, че по спокоен начин можете да обмените голямо количество практически знания и доста точно да определите нивото на всеки участник.
След като анализирахме резултатите от събитието, разбрахме, че сме допуснали много грешки:
- Най-непростимата грешка беше да вярваме, че 4-5 часа ще ни стигнат. В резултат на това само въвеждането и запознаването с натрупаните задачи отне близо 2 часа.
Работата със собствениците на продукти в началния етап и времето за навлизане в темата отне същото време. Така че оставащото време очевидно не беше достатъчно за цялостно разработване на картите за тестване. - Нямаше достатъчно време и енергия за подробна обратна връзка на всяка карта, тъй като вече беше нощ. Следователно ние очевидно се провалихме в тази част, но първоначално беше предназначено да бъдем най-ценните в хакатона.
- Решихме да оценим качеството на разработката чрез просто гласуване на всички участници, разпределяйки 3 гласа за всеки екип, които те биха могли да дадат за най-висококачествена работа. Може би е по-добре да се организира жури.
Какво постигнахте?
Ние частично решихме проблема си и сега имаме 4 смели, красиви мъже, които работят за нас, покривайки тила на 4 екипа за разработка. Значителен набор от потенциални силни кандидати и осезаеми промени в нивото на QA общността на града все още не са забелязани. Но има известен напредък и това не може да не радва.
Източник: www.habr.com