Тестирование программного обеспечения

Роль тестирования и ключевые понятия качества

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

В этой статье мы разберём:

зачем нужно тестирование и какие задачи оно решает

чем отличаются качество, обеспечение качества и контроль качества

базовую терминологию: ошибка, дефект, отказ

как думать о качестве через характеристики и риски

Зачем нужно тестирование

Тестирование помогает ответить на вопросы, которые невозможно закрыть только разработкой:

Работает ли система так, как задумано?

Что будет, если пользователь действует не так, как мы ожидали?

Насколько опасны оставшиеся проблемы и можно ли выпускаться?

Не сломали ли мы то, что раньше работало?

Тестирование полезно не только «в конце». Оно эффективно на всём жизненном цикле:

уточняет требования через примеры

выявляет проблемы проектирования и интеграции раньше, чем они станут дорогими

поддерживает быструю разработку через автоматизированные проверки

> Testing shows the presence, not the absence of bugs. — Edsger W. Dijkstra (Wikiquote: Edsger W. Dijkstra)

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

Качество: что это такое

Качество в ПО — это не только «без багов». Проще всего думать о качестве как о степени соответствия продукта:

потребностям пользователя

ожиданиям бизнеса

условиям эксплуатации

Качество включает функциональные и нефункциональные аспекты.

Функциональное качество

Функциональное качество отвечает на вопрос: делает ли система то, что должна.

Примеры:

корректность расчётов

правильная логика статусов заказа

соблюдение бизнес-правил

Нефункциональное качество

Нефункциональное качество отвечает на вопрос: насколько удобно, надёжно и безопасно система делает то, что должна.

Часто используют модель характеристик качества из стандарта ISO/IEC 25010 (как ориентир и общий язык):

функциональная пригодность

производительность и эффективность

совместимость

удобство использования

надёжность

безопасность

сопровождаемость

переносимость

Источник для обзора характеристик: ISO/IEC 25010 на Wikipedia

Важно: список характеристик сам по себе не даёт качества. Качество появляется, когда команда договаривается о целевых ожиданиях и проверяет их.

Обеспечение качества, контроль качества и тестирование

Термины похожи, но смысл разный.

QA (Quality Assurance, обеспечение качества) — процессы и практики, которые уменьшают вероятность появления проблем.

QC (Quality Control, контроль качества) — проверка результата, чтобы найти несоответствия.

Тестирование — один из ключевых инструментов QC, а также источник обратной связи для QA.

Практические примеры:

QA: стандарты код-ревью, Definition of Done, требования к логированию, соглашения по ветвлению, обучение команды.

QC: тестирование, ревью спецификаций, статический анализ, проверки соответствия чек-листам.

Если ориентироваться на определения, удобно сверяться с глоссарием ISTQB: ISTQB Glossary

Базовая терминология: ошибка, дефект, отказ

Чтобы одинаково понимать «что пошло не так», полезна связка из трёх понятий:

Ошибка (error) — человеческая ошибка: неверное понимание требования, опечатка, неправильное решение.

Дефект (defect, bug) — проблема в артефакте разработки: в коде, требовании, тесте, конфигурации.

Отказ (failure) — наблюдаемое неправильное поведение системы при выполнении.

Типичная цепочка:

разработчик ошибся в логике (ошибка)

в коде появился неверный оператор сравнения (дефект)

пользователь получил неправильную сумму в счёте (отказ)

Тестирование в первую очередь обнаруживает отказы (через выполнение) и помогает локализовать дефекты. А работа с процессами и коммуникацией снижает количество ошибок.

!Визуально показывает связь между ошибкой, дефектом и отказом

Верификация и валидация

Эти понятия помогают отделить два разных вопроса:

Верификация: мы делаем продукт правильно? То есть соответствует ли результат спецификациям и договорённостям.

Валидация: мы делаем правильный продукт? То есть решает ли продукт реальную задачу пользователя.

Примеры:

верификация: «поле принимает только email по формату», «API возвращает статус 200 по контракту»

валидация: «пользователь может восстановить доступ за 30 секунд без обращения в поддержку»

Оба направления важны: можно идеально реализовать неверное требование и получить «качественно сделанную бесполезную функцию».

Тестирование как управление рисками

Полезная модель мышления: тестирование — это не попытка проверить всё, а попытка снизить риски до приемлемого уровня.

Риск для продукта можно понимать как сочетание:

вероятности возникновения проблемы

ущерба, если проблема случится

На практике это превращается в приоритизацию:

что тестировать в первую очередь

что можно покрыть автоматизацией

где нужны дополнительные меры: мониторинг, фича-флаги, ограниченный релиз

Примеры высоких рисков:

платёжные сценарии и возвраты

безопасность (утечки, несанкционированный доступ)

миграции данных

интеграции со сторонними системами

Почему «раньше» дешевле: стоимость дефектов

Одна и та же проблема обходится дороже, если её найти поздно. Причины:

больше кода и зависимостей завязано на ошибочное решение

сложнее воспроизвести и диагностировать

дороже коммуникации и откаты

возможен реальный ущерб: деньги, репутация, штрафы

Поэтому ценны практики shift-left:

ревью требований и пользовательских сценариев

примеры и критерии приёмки до разработки

проверка контрактов API

ранние интеграционные проверки

И shift-right тоже важен:

мониторинг и алерты

наблюдаемость: логи, метрики, трассировки

безопасные эксперименты и постепенные раскатки

Что считать «хорошим тестированием»

Признаки зрелого подхода к тестированию:

есть понятные критерии качества (что значит «готово»)

тесты привязаны к рискам и требованиям, а не к случайному набору проверок

