Head of qa что это

Чем занимается Lead QA в IT-компании Just AI?

Елизавета Борщ Lead QA в компании Just AI.

Елизавета Борщ работает лидом QA-инженеров в компании, которая разрабатывает технологии в сфере разговорного искусственного интеллекта. Она стремится быть играющим тренером — не только управлять командой, но и участвовать в ручных проверках. Елизавета рассказала, какие виды тестирования бывают, как искать баги и какие требования предъявляют к новичкам.

Освойте профессию
«Тестировщик-автоматизатор»

Чем занимается QA-инженер в IT-компании

QA-инженер (Quality Assurance) обеспечивает качество на всех этапах разработки, начиная с требований, а тестировщик контролирует это качество. Моя должность в компании — Lead QA. Я занимаюсь как практическими задачами: провожу ручное и автоматизированное тестирование, пишу и делаю ревью документации, — так и организационными, например собеседую кандидатов. Улучшение качества продуктов — это непрерывный процесс, в который вовлечен весь департамент разработки. За этим процессом нужно постоянно следить , поэтому сейчас, например, проводится аудит тестирования, который должен помочь выявить слабые места.

Профессия / 16 месяцев
Тестировщик-автоматизатор
Лучший выбор для быстрого старта в IT
3 474 ₽/мес 6 317 ₽/мес

Департамент разработки состоит из кроссфункциональных команд, в каждой из которых есть backend— и frontend-разработчики, несколько QA-инженеров и DevOps, то есть QA не выделены в обособленную команду, они находятся максимально близко к процессу разработки. Все тесно взаимодействуют друг с другом, это позволяет подстраиваться под нужные скорости, чтобы реализовать новые фичи. Разработка ведется по нескольким направлениям: JAICP, Aimylogic, JAICF. Aimylogic — визуальный конструктор ботов и голосовых ассистентов, JAICP — это платформа корпоративного уровня, на которой можно разрабатывать разговорные решения любой сложности на JavaScript и Kotlin. JAICF — это фреймворк с открытым исходным кодом для разработки ботов на Kotlin. Продукты имеют более 20 различных интеграций: с платформами Яндекс.Алисы, Маруси от VK (ранее Mail.Ru Group), SmartMarket, мессенджерами, соцсетями.

На каких этапах нужно тестирование

Мы начинаем с тестирования требований. Чем раньше мы обнаружим проблему, тем дешевле ее исправить. На встрече с продакт-менеджерами мы обсуждаем возможность реализации новых фичей, требования, критерии конечного результата, задаем наводящие вопросы, подсвечиваем трудности. QA-инженер пишет тестовую документацию — это база знаний, набор кейсов, чек-листов, тест-планов, тестовых стратегий, инструкции, по которым QA может пройтись и проверить работоспособность функциональности. Для удобного хранения документации мы пользуемся TestRail — это инструмент для управления тестированием. Если всех устраивают критерии, задача переходит в разработку, команда ее оценивает, декомпозирует и приступает к реализации. Когда требования нужно доработать, мы возвращаем задачу заказчику. QA обязательно принимает участие в этом процессе, так как у него достаточный уровень экспертизы и он может предугадать потенциальную проблему. Когда требования утверждены, их передают на реализацию. После этого задачу тестируют. На этом этапе проводится функциональное тестирование (проверка того, как продукт выполняет свои функции) и тестирование юзабилити (интерфейса); если нужно, проводят еще и нагрузочное (проверка того, выдержит ли система повышенные нагрузки). Тестировщик смотрит негативные кейсы, то, как функциональность встроится в систему, и многое другое. В процессе тестирования заводятся баги в Jira, разработчики их фиксят и отдают на ретест (повторный тест).

Читайте также Кто такой тестировщик и чем он занимается

После внесения всех исправлений задача передается на этап интеграции. Это происходит в течение двух недель — спринта. После этого все команды сливают новые фичи в одну ветку, которая становится релиз-кандидатом. Это ветка версии кода, которая претендует на установку в продакшн. Как только все релиз-кандидаты готовы, вся система передается на регрессионное тестирование. На этом этапе важно убедиться не только в том, что новая функциональность работает корректно, но и в том, что ничего из старого в ходе разработки не сломалось. Регрессия проходит в два параллельных этапа:

• мануальные проверки. QA вручную сверяются с тестовой документацией, проходят по всем кейсам;
• автоматические проверки. Можно имитировать пользовательские сценарии, прокликивать стандартные действия конечного пользователя — это работа с frontend. Или проверять backend в рамках интеграционного тестирования (взаимодействие нескольких модулей между собой).

После регрессии релиз-кандидаты направляются на стейдж. Это специальное место, которое недоступно пользователям и имитирует продакшн. На этом этапе мы берем копии больших реальных данных и проводим PDV (Post deployment Verification — набор проверок, который позволяет убедиться в работоспособности системы). После этого релиз уходит в боевое окружение/прод.

Какие виды тестирования бывают

Видов тестирования очень много, все зависит от специфики проекта.

Один из основных видов — функциональное тестирование, так как оно учитывает сразу несколько аспектов, например требования и бизнес-кейсы (use-case). Кроме того, проверяем UI (пользовательский интерфейс), тестируем удобство использования. Все это важно, ведь уровень качества интерфейса показывает наше отношение и заботу о пользователе.

