Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java/Kotlin разработки в FinTech, а также преподаю на курсах в OTUS. В этой статье я хочу поговорить о том, что часто остаётся за кадром красивых диаграмм и идеальных user stories — о дефектах.
Когда мы проектируем API или разрабатываем сервис, мы обычно мыслим позитивно: как это будет работать, какой красивый ответ вернётся, как быстро пройдёт запрос. Но любой инженер со стажем вам скажет: система начинается не с успешного сценария, а с того, как она ломается. И именно здесь, в управлении дефектами, чаще всего и кроется разница между системой, которая просто «написана», и системой, которая надёжно работает в продакшене годами.
Дефект — это не баг, а часть жизненного цикла продукта
Мы привыкли называть это «багами». Но если копнуть глубже, дефект — это не просто ошибка в коде. Это следствие цепочки: ошибка человека → дефект в артефакте (требованиях, коде, конфигурации) → сбой в системе.
Часто провожу параллель с производством. Если на конвейере завода чертёжник ошибся в спецификации (ошибка), то технолог сделает не ту оснастку (дефект), и в итоге готовое изделие не подойдёт к сборочному узлу (сбой). В разработке ровно так же. И важно понимать: тестировщик не может исправить дефект. Он может только сделать его видимым. Это как подсветка фонариком в тёмной комнате: вы не убираете хлам, но наконец‑то видите, куда наступать нельзя.
Жизненный цикл дефекта: от хаоса к системе
В моей практике было много проектов, где управление дефектами сводилось к переписке в Telegram: «Серёга, упало тут, посмотри». Это работает, пока вас двое. Но когда команда из 20 человек, а спринт идёт к релизу, такой подход превращается в ад.
Именно поэтому в любом зрелом процессе управление дефектами — это формализованный жизненный цикл. Он не ради бюрократии, а ради одного: чтобы ни один дефект не потерялся, и каждый понимал, что с ним сейчас происходит.
Классический жизненный цикл дефекта выглядит так:
Каждый статус здесь — это триггер для конкретных действий. Когда дефект переходит в статус «Назначен», я, как Tech Lead, уже не должен гадать, кто его чинит. Когда он в «Повторном тестировании», тестировщик точно знает, что пора проверять. Это не про контроль, это про снятие неопределённости.
И вот пример — после того, как мы внедрили строгие статусы на проекте, где до этого дефекты жили в общей таблице Excel, то через две недели время закрытия критического дефекта сократилось с 3 дней до нескольких часов. Не потому, что разработчики стали быстрее писать код, а потому что перестали тратить время на поиск информации: кто отвечает, что уже сделано, а что ещё нет.
Кто и как меняет статусы: роли в процессе
Ключевая вещь, которую часто упускают, — это матрица ответственности. В хорошем процессе нельзя, чтобы разработчик сам себе закрыл дефект, а тестировщик назначил его в работу. Это конфликт интересов, который убивает качество.
У нас в FinTech мы используем чёткое разделение прав при работе с трекерами (Jira, YouTrack или любым другим инструментом):
Новый → Открыт / Новый → Отклонен: Это право тест‑лида или ведущего разработчика. На этом этапе мы отсеиваем дубликаты, невоспроизводимые сценарии и дефекты, которые по факту не дефекты, а «так и задумано». Если пропустить сортировку, разработчики будут тратить время на исправление того, что не нужно исправлять.
Открыт → Назначен: Здесь уже включается планирование. Ведущий разработчик или бизнес‑аналитик определяет, кто из команды будет заниматься задачей.
Назначен → В работе: Мой любимый статус. Его может менять только тот, кому дефект назначен. Это сигнал для всей команды: «всё, я в теме, не трогайте».
В работе → Исправлен: Меняет разработчик после того, как внёс изменения. Обратите внимание: он не закрывает дефект, а только говорит «я сделал».
Исправлен → Повторное тестирование: Этот переход — исключительно за тестировщиками. Они проверяют, действительно ли проблема ушла. Если нет — статус возвращается в «Открыт».
Это не просто workflow. Это система, которая защищает вас от ситуации, когда разработчик «починил» одно, но случайно сломал три смежных сценария, а дефект тем временем закрыли и забыли.
Сортировка дефектов: где зарыты грабли
Есть ещё один ритуал, который я считаю обязательным, но который многие команды недооценивают — это сортировка дефектов (defect triage). Это не просто совещание, это фильтр качества.
Мы собираемся раз в 2–3 дня (или чаще, если близится релиз) всем ядром: разработчики, тестировщики, бизнес‑аналитики. И на этом совещании мы смотрим на все дефекты в статусе «Новый» и отвечаем на три вопроса:
Достоверен ли дефект? Может, это проблемы тестовых данных или кривые руки тестировщика?
Какова его серьёзность? Это критический простой всего сервиса или просто опечатка на кнопке?
Каков его приоритет? Что важнее: чинить этот дефект или доделывать новую фичу?
И здесь начинается самое интересное. Часто вижу, как джуниоры смешивают серьёзность и приоритет. Это разные вещи.
Серьёзность (Severity) — это техническое влияние дефекта на систему. Критическая серьёзность (Severity 1) — это когда компонент не работает вообще. Например, не проходит оплата. Низкая (Severity 4) — орфографическая ошибка.
Приоритет (Priority) — это бизнес‑важность устранения. Высокий приоритет — значит, это нужно сделать прямо сейчас, потому что иначе мы не выпустим релиз или блокируем других.
Например — был у нас кейс: дефект с «неправильным отображением логотипа на странице успешной оплаты». Серьёзность — низкая (на работу системы не влияет). Но приоритет — срочный, потому что логотип — это часть брендинга, и заказчик готов был перенести релиз, если мы не поправим. Если бы мы руководствовались только серьёзностью, мы бы отложили это в долгий ящик. А так — подняли в очереди.
Как мы измеряем критичность: шкала на примере авиабилетов
Чтобы внести ясность, мы всегда фиксируем уровни серьёзности в документации. Это избавляет от споров «а это критично или нет?». Вот шкала, которую я использую в своих командах (и она очень похожа на ту, что описана во многих статьях в сети на эту тему):
Уровень 1 (Критический): Компонент не работает, альтернативы нет. Тестирование не может быть продолжено. В нашем API это, например, не работает метод создания заказа. Без него весь сценарий мертв.
Уровень 2 (Высокий): Компонент не работает, но есть обходной путь (workaround). Например, оплата через MasterCard падает, но Visa работает. Тестирование может идти, но ограниченно.
Уровень 3 (Средний): Функциональность ограничена, но критического влияния нет. Например, после оплаты не приходит PDF‑билет на почту, но билет есть в личном кабинете.
Уровень 4 (Низкий): Влияния на систему нет. Опечатки, артефакты вёрстки, незначительные несоответствия макетам.
Метаданные дефекта: почему «не воспроизводится» — это приговор
Самая частая фраза, которая выводит из себя разработчиков: «У меня не воспроизводится». И самая частая ошибка тестировщиков — не приложить достаточно данных, чтобы дефект можно было воспроизвести с первого раза.
В своём проекте мы сделали набор полей (метаданных) обязательными для заполнения. Это не для галочки, а чтобы исключить вопрос «а что делать?». Вот минимальный набор, который я требую:
ID дефекта: Уникальный номер. Без него в переписке бардак.
Среда: Dev, Stage, Prod? С разными конфигами поведение может кардинально отличаться.
Серьёзность и Приоритет: О чём мы говорили выше.
Шаги по воспроизведению: Это не «нажать кнопку», а «Шаг 1: отправить POST запрос на /api/v1/order с телом {...}. Шаг 2:...». Чем детальнее, тем быстрее починка.
Ожидаемый результат vs Фактический результат: Золотое правило. Если эти два поля путаются, дефект будет возвращаться на доработку.
Подтверждение: Скриншот, curl запрос, лог ошибки, дамп тела ответа. Всё, что помогает разработчику не гадать, а сразу видеть проблему.
Помню случай, когда один тестировщик просто написал: «При регистрации ошибка». Разработчик потратил полдня, пытаясь воспроизвести ситуацию, но у него всё работало. Оказалось, что ошибка возникала только при регистрации с email, содержащим символ «+». Если бы этот кейс был описан сразу, мы бы сэкономили 4 человеко‑часа. Это деньги проекта, выброшенные на ветер.
Практики, которые работают: как мы делаем в FinTech (и не только)
За годы работы в FinTech я выработал для себя несколько правил, которые превращают управление дефектами из рутины в инструмент контроля качества:
Автоматизация метрик. Мы не просто фиксируем дефекты, мы считаем их. Среднее время жизни дефекта (Mean Time to Resolution), количество дефектов, найденных на stage vs на prod, — это наши KPI. Если количество дефектов на prod растёт, мы останавливаем релизы и разбираемся, почему упало качество на этапе тестирования.
SLA на исправление. У нас есть соглашение об уровне обслуживания (SLA). Дефект с приоритетом «Срочный» (Priority 1) должен быть исправлен за 1 рабочий день. Это дисциплинирует и не даёт откладывать критичные вещи в долгий ящик.
Тестирование как часть дизайна. Когда мы проектируем API, я прошу аналитика или разработчика сразу прописывать не только happy path, но и все возможные негативные сценарии: что вернём, если передан невалидный токен? Что если тело запроса превышает лимит? Это не прихоть тестировщика, это часть архитектуры. Если у вас нет ответа на вопрос «как система ведёт себя, когда внешний сервис недоступен», значит, у вас есть скрытый дефект в требованиях.
Вместо заключения: дефекты — это окно в реальность
Управление дефектами — это не про поиск виноватых. Это про создание системы, где любая ошибка (человеческая или техническая) становится видимой, структурированной и устранимой с минимальными затратами. Это про прозрачность и предсказуемость.
Если вы чувствуете, что в ваших проектах дефекты живут своей жизнью, теряются в чатах, а релизы превращаются в лотерею, возможно, пришло время выстроить системный подход. И в OTUS для этого есть все возможности.
У нас вы найдёте не один курс, а целую экосистему обучения тестированию — на любой уровень подготовки. ➡ [Перейти в каталог]
Хотите освоить профессию с нуля? Есть подготовительный курс по ручному тестированию, где закладывают базу: что такое тест‑дизайн, как работать с требованиями, как оформлять дефекты так, чтобы их не возвращали.
Дальше — широкий выбор автоматизации: Java QA Engineer (Basic и Professional), JavaScript QA Engineer, автоматизация на Kotlin, Python и даже Go. Для тех, кто хочет копать глубже — курс по нагрузочному тестированию, где разбираются сценарии, которые валят системы в продакшене.
Отдельно стоит упомянуть тестирование игр и курс по ИИ в автоматизации тестирования — это уже взгляд в будущее, где нейросети помогают генерировать тесты и анализировать результаты. А если цель — вырасти в лидера, есть программа QA Lead, где учат управлять процессами, командами и выстраивать стратегию качества с нуля.
До 19 апреля на апрельские курсы действует тающая скидка −10% — удобная точка входа, чтобы начать развиваться в нужном направлении, пока условия позволяют сделать это чуть проще.
