Кузня кадрів як вчилися тестувальники і гарталися ковалі
Ми шукаємо тестувальників. Кожна IT-компанія рано чи пізно стикається з необхідністю найму таких спеціалістів. Пошуки йдуть довго, і часто закінчуються невдало. Нічого не вдієш: ринок сильно перегрітий, хороших тестувальників миттєво розбирають. Наші ВНЗ поки не готують інженерів з якості. Виходить, що тестувальник – це не диплом, а покликання і прогнозувати зростання кількості кадрів неможливо. А у нас "горять" проекти, нам терміново потрібні люди. У таких умовах ми зважилися на крайню міру: виховати цих людей із нуля. Так виникла ідея школи тестувальників у «Петер-Сервіс».
У цій статті ми поділимося досвідом навчання тестуванню непрофільних спеціалістів.
Як і будь-який проект, школа тестувальників також має свій життєвий цикл. Досить простий: підготовка, навчання та найвеселіше – afterparty.
Цілі та аудиторія
Викладачі
Напевно, не є таємницею, що саме викладачі визначають результат школи. Наші вчителі – це інженери виробничих відділів, програмісти та тестувальники. Ніхто з нас ніколи раніше не викладав. І знаєте, не варто примушувати людей вести уроки. Найкраще запросити добровольців. Повірте, ті, хто готовий абсолютно безкоштовно після роботи ще й навчати, зроблять це на відмінно. Швидше за все, такі фанати своєї справи зможуть «заразити» своїм ентузіазмом та школярів.
Проведена за підсумками школи ретроспектива показала, що на етапі підготовки дуже корисні тренінги для викладачів. Намагайтеся показати майбутнім вчителям основні хитрощі хороших презентацій та утримання уваги слухачів. Нам загалом пощастило: наші школярі виявилися власними силами дуже жадібними до знань. Але приПовна відсутність викладацького досвіду такий тренінг дав нам хорошу психологічну підтримку.
Також непогане рішення – перевірка планів уроків. По-перше, вчителі будуть володіти всім курсом, не повторюючись і не розриваючи контексту протягом усього навчання. А по-друге, схвалення колег додасть їм впевненості і не змусить думати: «чи я кажу?».
Про що ми сперечалися ще при складанні планів уроків, то це про розклад. 4 дні на тиждень по 3 години чи 3 дні на тиждень по 4 години? У результаті ми врахували досвід вечірнього навчання у ВНЗ і проводили заняття 3 рази на тиждень по 3 астрономічні години. Наша школа припала на весну, тому ми виключили з розкладу п'ятницю, день, коли багато хто їде на дачі.
Робочі місця
Від ваших цілей залежить процес навчання. І якщо захід анонсований як школа з максимальним зануренням у робочий процес, вам доведеться добре продумати цей процес.
Приблизно за місяць до початку занять ми всерйоз задумалися про робочі місця та стенди. Початкова ідея використати реальну інфраструктуру не знайшла підтримки у служби безпеки. Як максимально наблизити робоче середовище до тієї, що використовується в компанії, і не відкривати учням доступ у внутрішню мережу? Необхідно було розробити схему доставки додатків (утиліт, тестових фреймворків, IDE, бібліотек та ін.) на комп'ютери учнів, а також підготувати сервери для веб-додатків та баз даних. Для виконання цих завдань ми залучили наших фахівців DevOps, системних адміністраторів, інформаційно-технічний відділ та відділ безпеки.
Для створення універсального робочого місця учня ми вибрали технологію vagrant, яка успішно апробована нами на інших проектах. Vagrant дозволив створити віртуальну машину з усімнеобхідним для школи, запакувати її в «коробку» і в один клік розгортати на машинах учнів. Таким чином, ми отримали однакове та передбачуване для різних комп'ютерів та операційних систем робоче місце, яке можна було легко відновити у разі збою чи поломки, а головне відтворити на будь-якому комп'ютері. Однак майте на увазі, що розмір "коробки" в цьому випадку виходить досить великим, а значить часу на її початкову доставку на комп'ютер також потрібно багато. Наступного разу ми спробуємо використати робочі місця у вигляді VDI.
Сервери з тестовими програмами ми підготували, використовуючи vmWare VSphere. Все, як у реальній роботі: бази даних та сервіси додатків рознесені на різні інстанси, налаштований nginx, піднято доменну автентифікацію, виділено DMZ з доступом через OpenVPN. Після налаштування зробили снапшоти серверів. У ході навчання відбувалося реальне тестування систем, учні спеціально чи мимоволі «ламали» наші програми, брутфорсили, подавали навантаження, шукали вразливості у базах даних. Ми спочатку виходили з того, що відмовити і вийти з ладу могло, що завгодно, тому відновити робоче оточення будь-якої миті для нас не було проблемою — все миттєво відкочувалося і піднімалося зі снапшотів.
Так, до речі, про тестовий додаток. Звичайно, ідеально було б використати свої робочі проекти. Але, якщо це неможливо, постарайтеся знайти щось більш-менш сучасне. Зрозуміло, стародавній десктопний додаток з купою багів підходить для тестування. Але чи залишиться після нього інтерес до тестування, чи пахне на школярів нафталіном? Ми ж як додаток, що тестується, взяли реальний робочий прототип, який не був запущений у виробництво.
Загалом прийміть за аксіому, щозламатися може все і будь-якої миті. Тоді ви уникнете багатьох неприємностей і непотрібних стресів. Єдине, що ми не врахували — відключення електрики. І за законами Мура, саме це і сталося на одному із занять. Тому розслаблятися не можна ніколи навіть, здавалося б, у простій справі.
Отже, навчання розпочалося.
Поясніть школярам, що робити, якщо вони пропустили заняття. Де їм брати інформацію? Ми готували роздатковий матеріал з основними тезами уроків — дуже зручно для таких випадків. Добре, якщо ви зможете віддати презентації. Тільки робіть це централізовано, наприклад, через групу VK.
Як зазначалося, якщо навчання має бути максимально наближено до робочого процесу, то практика — понад усе. У будь-якому випадку пам'ятайте, що відмінний результат дає саме чергування теорії з практикою. І постарайтеся наводити якнайбільше прикладів із життя, з вашої роботи. Тоді в учнів з'явиться відчуття реальності професії і вони «загоряться».
Ми хотіли дати універсальні знання про тестування, тому вступний теоретичний курс ґрунтувався на програмі навчання базового рівня ISTQB. А ось щодо практики…
Наша компанія постачає складні багатокомпонентні системи. За виробництво окремих компонентів, як правило, відповідає виділена команда розробників та тестувальників. Ми побудували заняття таким чином, щоб провести учнів через основні рівні архітектури наших програм. У результаті кожен міг оцінити, в якій галузі йому було б цікаво працювати.
Для практики було обрано веб-додаток із триланковою архітектурою та досить стандартною реалізацією: клієнтська частина – HTML, CSS, Javascript, серверна частина – Java. Додаток розгортався на Apache Tomcat для зберіганняданих використовувалася СУБД Oracle. Ми просувалися від ручного тестування UI через SQL та бази даних до автоматизованого тестування REST API.
Якщо у ваших системах є інтерфейс користувача, почніть практикувати тестування саме на ньому. Людям, мало знайомим із програмуванням та IT, набагато простіше мати справу зі звичними полями введення та кнопками. Наша перша тестова практика полягала у тестуванні за готовим планом та створення звітів про дефекти. Для цього ми заздалегідь створили проект у JIRA та тестові сценарії у TestRail.
Поступово ускладнюйте програму. Наприклад, до простого ручного тестування додавайте інструменти локалізації помилок. У частині UI ми розглядали можливості Fiddler Web Debugger та інструментів розробника у браузері. У частині баз даних вивчали SQL. Початкові відомості про протокол HTTP розширили інформацію про REST-запити. На цей момент учні досить добре познайомилися з тестовим додатком і були готові до його автоматичного тестування.
Автоматизація виконувалася за допомогою Robot Framework, який широко використовується в нашій компанії. Не приховаємо, дуже хотілося отримати wow-ефект, автоматизувавши UI. Але через тимчасові обмеження та складність такої автоматизації довелося відмовитися від цієї ідеї на користь старого, доброго API. Ми прагнули того, щоб у кожного школяра в результаті все вийшло, і він відчув себе справжнім тестувальником. З автоматизацією тестів API це можливо.
На цьому навчання основ тестування в принципі можна було б вважати завершеним. Але добре відомо, що автотести не мають сенсу без автозапуску і повинні бути вбудовані в процес розробки. Тому ми вирішили не зупинятись, а освоїти зі школярами практику безперервної інтеграції. Як інструментизнову-таки застосовувалися інструменти, задіяні в компанії: TeamCity та BitBucket.
До речі, рішення використовувати один додаток для практики на всіх уроках виявилося дуже вдалим. Навіть дисфункційне тестування (usability, навантажувальне) проводилося на ньому ж. Так ми забезпечили консистентність та пов'язаність знань.
Хоча школа тестувальників називається школою, нам зовсім не треба, щоби школярі зазубривали матеріал. Адже ми, зрештою, хочемо найняти з-поміж них тестувальників. Тому нічого страшного, якщо вони чогось не пам'ятають, набагато важливіше, щоб вони розуміли суть. З тієї ж причини ведіть діалог з аудиторією, ставте питання, перевіряйте їх мислення. Ви не просто навчаєте, ви вибираєте собі співробітників. З перших уроків дивіться, чи підходять вони для ваших проектів.
Підсумковий іспит має сенс розробляти ще етапі планування навчання. Тоді треба визначитися з критеріями оцінки. Ми для себе вирішили, що у нас буде дві частини: тест на знання теорії та практичне завдання.
Для тесту з кожної теми ми підготували 3 запитання та набір відповідей. Звичайно, відповіді у вільній формі дали б нам ясніше розуміння способу мислення людини. Але трудомісткість перевірки у разі досить висока.
Як практичне завдання ми запропонували школярам протестувати один із модулів корпоративного веб-додатку. Цей модуль ще був готовий і насправді перебував у тестуванні. Тут ми вбили двох зайців: остаточно занурили школярів у робоче середовище та допомогли колегам із тестуванням (так, вони залишилися задоволені результатом). Все було по-чесному: хлопці шукали помилки, визначали їхні пріоритети та фіксували у Jira. На підсумкову оцінку впливали три параметри: знання теорії, коректність опису дефекту такорисність знайденого дефекту проекту.
І все-таки основну роль при відборі кандидатів для подальших співбесід для нас зіграв не іспит (він швидше проводився для самих школярів, для систематизації їх знань), а особисті враження на уроках. Ще до іспиту ми знали, кого і куди співбесідуватимемо. Хоча іспит дещо розширив список кандидатів.
Afterparty
Якщо ви плануєте працювати з вашими учнями в одній команді, добре б трохи розрядити обстановку. Оскільки ми створювали школу саме з метою наступного найму співробітників, випускний вечір був присвячений виходу за межі «учень-вчитель». Ми грали в ігри, їли піцу та взагалі весело проводили час. До речі, цей вечір допоміг нам частково оцінити й особисті риси потенційних співробітників.
Ну а далі... Далі були співбесіди у робочі команди. І майже половина колишніх школярів стали нашими колегами. Коли школа тільки замислювалася, ми мріяли хоча б про двох нових співробітників. На момент фінального тесту стало очевидним, що їх буде набагато більше. Тому заявляємо, що школа тестувальників стала для нас справжньою кузнею кадрів!