Мобильные приложения требуют серьезного внимания к уровню безопасности. Еще нам, например, важно учитывать, насколько боты готовы к наплыву новых пользователей, поэтому важно проводить тестирование производительности. Для написания таких тестов мы пользуемся инструментом JMeter.

Существует еще Unit-тестирование, но это зона ответственности разработчиков. Они пишут юниты при реализации функциональности для проверки работоспособности отдельных небольших фрагментов кода.

Поскольку у нас есть клиенты из разных стран, мы тестируем и локализацию: каждая строка текста на русском языке должна иметь свой эквивалент на других языках. Разработчик приписывает к русскоязычным строкам специальный префикс, чтобы скрипт выгрузил строки локализации в файл, который локализаторы будут переводить. После этого переводы переходят обратно разработчику, он вливает их скриптом в продукт, а QA проверяет, что все переводы попали на нужные места, нет, например, лишних специальных символов, которые могут даже «уронить» frontend.

Как определять баг

Можно обратиться к тестовой документации: ожидаемый результат должен совпадать с фактическим. Чтобы убедиться в этом, нужно пройти тест-кейс — набор шагов для тестировщика.

Важный инструмент тестирования — логи (файлы, которые содержат в себе информацию работы сервера/компонентов/пользователя); прочитать их можно при помощи различных инструментов, один из них — Graylog (open source инструмент для сбора и анализа событий). Есть разные уровни логирования, но самые опасные, конечно, ERROR.

При тестирования веба нужно владеть еще одним инструментом — консолью DevTools, которую можно вызвать в браузере с помощью F12 или сочетания Ctrl + Shift + J. Там есть несколько полезных вкладок: network, console, где можно, например посмотреть статус ответов на разные запросы. Самые частые группы кодов, которые нужны при оформлении баг-репортов, — это 500 (ошибки сервера) и 400 (ошибка пользователя).

Станьте тестировщиком – это лучший выбор для быстрого старта в IT

Почему для QA-инженера важна коммуникация

Just AI — моя первая работа в IT. До этого я работала инженером-металлургом и проходила курс «Тестирование ПО» в Политехническом университете, но некоторые технические нюансы изучала буквально на ходу. Через пару месяцев работы мне пришла задача на обновление React. Я начала гуглить, что это, спросила у разработчика. Она сказала, что нужно проверить несколько модальных окон, селектов. Показалось, что ничего сложного.

Выполнив эти тесты, я отдала задачу, и через несколько дней началась регрессия. В процессе тестирования формируется список багов, и я замечаю, что их 20, потом 50 и они всё прибывают. В итоге в системе оказалось около 80 багов, большая часть как раз из-за моей задачи; коллеги были в шоке.

Оказалось, что обновление React затрагивает вообще все, что происходит на UI. Я не дожала разработчика, когда задавала вопросы, и смирилась с коротким ответом. Тогда у нас практически не было автотестов и найти эти проблемы не было возможности, поэтому регрессия очень помогла.

Совет: Когда появляется проблема, нужно спокойно ее решить подручными средствами, а потом применить правило пяти «А почему?». Задав себе этот вопрос, ты дойдешь до первопричины, а затем сможешь найти решение, чтобы дальше этой ошибки не повторялось.

Я отработала в компании восемь месяцев, когда наш ведущий тестировщик решил уйти. Тогда начальник предложил мне взять на себя некоторые обязанности лида. Помню, как я впервые самостоятельно выкатывала релиз: меня буквально трясло, пока в чат не пришло сообщение об успешной установке, только тогда я спокойно выдохнула. Но ощущения были потрясающие. Как только начинаешь решать задачи, которые кажутся невыполнимыми, быстро мобилизуешься, перестаешь стесняться спрашивать команду о любых мелочах.

Поэтому для QA-инженера или тестировщика очень важна коммуникация. В этой нише нужно взаимодействовать практически со всеми участниками разработки: продакт-менеджерами, дизайнерами, техническими писателями, лидами, чтобы минимизировать количество проверок и повысить качество продукта.

У нас каждую неделю проводятся QA-митапы, где QA рассказывают о проблемах и трудностях, предлагают решения, делятся знаниями, которые нарабатывают в командах. Для стеснительных ребят я всегда открыта к личному диалогу, если нет желания озвучивать проблемы при всех. Поэтому я стараюсь подтягивать не только технические навыки, но и софт-скиллы.

Сейчас я прохожу курсы по тест-менеджменту и курс по аудиту QA-процессов и изучаю инструменты для выявления скрытых проблем. В IT до сих пор встречаются неразговорчивые люди, поэтому нужно уметь проводить опросы, ретроспективы, one-to-one встречи, которые позволяют разговорить людей, получить обратную связь или дать фидбэк.

Например, перед performance review сотрудник заполняет специальную форму обратной связи. Зачастую он отвечает, что все хорошо и проблем нет, но скорее всего это не так. Поэтому важно грамотно составлять опросы и строить диалог, чтобы выявить проблемные места и предпринять действия в будущем.

Как у нас устроен онбординг новичков

В нашей компании фактический опыт при найме не будет решающим фактором. Для того чтобы претендовать на должность, кандидат должен:

• понимать теоретические принципы тестирования;
• понимать принцип пирамиды тестирования и назначение каждого уровня. Пирамида тестирования — это диаграмма, описывающая разные уровни тестирования и его объем на каждом этапе;
• видеть различия между чек-листом и тест-кейсом, уметь их писать;
• знать, что такое баг-репорт, для чего он нужен, из каких атрибутов состоит.

