Мы ищем тестировщиков. Каждая IT-компания рано или поздно сталкивается с необходимостью найма таких специалистов. Поиски идут долго и часто заканчиваются неудачно. Ничего не поделаешь: рынок сильно перегрет, хороших тестировщиков мгновенно разбирают. Наши ВУЗы пока не готовят инженеров по качеству. Получается, что тестировщик – это не диплом, а призвание, и прогнозировать рост числа кадров невозможно. А у нас «горят» проекты, нам срочно нужны люди. В таких условиях мы решились на крайнюю меру: воспитать этих людей с нуля. Так возникла идея школы тестировщиков в «Петер-Сервис».
В этой статье мы поделимся опытом обучения тестированию непрофильных специалистов.
Как и любой проект, школа тестировщиков тоже имеет свой жизненный цикл. Довольно простой: подготовка, обучение и самое веселое – afterparty.
Цели и аудитория
При подготовке в первую очередь определите цель. Подумайте, чему и зачем вы хотите научить. Если вы готовите специалистов «под себя», то может быть, нет смысла читать стандартный курс по тестированию? Именно так поступили мы: сфокусировались на тех видах, техниках и инструментах тестирования, которые используем у себя в компании. Это тестирование UI, база данных, автоматизация, система контроля версий, а также continuous integration.
Также подумайте, кого вы хотите видеть в числе своих сотрудников. Оцените, сколько человек, какого возраста и социального статуса вы готовы обучать (если только, конечно, вы не хотите создать школу ради школы). Помимо этих моментов для нас важным являлось наличие у потенциальных школьников ноутбуков, т. к. мы планировали использовать рабочие ноутбуки только в крайних случаях.
Преподаватели
Наверное, не секрет, что именно преподаватели определяют результат школы. Наши учителя – это инженеры производственных отделов, программисты и тестировщики. Никто из нас никогда раньше не преподавал. И знаете, не стоит заставлять людей вести уроки. Лучше пригласить добровольцев. Поверьте, те, кто готов совершенно безвозмездно после работы еще и обучать, сделают это на отлично. Скорее всего, такие фанаты своего дела смогут «заразить» своим энтузиазмом и школьников.
Проведенная по итогам школы ретроспектива показала, что на этапе подготовки очень-очень полезны тренинги для преподавателей. Постарайтесь показать будущим учителям основные хитрости хороших презентаций и удержания внимания слушателей. Нам в общем-то повезло: наши школьники оказались сами по себе очень жадными до знаний. Но при полном отсутствии преподавательского опыта такой тренинг дал нам хорошую психологическую поддержку.
Также неплохое решение – взаимная проверка планов уроков. Во-первых, учителя будут владеть всем курсом, не повторяясь и не разрывая контекст на протяжении всего обучения. А во-вторых, одобрение коллег придаст им уверенности и не заставит думать: «а то ли я говорю?».
О чем мы спорили еще при составлении планов уроков, так это о расписании. 4 дня в неделю по 3 часа или 3 дня в неделю по 4 часа? В итоге мы учли опыт вечернего обучения в ВУЗах и проводили занятия 3 раза в неделю по 3 астрономических часа. Наша школа пришлась на весну, поэтому мы исключили из расписания пятницу, день, когда многие уезжают на дачи.
Рабочие места
От ваших целей зависит сам процесс обучения. И если мероприятие анонсировано как школа с максимальным погружением в рабочий процесс, вам придется хорошо продумать этот самый процесс.
Примерно за месяц до начала занятий мы всерьез задумались о рабочих местах и стендах. Первоначальная идея использовать реальную инфраструктуру не нашла поддержки у службы безопасности. Как же максимально приблизить рабочую среду к той, что используется в компании, и не открывать учащимся доступ во внутреннюю сеть? Необходимо было разработать схему доставки приложений (утилит, тестовых фреймворков, IDE, библиотек и пр.) на компьютеры учеников, а также подготовить серверы для web-приложений и баз данных. Чтобы выполнить эти задачи, мы привлекли наших специалистов DevOps, системных администраторов, информационно-технический отдел и отдел безопасности.
Для создания универсального рабочего места ученика мы выбрали технологию vagrant, успешно апробированную нами на других проектах. Vagrant позволил создать виртуальную машину со всем необходимым для школы ПО, упаковать ее в «коробку» и в один клик разворачивать на машинах учеников. Таким образом, мы получили одинаковое и предсказуемое для различных компьютеров и операционных систем рабочее место, которое можно было легко восстановить в случае сбоя или поломки, а главное — воспроизвести на любом компьютере. Однако имейте в виду, что размер «коробки» в этом случае получается довольно большим, а значит времени на ее первоначальную доставку на компьютер также потребуется много. В следующий раз мы попробуем использовать рабочие места в виде VDI.
Серверы с тестовыми приложениями мы подготовили, используя vmWare VSphere. Все, как в реальной работе: базы данных и сервисы приложений разнесены на разные инстансы, настроен nginx, поднята доменная аутентификация, выделена DMZ с доступом через OpenVPN. После окончательной настройки сделали снапшоты серверов. В ходе обучения происходило реальное тестирование систем, ученики специально или невольно «ломали» наши приложения, брутфорсили, подавали нагрузку, искали уязвимости в базах данных. Мы изначально исходили из того, что отказать и выйти из строя могло, что угодно, поэтому восстановить рабочее окружение в любой момент для нас не было проблемой — все моментально откатывалось и поднималось из снапшотов.
Для организации доступа в сеть в классе был поднят отдельный wifi. Попасть на стенд учащиеся могли только через OpenVPN, который автоматически поднимался в виртуальном окружении vagrant. Ученик имел отдельную учетную запись. Сервисы были подключены к домену, что упростило нам авторизацию и дало возможность ограничивать доступ при необходимости, хотя это и не понадобилось — попытки сломать являлись частью обучения. Данные в базах мы предварительно обезличили, а тестируемые приложения не являлись значимыми для production, поэтому рисков утечки важных данных и кода не было.
Да, кстати, о тестовом приложении. Конечно, идеально было бы использовать свои рабочие проекты. Но, если это невозможно, постарайтесь найти что-то более-менее современное. Разумеется, древнее десктопное приложение с кучей багов подходит для тестирования. Но останется ли после него интерес к тестированию, не пахнет ли на школьников нафталином? Мы же в качестве тестируемого приложения взяли реальный рабочий прототип, который не был запущен в производство.
В целом, примите за аксиому, что сломаться может все и в любой момент. Тогда вы избежите многих неприятностей и ненужных стрессов. Единственное, что не учли мы — отключение электричества. И по законам Мура, именно это и случилось на одном из занятий. Поэтому расслабляться нельзя никогда даже, казалось бы, в простом деле.
Обучение
Итак, обучение началось.
Объясните школьникам, что делать, если они пропустили занятия. Где им брать информацию. Мы готовили раздаточный материал с основными тезисами уроков — очень удобно как раз для таких случаев. Хорошо, если вы сможете отдать и презентации. Только делайте это централизованно, например, через группу 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, нагрузочное) проводилось на нем же. Так мы обеспечили консистентность и связанность знаний.
Хотя школа тестировщиков называется школой, нам совсем не надо, чтобы школьники зазубривали материал. Ведь мы, в конце концов, хотим нанять из их числа тестировщиков. Поэтому ничего страшного, если они чего-то не помнят, гораздо важнее, чтобы они понимали суть. По той же самой причине ведите диалог с аудиторией, задавайте вопросы, проверяйте их . Вы не просто учите, вы выбираете себе сотрудников. С самых первых уроков смотрите, подходят ли они для ваших проектов.
Большим плюсом на уроках является наличие ассистента. А лучше двух. Одному довольно сложно в течение трех часов и читать лекцию, и отвечать на вопросы, и помогать сразу всем с практикой.
Хорошо, если все вопросы зададут на уроке и школьники уйдут домой с полным пониманием происходящего. Но также хорошо, если вы сможете обеспечить им удаленный доступ к учебным приложениям. Мы даже не думали о домашних заданиях — зачем в 25 лет нагружать людей еще и домашками! Но оказывается, их ждали и хотели. Поэтому продумайте возможность их выполнения.
Экзамен
Итоговый экзамен имеет смысл разрабатывать еще на этапе планирования обучения. Тогда же надо определиться с критериями оценки. Мы для себя решили, что у нас будет две части: тест на знание теории и практическое задание.
Для теста по каждой теме мы подготовили 3 вопроса и набор ответов. Конечно, ответы в свободной форме дали бы нам более ясное понимание образа мыслей человека. Но трудоемкость проверки в этом случае довольно высока.
В качестве практического задания мы предложили школьникам протестировать один из модулей корпоративного веб-приложения. Этот модуль еще не был готов и на самом деле находился в тестировании. Здесь мы убили двух зайцев: окончательно погрузили школьников в рабочую среду и помогли коллегам с тестированием (да, они остались довольны результатом). Все было по-честному: ребята искали ошибки, определяли их приоритеты и фиксировали в Jira. На итоговую оценку влияли три параметра: знание теории, корректность описания дефекта и полезность найденного дефекта для проекта.
И все-таки основную роль при отборе кандидатов для последующих собеседований для нас сыграл не экзамен (он скорее проводился для самих школьников, для систематизации их знаний), а личные впечатления на уроках. Еще до экзамена мы знали, кого и куда будем собеседовать. Хотя экзамен немного расширил список кандидатов.
Afterparty
Если вы планируете в дальнейшем работать с вашими учениками в одной команде, хорошо бы немного разрядить обстановку. Поскольку мы создавали школу именно с целью последующего найма сотрудников, выпускной вечер был посвящен выходу за рамки «ученик-учитель». Мы играли в игры, ели пиццу и вообще весело проводили время. Кстати, этот вечер помог нам частично оценить и личные качества потенциальных сотрудников.
Ну а дальше… Дальше были собеседования в рабочие команды. И почти половина бывших школьников стали нашими коллегами. Когда школа только задумывалась, мы мечтали хотя бы о двух новых сотрудниках. На момент финального теста стало очевидно, что их будет гораздо больше. Поэтому заявляем, что школа тестировщиков стала для нас настоящей кузницей кадров!
Ссылки по теме
Автор: Петер-Сервис
