Многие имеют опыт работы тестировщиком. Наверняка среди читателей найдутся и такие, кто руководит целым отделом QA. Но мало кому выпадает шанс создавать QA-направление в огромной промышленной компании практически с нуля.
Привет, Хабр! Меня зовут Даша, я руковожу тестированием в ЕВРАЗе. Под катом расскажу, как нанять тестировщика без опыта и не пожалеть об этом, зачем одновременно знать Python и C# и почему бывает непросто наладить сквозное тестирование.
Рельсы, рельсы, шпалы, шпалы
Когда началась цифровая трансформация ЕВРАЗа, в его IT-сфере всё стало происходить очень быстро. Количество разработчиков и проектов росло почти экспоненциально, постоянно создавалось и внедрялось что-то новое. При таком взрывном росте случаются перекосы. В нашем случае — тестирование ПО не поспевало за его разработкой.
Разумеется, совсем без тестов в ЕВРАЗе никогда не обходились — металлургическое производство приучает к контролю качества всего, от стального рельса до ПО. Но до недавнего времени не было отдельного QA-департамента и в тестировании обходились ad-hoc-решениями — привлекали сотрудников поддержки, нанимали команды подрядчиков. Наконец решили, что это направление стоит развивать системно. Как результат — в ЕВРАЗе появилась я.
Войти в айти
Что касается веба, у меня было понимание, как тестировать, какие знания должны иметь кандидаты, какими инструментами им нужно владеть. Но разбирая заявки соискателей, я заметила, что их резюме одинаково красивые и неинформативные. Как среди них выбрать тех, кто действительно нам подойдёт, не проводя тысячу интервью?
Я стала изучать опыт других руководителей, читать статьи по теме. Очень удручала статистика, приведённая в одном из хабрапостов. Почитав отзывы на популярных площадках IT-курсов, я поняла, что многие выпускники шли учиться на QA, потому что «в тестирование легко войти», «что сложного в нажимании кнопок, я ведь постоянно пользуюсь продуктами и нахожу баги». Но есть и те, кто идёт туда осознанно, понимая, что будет интересно, но трудно.
С «осознанным» выпускником работать можно. Понятно, что знания у него будут на уровне пройденного курса (то есть необходимый минимум), а реального опыта работы не будет вовсе. Однако такого выпускника можно уже на месте научить всему необходимому, вырастить из него именно такого специалиста, в котором мы нуждаемся. Оставалось отделить зёрна от плевел. Для этого надо проверить, во-первых, что материал курса усвоен хорошо. Во-вторых — что есть какая-то база. Для тестировщика важно знать не только отличия чек-листа от тест-кейса — важно базовое понимание того, что именно он тестирует. Что такое цикл разработки, как в целом выглядит архитектура ПО, что такое база данных и т. п.
Нужно было собрать список вопросов, придумать практические задания, определить, что будет обязательной частью интервью, а что — для спорных случаев. Решила, что тестовое задание в стиле «вот страничка, напишите тест-кейсы и найдите баги» будет опциональным: на курсах на такое дрессируют хорошо, если кандидат отвечает уверенно, то и с заданием справится.
Я подготовила общий список вопросов, который затем адаптировала перед интервью, ориентируясь на резюме конкретного кандидата. После нескольких интервью мы выслали первый оффер. Дальше по накатанной пошло легче, и вскоре команда ручных тестировщиков была собрана.
С поиском автоматизатора было сложнее. Команда подрядчика писала автотесты на связке C# + Selenium. Их автотестами был покрыт весь основной функционал — это порядка 80+ тестовых сценариев. В ЕВРАЗе наиболее распространённый язык разработки тестов — Python. Питонистов на рынке труда найти проще, и в будущем такой выбор защитит ЕВРАЗ от кадрового голода. К тому же в тестовом фреймворке, использованном подрядчиком, были архитектурные сложности с написанием e2e-тестов для нашего продукта, и мы надеялись решить их переходом на pytest.
Соответственно, новый специалист по автоматизированному тестированию должен будет постепенно переносить существующие тесты с C# на Python. А для этого необходимо хотя бы базово знать и C#, и Python. И это сразу сильно сузило круг подходящих кандидатов. С каждым новым интервью я всё глубже погружалась в бездну уныния. Кандидаты были с хорошим набором скиллов, но на вопрос: «Сможете ли вы поддерживать текущие тесты и параллельно переписывать их на Python?» — отвечали: «Скорее нет, чем да».
Спасло нас чудо, натуральный deus ex machina. Среди питонистов ЕВРАЗа нашёлся человек, у которого уже был и опыт написания автотестов, и опыт работы с C#. Он захотел присоединиться к нашей команде, и это решило проблему.
Эффект домино
Укомплектовать команду было нелегко, но с 1С это был новый уровень сложности. В команде тестирования 1С уже работал один автоматизатор и три ручных тестировщика. Они пришли в тестирование из техподдержки, имели понимание процессов, навыки работы с 1С ERP. Команда отлично справлялась с задачами, но задач было слишком много, и нехватка рук постепенно становилась критической.
Я лично раньше не сталкивалась с тестированием 1С ERP. Пришлось погрузиться в работу системы, в те процессы, которые уже выстроены, — надо было составить список требований к кандидатам, более содержательный, чем и так понятное «знать и понимать специфику».
Оказалось, что людей, одновременно обладающих знанием 1С ERP и опытом тестировщика, довольно мало. Все интервью заканчивались неудачами. В итоге решили снова использовать внутренний ресурс — пригласили специалистов из команды сопровождения. По факту их и так уже привлекали к тестированию (как я рассказывала выше — бурный рост IT в ЕВРАЗе, ad-hoc-решения, всё такое). Кроме того, у них был огромный бонус — опыт работы с пользователями, понимание того, как пользователи взаимодействуют с нашими системами. Это очень помогает с осознанием, какие пользовательские сценарии надо тестировать.
Система электронного документооборота — ещё одно важное направление для тестирования. С одной стороны, это обычное тестирование веб-приложения: проверка функциональности, пользовательского интерфейса, навигации, валидации данных, поддержки различных браузеров, ну плюс ещё тестирование мобильных приложений. С другой стороны, СЭД интегрирована с кучей других систем — с 1С, SAP, HuntFlow, с базами данных и CRM.
Наша СЭД построена на платформе IBM Domino. Кроме веб-клиента используется клиент IBM Notes для администрирования — настройки агентов, представлений, прав доступа и т. п. В общем, СЭД — это сложная многокомпонентная кухня. Тестировщику необходимо иметь представление о её составляющих, тестировать интеграцию различных компонентов — например, запуская из адресной строки браузера агентов с предустановленными параметрами. Надо понимать SQL и NoSQL — СЭД взаимодействует с реляционными СУБД, но в самом Domino используется документное хранилище. Надо тестировать функциональность пользовательских ролей — менять настройки через IBM Notes, затем проверять бизнес-логику. Таким образом, даже для мануального тестирования требуется значительный объём знаний, базовые навыки программирования и опыт работы с БД. В итоге на эти вакансии также пришлось брать специалистов из команды сопровождения — из тех, что прошли курсы тестирования и хоть немного умеют кодить.
Блеск и нищета сквозного тестирования
В том багаже опыта, который я принесла с собой в ЕВРАЗ, один из самых дорогих чемоданов — понимание важности e2e-тестов. Возможность автоматического сквозного тестирования критического функционала перед выкатыванием билда в прод — бесценна. Это позволяет сильно уменьшить число седых волос у разработчиков и количество сломанных в ярости клавиатур у пользователей.
Подрядчик, о котором говорилось выше, написал более 80 автотестов на C# + Selenium, но из этих тестов только два были сквозными. Проблема в том, что наш интернет-магазин не работает полностью автоматически — покупки обрабатывает оператор-человек. Всё-таки закупка нескольких тонн стальной арматуры не то же самое, что купить шлёпанцы на Авито. Здесь нужно написать тестовый сценарий для фронта, потом тестовый сценарий для 1C, а самое главное — как-то увязать их между собой.
Тестовый фреймворк, использованный подрядчиком, такого не позволял — он умел только запускать тестовые сценарии для фронта один за одним, без возможности гибко интегрировать их с чем-то ещё. Пока что большинство сквозных тестов у нас только в проекте, мы разбираемся с девопсами, как правильнее всего будет настроить интеграцию.
Многорукий бог дедлайна
Сейчас у нас три команды тестировщиков.
Команда 1С — 3 ручных тестировщика и автоматизатор.
Команда Web — 3 ручных тестировщиков, лид команды и автоматизатор.
Команда СЭД — 4 ручных тестировщика, которые постепенно отбиваются от рук, в смысле — осваивают автоматизированное тестирование и уже понемногу внедряют автотесты на своих проектах.
Ряд проектов в ЕВРАЗе делается командами подрядчиков. Обычно такие команды занимаются и разработкой, и тестированием. Но часто приходится взаимодействовать, и «наши» тестировщики работают бок о бок с «не нашими».
Все три команды ударно трудятся, выпуская в неделю от 1 до 3 релизов. Идёт работа по автоматизации регрессионного и сквозного тестирования. В планах — погрузиться в тестирование безопасности и нагрузочное тестирование.
Несмотря на расширение штата, работы у нас по-прежнему больше, чем рук. Сейчас открыты вакансии для тестировщиков веба и 1С. В скором времени мы планируем собрать команду тестирования мобильных приложений, и мне ещё предстоит выяснить, как правильно искать специалистов на эти должности.
Дерево прокачки
Как я уже говорила выше, в своей кадровой политике мы сделали ставку на набор джунов. Но джун — это такой покемон, которому надо со временем эволюционировать в следующую форму. Важно дать ему чёткие ориентиры для этого, чтобы он понимал, как и зачем, и мог решить, куда.
На первых этапах новичком-тестировщиком занималась сама команда тестирования. К нему прикреплялся ментор, который помогал понять процессы, выдавал задачи, рассказывал о подходах. Другие более опытные тестировщики делились своим опытом, кидали ссылки на полезные статьи и тому подобное. Это неплохая система, но слишком хаотичная. Не было чёткого представления, как развивать команду; не существовало выстроенной системы, с помощью которой можно понять уровень сотрудника, оценить его знания, выяснить его зоны ближайшего развития.
Первым делом я составила матрицу компетенций и оценила по ней каждого сотрудника. Так стало понятно, у кого какие слабые стороны, которые надо бы подтянуть, и сильные, в направлении которых имеет смысл развиваться. Также собрала обратную связь — сотрудники поделились своими болями, отзывами о задачах, стремлениями, пожеланиями. На основе полученных данных мы начали разрабатывать индивидуальные планы развития.
После оценки навыков сотрудника мы отмечаем те, в которых ему необходимо развиваться или в которых он хочет прокачаться сам.
Эти навыки добавляются в план развития; редактируются, если это необходимо.
План развития становится доступным для сотрудника и его наставника.
Наставник встречается с сотрудником и прорабатывает определенные задачи, которые помогут прокачать необходимый навык.
У каждой задачи есть статус прогресса, так что любой прогресс выполнения сотрудником задачи сразу фиксируется.
Все участники в любой момент могут посмотреть прогресс выполнения любой задачи и прогресс по развитию навыка в целом.
Помимо прокачки отдельных сотрудников важна прокачка команд в целом. Для этого проводятся митапы по обмену опыта между командами разных направлений. Если посмотреть на процессы другой команды со стороны, можно увидеть в них слабые места или, наоборот, что-то, что стоит позаимствовать для себя.
Доверие и контроль
Как руководитель тестирования я придерживаюсь трёх принципов:
Поощрять обмен знаниями.
Использовать неудачи для обучения, а не поиска виноватых.
Доверять команде.
И команды, и отдельные сотрудники должны иметь высокую степень автономии. Они имеют право самостоятельно учиться, делать ошибки, выстраивать процессы. Такой подход даёт лучшие результаты, чем постоянный контроль.
Впрочем, это не значит, что я просто пускаю всё на самотёк. Я постоянно провожу личные встречи с сотрудниками. Это помогает познакомиться с каждым членом команды, узнать их успехи и неудачи. Понять, чем они живут, чем увлекаются, куда хотят расти. Общение с глазу на глаз позволяет лучше справиться с возможными конфликтами, выявить потенциальные проблемы прежде, чем они станут, так сказать, кинетическими.
Конечно, если дать человеку KPI — он найдёт способ вместо работы производить KPI. И всё же совсем без метрик нельзя. На текущий момент я использую следующие метрики:
количество ошибок, найденных в тестовой среде;
количество багов, пропущенных в продакшен;
количество созданных и выполненных автоматизированных тестовых случаев;
количество написанных и обновленных тест-кейсов;
количество пройденных тест-кейсов во время регрессионного и smoke-тестирования;
степень покрытия системы тестами.
Почему именно эти? Потому что направление тестирования в ЕВРАЗе новое, а продукты существуют и функционируют уже давно. Поэтому первое, что нужно сделать, — стабилизировать систему, выстроить процесс тестирования так, чтобы как можно меньше дефектов дошло до конечного пользователя. После того как процесс будет налажен и всё станет работать как часы, можно будет выбрать новые метрики и поставить новые цели.
Создавать направление QA в огромном холдинге практически с нуля — непростой, но очень интересный опыт. Надеюсь, вы не заскучали, читая эту статью. Разумеется, то, что в ней написано, лишь верхушка айсберга. Если у вас есть вопросы — не стесняйтесь задавать их в комментариях. А если ощутили желание принять участие во всём этом — можете посмотреть список наших вакансий.