Конечно, важны и технические навыки: понимание клиент-серверной архитектуры, HTTP-протокола. Нужно уметь работать с командной строкой, знать основы Linux, принципы работы баз данных и писать хотя бы простые SQL-запросы, например на выборку данных с определенными условиями из одной или нескольких таблиц.

Адаптация сотрудника проходит одинаково, независимо от грейда. Он знакомится с устройством компании, делает тестовое, чтобы погрузиться в продукт. После ментор составляет ему тестовый ран, куда входят тест-кейсы с проверками основного функционала продукта. Это похоже на регрессию, но только в урезанном формате. Получается, что это дополнительное ревью тестовой документации, ведь новый сотрудник свежим взглядом может увидеть, что стоит скорректировать.

После знакомства, которое длится около двух-трех недель, мы передаем человеку небольшие баги, например с продакшна. Так он на практике поймет, как устроен процесс работы в его команде.

Выполнив такие небольшие задачи, он может работать с тестовой документацией, проверять ее точность, исключать или добавлять тесты, верифицировать новые фичи. К этому этапу он также подключается к общим регулярным регрессиям, может на равных со своим коллегой брать спринтовые задачи, заниматься перекрестным тестированием.

Куда расти QA-инженеру

QA-инженеры могут развиваться в нескольких направлениях, например стать аналитиками или продакт-менеджерами. Это возможно, так как они глубоко разбираются в продукте, особенностях его работы и желаниях пользователя.

Чаще всего из ручного тестирования специалисты уходят в автоматизацию. Здесь большой выбор направлений: тестирование backend, API, UI-тесты, нагрузочное тестирование, для которого, кстати, нужны серьезные технические знания.

В нашей команде есть выделенный автоматизатор, который занимается только написанием и поддержкой UI-автотестов на Kotlin. При этом остальные мануальщики как минимум могут поддерживать существующие автотесты. Некоторые, пройдя нашу внутреннюю школу автоматизации, даже пишут свои.

Можно развиваться вертикально и стать QA-лидом или тест-менеджером. Чаще всего они гораздо меньше работают «руками», но бывают «играющие тренеры» — специалисты, которые совмещают и менеджерские, и технические задачи. Мне нравится эта модель.

Тестировщик-автоматизатор

Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.

Преодоление кризисов в качестве лидера команды: первый год в роли Head of QA

За 7 лет работы в QA я успел попробовать разные роли:

– тестировщик в стартапе;

– тест-лид в агентстве и корпорации;

– и вот недавно прошел год, как я работаю хедом QA в Mayflower.

Меняется не только моя роль, но и количество людей, за которых я отвечаю. Если несколько лет назад я управлял командой из двух тестировщиков, то сейчас отвечаю за отдел тестирования, в котором почти 30 человек. В этой статье хочу поделиться своим опытом работы в роли хеда. Это может быть полезным для тех, кто планирует расти в эту сторону, но имеет внутренние вопросики.

Про страхи

Небольшой дисклеймер о том, что я имею в виду под страхом в этой статье: конечно, это не паническое состояние или желание убежать, скорее, сомнения в своей экспертности, синдром самозванца — суперзнакомое многим в IT ощущение.

Год назад я согласился выйти на позицию хеда тестирования. С одной стороны, я был очень рад новому челленджу, а с другой стороны, в голове блуждали какие-то страхи. С ходу мне даже сложно было разобраться, что именно меня пугает и почему. Спустя некоторое время эти страхи «оформились», и я смог их для себя структурировать в понятные пойнты:

1. Люди

В предыдущей компании я был лидом семи инженеров в нескольких командах. Семь — отличная цифра, ровно столько элементов ты можешь удержать в голове. Теперь же мне на старте дали 15 человек (а за год их стало почти 30). Меня волновало, как мне удастся найти общий язык с таким большим количеством людей в команде, стоит ли это вообще делать, какие сложности ждут меня (и их) и как я буду их преодолевать.

2. Переход в новую роль

В Mayflower роль Head of QA — это всего минус один от c-level в структуре организации. Ранее напрямую с такими серьёзными ребятами мне работать не приходилось. Поэтому внутренний мандраж первое время, конечно, присутствовал. Как выглядит работа с c-level? Есть ли какие-то общепринятые правила, которых я пока не знаю? Справлюсь ли я с этим форматом?

3. Экспертиза

Другая сложная тема — принятие правильных решений по процессам тестирования. Насколько получится выстроить схему анализа проблем, поиска их решения, внедрения изменений и наблюдения за результатом? Буду ли я предлагать оптимальные изменения, как буду определять, где я неправ?

С такими вводными я взялся за новую роль. Дальше был год работы, в течение которого многие вещи стали проще, некоторые страхи испарились, а что-то оказалось сложнее, чем я думал. Поделюсь внутрянкой страхов, действиями против них и выводами, к которым я пришёл. Моя цель — помочь и поддержать тех, кто только начинает этот путь.

Люди

Опыта управления такой большой командой у меня ещё не было, поэтому, естественно, я боялся оказаться для них плохим лидером. К сожалению, Википедия не дает определения понятия «плохой лидер», поэтому я поделюсь своим, кем я точно НЕ хотел стать для своей команды.

Плохой лидер:

– не умеет в баланс между ответственностью и доверием, например, может полностью утаскивать на себя принятие решений, не обсуждая и не делегируя лидам, инженерам, или, наоборот, скидывает все проблемы и необходимые изменения своим сотрудникам;

– не выражает поддержку там, где она необходима / заслужена или перехваливает сотрудника;

– не годится для того, чтобы брать с него пример в решении проблем и движении к достижению цели;

– не справляется со своим характером, и из-за этого кто-то огребает;

– не видит общей картины происходящего, не может сделать вывод о том, что хорошо и что плохо, и не может выступать в роли визионера.

Портрет антилидера у меня был, так что же я сделал, чтобы в него не превратиться?

Конечно, сначала я знакомился с ребятами на личных встречах и разбирался в общем процессе их работы. Здесь стоит отметить, что все 27 инженеров группами по два-три человека вгружены в отдельные полностью укомплектованные продуктовые команды (со своим проджектом, продактом, аналитиком, разработчиками и тд). Мне пришлось использовать разные подходы к абсолютно разным людям, которых было много. Кроме того, они работают в разных командах, в каждой из которых существует своя атмосфера и специфика. Я понимал, что путь к нахождению общих точек соприкосновения и доверию лежит через решение кризисных ситуаций:

— острых ситуаций отдельных ребят;
— сложных кейсов по процессам работы отдела.

Эти кризисы действительно возникают и могут продолжаться, они не проходят сами по себе, а мы с обеих сторон — я и мои QA — берем на себя ответственность, пытаемся понять причины проблемы через диалог со мной, лидами, через ретро внутри команд, личный анализ и идем по договоренностям.

«Капитанский» рецепт выхода из кризиса, по которому я пытаюсь идти каждый раз:

1. Анализ проблемы и подсвечивание ключевых точек напряжения, которые и являются источником проблемы.
2. Транслирование всем задействованным лицам, кто и что сделал неправильно. Идеально, чтобы каждый четко понимал свою роль, ответственность и результат в данной проблеме, ситуации или процессе.
3. Обозначение и фиксирование ожиданий (в виде целей/блока ретро/тд для человека/команды). Должно быть ясно, что, кто и зачем должен выполнить в определенный срок.
4. Договоренность насчет формата синхронизаций с человеком/командой по статусу решения проблемы.
5. Сам процесс мониторинга решения проблемы.
6. Подведение итогов по достижению оговоренного срока для решения проблемы.

Спустя год я вижу, что с большинством у меня выстроились доверительные отношения.

Хотя диапазон кейсов был очень разный: кто-то затащил крутой подход в тестировании, и мы радовались его успехам, а кто-то ловил дизмораль из-за разных ситуаций на проекте, и я пытался ему помочь. Так мы познакомились друг с другом, QA поняли, где я могу быть полезен и в каких вопросах мне можно довериться.

Однажды меня зацепила мысль: руководитель отдела QA (применимо и к любым другим) не может делать вывод обо всем только по дашбордам, метрикам, автоматизированным уведомлениям и ощущению его лидов — ему необходимо выстраивать связь с каждым из сотрудников, слушать, о каких проблемах говорят именно они, а не надеяться на консолидированный фидбек, принесенный на блюдечке.

Чем больше человек в команде, тем сложнее следить за всем происходящим и системное общение с каждым инженером случается не чаще раза в 4–5 месяцев. И всё же, если того требует ситуация, надо делать исключения и видеться чаще.

Не стоит бояться размера отдела: всегда можно изобрести какой-то формат, в котором будет достаточное количество коммуникаций. Важно не терять прямую связь с сотрудниками: только так ты действительно будешь понимать боли, ценность конкретных достижений инженеров и фактическое влияние твоих изменений на процесс доставки.

Возвращаясь к теме про лидерство и то, как я вижу имеющийся итог: я все ещё продолжаю искать правильный баланс. Иногда мне тяжело проводить черту между личным отношением к человеку и требовательностью в рамках моей ответственности. Этот баланс становится лучше с каждым отдельным кейсом, в котором я участвую, хотя эмоционально это дается мне непросто (хотя никто и не обещал, что будет легко).

Переход в новую роль

Помимо самой софтовой части работы с людьми было тревожно начать работать в прямой связке с c-level.

Вопросы в голове были примерно такие:

• Вдруг я знаю мало, а они много и поэтому их решения будут круче и применимее?
• Будут ли мне давать свободу в принятии решений или придется действовать строго по указке?
• Получится ли выйти на взаимопонимание и доверие в плане принимаемых решений? Смогу ли я достаточно внятно продавать свою позицию по разным вопросам?

В течение года все эти вопросы возникали в разные моменты и сейчас иногда могут возникнуть — но такова уж специфика плотной работы с c-level.

Мои наблюдения по прошествии года:

1. У менеджмента действительно может быть круче экспертиза по управленческим решениям. И вместо сомнений в себе, куда эффективнее попытаться перенять глобальное мышление, способность видеть общую картину благодаря их рекомендациям, советам, вопросам.
2. Самый большой челлендж на старте — понять, что ты сам определяешь, куда движется отдел тестирования, с какой скоростью и для каких целей.
3. Вас нанимают как раз потому, что нужен хороший менеджер, берущий на себя ответственность за отдел, готовый искать хорошие решения для имеющихся проблем. На старте важно договориться об ожиданиях по уровню свободы в принимаемых решениях. И поэтому надо выстраивать честный диалог с CTO, COO и тд — пусть это может казаться сложным в первое время. Как только появляются первые плоды вашей работы, диалог с c-level сразу становится более комфортным и понятным.