результаты тестирования помогают принимать решения о релизе

дефекты анализируются, и команда предотвращает их повторение (улучшает процесс)

автоматизация используется там, где она даёт скорость и стабильность, а не «ради процента покрытия»

Итоги

Тестирование — это механизм обратной связи и управления рисками, а качество — это соответствие потребностям и ожиданиям в реальных условиях.

Ключевые понятия, которые важно унести из этой темы:

качество включает функциональные и нефункциональные характеристики

QA — про предотвращение проблем, QC — про их обнаружение, тестирование — ключевой инструмент QC

ошибка, дефект и отказ — разные уровни одной цепочки

верификация отвечает за «сделали правильно», валидация — за «сделали нужное»

тестирование эффективно, когда приоритизируется по рискам и начинается как можно раньше

Виды и уровни тестирования: от модульного до приемочного

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

уровни тестирования — на каком масштабе мы проверяем систему

виды тестирования — что именно мы проверяем (функциональность, производительность, безопасность и т.д.)

Эта статья даст вам понятную карту: какие уровни бывают, какие задачи на каждом решаются и как выбирать виды тестирования под риски продукта.

Уровни тестирования и зачем они нужны

Уровень тестирования — это «высота приближения» к системе: от маленькой части кода до продукта в целом.

Одна и та же ошибка может проявляться по-разному на разных уровнях:

на модульном уровне можно поймать неверный расчёт

на интеграционном — несовместимость контрактов между сервисами

на системном — дефект в сквозном бизнес-сценарии

на приемочном — несоответствие ожиданиям пользователя или бизнеса (валидация)

Важно: уровни не конкурируют, а дополняют друг друга. Чем ниже уровень, тем быстрее и дешевле диагностика; чем выше — тем ближе проверка к реальному использованию.

!Пирамида показывает соотношение количества и скорости тестов на разных уровнях

Модульное тестирование (Unit testing)

Модульное тестирование проверяет минимальные части программы (обычно функцию или метод) в изоляции.

Что обычно проверяют:

корректность вычислений и преобразований данных

ветвления и граничные случаи

обработку ошибок

Кто обычно пишет:

чаще разработчики (и это нормально: ближе всего к коду и контексту)

Плюсы:

быстро выполняется

легко локализовать причину падения

хорошо подходит для предотвращения повторных дефектов в логике

Ограничения:

не показывает, что система в целом работает в связке

если тестировать «внутренности» без фокуса на поведение, тесты становятся хрупкими

Практический пример:

функция расчёта скидки возвращает правильное значение для суммы заказа, промокода и статуса клиента

Компонентное тестирование

Компонент — это более крупный блок, чем модуль: например, отдельный сервис, библиотека, экран приложения или слой бизнес-логики.

Компонентные тесты проверяют:

поведение компонента как «чёрного ящика» (через публичный интерфейс)

корректность работы с зависимостями (часто через заглушки)

Отличие от модульных:

модульный тест обычно «видит» функции и классы

компонентный чаще «видит» публичные API компонента

Интеграционное тестирование

Интеграционное тестирование проверяет, как несколько компонентов работают вместе: сервис с базой данных, фронтенд с API, два микросервиса через очередь и т.д.

Типовые цели:

проверить совместимость форматов данных и контрактов

проверить настройки и конфигурацию окружения (адреса, права, сертификаты)

обнаружить проблемы «на стыках»: таймауты, ретраи, транзакции, кодировки

Инструменты и подходы (общие термины):

тестовые окружения (staging/QA)

тестовые двойники зависимостей: заглушка (stub), мок (mock)

Пример:

сервис заказов создаёт заказ и сохраняет его в БД, затем публикует событие в очередь, и сервис оплаты корректно его обрабатывает

Системное тестирование

Системное тестирование проверяет систему целиком в условиях, максимально похожих на реальные, но в контролируемом тестовом окружении.

Фокус:

сквозные бизнес-сценарии (end-to-end)

взаимодействие всех ключевых частей: UI, API, БД, интеграции

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

Почему системные тесты не должны быть единственным слоем:

они дорогие в поддержке

чаще нестабильны из-за большого числа зависимостей

диагностика падений сложнее

Пример:

пользователь регистрируется, добавляет товар в корзину, оплачивает, получает чек и видит заказ в истории

Приемочное тестирование

Приемочное тестирование отвечает на вопрос: готов ли продукт к поставке/релизу с точки зрения бизнеса и пользователя.

Это уровень, где особенно важна связка с понятиями из прошлой темы:

верификация: соответствует ли поведение согласованным требованиям и критериям приёмки

валидация: решает ли это реальную задачу пользователя (и не создаёт ли новых проблем)

Кто участвует:

владелец продукта (Product Owner), бизнес-представители, иногда поддержка

тестировщики помогают подготовить критерии и сценарии, собрать доказательства

Варианты приемки:

UAT (User Acceptance Testing) — пользовательская приемка

приемка по контракту (например, по SLA/условиям договора)

операционная приемка (готовность к эксплуатации: мониторинг, логи, инструкции)

Пример:

бизнес подтверждает, что новая схема возвратов соответствует правилам, а пользователь может оформить возврат за понятное время и без критичных ошибок

Полезный терминологический ориентир: ISTQB Glossary

Виды тестирования: что именно мы проверяем

Если уровни отвечают на вопрос «где тестируем», то виды тестирования — «что и под каким углом проверяем». Один и тот же вид тестирования может применяться на разных уровнях.

Ниже — самые практичные и часто встречающиеся виды.

Функциональное тестирование

Функциональное тестирование проверяет, что система делает то, что должна, по бизнес-правилам и требованиям.

Что входит:

проверки пользовательских сценариев

проверки бизнес-логики и правил

проверки обработки ошибок и нештатных входных данных

Где применяется:

на всех уровнях (от модульного до приемочного)

Нефункциональное тестирование

Нефункциональное тестирование проверяет характеристики качества: производительность, безопасность, удобство, надёжность и т.д.

Частые подвиды:

тестирование производительности (нагрузка, стресс, стабильность под нагрузкой)

тестирование безопасности (уязвимости, контроль доступа)

тестирование удобства использования (насколько понятно и эффективно пользователю)

тестирование совместимости (браузеры, устройства, версии ОС)

Эти виды особенно напрямую связаны с управлением рисками: даже «правильная» функциональность может быть неприемлемой, если система медленная или небезопасная.

Регрессионное тестирование

Регрессионное тестирование проверяет, что изменения не сломали то, что раньше работало.

Важно понимать:

регрессия — это не отдельный уровень, а набор повторных проверок на нужных уровнях

регрессия может быть ручной и автоматизированной

Типичный состав регрессии:

критичные бизнес-потоки (покупка, оплата, вход)

интеграции

места, где часто ломается (исторически проблемные зоны)

Smoke и Sanity: быстрые проверки «дышит ли сборка»

Два похожих термина, которые часто путают:

Smoke testing — короткий набор проверок, что сборка в принципе пригодна для более глубокого тестирования (например, приложение запускается, ключевые экраны открываются).

Sanity testing — быстрая проверка конкретного изменения или фикса (например, исправили оплату — проверили оплату и ближайшие связанные сценарии).

Оба подхода помогают экономить время команды и быстрее находить «критические поломки».

Исследовательское тестирование (Exploratory testing)

Исследовательское тестирование — это одновременное изучение продукта, проектирование и выполнение тестов.

Когда особенно полезно:

требования неполные или меняются

новая функциональность, где ещё нет понятного чек-листа

нужно быстро найти неожиданные отказы и «углы» поведения

Важно:

исследовательское тестирование можно и нужно делать управляемо: фиксировать заметки, наблюдения, шаги воспроизведения и выводы

Как связать уровни и виды: практическая матрица

Удобная рабочая логика: на каждом уровне выбрать виды тестирования, которые закрывают главные риски.

| Уровень | Что ловим лучше всего | Примеры видов тестирования | |---|---|---| | Модульный | Ошибки в логике и вычислениях | функциональное, часть регрессии (авто) | | Компонентный | Ошибки в поведении компонента и его API | функциональное, контрактные проверки | | Интеграционный | Проблемы «на стыках» и конфигурации | функциональное, часть нефункционального (например, таймауты) | | Системный | Поломки сквозных сценариев | end-to-end, регрессия критичных потоков, совместимость | | Приемочный | Готовность для бизнеса/пользователя | приемка по критериям, UX-проверки, операционная готовность |

Как выбрать нужный набор тестов (простая стратегия)

Чтобы не пытаться «покрыть всё», используйте правила, привязанные к рискам:

ниже уровни — для быстрых и частых проверок логики

интеграционные тесты — для рисков контрактов, данных и инфраструктуры

системные тесты — только для самых критичных сквозных сценариев

приемка — для решения «выпускаемся или нет» и подтверждения ценности

Хороший набор тестов обычно выглядит так:

много быстрых модульных и компонентных проверок

умеренное число интеграционных

мало системных end-to-end (только критичный костяк)

понятная приемка с критериями и ответственными

Итоги

Уровни тестирования описывают масштаб: модульный → компонентный → интеграционный → системный → приемочный.

Виды тестирования описывают фокус: функциональное, нефункциональное, регрессионное, smoke/sanity, исследовательское и др.

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

Тест-дизайн: техники, тест-кейсы и чек-листы

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

Тест-дизайн — это набор подходов и техник, которые помогают:

превращать требования и риски в проверяемые условия

выбирать минимально достаточный набор тестов

делать проверки понятными, воспроизводимыми и полезными для команды

В этой статье разберём:

чем отличаются тест-кейс и чек-лист

как выглядит базовый процесс тест-дизайна

ключевые техники (эквивалентные классы, граничные значения, таблицы решений, переходы состояний, pairwise)

как связывать тесты с рисками и требованиями

Для терминов можно ориентироваться на глоссарий ISTQB: ISTQB Glossary.

Что такое тест-дизайн и что он даёт

Тест-дизайн начинается не с написания тест-кейсов, а с ответа на вопрос: что может пойти не так и как мы это поймём.

Обычно тест-дизайн даёт:

прозрачность: что именно проверяем и почему

покрытие: уверенность, что важные условия не забыты

эффективность: меньше дублей, больше пользы на единицу времени

воспроизводимость: разные люди смогут повторить проверку и получить сравнимый результат

Базовый процесс тест-дизайна

На практике удобна простая последовательность.

Собрать входные артефакты: требования, макеты, API-контракты, бизнес-правила, риски, данные о прошлых дефектах.

Выделить тестовые условия: утверждения вида что должно выполняться или что не должно происходить.

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

Сформировать набор тестов: тест-кейсы, чек-листы, наборы тестовых данных.

Приоритизировать по рискам: в первую очередь критичные потоки и места с высокой ценой ошибки.

Обеспечить трассируемость: привязать тесты к требованиям, пользовательским историям или рискам.

Поддерживать и улучшать: после изменений и найденных дефектов корректировать набор тестов.

Термин трассируемость означает, что вы можете ответить на вопросы:

какие тесты подтверждают конкретное требование

какие требования остаются без проверок

почему конкретный тест существует (какой риск или правило он закрывает)

Тест-кейс и чек-лист: в чём разница

Оба инструмента нужны, но подходят под разные задачи.

Тест-кейс

Тест-кейс — это подробное, воспроизводимое описание проверки с шагами и ожидаемым результатом.

Тест-кейс полезен, когда:

важно повторять проверку много раз (регрессия)

проверку будут выполнять разные люди

нужен понятный артефакт для аудита, отчётности или совместной работы

сценарий сложный и легко ошибиться без инструкции

Типичная структура тест-кейса:

идентификатор и название

цель (что подтверждаем)

предусловия (состояние системы до начала)

тестовые данные

шаги

ожидаемый результат на ключевых шагах или в конце

постусловия (если важно, что должно измениться)

Чек-лист

Чек-лист — это список проверок без детальных шагов. Он описывает что проверить, но обычно не фиксирует как именно.

Чек-лист полезен, когда:

проверка требует гибкости и опыта (например, исследовательские проверки)

шаги зависят от контекста (разные окружения, роли, вариации данных)

нужно быстро пробежаться по ключевым рискам

продукт часто меняется, а поддержка подробных тест-кейсов слишком дорогая

Практическое правило:

если важна повторяемость и единообразие — чаще нужен тест-кейс

если важна скорость и адаптивность — чаще нужен чек-лист

Как писать хорошие тест-кейсы

Качество тест-кейса определяется не длиной, а тем, насколько он снижает риск ошибок при выполнении.

Хороший тест-кейс обычно:

проверяет одну основную идею (одну причину падения)

использует конкретные данные (а не “введите корректное значение”)

содержит проверяемый ожидаемый результат (а не “всё должно быть ок”)

избегает лишних шагов, не влияющих на цель

не привязан к хрупким деталям UI, если можно проверить на более стабильном уровне (например, через API)

Плохие формулировки ожидаемого результата:

“ошибок нет”

“всё работает”

“данные сохраняются” (без указания где и как это проверить)

Хорошие формулировки:

“появляется сообщение: Неверный пароль, пользователь остаётся неавторизованным”

“в базе создана запись с status=PAID, в истории заказов отображается оплаченный заказ”

Техники тест-дизайна

Техники помогают системно получать тестовые условия и сокращать количество тестов без потери смысла. Ниже — самые практичные техники чёрного ящика.

Термин чёрный ящик означает: мы проектируем тесты по внешнему поведению и правилам, не опираясь на внутреннее устройство кода.

Эквивалентное разбиение

Эквивалентное разбиение — мы делим входные данные на группы, внутри которых система должна вести себя одинаково. Затем выбираем по одному представителю из каждой группы.

Пример:

поле “Возраст” принимает значения от 18 до 65

эквивалентные классы: меньше 18, 18–65, больше 65

Вместо десятков проверок по каждому возрасту можно проверить по 1–2 значения на класс.

Анализ граничных значений

Анализ граничных значений дополняет эквивалентные классы: ошибки часто прячутся на границах диапазонов.

Для диапазона 18–65 полезно проверить:

17 (ниже минимума)

18 (минимум)

19 (сразу внутри диапазона)

64 (сразу внутри диапазона)

65 (максимум)

66 (выше максимума)

!Иллюстрация показывает, какие значения стоит выбирать для проверки диапазона

Таблицы решений

Таблица решений полезна, когда поведение определяется комбинацией условий (правил), и легко пропустить важное сочетание.

Пример правила для скидки:

если клиент VIP и сумма заказа ≥ 10 000 — скидка 10%

если клиент не VIP и сумма заказа ≥ 10 000 — скидка 5%

если сумма заказа < 10 000 — скидки нет

| Условия | Правило 1 | Правило 2 | Правило 3 | |---|---:|---:|---:| | Клиент VIP | Да | Нет | Неважно | | Сумма ≥ 10 000 | Да | Да | Нет | | Ожидаемая скидка | 10% | 5% | 0% |

Таблица помогает увидеть, какие комбинации мы уже покрыли, и не забыть редкие случаи.

Переходы состояний

Тестирование переходов состояний применяют, когда у объекта есть состояния и правила переходов между ними.

Пример: заказ может быть в состояниях:

NEW (создан)

PAID (оплачен)

CANCELLED (отменён)

REFUNDED (возвращён)

Тестовые идеи:

разрешённые переходы (например, NEW → PAID)

запрещённые переходы (например, REFUNDED → PAID)

корректная обработка повторных действий (например, повторная оплата)

Эта техника особенно полезна на системном и интеграционном уровнях из предыдущей темы: многие дефекты появляются на “стыках” статусов и событий.

Pairwise (попарное тестирование)

Pairwise помогает сократить число комбинаций параметров. Идея: многие дефекты вызываются взаимодействием двух факторов, поэтому стремимся покрыть все пары значений параметров.

Пример параметров:

браузер: Chrome, Firefox, Safari

язык: RU, EN

роль: user, admin

Полный перебор даст комбинаций, а pairwise часто позволяет покрыть пары меньшим набором.

Важно: pairwise — инструмент оптимизации, но он не заменяет проверки критичных “тройных” комбинаций, если риск именно там.

Тестирование на основе сценариев использования

Здесь источник тестов — пользовательские сценарии (use cases, user stories): что пользователь делает и какую ценность получает.

Плюсы:

тесты ближе к реальным потокам

проще объяснить бизнесу покрытие и риски

Ограничение:

сценарии часто не покрывают “углы”: ошибки ввода, конкурентные действия, редкие статусы

Поэтому сценарии обычно дополняют техниками граничных значений и таблицами решений.

Тестовые условия: что это и как их формулировать

Тестовое условие — это проверяемое утверждение о системе. Оно стоит “между” требованием и конкретным тестом.

Примеры тестовых условий:

“пользователь не может войти с неверным паролем, показывается понятная ошибка”

“при оплате создаётся чек и сохраняется в истории заказов”

“нельзя применить промокод к пустой корзине”

Из одного условия часто получается несколько тестов: позитивные, негативные, граничные, по ролям.

Как выбрать между тест-кейсами и чек-листами

На практике часто используют смешанный подход.

Костяк регрессии (критичные бизнес-потоки, платежи, авторизация) — чаще тест-кейсы или автоматизация.

Новые и рискованные области — чек-листы и исследовательские сессии.

Сложные правила — таблицы решений, а затем тест-кейсы по строкам таблицы.

Хороший признак зрелости: у команды есть осознанный ответ, почему здесь чек-лист, а здесь тест-кейс.

Типичные ошибки в тест-дизайне

писать тесты “по экрану”, а не по правилам и рискам

дублировать одно и то же на разных уровнях без причины (например, много одинаковых end-to-end вместо быстрых проверок на низких уровнях)

проверять только позитивные сценарии

не фиксировать ожидаемый результат в проверяемом виде

раздувать набор тест-кейсов так, что его перестают выполнять и поддерживать

Итоги

Тест-дизайн — это дисциплина, которая соединяет требования и риски (из темы про качество) с практическими проверками на разных уровнях (из темы про уровни тестирования).

Ключевые идеи:

тест-кейс даёт воспроизводимость и удобен для регрессии, чек-лист даёт скорость и гибкость

начинайте с тестовых условий, затем выбирайте технику и оформляйте проверки

используйте техники: эквивалентные классы, граничные значения, таблицы решений, переходы состояний, pairwise

приоритизируйте тесты по рискам и поддерживайте трассируемость к требованиям

Дефекты и баг-репорты: жизненный цикл и приоритизация

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

Эта статья про то, как работать с дефектами как с управляемым потоком:

чем дефект отличается от отказа и почему это важно для коммуникации

что такое качественный баг-репорт и какие поля в нём критичны

типичный жизненный цикл дефекта в баг-трекере

как работает триаж и как отличать серьёзность от приоритета

как приоритизировать дефекты, опираясь на риски (связь с темами про качество и тест-дизайн)

Термины можно сверять с глоссарием: ISTQB Glossary.

Дефект, отказ и баг-репорт

Важно не путать уровни описания проблемы:

Отказ (failure) — наблюдаемое неправильное поведение системы при выполнении.

Дефект (defect, bug) — проблема в артефакте разработки (код, требования, конфигурация), которая может приводить к отказам.

Баг-репорт (дефект-репорт) — документированная запись о проблеме в баг-трекере: что произошло, как повторить, почему это важно и какой ожидаемый результат.

Практическая польза такого разделения:

тестировщик часто фиксирует отказ (симптом) и даёт данные для поиска дефекта (причины)

разработчику и команде проще договориться о приоритете, когда ясно что ломается и какой риск/ущерб

Зачем нужен хороший баг-репорт

Качественный баг-репорт экономит время всей команды:

сокращает количество уточняющих вопросов

ускоряет воспроизведение и диагностику

уменьшает риск, что дефект «потеряется» или будет исправлен не там

помогает принимать решение чинить сейчас или принять риск

Плохой баг-репорт стоит дорого: дефект может «переехать» в релиз, регрессировать, или команда потратит часы на попытки воспроизвести проблему.

Минимально достаточная структура баг-репорта

Набор полей зависит от компании и инструмента, но почти всегда есть ядро, без которого репорт превращается в чат-сообщение.

Заголовок

Заголовок должен кратко отвечать на вопросы где и что не так.

Плохие заголовки:

«Не работает оплата»

«Ошибка 500»

Хорошие заголовки:

«Checkout: при оплате картой с 3DS заказ создаётся, но остаётся в статусе NEW»

«API /login: при неверном пароле возвращается 200 OK вместо 401»

Окружение

Окружение фиксирует контекст, без которого проблему иногда невозможно повторить:

стенд: dev, qa, staging, prod

версия/сборка: номер релиза, commit, build number

платформа: ОС, браузер, устройство

роль пользователя и способ авторизации

конфигурация: фича-флаги, регион, язык, часовой пояс (если важно)

Предусловия

Предусловия — состояние системы до начала шагов.

Примеры:

«Есть пользователь с ролью manager»

«В корзине есть товар X, промокод не применён»

Шаги воспроизведения

Шаги должны быть:

короткими

однозначными

достаточными для повторения

Хорошая эвристика: минимальные шаги, которые всё ещё воспроизводят проблему.

Фактический и ожидаемый результат

Фактический результат (Actual) — что реально произошло.

Ожидаемый результат (Expected) — как должно быть по требованиям, бизнес-правилам или здравому смыслу.

В ожидаемом результате важно избегать формулировок «должно работать». Лучше описывать наблюдаемые факты:

сообщения

коды ответа API

изменения статуса

записи в истории/журнале

Доказательства

В зависимости от типа продукта полезны:

скриншоты/видео

HAR-файл, network-логи

логи приложения

request/response для API

идентификаторы сущностей: orderId, userId, correlation id

Пример баг-репорта (как артефакт)

| Поле | Пример заполнения | |---|---| | Заголовок | Checkout: после успешного 3DS платежа заказ остаётся NEW | | Окружение | staging, build 1.24.0+318, Chrome 121, Windows 11 | | Предусловия | Пользователь userA авторизован, в корзине товар SKU-10, доставка выбрана | | Шаги | 1) Открыть Checkout 2) Выбрать оплату картой 3) Пройти 3DS 4) Вернуться в магазин | | Actual | Показано «Оплата успешна», но заказ в профиле со статусом NEW, чек не создан | | Expected | При успешной оплате заказ переходит в PAID, создаётся чек, в истории заказов статус PAID | | Доп. данные | orderId=98421, время 14:12 UTC+3, в логах payment-service callback received |

Жизненный цикл дефекта

Жизненный цикл — это цепочка состояний в баг-трекере. Конкретные названия могут отличаться, но смысл обычно одинаковый.

!Диаграмма показывает типовые статусы дефекта и варианты исходов

Типичный поток выглядит так:

New

Triaged

In Progress

Fixed

Ready for QA

Verified

Closed

И типичные альтернативные исходы:

Duplicate — это уже заведено (ссылка на исходный дефект)

Rejected / Not a bug — поведение корректно (или ожидаемо)

Cannot reproduce — не удаётся воспроизвести по текущим данным

Deferred / Won’t fix now — исправление откладывают (принят риск)

Reopened — проблема осталась или вернулась (регрессия)

Что важно на каждом этапе

New → Triaged: команда подтверждает, что проблема понятна, воспроизводима или хотя бы достаточно описана, и решает её судьбу.

Triaged → In Progress: назначают ответственного и согласуют приоритет.

Fixed → Ready for QA: разработчик фиксирует версию исправления и даёт контекст, что именно изменилось.

Ready for QA → Verified: тестировщик проверяет исправление и оценивает регрессию.

Verified → Closed: дефект закрывают как решённый.

Триаж дефектов

Триаж — это процесс «разбора входящих» дефектов и принятия решений:

действительно ли это дефект

насколько он важен

кто должен исправлять

когда имеет смысл исправлять

На триаже полезно проверять:

воспроизводимость: есть ли шаги и данные

уникальность: нет ли уже такого дефекта

понятность ожидаемого результата: на что опираемся (требование, правило, договорённость)

область ответственности: фронтенд, бэкенд, интеграция, данные, инфраструктура

масштаб воздействия: сколько пользователей и сценариев затронуто

Результат триажа должен быть конкретным: назначено, отклонено с причиной, нужны данные, отложено.

Серьёзность и приоритет: не одно и то же

Эти два понятия постоянно путают, из-за чего команда спорит «на эмоциях».

Серьёзность (Severity) — насколько сильно дефект влияет на работоспособность и качество: от косметики до критической поломки.

Приоритет (Priority) — насколько срочно нужно исправить дефект с учётом рисков, дедлайнов и стоимости исправления.

Один и тот же severity может иметь разный priority.

Примеры:

высокая серьёзность, но низкий приоритет: ошибка в редком отчёте, которым пользуется 1% пользователей раз в год

средняя серьёзность, но высокий приоритет: баг в онбординге, который ухудшает конверсию (бизнес-ущерб), даже если есть обходной путь

Пример шкал (как договориться в команде)

Пример severity:

S1 Blocker: невозможно продолжать тестирование/работу, нет обходного пути

S2 Critical: ломается ключевой сценарий, возможны потери денег/данных

S3 Major: функциональность работает частично, есть обходной путь

S4 Minor: малозаметный дефект, не мешает основному сценарию

S5 Trivial: косметика, текст, выравнивание

Пример priority:

P0: чинить немедленно, релиз блокируется

P1: чинить в ближайшем релизе

P2: можно отложить, планировать

P3: низкий приоритет, чинить при наличии времени

Важно: шкалы не «истина», а договорённость. Их ценность — в единообразии решений.

Как приоритизировать дефекты по рискам

Из темы про качество мы брали идею: риск зависит от вероятности и ущерба. Для дефектов это удобно переводится в простые вопросы.

Вопросы, которые помогают быстро оценить приоритет

Какие деньги/данные/репутация под ударом?

Сколько пользователей затронуто и как часто?

Это ключевой поток (вход, оплата, создание заказа) или второстепенный?

Есть ли обходной путь и насколько он реалистичен?

Это регрессия (раньше работало) или «всегда так было»?

Это проблема безопасности или приватности?

Дефект влияет на юридические требования или договорные SLA?

Практические множители, которые почти всегда повышают приоритет

дефект в платёжных сценариях

риск потери данных или неконсистентности

уязвимость безопасности (особенно с эскалацией прав)

массовое влияние на пользователей

отсутствие обходного пути

регрессия в уже поставленной функциональности

Связь с тест-дизайном

Техники тест-дизайна помогают не только находить дефекты, но и объяснять их важность:

граничные значения часто указывают на риск массовых ошибок ввода

таблицы решений помогают показать, какое правило нарушено и какие комбинации ещё под угрозой

переходы состояний помогают быстро объяснить, почему дефект опасен в сквозных процессах (например, заказ «завис» между статусами)

Дубликаты, «не баг» и «не воспроизводится»: как разруливать корректно

Duplicate

Если дефект — дубликат:

закрывайте как Duplicate

добавляйте ссылку на исходный дефект

переносите важные уточнения (логи, новые окружения, частоту проявления) в исходный

Not a bug

Поведение может быть корректным, если:

так описано в требованиях или критериях приёмки

это осознанное ограничение

это ожидаемая деградация при неверных данных

Даже в случае Not a bug полезно:

указать, на какой артефакт опираемся (правило, описание, решение)

предложить улучшение UX, если пользовательский опыт страдает (это может стать задачей улучшения, а не дефектом)

Cannot reproduce

Если не воспроизводится, это не означает, что проблемы нет. Частые причины:

зависимость от данных, времени, региона

гонки и конкуренция запросов

кеши, ретраи, нестабильные интеграции

Что помогает:

точное время, requestId, correlationId

логи и метрики

указание частоты: «1 из 20 попыток»

упрощение шагов до минимального сценария

Проверка исправления и регрессия

После статуса Fixed тестировщик обычно делает два слоя проверок:

проверка фикса: шаги из баг-репорта теперь дают ожидаемый результат

точечная регрессия: связанные сценарии вокруг изменённой области (особенно на стыках интеграций и статусов)

Чтобы регрессия не превращалась в хаос:

опирайтесь на приоритизированный набор регрессионных проверок из прошлой темы (костяк критичных потоков)

по возможности добавляйте проверку в виде тест-кейса или автотеста, если дефект рискованный и может повторяться

Типичные ошибки при заведении дефектов

нет конкретного ожидаемого результата

«шаги» описаны как общие слова без данных

не указано окружение и версия

смешаны несколько проблем в одном репорте

приоритет выставлен «по ощущению», без описания влияния

нет доказательств, хотя их легко приложить

Итоги

Дефект — причина, отказ — проявление, баг-репорт — артефакт коммуникации.

Хороший баг-репорт содержит: заголовок, окружение, предусловия, шаги, actual/expected, доказательства.

Жизненный цикл дефекта — управляемый процесс от регистрации до верификации, с ветками для дубликатов и отклонений.

Severity описывает техническую/пользовательскую тяжесть, Priority — срочность исправления для бизнеса.

Приоритизация должна опираться на риски и влияние на ключевые потоки, а не на громкость проблемы.

Инструменты тестировщика: ручное, API и основы автотестов

Тестировщик работает не только с проверками, но и с инструментами, которые помогают эти проверки выполнять быстрее, точнее и воспроизводимо. В прошлых темах мы связали тестирование с рисками, уровнями тестирования, тест-дизайном и работой с дефектами. В этой статье соберём практическую картину: какими инструментами закрываются разные уровни и виды тестирования и как сделать результат проверок полезным для команды.

Разберём три направления:

ручное тестирование и инструменты для исследования продукта

API-тестирование как быстрый способ проверить логику и интеграции

основы автотестов: что автоматизировать, где запускать и как избежать хрупкости

!Наглядно показывает, почему тестировщик комбинирует ручные проверки, API и автотесты

Как выбрать инструменты: привязка к рискам и уровням

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

быстро получать сигнал о проблеме

легко воспроизводить и собирать доказательства

поддерживать регрессию на нужных уровнях

Практическое правило сочетания подходов:

ручные проверки хорошо находят проблемы UX, сценарные несостыковки и неожиданные отказы

API-проверки быстро подтверждают бизнес-правила и интеграции без зависимости от нестабильного UI

автотесты удерживают регрессию и ускоряют выпуск, если они стабильны и запускаются регулярно

Инструменты для ручного тестирования

Ручное тестирование включает как выполнение заранее подготовленных тестов (тест-кейсы и чек-листы из темы про тест-дизайн), так и исследовательские сессии.

Тест-менеджмент: где хранить тесты и результаты

Цель инструментов тест-менеджмента не в том, чтобы писать больше документов, а в том, чтобы обеспечить:

повторяемость регрессии

видимость покрытия по требованиям и рискам

историю результатов

Варианты реализации:

специализированные системы тест-менеджмента

задачи и подзадачи в трекере

таблицы, если процесс маленький и дисциплина высокая

Ключевой критерий: по артефактам должно быть понятно, что проверили, что не проверили и почему это достаточно для решения о релизе.

Браузерные инструменты: DevTools

Для веб-продуктов базовый инструмент тестировщика это DevTools.

Что полезно уметь делать:

смотреть сетевые запросы и ответы (вкладка Network)

проверять коды ответов, заголовки, тело ответа

находить клиентские ошибки (вкладка Console)

проверять хранилища: cookies, localStorage, sessionStorage

Документация: Chrome DevTools

Снифферы и прокси: увидеть трафик приложения

Прокси в тестировании это инструмент, который позволяет перехватывать и анализировать HTTP(S)-трафик между клиентом и сервером.

Зачем нужно:

воспроизвести дефект и приложить точные request/response в баг-репорт

увидеть, какие данные реально отправляются

проверить работу кеширования, редиректов, заголовков, авторизации

Типовые инструменты:

Charles Proxy

Fiddler

Данные для тестирования: учётки, роли, состояния

Многие отказы зависят не от шагов, а от данных.

Полезные практики:

заранее иметь набор тестовых пользователей по ролям

уметь быстро создавать тестовые сущности через админку или API

фиксировать идентификаторы сущностей в баг-репорте: userId, orderId, requestId

Это напрямую улучшает качество дефект-репортов из прошлой темы: дефект становится воспроизводимым и диагностируемым.

API-тестирование: быстрые проверки логики и интеграций

API это интерфейс взаимодействия программ друг с другом. Чаще всего в продуктовых командах тестируют HTTP API, где клиент отправляет запрос на endpoint (адрес ресурса), а сервер возвращает ответ.

Плюсы API-тестирования:

меньше зависимостей от UI, выше стабильность

проще покрывать граничные значения и таблицы решений из тест-дизайна

быстрее локализовать, где проблема: фронтенд или бэкенд

Базовые понятия HTTP, которые нужны тестировщику

метод: GET, POST, PUT, PATCH, DELETE

