QA Engineer, или инженер по обеспечению качества, участвует в работе над качеством продукта от анализа требований до проверки перед релизом. Он оценивает риски, планирует проверки, проводит тестирование, фиксирует дефекты и помогает сохранять связь между требованиями, тестами и результатами.
При этом качество продукта не относится только к зоне QA. Разработчики отвечают за качество кода и модульные проверки, аналитики и владельцы продукта — за требования и критерии приёмки, DevOps — за инфраструктуру и окружения. Разберём, где проходят эти границы и какие задачи остаются за QA-инженером.
Что входит в зону ответственности QA-инженера
В зону ответственности QA-инженера входят анализ рисков, планирование и проектирование проверок, системное и регрессионное тестирование, работа с дефектами и контроль покрытия. Выполнение тестов — только одна часть этой работы.
Обеспечение качества отличается от непосредственного тестирования направленностью на предотвращение проблем. QA-инженер подключается к требованиям и критериям приёмки до появления готового кода, чтобы заранее найти неоднозначности, определить риски и понять, какие проверки понадобятся.
Работу по тестированию обычно разделяют на несколько связанных этапов: планирование, мониторинг и контроль, анализ, проектирование, подготовку тестов, их выполнение и завершение тестирования. Анализ отвечает на вопрос, что требуется проверить, а проектирование — как именно это сделать.
Такое разделение относится к командам, где перечисленные роли существуют отдельно. В конкретной компании обязанности пересекаются: например, QA-инженер сам пишет автотесты или разработчик участвует в системных проверках. Поэтому границы стоит определять по конкретным решениям и задачам, а не только по названиям должностей.
Чем зона QA-инженера шире тестирования
Зона QA-инженера шире непосредственного тестирования, если в неё входит предотвращение дефектов ещё до выполнения проверок. QA участвует в анализе требований, оценке рисков, обсуждении критериев приёмки и выборе подхода к тестированию.
Само тестирование позволяет обнаружить дефекты, но не доказывает их отсутствие. Если QA подключается только перед релизом, часть проблем команда находит уже после разработки, когда исправление затрагивает готовый код и связанные с ним решения.
Названия «QA-инженер» и «тестировщик» в компаниях используют по-разному. Поэтому точнее сравнивать не должности, а обязанности: выполняет ли специалист только проверки готового продукта или участвует также в планировании качества, анализе рисков и предупреждении дефектов.
При этом ответственность за качество нельзя полностью передать QA-инженеру. Разработчики, аналитики, владельцы продукта и другие участники отвечают за качество решений в своей части работы.
Где проходит граница обязанностей QA-инженера
Граница обязанностей QA-инженера проходит по уровню проверки и предмету решения. Разработчик отвечает за проверки, тесно связанные с кодом, QA — за системное поведение и риски продукта, бизнес — за приёмку результата, а DevOps — за работоспособность инфраструктуры тестирования.
На практике используют несколько уровней тестирования: модульный, интеграцию компонентов, системный, интеграцию систем и приёмочный уровень. Распределение между специалистами зависит от проекта, но проверки низкого уровня чаще находятся ближе к разработчикам, а системные — к QA.
Отдельная граница проходит по тестовой инфраструктуре. QA определяет, какие проверки и на каком этапе нужны команде, а работоспособность конвейера, стендов и другой инфраструктуры относится к специалистам, которые её поддерживают.
Что проверяет разработчик, а не QA-инженер
Разработчик отвечает прежде всего за проверки собственного кода на модульном уровне. Такие тесты находятся рядом с реализацией, быстро выполняются и позволяют находить проблемы до передачи функциональности на системное тестирование.
Google публиковал данные своей системы непрерывной интеграции: из примерно 4,2 миллиона тестов около 63 тысяч показывали нестабильный результат в течение недели. Среди малых тестов нестабильными были около 0,5%, среди средних — 1,6%, а среди больших — 14%.
Эти данные не означают, что крупные проверки не нужны. Они показывают, почему команде важно сочетать тесты разного уровня: быстрые изолированные проверки дают раннюю обратную связь, а более крупные проверяют взаимодействие частей системы.
Передачу задачи между разработкой и тестированием удобнее фиксировать в общем рабочем процессе. Когда команда привыкла отслеживать выполнение задач в одном месте, видно, какие изменения уже готовы к проверке и какие ещё находятся у разработчика.
Что берёт на себя SDET или инженер по автоматизации
SDET или инженер по автоматизации отвечает за инженерную реализацию автоматизированного тестирования: фреймворк, код автотестов, инфраструктуру запуска и интеграцию проверок в общий конвейер. Конкретное распределение зависит от структуры команды.
QA-инженер при этом определяет вместе с командой, какие риски стоит закрывать автоматическими проверками, какие сценарии требуют регулярного прогона и какой результат считается достаточным для продолжения сборки или выпуска.
Автоматизация не заменяет все виды тестирования. Повторяемые и стабильные сценарии подходят для автоматических проверок, а исследовательское тестирование и оценка пользовательского опыта требуют участия человека.
Что задаёт аналитик, а не QA-инженер
Аналитик и Product Owner задают содержание требований и критериев приёмки, а QA-инженер проверяет, можно ли эти условия однозначно проверить. Эта граница позволяет не смешивать решение о том, каким должен быть продукт, с решением о том, как подтвердить выполнение требования.
Для QA критерии приёмки становятся основой тестовых условий. Если формулировка допускает несколько трактовок или не содержит проверяемого результата, проблему стоит уточнить до начала разработки.
Такой разбор помогает находить неполные и противоречивые требования раньше, чем они превращаются в несколько разных вариантов реализации.
Где проходит граница между QA-инженером и DevOps
QA-инженер отвечает за требования к тестовым проверкам, а DevOps — за техническую работоспособность инфраструктуры, в которой они выполняются. К этой инфраструктуре относятся конвейеры сборки, окружения и механизмы запуска.
Например, QA определяет, какие автотесты нужно выполнить перед следующим этапом и какой результат должен остановить сборку. DevOps обеспечивает, чтобы соответствующий шаг конвейера запускался и работал стабильно.
Как QA-инженер выстраивает стратегию тестирования
QA-инженер выстраивает стратегию тестирования от рисков продукта: определяет, какие ошибки наиболее критичны, где вероятность проблемы выше и какие проверки нужны в первую очередь. Проверить все возможные комбинации во многих системах невозможно, поэтому объём тестирования приходится ограничивать осознанно.
После оценки рисков определяют уровни и типы тестирования, техники, необходимое покрытие, тестовые данные, окружения и критерии завершения. Эти договорённости фиксируют в тест-плане или другом документе команды.
Подход к тестированию проще сохранять в письменном виде. Например, команда может вести регламенты вместе с другой рабочей документацией, чтобы правила проверок не зависели от памяти отдельных участников.
Тестовая пирамида показывает распределение проверок по уровням, а не задаёт обязательные проценты. Общий принцип заключается в сочетании тестов разной гранулярности: быстрых изолированных проверок делают больше, а крупных сквозных — меньше из-за стоимости и длительности выполнения.
Как QA-инженер распределяет ручное и автоматизированное тестирование
QA-инженер распределяет ручные и автоматизированные проверки по цели тестирования, повторяемости сценария и необходимости человеческой оценки. Автоматизация подходит для стабильных повторяемых проверок, а ручной подход сохраняется там, где требуется исследование поведения продукта или пользовательского опыта.
Исследовательское тестирование сочетает изучение продукта, проектирование проверки и её выполнение. Следующий шаг зависит от того, что тестировщик обнаружил на предыдущем, поэтому полностью заменить такой процесс заранее написанным автоматическим сценарием нельзя.
Набор автотестов при этом требует регулярного пересмотра. Сценарии меняются вместе с продуктом, а проверки, которые больше не соответствуют актуальным рискам, перестают приносить нужную информацию.
На каких этапах QA-инженер включается в разработку
QA-инженер включается в работу уже на этапе требований, до появления готового кода. Такой подход помогает обнаруживать неоднозначности и риски раньше и заранее готовить необходимые проверки.
Раннее подключение тестирования часто называют shift-left, или сдвигом влево: проверки и действия по обеспечению качества переносятся на более ранние этапы разработки.
На этапе требований QA ищет неоднозначности, неполные условия и противоречия. До завершения разработки готовит тестовые сценарии и данные. После появления работающего функционала проводит динамические проверки, а перед релизом оценивает влияние изменений и необходимый объём регрессии.
Раннее тестирование требует времени на старте, но позволяет исправлять часть проблем до того, как они затронули код и связанные компоненты.
Как QA-инженер проводит регрессию перед релизом
QA-инженер проводит регрессионное тестирование, чтобы проверить, не нарушили ли изменения ранее работавшую функциональность. Его не следует смешивать с подтверждающим тестированием конкретного исправления.
Подтверждающая проверка отвечает на вопрос, исправлен ли найденный дефект. Регрессионная — не вызвало ли изменение новых проблем в том же компоненте, соседних функциях или связанных системах.
Объём регрессии определяют по влиянию изменения. Если известно, какие компоненты и сценарии оно затрагивает, команда выбирает связанные проверки вместо полного прогона всего набора после каждой правки.
Для завершения тестирования учитывают:
- достигнутое покрытие;
- количество и серьёзность нерешённых дефектов;
- результаты критичных тестов;
- остаточные риски выпуска.
Повторяемую регрессию удобно вести чек-листами , связанными с задачами: команда видит, какие проверки уже выполнены, что осталось и кто отвечает за следующий шаг.
Кому QA-инженер передаёт дефекты в команде
QA-инженер передаёт дефект специалисту, который отвечает за его исправление, через общий процесс работы с ошибками. До передачи проблему нужно описать так, чтобы команда смогла воспроизвести её, оценить влияние и принять решение о приоритете.
Дефект проходит несколько состояний: обнаружение, описание, разбор, решение об исправлении, работа разработчика, повторная проверка и закрытие. В ходе разбора также может выясниться, что проблема относится не к дефекту, а к изменению требований или ожидаемому поведению.
В карточке дефекта фиксируют основные данные:
- продукт, компонент и окружение;
- условия и шаги воспроизведения;
- ожидаемый результат;
- фактический результат;
- серьёзность проблемы;
- статус;
- ссылки на связанные задачи и проверки.
Серьёзность описывает влияние дефекта на работу продукта, а приоритет определяет очередность исправления. QA предоставляет данные о проблеме и её последствиях, а решение о месте дефекта в плане работ принимают участники, отвечающие за релиз и приоритеты.
Когда дефект передают разработчику, его удобно оформлять по тем же принципам, по которым команда привыкла ставить задачи разработчикам: внутри карточки остаются окружение, шаги воспроизведения и ожидаемый результат.
Как QA-инженеру сохранять связь между требованиями, проверками и дефектами
QA-инженеру помогает прослеживаемость — сохранённая связь между требованием, проверкой, результатом тестирования и найденным дефектом. По ней видно, какие требования уже проверены, где есть проблемы и какие части продукта потребуется перепроверить после изменения.
Такая связь решает сразу две задачи. Во-первых, показывает покрытие требований проверками. Во-вторых, помогает оценивать влияние изменений: если меняется требование, видно, какие тесты и связанные дефекты относятся к нему.
Прослеживаемость особенно трудно поддерживать, когда требования, задачи, тестовые материалы и дефекты находятся в разных системах. Перед релизом данные приходится сопоставлять вручную, а часть связей остаётся только в переписке.
В Strive команда может организовать работу тестировщиков в общем рабочем пространстве и хранить рядом задачи, инструкции, чек-листы и другие материалы для проверок.
Когда задачи проходят последовательные статусы, участники видят, что уже передано в тестирование, что вернулось разработчику на исправление и что ожидает повторной проверки.
Тот же принцип работает на канбан-доске. Если команда ведет задачи со статусами, переходы между разработкой, тестированием, исправлением и повторной проверкой видны без отдельного сбора информации в переписке.
Работа QA-инженера включает не только поиск дефектов, но и анализ рисков, подготовку проверок, участие в требованиях, регрессию и сохранение связи между требованиями, тестами и результатами. При этом качество остаётся общей ответственностью команды: QA помогает сделать риски и состояние проверок видимыми, но не заменяет работу разработчиков, аналитиков, DevOps и владельцев продукта.