Экспертиза

Третьим элементом, который вызывал вопросы, оказалась моя профессиональная экспертиза и её применимость. Она, в свою очередь, раскладывается на отладку процессов и управление инструментами QA.

Отладка процессов

В плане отладки процессов я переживал, что:

• мне будет сложно что-то вообще увидеть с моей позиции, не состоя при этом ни в одной продуктовой команде;
• я не смогу понимать, как контролировать развитие инструментария тестирования, какие решения и для каких проблем предлагать.

Что я в итоге сделал и получилось ли всё пофиксить? Я выстроил коммуникацию со всеми холдерами процесса доставки. Засетапил синки с лидом проджект-менеджеров, QA-техлидами, настроил сбор и анализ метрик (читайте мою другую статью про Плотность дефектов “со звездочкой”). Ввел процесс постмортемов для каждого критического бага на уровне лидов фронта, бэка и QA, и в ближайшее время планирую увести это внутрь команд. На наших постмортем-встречах мы детально обсуждаем криты. Такой процесс позволяет не только быстрее и точнее залатывать открывшиеся дыры в процессах, но и действовать превентивно.

Любое решение по изменению процесса доставки стоит проводить через проджектов, обсуждать с командой QA, учитывая их комментарии и предложения. Выводы о пользе изменения можно делать по метрикам, субъективным ощущениям команд и их тимлидов, информации с ретроспектив. При таком подходе неполезные процессы отмирают сами собой, а нужные остаются и становятся естественными.

Управление инструментарием QA

Под инструментарием QA я подразумеваю фреймворки и их развитие, написание автотестов, работу с чеклистами, используемые для тестирования приложения и тд.

Для контекста, в моем случае в структуре нашего отдела над инженерами находятся техлиды тестирования, отвечающие за фреймворки и инфраструктуру тестирования. Мои запросы по части автоматизации существуют на уровне процессов и цифр:

1. Успеваем ли мы писать тесты? Каково качество написанных тестов? Есть ли люди, которых надо подтянуть до нужного базового уровня?
2. Насколько текущее решение помогает нам решать поставленные задачи? «Хватает» ли нам выбранного фреймворка?
3. На что из нашего бэклога мы в первую очередь должны тратить ресурс? Какие наши ожидания от полугода-года работы по разгребанию фокусных задач из бэклога?
4. Какие наши ожидания от скорости прохождения тестов? Сколько у нас flaky тестов сейчас и сколько мы хотим, чтобы было?

Я собираю набор метрик, наши ожидания от инфраструктуры и фреймворков и ограничения. Принятие решений по конкретным изменениям фреймворкам, мониторинг тестов, помощь и развитие тестировщиков по этим направлениям лежит в зоне ответственности QA-техлидов.

Все, что касается самих инструментов (мобилки для тестирования, отдельное приложение и остальное), артефактов (чеклист, тест-кейс и прочее) — обсуждаем c техлидами и отделом.

Как именно вы будете развивать ваш отдел напрямую зависит от его структуры и целеполагания. Например, если у вас есть кто-то когда-то немного работавший с нагрузочным тестированием — пусть сделает MVP, докажет его работоспособность и дальше может претендовать на роль «эксперта». При таком подходе развитие технического направления не размазывается на всех, а закрепляется за конкретным человеком. Потом он может искать падаванов внутри и подключать их к поддержке и развитию фреймворка, шеря с ними свои цели.

Как руководитель отдела, вы будете оформлять запрос на закупку лицензий, и если у вас ведется контроль бюджетов, вам понадобятся реальные доводы по именно такому количеству пользователей, именно этому типу лицензии и ее сроку. Поэтому финальная ответственность за решение приобрести софт/хардвер лежит на вас.

Заключение

Роль руководителя отдела тестирования сложна и к ней никогда нельзя полностью подготовиться. Конечно, все сложности реально преодолеть. Из забавных наблюдений: внутри отдела вам может быть непросто объяснить, чем конкретно вы занимаетесь, потому что спектр ответственности огромный и нет одних и тех же задач, над которыми вы работаете каждый день. С этим элементом неопределенности приходится жить, и нужно становиться маячком для своего отдела, подсвечивая, зачем мы вообще здесь собрались, почему мы тестируем именно так и к чему хотим прийти в ближайшие годы.

Каждому размышляющему о постепенном переходе в хеды/лиды я также советую найти себе ментора на первое время. Это отлично поможет фокусироваться на проблемах, быстрее находить их решение, а также вы заручитесь ментальной поддержкой.

Смелости, терпения и удачи!

Кто такой QA Lead?

Давайте поговорим о том, кто такой QA Lead, чем он занимается, а также как можно им стать.

QA Lead — это специалист, который руководит командой (командами) тестировщиков. В числе его обязанностей могут быть следующие:

• определение стратегии тестирования;
• создание планов тестирования на разных этапах тестинга;
• контроль соблюдения сроков тестирования;
• оптимизация процессов контроля качества на проекте;
• собеседование тестировщиков;
• разработка тестовой документации, ее поддержка в актуальном состоянии.

В зависимости от проекта круг обязанностей может меняться, но не меняется главная цель — контроль обеспечения соответствия выпускаемого программного продукта стандартам отрасли, стандартам компании, требованиям заказчика.

Как становятся лидами?