endpoint: путь ресурса, например /api/orders/123

заголовки: метаданные запроса, например Authorization, Content-Type

тело запроса: данные, которые отправляем, часто JSON

код ответа: сигнал результата, например 200, 400, 401, 500

Справочник по кодам: MDN HTTP response status codes

Контракты API и документация

Если у API есть описание в формате OpenAPI, это помогает тестировщику:

понимать структуру запросов и ответов

видеть обязательные поля и типы

быстро находить граничные условия

Источник стандарта: OpenAPI Specification

Инструменты для ручного API-тестирования

#### Postman

Postman позволяет собирать коллекции запросов, сохранять переменные окружений и запускать наборы проверок.

Полезные возможности:

переменные окружения: baseUrl, токены, тестовые идентификаторы

коллекции под регрессию API

простые проверки прямо в Postman (например, что статус 200 и есть поле id)

Документация: Postman Learning Center

#### curl

curl удобен как минимальный инструмент для воспроизведения запросов и прикладывания примера в баг-репорт.

Документация: curl documentation

Пример запроса:

Что здесь важно:

-i показывает заголовки и код ответа

-H задаёт заголовок

-d передаёт тело запроса

Типовые проверки API

Идеи для проверок напрямую следуют из техник тест-дизайна:

эквивалентные классы: корректные и некорректные входные данные

граничные значения: минимумы, максимумы, пустые строки, длины

таблицы решений: комбинации условий, влияющих на результат

переходы состояний: допустимые и запрещённые изменения статусов

Примеры практических проверок:

аутентификация и авторизация: 401 без токена, 403 при недостаточных правах

валидация входных данных: понятные ошибки 400 и сообщения о неверных полях

идемпотентность там, где она ожидается

Идемпотентность означает: повторный одинаковый запрос приводит к тому же результату без нежелательных эффектов. Например, повторный GET не должен менять данные.

Основы автотестов: что это и зачем

Автотест это код, который выполняет проверку автоматически и выдаёт результат без участия человека.

Автоматизация не заменяет тестирование, она автоматизирует повторяемые проверки. Обычно это:

регрессия критичных потоков

проверки контрактов API

проверки бизнес-правил на низких уровнях

Из темы про уровни тестирования: самый устойчивый и быстрый слой автоматизации обычно ближе к модульным и API-проверкам, а самый дорогой и хрупкий это end-to-end через UI.

Пирамида автоматизации как практическая эвристика

Её смысл:

больше быстрых проверок на низких уровнях

меньше тяжёлых UI end-to-end

Важно: это не запрет на UI-автотесты. Это подсказка, как не получить медленный и нестабильный набор, который перестанут запускать.

Основные виды автотестов по инструментам

#### API-автотесты

Проверяют API напрямую и обычно дают хорошее соотношение скорости и ценности.

Пример на Python с pytest (концептуально):

Что здесь происходит:

requests.post отправляет HTTP запрос

assert это утверждение, которое должно быть истинным, иначе тест падает

Документация:

pytest documentation

#### UI-автотесты

UI-автотесты управляют приложением как пользователь: клики, ввод, проверки отображения.

Современный популярный инструмент для веба:

Playwright

Классический инструмент:

Selenium

UI-автотесты стоит оставлять для:

критичных сквозных сценариев

проверок интеграции на уровне поведения пользователя

Не стоит пытаться UI-автотестами закрыть все комбинации и граничные значения: это будет дорого и нестабильно.

Где запускать автотесты: локально и в CI

CI это непрерывная интеграция: система, которая автоматически собирает проект и запускает проверки при изменениях.

Ожидаемая схема работы:

разработчик и тестировщик могут запускать тесты локально

CI запускает набор тестов на каждый merge или релизный кандидат

результаты видны команде, падения требуют разбора

Если тесты не запускаются регулярно, они перестают быть инструментом контроля качества и превращаются в забытый код.

Стабильность автотестов и проблема flaky

Flaky тест это тест, который то проходит, то падает при одинаковых условиях.

Типовые причины:

зависимость от времени и таймингов (анимации, ожидания, асинхронность)

общие тестовые данные и конфликты между параллельными запусками

нестабильные окружения и внешние интеграции

проверки через хрупкие UI-селекторы

Как снижать flaky:

делать явные ожидания событий вместо sleep

изолировать тестовые данные

минимизировать количество end-to-end там, где достаточно API

фиксировать окружение и версии

Как связать ручное, API и автотесты в один процесс

Чтобы подход был системным, полезна связка с предыдущими темами.

Связь с тест-дизайном

чек-листы помогают быстро покрывать риски в ручном тестировании

тест-кейсы полезны для регрессии и воспроизводимости

техники чёрного ящика дают идеи и для ручных, и для API, и для автотестов

Связь с дефектами и баг-репортами

Хороший баг-репорт часто невозможен без инструментов:

DevTools и прокси дают точный request/response

curl даёт минимальный пример воспроизведения

автотест может стать доказательством регрессии и защитой от повторения

Практический результат: команда быстрее проходит цикл нашли отказ → локализовали дефект → исправили → проверили → добавили защиту от повторения.

Итоги

Инструменты тестировщика выбираются по рискам и уровню проверки: ручное, API, автотесты дополняют друг друга.

Для ручного тестирования важны DevTools, прокси, управление тестовыми данными и понятные артефакты (чек-листы, тест-кейсы).

API-тестирование ускоряет проверку бизнес-логики и интеграций, опирается на HTTP и контракт API.

Автотесты эффективны для повторяемых проверок, но требуют дисциплины: стабильность, запуск в CI, правильный уровень автоматизации.