Вернуться к блогу
В заказной разработке есть опасный миф: тестирование – это финальный «полировочный» этап, который можно сжать, если сроки поджимают. На практике ошибки, пропущенные на старте, обходятся бизнесу дороже, чем спокойная работа с качеством по ходу проекта.
В Amiga мы смотрим на QA шире, чем на поиск дефектов. Для нас QA в заказной разработке – это управление рисками качества на протяжении всего жизненного цикла продукта: от требований и архитектуры до релиза, поддержки и развития. Сначала мы определяем приоритеты проверки: определяем критичные бизнес-сценарии, согласуем список приоритетных устройств и браузеров и фиксируем критерии готовности к релизу.
Такой подход помогает сначала проверять самые важные зоны продукта, а уже потом переходить к менее критичным деталям.
В этом руководстве разберем, как QA включается в проект, зачем бизнесу тест-план, что входит в хороший баг-репорт, где помогает автоматизация и почему качественный релиз начинается задолго до кнопки Deploy.
Эти мифы лучше проговорить в начале проекта. Тогда у команды появляется общий порядок: как мы работаем, за что отвечает QA, где помогает автоматизация и в каких случаях бизнес принимает решение по рискам.
Ни одна команда не гарантирует 100% всех возможных действий пользователя. Мы в Amiga строим QA-процесс иначе: выделяем критичные сценарии, проверяем слабые места, удерживаем регресс и помогаем продукту корректно обрабатывать ошибки.
Это разные роли. Разработчик строит логику, QA проверяет, как эта логика ведет себя в реальности: при странных данных, слабой сети, ошибках сервера, разных ролях и неожиданных действиях пользователя.
Автоматизация полезна только там, где уже есть понятные процессы и стабильные сценарии. Поэтому сначала мы наводим порядок в тест-кейсах, приоритетах и критериях приемки, а потом автоматизируем то, что действительно повторяется и влияет на релиз.
Если тестировщик впервые видит продукт за два дня до сдачи, он может зафиксировать проблему, но уже почти не влияет на ее стоимость. Поэтому QA подключается не в конце, а поэтапно.
Такой подход совпадает с тем, как мы выстраиваем тестирование web-продуктов: не как разовую проверку, а как системную работу с надежностью, функциональностью и ожиданиями пользователей.
QA работает поэтапно: помогает найти риски в требованиях, подготовить проверки, стабилизировать релиз и поддерживать продукт после запуска.
Качество нельзя прикрутить к продукту в последний вечер перед релизом. Оно появляется там, где команда заранее договорилась о требованиях, граничных сценариях, тестовых данных, критериях приемки и правилах выпуска.
Мы начинаем работу над качеством еще на этапе аналитики. QA-специалисты вместе с аналитиками, архитекторами и разработчиками изучают требования и задают вопросы, которые экономят бизнесу время позже.
Автоматизация в QA нужна не для красивого слова в отчете. Она закрывает повторяемые проверки, которые человек может пропустить из-за усталости или дедлайна.
Мы используем CI/CD-процессы там, где каждый коммит проходит базовый набор проверок. Так команда быстрее видит, не сломали ли изменения уже работающий функционал. Но автоматизация не заменяет мышление QA: сначала нужны понятные сценарии, тест-кейсы и приоритеты, затем скрипты.
Граница простая: частые, стабильные и критичные сценарии лучше автоматизировать. Редкие проверки, меняющиеся интерфейсы и исследовательское тестирование часто разумнее оставить ручной проверке.
Пример из e-commerce-проекта: перед релизом промо-функционала QA проверял сценарий покупки по акции: оплату в «идеальных» условиях, повторное нажатие на кнопку, задержку ответа платежного сервиса и нестабильную сеть.
В одном из сценариев пользователь мог нажать «Оплатить» дважды, пока первый запрос еще обрабатывался. Интерфейс выглядел нормально, но сервер получал два события. Для клиента это означало риск двойного списания, обращений в поддержку и репутационных потерь в день запуска.
Мы остановили релиз фичи, зафиксировали баг и договорились с командой, как закрываем риск: блокируем повторное действие на фронте, добавляем идемпотентность на стороне backend и покрываем сценарий регрессионной проверкой. Релиз сдвинули, но не выпустили проблему к пользователям. Это хороший пример того, зачем QA нужен не только для поиска визуальных дефектов, а для защиты бизнес-процесса от двойного списания, потери заказа или некорректного статуса оплаты.
Наша экспертиза не ограничивается одним стеком. Мы работаем с мобильными приложениями, веб-интерфейсами, backend, API и интеграциями. Поэтому QA смотрит не только на экран, но и на данные, права доступа, состояния сети, браузеры, устройства, версии ОС и поведение продукта после обновлений.
Перед выбором проверок мы разбираемся, что для бизнеса критично именно в этом продукте: оплата, регистрация, личный кабинет, интеграции, доступность сервиса, корректность данных или скорость обработки заявок. От этого зависит набор проверок: где нужен подробный регресс и список приоритетных устройств, а где достаточно smoke-проверки.
В мобильных проектах QA учитывает особенности iOS, Android, Flutter и нативной разработки. Подробнее о подходе к mobile можно посмотреть в услуге мобильной разработки Amiga.
В web-проектах важны браузеры, адаптивность, API, нагрузка и стабильность пользовательских сценариев. Это напрямую связано с нашей веб-разработкой и поддержкой сложных интерфейсов.
Мы не работаем «на глаз». Набор инструментов зависит от проекта, но обычно включает проверенные решения:
Хороший баг-репорт – это язык, на котором общаются бизнес, QA и разработчик. Его задача – убрать догадки и быстро довести проблему до исправления.
Хороший баг-репорт убирает догадки: команда видит шаги воспроизведения, фактический и ожидаемый результат, severity, priority и доказательства.
Мы не объединяем разные проблемы в одну задачу. Если не работает кнопка «Оплатить» и криво отображается шрифт, это два разных дефекта. Так команда видит реальные проблемные зоны и принимает управленческие решения: исправлять точечно, переписать модуль или усилить регресс.
Summary. Краткое и понятное описание проблемы.
Steps to reproduce. Пошаговый алгоритм без лишней интерпретации: открыть, нажать, ввести, подтвердить.
Actual result. Что произошло фактически.
Expected result. Что должно было произойти по требованиям или согласованному сценарию.
Severity. Насколько дефект влияет на продукт: блокирует сценарий, мешает части пользователей или относится к визуальной мелочи.
Priority. Как быстро дефект надо исправить с точки зрения бизнеса и релиза.
Environment. Для mobile: устройство, версия ОС, версия приложения, состояние сети. Для web: браузер, версия браузера, ОС, разрешение экрана, окружение.
Evidence. Скриншот, видео, лог, ссылка на запрос или запись сетевого трафика.
Для начинающих QA и команд, которые хотят прокачать документацию, полезен отдельный материал Amiga про баг-репорт, тест-кейс и чек-лист.
Чек-лист – это не формальность, а способ не потерять важные сценарии в плотном спринте. Внутри проекта чек-листы делятся по зонам ответственности.
В разработке случается всякое. Иногда критичный дефект находится за час до дедлайна. В такие моменты мы не прячем проблему за красивым отчетом, а показываем клиенту три вещи: что сломано, какие последствия для бизнеса и какие варианты решения есть.
Мы не принимаем решение за бизнес, но даем достаточно фактов, чтобы выбрать меньшее из зол. Иногда лучше сдвинуть релиз на день, чем пустить пользователей в сервис, где не работает оплата или теряются заявки.
Если мы видим, что модуль держится на временном решении, мы фиксируем это как технический долг. В заказной разработке не всегда получается сделать все идеально с первого раза: бывают сжатые сроки, меняющиеся требования и компромиссы. Важно не копить долг в тишине, а заранее обсудить с заказчиком план исправления.
Лучше подключать QA на этапе аналитики и проектирования. Тогда команда проверяет требования, сценарии, ограничения и риски до того, как они превращаются в дорогие изменения в коде.
Тестировщик чаще фокусируется на поиске дефектов и проверке конкретных сценариев. QA специалист шире: он помогает не только с тестированием, но и построением процесса качества вокруг продукта – от анализа рисков и критериев приемки до регресса, релизной готовности и поддержки после запуска.
Минимум: summary, шаги воспроизведения, фактический результат, ожидаемый результат, severity, priority, окружение и доказательства: скриншот, видео, лог или ссылка на запрос.
Нет. Автоматизация окупается на повторяемых, стабильных и критичных сценариях. Если продукт активно меняется, часть проверок разумнее оставить ручной или исследовательской.
Перед релизом QA проводит smoke-тест критичного функционала, повторно проверяет ключевые исправления и убеждается, что в релизной версии нет блокирующих дефектов.
Иногда да, если дефекты не критичны и бизнес понимает последствия. Важно оценить severity и priority, зафиксировать риски и договориться, когда команда закрывает оставшиеся задачи.
QA в заказной разработке защищает бизнес не красивыми отчетами, а предсказуемостью. Команда заранее видит риски, проверяет требования, фиксирует дефекты понятным языком, удерживает регресс и помогает принять честное решение перед релизом.
Хороший QA-процесс не обещает магии. Он делает другое: снижает вероятность дорогих ошибок, помогает продукту выдерживать реальные сценарии пользователей и превращает релиз из лотереи в управляемый этап разработки.