Как правило, QA Lead’ом становится опытный Senior QA Engineer, который давно работает в сфере тестирования в целом или в конкретной компании в частности. К примеру, текущий QA Lead уходит, а на замену ему нужен толковый человек, хорошо знающий стек технологий продукта. По сути, это не что иное, как карьерный рост. Однако не существует строгой формулы — все зависит от человека и его способностей, а также политики компании. К примеру, вполне себе можно встретить тестировщика, который вырос до лида в течение 5-6 лет (а бывает и раньше). Однако случается и обратное: например, тестировщик, который 10 лет работает мидлом и особо не переживает по этому поводу. Приходилось слышать и такую фразу, правда, от разработчика: «Если я стану сеньором, то и требовать с меня будут больше». Таким образом, определенная логика в этом есть, ведь, как известно, с большой должностью приходит большая ответственность.

Но если вы все-таки застоялись на месте в качестве Senior QA Engineer, то как шагнуть вперед и можно ли в принципе сначала научиться быть лидом, а потом им стать?

В целом, нет ничего невозможного. По большему счету, тактика такова:

1. Продолжайте «яростно» трудиться на своем проекте (если проект слишком простой — ищите новый), не застаивайтесь в зоне комфорта, развивайтесь неустанно (по истечении каждого полугода-года у вас должен быть список каких-то новых достижений). Беритесь за сложные задачи, будьте активными, и рано или поздно вас обязательно заметят.
2. Обучайтесь. Это можно делать и самостоятельно, но в таком случае не будет системности. Лучше всего — пройти соответствующий курс на какой-нибудь образовательной платформе. Это будет отличный плюс в карму, кроме того, полученные знания окажутся весьма полезными, т. к. управление — это отдельная наука, имеющая свои нюансы.

Интересует профессия QA Lead? Обратите внимание на специализированный курс в Otus!

QA Lead/Head: кто это, обязанности, зарплаты и как им стать в 2023 году. Обзор профессии.

Обучение

Автор Роман Семенцов На чтение 8 мин. Просмотров 1.3k.

Кто такой QA Lead?

QA Lead (QA Head, руководитель команды тестировщиков) — это специалист, который определяет стратегии тестирования для обеспечения соответствия выпускаемого продукта стандартам отрасли и компании. QA-руководители создают планы тестирования, включая отдельные этапы тестирования, и обеспечивают соблюдение командой сроков, установленных в этих планах.

Что делают QA Lead и чем занимаются?

Обязанности на примере одной из вакансий:

• Оптимизация процессов контроля качества в компании на всех стадиях SDLC
• Организация работы распределенного отдела тестирования
• Разработка системы профессионального развития, карьерного роста и материального стимулирования сотрудников отдела тестирования
• Разработка и поддержка тестовой документации в актуальном состоянии
• Оперативное руководство отделом тестирования

Что должен знать и уметь QA Lead?

Требования к QA Lead:

• Опыт использования Atlassian JIRA для оптимизации процессов контроля качества в компании
• Опыт ведения и развития базы знаний (ex. Atlassian Confluence)
• Знание английского языка на уровне чтения технической документации

Востребованность и зарплаты QA Lead

На сайте поиска работы в данный момент открыто 155 вакансий, с каждым месяцем спрос на QA Lead растет.

Количество вакансий с указанной зарплатой QA Lead по всей России:

• от 90 000 руб. 49
• от 145 000 руб. 43
• от 200 000 руб. 17
• от 255 000 руб. 9
• от 310 000 руб. 5

Вакансий с указанным уровнем дохода по Москве:

• от 205 000 руб. 8
• от 280 000 руб. 7
• от 355 000 руб. 3
• от 435 000 руб. 2
• от 510 000 руб. 1

Вакансий с указанным уровнем дохода по Санкт-Петербургу:

от 125 000 руб. 3

Как стать QA Lead и где учиться?

Варианты обучения для QA Lead:

• Самостоятельное обучение – всевозможные видео на YouTube, книги, форумы, самоучители и т.д. Плюсы – дешево или очень недорого. Минусы – нет системности, самостоятельное обучение может оказаться неэффективным, полученные навыки могут оказаться невостребованными у работодателя;
• Онлайн-обучение. Пройти курс можно на одной из образовательных платформ. Такие курсы рассчитаны на людей без особой подготовки, поэтому подойдут большинству людей. Обычно упор в онлайн-обучении делается на практику – это позволяет быстро пополнить портфолио и устроиться на работу сразу после обучения.

Ниже сделали обзор 3 лучших онлайн-курсов.

3 лучших курса для обучения QA Lead: подробный обзор

1 место. Курс «QA Lead» — OTUS

Стоимость: 108 000 ₽

Вы изучите все аспекты управленческой деятельности в контексте руководства командой тестировщиков и прокачаете Hard и Soft Skills. Курс позволит глубже осознать все аспекты процесса тестирования: стратегически и финансово планировать тесты, обосновывать целесообразность и внедрять практики тестирования, грамотно распределять задачи в командах.

Для кого этот курс:

• Для тех, кто хочет стать QA лидом, Тест-менеджером, руководителем тестирования и у кого полностью отсутствуют управленческие навыки.
• Для текущих управленцев, курс поможет систематизировать имеющиеся знания и предоставит новые знания.
• Для middle, senior разработчиков и системных аналитиков, курс поможет сменить профиль деятельности.

Во время обучения вы:

1. Получите и систематизируете знания о руководстве над процессом тестирования
2. Сможете сформировать команду «с нуля»: нанимать новых сотрудников, дизайнить эффективные команды, оценивать эффективность команды
3. Разовьете компетенции сотрудников, выстроите процессы наставничества, менторства и онбординга
4. Научитесь выстраивать отношения с сотрудниками, стейкхолдерами и бизнес-заказчиками
5. Выстроите процесс тестирования: оцените трудозатраты и планирование, ROI автоматизации, инфраструктуры тестирования и т.д.
6. Научитесь строить процесс в зависимости от используемого подхода к разработке: проектный подход, agile(scrum, kanban)
7. Создадите систему по сбору метрик качества продукта и построите процесс баг-менеджмента на своем проекте
8. Непрерывно эмпирически улучшите процесс, оценивая качественно и количественно эффективность тех или иных изменений.

Программа обучения

Модуль 1. Ответственности и обязанности QA лида

• Тема 1. QA Lead — зачем нужна эта роль?
• Тема 2. Навыки и роли QA Lead

Модуль 2. Формирование команды

• Тема 3. Дизайн команды
• Тема 4. Проведение собеседований
• Тема 5. Адаптация нового сотрудника

Модуль 3. Развитие компетенций сотрудников

• Тема 6. Процесс развития сотрудника
• Тема 7. Целеполагание: ИПР
• Тема 8. Целеполагание: OKR
• Тема 9. Обучение сотрудников

Модуль 4. Оценка эффективности сотрудника

• Тема 10. Работа с обратной связью
• Тема 11. Perfomance review
• Тема 12. Матрица компетенций

Модуль 5. Работа с мотивацией сотрудников

• Тема 13. Эмоциональное состояние команды
• Тема 14. Нематериальная мотивация
• Тема 15. Стабильность команды и взаимозаменяемость людей

Модуль 6. Понимание продукта и системы

• Тема 16. Бизнесовая составляющая продукта
• Тема 17. Техническая составляющая продукта
• Тема 18. Определение критериев качества

Модуль 7. Тестовое покрытие

• Тема 19. Методы тестирования требований
• Тема 20. Способы построения тестовой модели
• Тема 21. Оценка эффективности тестовой стратегии с помощью тестового покрытия

Модуль 8. Организация процессов и коммуникации

• Тема 22. Команды в процессе разработки
• Тема 23. Процессные методологии и тестирование в них
• Тема 24. Организация прозрачного и понятного процесса работы
• Тема 25. Коммуникации
• Тема 26. Фасилитация для построения продуктивных коммуникаций

Модуль 9. Автоматизация и работа с инфраструктурой

• Тема 27. Формирование стратегии тестирования
• Тема 28. Цели автоматизации тестирования
• Тема 29. ROI автоматизации
• Тема 30. Организация тестирования при различных методологиях разработки
• Тема 31. Управление инфраструктурой для тестирования

Модуль 10. Планирование и метрики

• Тема 32. Оценка трудозатрат и планирование тестирования
• Тема 33. Метрики
• Тема 34. Жизненный цикл бага
• Тема 35. Анализ метрик с багами
• Тема 36. Оптимизация тестовой модели

Модуль 11. Проектная работа

• Тема 37. Консультация по проектам и домашним заданиям
• Тема 38. Подведение итогов курса

Выпускной проект:

В итоговой проектной работе вы должны будете разработать стратегию тестирования на продукт/систему, в тестировании которой задействовано более 3-х команд.

• Описать процесс тестирования на продукт/систему с учетом архитектуры и имеющихся компетенций в командах.
• Подготовить планы развития по сотрудникам для достижения целей стратегии
• Рассчитать финансовую модель по необходимым изменениям (какое business value, какие инвестиции нужны будут)
• Сформулировать стратегию через OKR
• Подготовить 2 презентации:

— для руководителей и стейкхолдеров
— для своих сотрудников

После обучения вы:

1. Получите сертификат об окончании курса;
2. Будете уметь эффективно управлять командой тестировщиков;
3. Повысите свой профессиональный уровень в качестве QA Leader;
4. Сможете сформировать стратегию тестирования;
5. Сформируете команду, сможете ее мотивировать, оценить эффективность и точки роста;
6. получите приглашение пройти собеседование в компаниях-партнерах OTUS (в случае успешного обучения).

2 место. Курс «Руководитель команды тестирования (QA — Lead)» — Центр компьютерного обучения «Специалист» при МГТУ им.Н.Э.Баумана

Стоимость: 135 290 ₽ — 150 690 ₽

На программе вы изучите тестирование ПО от азов до продвинутых методов тестирования и получите необходимые знания по управлению командой проекта.

В программу включены курсы:

1. Руководитель структурного подразделения
2. Управление командой проекта. Роль и компетенции руководителя проекта
3. Тестирование ПО. Уровень 1. Тестировщик программного обеспечения
4. Тестирование ПО. Уровень 2. Тест-дизайн.
5. Тестирование ПО. Уровень 2. Управление командой тестировщиков.
6. Тестирование мобильных приложений
7. Автоматизированное тестирование веб-приложений с использованием Selenium
8. Эффективные переговоры.

Каждый проект уникален и у каждой команды свои задачи, цели и запросы. Однако всех объединяет желание работать в успешной команде и с инструментами, которые экономят время и позволяют QA-специалистам тестировать качественнее и быстрее.

