Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про процесс тестирования программного обеспечения.
Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а также преподаю на курсах разработки и архитектуры в OTUS. За годы работы я видел десятки команд, которые считали, что тестирование — это просто «прогнать тесты и сдать отчёт». Это опасное заблуждение. В прошлой статье мы разбирали природу дефектов и то, как они проникают в код. Сегодня поговорим о том, как выстроить вокруг них системную защиту — процесс тестирования.
Тестирование — это не этап, а параллельный процесс
Одна из самых устойчивых иллюзий в IT выглядит так: сначала пишем код, потом передаём тестировщикам, те проверяют и выдают вердикт. В реальности такой подход гарантирует одно — хроническую нехватку времени на тестирование в конце спринта и панику перед релизом.
Полностью разделяю подход, описанный во многих источниках о том, что: тестирование — это не отдельный вид деятельности, а процесс, протекающий параллельно с остальными операциями. И начинается он задолго до первого запуска приложения.
Наверняка многие думают, что тестирование исчерпывается выполнением тестов. На самом деле прогон тестов — лишь верхушка айсберга. Основная работа происходит до и после: планирование, анализ, проектирование, реализация, мониторинг и завершение.
Не раз убеждался: чем раньше в процесс включается тестовая активность, тем меньше сюрпризов на финальной стадии. И наоборот — когда тестирование рассматривают как «последний этап», баги находят, но исправлять их уже некогда.
Процесс тестирования: 7 групп мероприятий
Давайте разложим процесс на составляющие. В нём выделяют семь основных групп мероприятий. Это не строгая последовательность, а скорее набор взаимосвязанных активностей, которые могут выполняться параллельно или итеративно.
1. Планирование тестирования
На этом этапе мы отвечаем на вопрос: «Что и как мы будем тестировать?». Формируется стратегия, определяются цели, ресурсы, сроки, критерии начала и окончания тестирования.
Планирование на первый взгляд кажется скучной формальностью, но реально его можно рассматривать как инвестиции: час, потраченный на план, экономит неделю неверно выстроенного процесса.
2. Мониторинг и контроль тестирования
Это постоянное сопоставление фактического хода работ с запланированным. Сюда входит сбор метрик, отслеживание прогресса, анализ отклонений и принятие корректирующих мер.
Многие команды настраивают дашборд, который показывает не только количество пройденных тестов, но и динамику покрытия критических сценариев. Это позволяет контролировать и замечать критические моменты в процессе.
3. Анализ тестирования
Здесь мы изучаем требования, документацию, архитектуру и выделяем тестовые условия — то, что нужно проверить. Это не тест‑кейсы, а именно объекты для проверки: «корректность расчёта процентов», «обработка ошибки при недоступности БД», «поведение при невалидном email».
Анализ — это момент, когда тестировщик превращается в сыщика. Хороший тестировщик видит дыры там, где требования молчат.
Пример из практики. В одном проекте требование звучало так: «Система отправляет уведомление при регистрации». Прочитав это, у тестировщика возник резонный вопрос: а что, если email‑сервис недоступен? Регистрация должна падать? Или уведомление уходит в очередь? А если очередь переполнена? По факту оказалось, что это никто не проработал в требованиях и если бы не этот вопрос, то в продакшене бы все получили либо недоступный сервис регистрации, либо «молчаливо» потерянные уведомления.
4. Тест‑дизайн (проектирование тестов)
На этом этапе высокоуровневые тестовые условия превращаются в конкретные тест‑кейсы. Выбираются техники тест‑дизайна: классы эквивалентности, граничные значения, таблицы решений, попарное тестирование и другие.
Часто тест‑дизайн путают с реализацией. Но это разные вещи. Проектирование — это мышление: «как сломать систему?», а реализация — это запись.
Для сложной логики всегда прошу команду использовать диаграммы состояний или таблицы решений. Они выявляют неочевидные комбинации. Однажды таблица решений для формы из пяти полей показала, что при определённых условиях система должна блокировать операцию, хотя в требованиях это не было прописано. Мы добавили сценарий до начала разработки — и как выяснилось в итоге, это существенно позволило сэкономить время процесса тестирования.
5. Реализация тестов
Создание наборов тестов из готовых тест‑кейсов. Это может быть формирование тестовых наборов для регресса, подготовка тестовых данных, написание автотестов.
На этом этапе важно не просто собрать всё в кучу, а структурировать: выделить smoke‑набор для быстрой проверки после сборки, критический набор для обязательного прогона перед релизом, регресс для глубокой проверки.
6. Выполнение тестов
Непосредственный прогон тестов. Ручной или автоматизированный. Сравнение фактического результата с ожидаемым. Запись дефектов.
Но выполнение — это не просто про «нажать кнопку». Тут от команды требуется, чтобы перед началом выполнения у всех было чёткое понимание критериев завершения. Это обязательная часть плана и каждый должен понимать критерии (которые должны быть формализованы и лучше в цифрах) когда процесс будет считаться завершенным.
7. Завершение тестирования
Финальные мероприятия: анализ завершённых работ, архивация артефактов, оценка того, что прошло хорошо, а что нет, составление отчёта о тестировании.
Здесь часто упускают ретроспективу процесса тестирования. А зря. Именно на этом этапе рождаются инсайты для будущих проектов: какие сценарии оказались избыточны, какие техники тест‑дизайна сработали, где узкие места. Здесь лучше фиксировать свои мысли на тему — «Что можно было сделать лучше, качественнее и быстрее?»
Процесс тестирования наглядно
Попробуем визуализировать логику процесса. На рисунке 1 представлена диаграмма, показывающая, как группы мероприятий связаны между собой.
Обратите внимание: мониторинг и контроль пронизывают все этапы. Это не линейный конвейер, а гибкая система с обратными связями. Если на выполнении тестов мы видим, что покрытие недостаточно, мы возвращаемся к анализу или тест‑дизайну — и это нормально.
Best practice: как мы выстроили процесс в команде
Некоторое время назад возникла задача о перестройке процесса тестирования. Команда состояла из 12 разработчиков и 3 тестировщиков. Исходный процесс выглядел так: тестировщики начинали работать, когда разработка «заканчивалась», но при этом тестирование всегда вываливалось за установленные сроки.
После нескольких продуктивных обсуждений процесса был найден ряд решений, которые помогли исправить ситуацию:
Анализ тестирования стартует на этапе уточнения требований. Тестировщик участвует в grooming, задаёт вопросы, выявляет тестовые условия ещё до того, как написана первая строка кода.
Тест‑дизайн идёт параллельно с разработкой. Пока пишется код, проектируются тест‑кейсы. К моменту готовности фичи тесты уже готовы к прогону.
Автоматизация на уровне тест‑дизайна. Мы внедрили подход, когда тест‑дизайн сразу ведётся в формате, пригодном для автоматизации (Gherkin). Это снизило порог входа для автоматизаторов.
Мониторинг через дашборды. Каждый день видно не только сколько тестов пройдено, но и динамику покрытия по модулям. Если какой‑то модуль «зависает» без тестов, это видно за неделю до критической точки.
Ретроспектива тестирования после релиза. Обсуждаем не только что нашли, но и что упустили, почему, как не допустить в следующий раз.
Результат: время от начала разработки до выкатки заметно сократилось. А главное — команда перестала работать в режиме аврала перед каждым релизом!
Что дальше?
Мы разобрали, из каких мероприятий состоит процесс тестирования и почему нельзя сводить его только к прогону тестов. Это фундамент, на котором строится качество продукта. Но теория — это только полдела. Настоящее мастерство приходит, когда вы начинаете применять эти принципы в реальных проектах, адаптировать под контекст, выбирать нужные техники тест‑дизайна и выстраивать мониторинг.
Когда нужно не просто находить баги, а выстраивать тестирование как понятный и управляемый процесс — с приоритетами, метриками и нормальной работой команды, — нужен следующий шаг. Курс «QA Lead» помогает перейти от выполнения тестовых задач к управлению качеством на уровне команды и процесса.
Нет времени учиться «когда‑нибудь потом», а задача расти в роли уже горит, удобно заходить в обучение в момент, когда это можно сделать выгоднее.
С 1 по 4 апреля в честь дня рождения OTUS действует дополнительная скидка 10% по промокоду birthday на любые курсы. Она суммируется с другими скидками — это шанс не откладывать решение, которое и так давно назрело. ➡
[Получить скидку]
Если вам интересно погрузиться глубже, разобрать реальные кейсы и научиться выстраивать эффективный процесс тестирования, приходите на на бесплатные уроки:
14 апреля 19:00. «Внедрение автотестирования с участием искусственного интеллекта». Записаться
16 апреля 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться
