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

Найденный баг может быть сигналом о проблемах в процессе, а не просто результатом тестирования

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

Разберём на конкретном кейсе из практики Modus и возьмём изменение, которое выглядит абсолютно локальным — например, после авторизации пользователя нужно отобразить страницу пользовательского соглашения.

Звучит просто: пользователь логинится, принимает соглашение, попадает в продукт. С точки зрения задачи — новый эндпоинт на бэке (POST /agreement/accept), флаг agreement_accepted в профиле пользователя и одна дополнительная страница на фронте. Но если посмотреть шире, картина меняется — это изменение затрагивает один из самых критичных процессов системы, авторизацию. А значит, в системе появляется новая ветка пользовательского сценария:

авторизация → принятие соглашения → получение пользовательского контекста → переход в систему

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

Поэтому инженер качества смотрит не только на новую функциональность. Он задаёт себе вопрос: «Что ещё может измениться из‑за появления новой ветки авторизации?»

Это и есть анализ влияния изменений (Impact Analysis). Его цель — определить, какие компоненты системы могут быть затронуты изменением, даже если на первый взгляд они с ним никак не связаны. Такой анализ нужен не для того, чтобы «проверить всё подряд» (это невозможно), а чтобы сфокусироваться на самых рискованных областях.

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

Как риск выстрелил на практике

Все началось просто: API вернул поле permissions не в виде массива объектов, а в виде строки — сериализованный JSON приехал как обычный текст. Из‑за этого на фронте пропала возможность редактировать отчёты, потому что клиент попросту не смог разобрать этот тип.

Ожидаемый ответ API:

"permissions": [

    {

        "edit": 1,

        "settings": 1,

        "view": 1

    }

]

Фактический ответ API:

"permissions": "[{"view": 1, "edit": 1, "settings": 1}]"

Разница ровно в кавычках и экранировании: во втором варианте это уже не массив, а строка «[{…}]», которую фронт ожидаемо не смог смапить в объект прав. Классическая ошибка сериализации — где‑то по пути объект прогнали через лишний JSON.stringify или отдали как строку из хранилища.

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

Баг обнаружили потому, что ещё на этапе анализа изменения был выведен риск: новая ветка авторизации может повлиять на пользовательский контекст. Поэтому помимо тестирования самой новой страницы заранее запланировали:

• проверку структуры ответа API (типы полей, а не только их наличие);

• корректность ролей и прав пользователя;

• ключевые сценарии, которые от этих прав зависят (в том числе редактирование отчётов).

Баг не «попался случайно» — он попал точно в зону, которую заранее пометили как опасную.

Почему это важно в большом продукте

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

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

Ранний анализ рисков доступен даже для неопытных QA‑инженеров

Представим разработку в виде временной линии. «Лево» — это начало проекта: идея, требования, написание кода, а «право» — прод и эксплуатация. Тогда Shift‑Left — это перенос задач тестирования и контроля качества как можно левее, к ранним этапам разработки — на груминг, ревью требований, обсуждение задачи в комментариях Jira, ещё до того, как разработчик создал ветку.

Сначала может показаться, что shift‑left testing — это история исключительно для Middle или Senior QA, которые лезут в код и пишут автотесты в CI. Но это не так. Shift‑left — это в первую очередь про образ мыслей, а не про уровень грейда. Даже начинающий тестировщик может задавать вопросы к требованиям, анализировать влияние изменений и помогать команде отлавливать дефекты ещё до того, как написана первая строчка кода.

Поэтому, когда к вам приходит задача, первым делом попробуйте задать себе (и команде) уточняющие вопросы по требованиям. В идеале — до того, как разработчик сядет писать код. Это снизит риски того, что задача будет проходить несколько циклов итераций «сделал → ревью → переделал». 

Вопросы, которые стоит задавать до старта разработки

Ниже — несколько примеров вопросов, основанных на нашей системе в Modus BI:

• Как должна повести себя система, если пользователь решит закрыть отчёт на этом шаге? Такие сценарии часто выпадают из виду — все по умолчанию проектируют «счастливый путь» (happy path) и подразумевают, что пользователь всегда проходит флоу до конца. А он берёт и закрывает вкладку на середине.

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

• Если пользователь авторизуется через сторонние сервисы, сохраняется ли логика поведения продукта? То есть будет ли одинаково работать флоу при логине через SSO, OAuth‑провайдера и стандартный login/password — не только в момент входа, но и в дальнейших сценариях, где используется профиль.

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

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

Фокус на ценности, а не на покрытии

В начале карьеры многие пишут тест‑кейсы буквально на всё подряд — проверить цвет кнопки, отступ, шрифт, выравнивание. Это абсолютно нормально и кажется, что у нас отличный уровень «покрытия»: кейсов сотни и всё расписано. 

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

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

Но что, если тестировать по принципу: «Тестируй то, что важно, и исследуй то, что опасно». По сути, это риск‑ориентированное тестирование (Risk‑Based Testing): время команды ограничено, поэтому в первую очередь проверяются наиболее критичные сценарии и самые рискованные изменения. К «опасному» обычно относится всё, что трогает деньги, права доступа, интеграции с внешними сервисами, миграции БД и фоновые джобы — то есть места, где ошибка не откатывается одним F5. 

Простой пример. Форма авторизации с точки зрения UI идеальна: пиксель в пиксель по макету, все отступы выверены, шрифты те самые. Но при этом пользователь не может залогиниться через сторонний сервис — OAuth‑редирект возвращается с корректным code, а бэкенд не может обменять его на токен и возвращает ошибку 500. В таком случае тестирование теряет свою ценность: формально проверено много, а до основного сценария пользователь просто не доходит.

Поэтому лучше сместить фокус с косметики на логику и безопасность — так полезнее и для тестировщика, и для самого продукта.

Качество — ответственность всей команды, а не только QA

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

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

Чтобы изменить паттерн «только QA несет ответственность за качество продукта», нужно говорить не только о том, какие баги нашли, но и о том, почему они вообще появились. И предлагать системные правки процесса, а не разовые заплатки. Например:

• Функциональность сломалась, потому что нигде не описано, какие компоненты системы могло затронуть изменение кода. Давайте выделим в шаблоне PR/задачи секцию, в которой разработчики будут писать затронутые области — например, «изменяет контракт API», “трогает миграцию”, «влияет на права».

• Разработчик сделал не то, потому что в задаче нет чётких требований к итоговой функциональности. Давайте введём обязательный блок: Критерии приёмки (Acceptance Criteria) — в формате Given / When / Then, чтобы и разработчик, и QA видели одинаковую картину до старта работы.

Это не значит, что вы придираетесь к мелочам. Наоборот — это меняет восприятие QA в команде. Тестировщик перестаёт быть единственным, кто ищет баги (и виноватым, если что‑то пропустил), и становится человеком, который помогает сделать продукт стабильнее в начале разработки.

Заключение

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

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

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

P. S. Присоединяйтесь к нашему BI‑сообществу в Telegram и будьте в курсе последних новостей Modus!