При прохождении программы вы овладеете компетенциями руководителя и всем необходимым инструментарием, узнаете, как управлять командой проекта: контролировать и мотивировать участников, разрешать конфликты, научитесь тестировать программные продукты, получите практические навыки по работе с инструментами: Charles Proxy, Postman, Android Studio, ADB, Сервисом Browserstack, DevTools и др., узнаете современные подходы к проектированию тестов, рассмотрите техники функционального тестирования.

Программа предназначена для:

1. QA лидов, Тест-менеджеров

• Руководитель службы (проектов) тестирования
• Руководитель команды тестовых инженеров
• QA Manager/Руководитель отдела (команды) тестирования

1. Для текущих управленцев, для систематизации имеющиеся знаний и получения новых.

• Тест-дизайнер
• Ведущий тестировщик
• Старший инженер-тестировщик

1. Для middle, senior разработчиков и системных аналитиков — для развития компетенций.

3 место.Курс «Школа тест-менеджеров v. 2.0» — Software-Testing

Стоимость: 18 500 ₽ — 24 000 ₽

Этот курс создан для ведущих тестировщиков и руководителей тест-команд. Если вы отвечаете за организацию тестирования на проекте, то этот курс – именно то, что поможет вам достичь максимального результата.

Программа курса:

1. Введение, цели курса и цели тестирования

• Знакомство с курсом, тренером и группой
• Цели тестирования: какие бывают?
• Как выявить потребности вашего проекта от тестирования?
• TaaS: Testing as a Service

1. Процесстестирования

• Что такое процесс тестирования?
• Как адаптировать тестирование под модели разработки на проекте?
• Муда, Мури и остальные М: что мы делаем лишнего в своей работе?
• Поиск «узких горлышек» в тестировании, использование инструментов ТОС
• Варианты реализации гибкого и формального тестирования

1. Планирование тестирования

• Разработка и согласование тестовой стратегии
• Разработка формальных тест-планов (RUP, IEEE, ГОСТ)
• Инструменты управления планами

1. Оценка трудозатрат на тестирование

• Подходы к оценке трудозатрат (Estimations)
• Сбор статистики для повышения точности оценок
• KPI в оценке трудозатрат

1. Управление задачами и ошибками

• Ведение задач на проекте
• Разработка оптимального workflow для дефектов
• Формат ведения дефектов
• Сбор статистики пользовательских обращений

1. Управление тестами на проекте

• Исследовательское, Скриптовое и Сессионное тестирование
• Введение в тест-анализ и основные техники
• Инструменты для документирования тестов: как выбрать?
• Формат документирования тестов: как выбрать?
• Комбинирование различных подходов

1. Знакомство с клиентом

• Какова целевая аудитория вашего продукта?
• Какая статистика использования ПО?
• Как потребности клиентов и пользователей влияют на приоритеты в тестировании?
• Организация юзабилити-тестирования и бета-кампаний

1. Оценка качества продукта

• Что такое качество, и кто судья?
• Как определить готовность ПО к релизу?
• Метрики и KPI на релиз, итерацию, новые задачи в продукте
• Согласование внутренних критериев приёмки
• Вовлечение всей команды разработки в понятие качества

1. Организация автоматизированного тестирования

• Цели автоматизации тестирования
• Организация команды автоматизации
• Отбор тестов в автоматизированное тестирование

1. Инструменты автоматизированного тестирования

• Фреймворки автоматизированного тестирования
• Интерфейсы для автоматизации
• Средства разработки и управления автотестами
• Инфраструктура автотестирования: отчётность, автозапуск, тестовые среды.

1. Создание команды тестировщиков

• Как понять, какие сотрудники вам нужны? Создание профиля
• Поиск тестировщиков и разработка тестов для отбора кандидатов
• Оценка квалификации команды, матрица компетенций
• Увольнение

1. Организация командной работы в тестировании

• Распределение ролей между сотрудниками
• Передача знаний в команде
• Постановка и делегирование задач
• Контроль выполнения работ

1. Мотивация тестировщиков

• Вечный компромисс между рабочим и личным
• Создание среды комфорта на работе
• Вечный интерес и ответственность за свою работу
• Обратная связь руководителя
• Корпоративная культура

1. Оценка эффективности тестирования

• Что мы сделали хорошо, а что надо улучшать?
• Поиск оптимальных зон развития
• Метрики для оценки тестирования на проекте

1. План внедрения

• Интеграция всех рассмотренных техник
• Алгоритм по внедрению в зависимости от особенностей вашего проекта
• Мотивашечки для закрепления полученных навыков

1. Подведение итогов

• Сюрприз и выпускной.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 4.9 / 5. Количество оценок: 80

Оценок пока нет. Поставьте оценку первым.

Преимущества выбора курсов в РоманСеменцов.ру

1. Агрегатор онлайн-курсов

• Освойте новую профессию
• Дата начала: 2023-01-01
• Дата окончания: 2023-12-31
• Большой выбор курсов

2. Рейтинги онлайн-школ

• ТОП школ по любым направлениям
• Дата начала: 2023-01-01
• Дата окончания: 2023-12-31
• Рейтинги школ

3. Актуальное обучение

• Выбирайте лучшие курсы по отзывам реальных учеников
• Дата начала: 2023-01-01
• Дата окончания: 2023-12-31
• Реальные отзывы

Автор статьи. Ответственный за актуальный контент, текст и редактуру сайта. Эксперт по выбору профессии, курсов и профессий с 2016 года. Делюсь личным практическим опытом.