Перейти к основному содержимому

Документация тестировщика

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Тестировщику Разработчику Аналитику
Теория данных (раздел 3)

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

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

Документация тестировщика​

Тестовая документация — это всё, что фиксирует зачем мы проверяем систему и что уже проверили. Код отвечает на вопрос "как устроено"; тестовая документация — "как должно работать и как мы это подтвердили".

Тестировщик создаёт документацию, чтобы:

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

Главные артефакты:

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

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

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

  • Понедельник: аналитик и QA согласуют scope, QA обновляет тест-план и критерии готовности.
  • Вторник: QA собирает чек-лист smoke и черновики тест-кейсов на новый функционал.
  • Среда — команда получает сборку, QA прогоняет кейсы, фиксирует статус и заводит баг-репорты.
  • Четверг: после фиксов выполняется retest и целевой sanity, обновляется тестовый набор.
  • Пятница: QA выпускает отчёт о тестировании с выводом "готово к релизу" или "нужны доработки".

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

Разбор кейса. Документация и решение о релизе​

Ситуация:

  • Команда выпускала обновление корзины в интернет-магазине.
  • Функция промокодов работала нестабильно: часть скидок применялась, часть исчезала после обновления страницы.
  • Разработчики считали проблему "случайной", потому что локально баг воспроизводился редко.

Что помогло:

  • QA поднял связку артефактов — тест-кейс на применение промокода, чек-лист регресса корзины, баг-репорт с конкретным окружением и шагами.
  • В отчёте тестирования добавили метрику: в каких браузерах и при каких комбинациях "гость/авторизованный" баг повторяется.
  • В тест-плане явно зафиксировали риск: "изменение расчёта скидок затрагивает оплату и выдачу чека".

Результат:

  • Ошибка локализовалась в отдельном условии расчёта для гостевого пользователя.
  • Команда остановила релиз до фикса, чтобы не допустить массовых финансовых расхождений.
  • После исправления QA повторил retest по тем же шагам, а затем регресс по связанным сценариям.

Вывод:

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

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

Артефакты тестирования​

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

Рассмотрим их основные виды:

  1. План тестирования содержит информацию:
  • о том, кто будет выполнять тестирование;
  • о стратегии тестирования (типы, уровни, методы);
  • о тестовой среде;
  • о критериях приёмки;
  • о действиях, которые будут выполняться в ходе тестирования;
  • о ресурсах;
  • о прочих участниках тестирования;
  • об инструментах.

  1. Чек-лист, содержащий набор проверок и статусов (состояний - выполнен/не выполнен, успешно/неуспешно).

  2. Тестовый сценарий, содержащий верхнеуровневый алгоритм проверки.

  3. Тест-кейсы, более низкоуровневые детали, содержащие:

  • номер тест-кейса, заголовок и описание;
  • предусловия;
  • тестовые данные;
  • шаги;
  • ожидаемые результаты;
  • постусловия.
  1. Тестовые наборы, содержащие тест-кейсы. Это структурированная коллекция тест-кейсов, сгруппированных для проверки какого-то сценария. Может также включать:
  • отчеты;
  • данные;
  • инструменты.
  1. Отчёт по результатам тестирования.

Если в ходе тестирования обнаружились ошибки, то их обычно оформляют отдельным документом (или страничкой задачи в Jira/Confluence) - баг-репортом, содержащим:

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

Потом разработчики берут в работу такие баг-репорты и исправляют проблемы.

Минимум для тикета в Jira / YouTrack

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

Severity и priority — отдельно, см. основы.

Термины "ошибка / дефект / сбой" — в цепочке из основ.

Основные компоненты тестовой документации​

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

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

Тест-кейс — это операционный артефакт, представляющий собой детализированную инструкцию для проверки конкретного аспекта поведения системы. Он включает в себя предусловия, последовательность действий, входные данные, ожидаемый результат и постусловия. Тест-кейсы строятся на основе функциональных и нефункциональных требований и обеспечивают прозрачность и повторяемость проверок. Каждому тест-кейсу присваивается уникальный идентификатор, что позволяет отслеживать его исполнение в системах управления тестированием (Test Management Tools) и связывать с дефектами при их обнаружении. Качественный тест-кейс исключает двусмысленность: его должен суметь выполнить любой специалист, даже при отсутствии глубокого знания предметной области.

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

Жизненный цикл тест-кейса​

Типичные статусы в TMS (TestRail, Zephyr, Qase и аналоги):

Черновик → На ревью → Утверждён → Выполняется → Пройден / Провален → Устарел (архив)
СтатусСмысл
Черновик (New)Идея проверки, ещё без полных шагов
Утверждён (Ready)Согласован с аналитиком или лидом QA, можно гонять в регресс
Не выполнен (Not tested)В плане итерации, прогон ещё не начинали
Выполняется (In progress)Идёт прогон; для коротких кейсов статус иногда пропускают
Провален (Failed)Факт ≠ ожидание → заводится баг-репорт
Пропущен (Skipped)Сознательно не гоняли на этой итерации (scope, блокер среды)
Заблокирован (Blocked)Выполнить нельзя — нет сборки, данных или зависимого кейса
Требует доработки (Not ready)Устарели шаги или требования; кейс возвращают автору
Устарел (Closed / archived)Требование снято или UI изменился — кейс обновляют или снимают с регресса
Названия статусов

В Jira, TestRail и YouTrack подписи отличаются, но логика одна: готов → в работе → результат → архив или доработка.

Программа и методика испытаний (ПМИ)​

ПМИ — документ для формальной приёмки (госзаказ, enterprise, медицина, финтех с аудитом). Фиксирует как и чем будут испытывать систему или компонент перед сдачей заказчику.

Типовые разделы:

  • объект испытаний и цель;
  • основание (контракт, ТЗ, приказ);
  • объём и границы (что входит / не входит);
  • методы, сценарии, критерии pass/fail;
  • средства (стенды, инструменты, данные);
  • роли и порядок согласования с заказчиком.

ПМИ опирается на ТЗ; до начала испытаний документ согласуют с заказчиком. В Agile-командах чаще живут тест-план релиза и критерии приёмки в user story, но для контрактной сдачи ПМИ остаётся обязательным артефактом — см. также экономику производства ПО.

Чек-лист удобно сначала набросать творчески, затем развернуть стабильные пункты в кейсы — так снижают монотонность работы и чередуют "идеи" с формализацией. Отработать цепочку "чек-лист → кейсы → баг-репорт" на одном продукте можно в лаборатории "Конвертер файлов".

Чек-лист (checklist) — упрощённая форма фиксации тестовых сценариев, представляющая собой структурированный перечень пунктов, подлежащих проверке. В отличие от тест-кейсов, чек-листы не предполагают детализированных шагов и часто используются на этапах быстрого или исследовательского тестирования (exploratory testing), а также для регрессионной проверки стабильных участков функциональности. Их преимущество — гибкость и экономия времени на подготовку, недостаток — отсутствие стандартизации и сложность в достижении полной прослеживаемости требований. Тем не менее, в условиях ограниченных ресурсов или при итеративных релизах чек-листы демонстрируют высокую эффективность.

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

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

  • Реальными — выгружены из продуктовой среды (с соблюдением требований к анонимизации и защите персональных данных);
  • Сгенерированными — искусственно созданы с помощью скриптов или специализированных генераторов;
  • Минимальными — достаточными лишь для проверки конкретного условия;
  • Граничными — расположенными на границах допустимых диапазонов (например, минимальное и максимальное значение числового поля);
  • Негативными — содержащими невалидные или неожиданные значения.

Управление тестовыми данными включает в себя их создание, поддержку и обеспечение соответствия политикам безопасности и конфиденциальности. В современных практиках часто используется маскировка данных (data masking) или синтетическая генерация, что позволяет избежать использования чувствительной информации в средах тестирования.

Процесс и этапы тестирования — от планирования к сдаче​

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

Подготовка тест-кейсов начинается после анализа требований и завершения этапа проектирования. На этом этапе тестировщики формируют наборы тест-кейсов и чек-листов, основываясь на функциональной спецификации, user stories, макетах интерфейсов и других источниках. Важным аспектом является прослеживаемость: каждый тест-кейс должен быть связан с конкретным требованием, что позволяет отслеживать покрытие и выявлять пропуски. Также проводится разработка и подготовка тестовых данных, настройка окружений и (при необходимости) интеграция с системами автоматизации.

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

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

Уровни тест-кейсов и типы тестирования​

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

  • Unit-тесты (компонентное тестирование) — проверяют отдельные функции или методы на уровне кода; как правило, пишутся разработчиками и не входят в предмет тестовой документации, создаваемой QA-инженерами, но влияют на общую стратегию покрытия.
  • Интеграционные тест-кейсы — направлены на проверку взаимодействия модулей или систем.
  • Системные тест-кейсы — охватывают ПО как единое целое в соответствии со спецификацией.
  • Приёмочные тест-кейсы — фокусируются на валидации бизнес-сценариев и готовности продукта к использованию конечными пользователями.

В контексте приёмки выделяют два ключевых типа:

Система Integration Testing (SIT)​

SIT проводится после завершения внутренних этапов разработки и unit-/интеграционного тестирования. Его цель — убедиться, что все компоненты системы корректно взаимодействуют друг с другом и с внешними системами (например, базами данных, API сторонних сервисов, ERP-системами). Тест-кейсы для SIT часто строятся на основе технических спецификаций и контрактов взаимодействия. Участие в SIT — зона ответственности QA-команды и системных инженеров.

User Acceptance Testing (UAT)​

UAT выполняется представителями бизнеса или конечными пользователями в условиях, приближенных к реальным. На этом этапе проверяется "решает ли система бизнес-задачу". Тест-кейсы для UAT формулируются бизнес-аналитиками совместно с заказчиком и выражены в терминах предметной области, а не технических деталей. Успешное прохождение UAT является формальным основанием для запуска продукта в эксплуатацию.

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

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

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

Если функциональное тестирование отвечает на вопрос "что делает система?", то нефункциональное — на вопрос "как она это делает?". Оно включает:

  • Тестирование производительности (нагрузочное, стрессовое, soak-тестирование);
  • Тестирование безопасности (проверка уязвимостей, аутентификации, авторизации);
  • Тестирование удобства использования (usability);
  • Тестирование совместимости (браузеров, ОС, устройств);
  • Тестирование локализации и интернационализации.

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

Среды для тестирования​

Тестирование невозможно без соответствующих сред (environments) — изолированных копий системы, имитирующих различные стадии жизненного цикла:

  • Dev — для первичной проверки разработчиком;
  • QA/Test — основная среда для ручного и автоматизированного тестирования;
  • Staging/Pre-production — максимально приближена к production, используется для UAT и финальной валидации;
  • Production — в ограниченных случаях применяется для A/B-тестирования или feature-flag валидации.

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

Стратегия тестирования и оценка затрат​

Стратегия тестирования — это высокоуровневый план, определяющий, как, когда и чем будет тестироваться продукт. Она учитывает тип проекта (greenfield vs legacy), критичность системы, регуляторные требования, риски и доступные ресурсы. Стратегия может предполагать сочетание ручного и автоматизированного тестирования, смещение акцентов на раннее тестирование (shift-left) или, наоборот, усиленную валидацию на поздних этапах.

Оценка затрат включает три компонента:

  1. Время — человеко-часы на проектирование, подготовку данных, выполнение тестов, анализ результатов;
  2. Силы — количество и квалификация специалистов, необходимых на каждом этапе;
  3. Деньги — лицензии на инструменты, инфраструктурные расходы, стоимость простоев при обнаружении дефектов на поздних стадиях.

Важно понимать: вложения в раннее тестирование многократно окупаются за счёт снижения стоимости исправления дефектов. По оценкам, исправление ошибки на этапе production может быть в 10–100 раз дороже, чем на этапе проектирования.

Организация процесса тестирования​

Эффективное тестирование требует чёткой организационной модели:

  • Назначение ответственных за каждый вид тестирования;
  • Интеграция в CI/CD-процессы (например, запуск регрессионных тестов при каждом пуше);
  • Использование систем управления тестами (TestRail, Zephyr, Xray и др.);
  • Ведение дефект-трекинга (Jira, Bugzilla);
  • Регулярные ретроспективы и анализ метрик качества.

Сдача тестирования​

Формально сдача тестирования оформляется Test Summary Report — документом, содержащим:

  • Объём выполненных тестов;
  • Количество выявленных и закрытых дефектов;
  • Критические риски и ограничения;
  • Рекомендации по выпуску (Go/No-Go).

Этот отчёт служит основанием для принятия управленческого решения.

Использование пользователей как тестировщиков — практика и правовые аспекты​

Привлечение реальных пользователей к тестированию (например, через бета-программы, community Testing или пилотные запуски) — распространённая практика, особенно в B2C-проектах. Она позволяет получить обратную связь по usability, выявить неочевидные сценарии и проверить поведение в разнообразных условиях.

Однако такая практика сопряжена с юридическими и этическими обязательствами:

  • Необходимо получать явное согласие на сбор данных (в соответствии с GDPR, CCPA и другими нормами);
  • Данные пользователей должны быть анонимизированы;
  • Участие должно быть добровольным, с возможностью отказа в любой момент;
  • Программа тестирования должна быть прозрачной — пользователь должен понимать, что участвует в тестировании, какие данные собираются и для чего.

Нарушение этих принципов может привести к репутационным и юридическим последствиям.

Автоматизация тестирования — инструменты, архитектура и документирование​

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

Selenium WebDriver как основа UI-автоматизации​

Selenium WebDriver — это кросс-браузерный API для программного управления веб-браузерами. Он предоставляет низкоуровневый интерфейс для взаимодействия с DOM-элементами — открытие страниц, ввод текста, клики, навигация, работа с фреймами и алертами. Именно благодаря WebDriver стало возможным создание устойчивых, кросс-платформенных автотестов для веб-приложений.

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

  • Инициализация драйвера — выбор браузера (Chrome, Firefox, Edge, Safari) через соответствующий драйвер (ChromeDriver, GeckoDriver и др.). В документации указывается, какие драйверы требуются, их совместимость с версиями браузеров и метод их интеграции (локально, через WebDriver Manager, в Docker-контейнере).
  • Локаторы элементов — стратегия идентификации UI-компонентов (по id, name, cssSelector, xpath). Важно фиксировать в документации принципы выбора локаторов — предпочтение устойчивых (например, атрибутов data-testid), избегание хрупких xpath-выражений, зависящих от структуры DOM.
  • Ожидания (waits): корректная работа с асинхронностью. В документации описывается применение явных ожиданий (WebDriverWait с ExpectedConditions) для ожидания состояний элементов (кликабельность, видимость), а не использование Thread.sleep(). Также упоминается ограниченное применение неявных ожиданий и их глобальный характер.
  • Работа с окружением: переключение между фреймами (switchTo().frame()), обработка алертов (switchTo().alert()), навигация (navigate().back(), refresh() и др.). Эти операции требуют чёткого описания в тестовых сценариях, особенно если они влияют на состояние приложения.

Пример из практики: в чек-листе или спецификации автотеста может быть указано:

"После загрузки модального окна ожидать появления элемента с data-testid="confirmation-modal" в течение 10 секунд; при отсутствии — зафиксировать ошибку как блокирующую".

Такой подход обеспечивает прозрачность и воспроизводимость.

Фреймворки для организации автоматизированных тестов — NUnit, MSTest, xUnit​

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

В экосистеме .NET наиболее распространены три:

  • NUnit — зрелый, гибкий фреймворк с богатой системой атрибутов ([Test], [SetUp], [TearDown], [TestCase]), поддержкой параметризованных тестов и параллельного выполнения. Широко используется в QA-практике благодаря декларативности и расширяемости.
  • MSTest — встроенный в Visual Studio фреймворк от Microsoft. Обеспечивает глубокую интеграцию с инструментами разработки (Test Explorer, Azure DevOps), но исторически уступал NUnit в гибкости. Современная версия (MSTest V2) устранила многие ограничения.
  • xUnit — современный, минималистичный фреймворк, разработанный с учётом принципов TDD. Отличается строгой архитектурой — отсутствие базового класса для тестов, обязательное использование атрибутов [Fact] и [Theory], изоляция контекста между тестами по умолчанию. Рекомендуется при построении надёжных, изолированных проверок.

Все три фреймворка позволяют:

  • Организовать setup/teardown логику (инициализация драйвера, авторизация, очистка состояния);
  • Группировать тесты по классам и атрибутам;
  • Интегрироваться с CI/CD-системами;
  • Генерировать отчёты в форматах, пригодных для анализа (TRX, NUnit3 XML и др.).

Важно: автоматизированный тест — это тоже документ. Его читаемость, именование (Should_Display_Error_When_Email_Is_Invalid) и структура (Given-When-Then в коде) должны соответствовать тем же стандартам научной ясности и точности, что и ручные тест-кейсы. Комментарии в коде автотестов не заменяют внешнюю документацию, но дополняют её: например, поясняют почему выбран тот или иной локатор или ожидание.

Роль автоматизации в тестовой документации​

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

  • Тест-план определяет, какие сценарии подлежат автоматизации;
  • Тест-кейсы описывают поведение на человеческом языке;
  • Автоматизированный тест — это техническая реализация этого кейса;
  • Отчёт об исполнении автотеста — доказательство выполнения кейса.

Таким образом, тестовая документация становится живым артефактом — её частьы существуют в разных средах (Confluence, TestRail, Git), но связаны между собой через идентификаторы, требования и метрики покрытия.

Примеры тестовой документации​

План тестирования​

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

План тестирования для веб-приложения "Каталог товаров"

1. Цели и область применения

Документ описывает стратегию тестирования модуля каталога товаров интернет-магазина. Целью является выявление дефектов в отображении товаров, работе фильтров и поиске до момента релиза версии 2.0. В зону проверки входят все страницы каталога, включая мобильную версию интерфейса.

2. Роли и ответственность

Команда тестирования включает двух инженеров по качеству (QA). Один специалист отвечает за функциональное тестирование и чек-листы, второй занимается нагрузочным тестированием и автоматизацией регресса. Менеджер проекта утверждает критерии приемки. Разработчики исправляют обнаруженные ошибки.

3. Стратегия тестирования

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

4. Тестовая среда

Тестирование выполняется на сервере окружения "Staging", который зеркально копирует конфигурацию продакшена. Для работы используются браузеры Google Chrome последней версии, Mozilla Firefox, Safari и Microsoft Edge. База данных представлена экземпляром PostgreSQL версии 14. Инструментарий включает Jira для управления задачами, Selenium WebDriver для автоматизации и JMeter для имитации нагрузки.

5. Критерии приемки

Релиз считается готовым к выпуску при условии отсутствия ошибок с приоритетом "Критический" или "Блокирующий". Ошибки уровня "Высокий" должны быть исправлены или иметь утвержденный план обхода. Покрытие кода функциональными тестами должно составлять не менее 80%. Все критические сценарии использования товара должны пройти успешную проверку.

6. Ресурсы и инструменты

Для выполнения работ выделены два рабочих места с доступом к тестовой среде. Используются инструменты — Jira (трекер задач), Confluence (документация), TestRail (управление тест-кейсами), Jenkins (CI/CD пайплайны). Время на тестирование составляет две недели спринта.

7. Участники процесса

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

Чек-лист​

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

Чек-лист проверки авторизации пользователя

  • Проверка входа с корректными логином и паролем
  • Проверка отображения сообщения об ошибке при неверном пароле
  • Проверка блокировки аккаунта после пяти попыток ввода неверного пароля
  • Проверка функции "Забыли пароль" и отправки письма восстановления
  • Проверка автоматического выхода из системы через 30 минут бездействия
  • Проверка работы кнопки "Выход" и очистки сессии
  • Проверка отображения имени пользователя в личном кабинете после входа
  • Проверка доступа к закрытым разделам только для авторизованных пользователей
  • Проверка корректной работы OAuth входа через Google аккаунт
  • Проверка защиты от перебора паролей (CAPTCHA после нескольких неудач)

Статусы в данном документе фиксируются как "Выполнено" или "Не выполнено". При обнаружении несоответствия система автоматически помечает соответствующую строку как выполненную с ошибкой.

Тестовый сценарий​

Тестовый сценарий описывает высокоуровневый путь пользователя внутри системы для проверки целостности бизнес-процесса. Этот документ объединяет несколько связанных тест-кейсов в единую последовательность действий, имитирующую реальное использование функционала.

Сценарий: Оформление заказа нового товара

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

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

Тест-кейс​

Тест-кейс является детальным описанием конкретных условий, шагов и ожидаемых результатов для проверки отдельного аспекта функциональности программы. Этот документ содержит всю необходимую информацию для воспроизведения проверки любым сотрудником команды.

Тест-кейс № TC-CART-005: Добавление товара в корзину

Номер: TC-CART-005

Заголовок: Проверка добавления товара в корзину с положительным балансом

Описание:

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

Предусловия:

  1. Пользователь авторизован в системе.
  2. Корзина пользователя не заполнена полностью.
  3. На складе имеется требуемое количество товара.
  4. Товар доступен для покупки.

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

  • Логин: test_user@example.com
  • Пароль: SecurePass123!
  • ID товара: PROD-98765
  • Количество: 1 шт.

Шаги выполнения:

  1. Открыть страницу товара с ID PROD-98765.
  2. Убедиться, что кнопка "Добавить в корзину" активна.
  3. Нажать кнопку "Добавить в корзину".
  4. Подождать завершения анимации загрузки.
  5. Открыть панель корзины или перейти на страницу корзины.
  6. Проверить наличие товара в списке позиций корзины.
  7. Проверить отображение правильного количества товара.
  8. Проверить корректность подсчета общей суммы корзины.

Ожидаемый результат:

  1. Товар появляется в корзине.
  2. Количество товара соответствует введенному значению (1 шт.).
  3. Сумма корзины обновляется с учетом цены выбранного товара.
  4. Отображается всплывающее уведомление "Товар добавлен в корзину".
  5. Значение счетчика товаров в иконке корзины увеличилось на единицу.

Постусловия:

  • Товар остается в корзине пользователя.
  • Состояние базы данных обновлено: создана запись о позиции в корзине.
  • Пользователь может продолжить оформление заказа или удалить товар.

Тестовые наборы​

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

Набор "Регрессионное тестирование модуля оплаты"

Цель набора:

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

Состав набора:

  1. Тест-кейсы проверки методов оплаты:

    • TC-PAY-001: Оплата банковской картой (Visa/Mastercard)
    • TC-PAY-002: Оплата через электронный кошелек (PayPal)
    • TC-PAY-003: Оплата криптовалютой
    • TC-PAY-004: Оплата через систему быстрых платежей

  2. Тест-кейсы проверки обработки ошибок:

    • TC-PAY-ERR-001: Обработка истечения срока действия карты
    • TC-PAY-ERR-002: Обработка недостаточных средств
    • TC-PAY-ERR-003: Обработка отказа банка-эквайера
    • TC-PAY-ERR-004: Обработка сбоя соединения с платежным шлюзом

  3. Тест-кейсы безопасности:

    • TC-PAY-SEC-001: Шифрование передаваемых данных
    • TC-PAY-SEC-002: Защита от повторного использования токенов
    • TC-PAY-SEC-003: Проверка соответствия стандартам PCI DSS

Прилагаемые материалы:

  • Отчеты о предыдущих запусках этого набора.
  • Скрипты автоматизации для ключевых сценариев.
  • Набор тестовых данных (валидные номера карт, токены).
  • Документация по настройке тестового окружения платежной системы.

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

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

Отчет по результатам тестирования summarizes findings from the Testing process, providing stakeholders with a clear understanding of the quality status, identified defects, and readiness for release. This document serves as the final verdict on whether the software meets the acceptance criteria.

Отчет о тестировании версии 2.1 "Функционал каталога"

Дата составления: 15 марта 2026 года

Версия ПО: 2.1.0

Ответственный за отчет: Иван Петров, Senior QA Engineer

1. Резюме

Проведено полное функциональное и регрессионное тестирование модуля каталога товаров. Выявлено 15 дефектов, из которых 12 исправлены, 2 находятся в процессе исправления, 1 отклонен как несуществующий. Качество продукта оценивается как высокое. Рекомендован переход к следующему этапу разработки.

2. Статистика выполнения

  • Всего создано тест-кейсов: 120
  • Выполнено тест-кейсов: 120
  • Пройдено тест-кейсов: 112
  • Не пройдено тест-кейсов: 8
  • Процент успеха: 93.3%

3. Обнаруженные дефекты

ПриоритетКол-во дефектовСтатус исправления
Критический1Исправлен
Высокий4Исправлен (3), В работе (1)
Средний6Исправлен (5), Отклонен (1)
Низкий4Исправлен (4)
Всего1512 исправлено, 3 требуют внимания

4. Детальный анализ проблем

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

5. Риски

Существует риск возникновения аналогичных ошибок сортировки в других разделах каталога. Рекомендуется провести дополнительное выборочное тестирование остальных категорий товаров.

6. Заключение

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

Тексты и сообщения в продукте​

Проверяют не только кнопки и API, но и то, что видит пользователь — подписи, письма, ошибки, подсказки в формах. Это часть статического тестирования: код можно не запускать, достаточно прочитать макет или черновик ТЗ (основы).

Что обычно входит в проверку:

  • письма после регистрации, оплаты, сброса пароля;
  • тексты ошибок и валидации в формах;
  • подсказки "что вводить" и placeholder;
  • кнопки, заголовки, FAQ, инструкции;
  • согласованность терминов с требованиями.

Чек-лист на один экран или письмо:

  • Нет опечаток и обрезанных фраз
  • Тон и термины совпадают с остальным продуктом
  • Ссылки в письме ведут на нужный стенд
  • Сообщение об ошибке объясняет, что сделать пользователю
  • Для l10n — длина строки не ломает вёрстку (классификация)

Баг-репорт​

Баг-репорт — единственный официальный способ передать разработчику "вот что сломалось". Хороший баг воспроизводится за 5 минут; плохой превращается в переписку "у меня работает".

Минимальный набор полей​

ПолеЗачем
ЗаголовокОдна фраза: что не так и где
Шаги воспроизведенияНумерованный список — без "иногда" и "как-то"
Ожидаемый результатКак должно быть по требованию или здравому смыслу
Фактический результатЧто произошло на самом деле
ОкружениеОС, браузер/версия приложения, стенд (test/preprod)
Severity / PriorityНасколько больно и насколько срочно чинить
ВложенияСкрин, видео, HAR, лог — всё, что ускорит разбор

Опционально, но ценно — ссылка на требование (REQ-…, user story), тест-кейс, учётная запись тестового пользователя.

Severity и Priority​

Эти поля путают на собеседованиях и в Jira. Severity (серьёзность) — насколько сильно баг бьёт по системе или бизнесу. Priority (приоритет) — насколько срочно его чинить в бэклоге.

SeverityPriority
ВопросНасколько сильно влияет на продукт?Насколько срочно править?
Кто задаётОбычно QAPM, тимлид, product owner
ПримерПадение оплаты — CriticalТот же баг в модуле, который включат через квартал — Low

Severity (типовая шкала):

  • Blocker — нельзя продолжать тестирование или релиз (сайт не открывается).
  • Critical — ключевая функция мертва, обхода нет (не проходит оплата).
  • Major — функция сломана, но есть обход (оплата только картой Visa).
  • Minor — некритичное отклонение (опечатка в подсказке).
  • Trivial — косметика.

Priority — очередь в бэклоге — P0 "чиним сегодня", P1 "в этом спринте", P2 "когда успеем".

Живой пример расхождения

Баг: "Неверный цвет иконки в настройках профиля". Severity: Minor. Priority: Low — можно отложить.

Баг: "При экспорте отчёта в Excel теряются строки". Severity: Critical для бухгалтерии. Priority: High — если отчёт нужен к закрытию месяца; Low — если фича ещё никто не использует.

Примеры оформления баг-репорта​

Слабый вариант

  • Заголовок: "Не работает"
  • Описание: "Сортировка кривая, пофиксите"

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

Сильный вариант

  • Заголовок: Каталог "Электроника" — сортировка "от дешёвых к дорогим" не меняет порядок карточек
  • Шаги: 1) Открыть /catalog/electronics 2) Выбрать сортировку "Цена ↑" 3) Сравнить цены первых 5 карточек
  • Ожидание: цены по возрастанию
  • Факт: порядок не меняется (скрин во вложении)
  • Окружение: Chrome 120, test, сборка 2.1.0

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

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

Найден → Open → In Progress → Fixed → Retest → Closed
                      ↓                    ↓
                  Rejected            Reopened (если не помогло)
СтатусЧто происходит
OpenБаг заведён, ждёт разработчика
In ProgressРазработчик чинит
FixedИсправление в сборке — ваша очередь: регресс по шагам
ReopenedФикс не помог или сломал соседнее
Rejected / Won't fix"Не баг", "по дизайну", "не в scope" — нужен аргумент или согласование с аналитиком

Retest (повторная проверка) — вы повторяете те же шаги на новой сборке. Недостаточно "разработчик сказал, что починил": проверка — зона ответственности QA.

Локализация дефекта​

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

Не путать с l10n

Локализация продукта (l10n) — перевод и адаптация интерфейса под язык и регион. Локализация дефекта — найти, в каком модуле и при каких данных ошибка. Это разные термины. Про l10n — классификация.

Порядок действий:

  1. Зафиксировать полный сценарий, на котором баг виден.
  2. Убрать шаги по одному — баг остаётся?
  3. Упростить данные (короткий email, одна позиция в корзине).
  4. Проверить на другом браузере или роли — проблема в UI или в API (тестирование API).
  5. Сверить состояние в БД (SQL для тестировщика).

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

Цепочка НЛО​

НЛО — мнемоника из трёх шагов при работе с дефектом: Найти, Локализовать, Оформить.

ШагДействиеАртефакт
Н — НайтиВоспроизвести расхождение с ожиданиемЗаметки, скрин, HAR
Л — ЛокализоватьСузить модуль, данные, окружениеМинимальные шаги
О — ОформитьЗавести баг в трекереБаг-репорт в Jira/YouTrack

Пропущенные баги (escaped defects)​

Escaped defect — дефект, который дошёл до production или к заказчику, хотя команда QA его не поймала до релиза. После инцидента полезен короткий разбор:

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

Итог фиксируют в ретроспективе или в комментарии к тикету, чтобы тот же класс ошибок не прошёл снова. Метрики — в добро пожаловать в тестирование.

Типичные ошибки в баг-репортах​

ОшибкаПочему мешаетКак исправить
Заголовок "Не работает" / "Баг в корзине"Нет зоны и симптома[Модуль] что сломалось при каких условиях
Шаги с "иногда", "быстро кликнуть"Не воспроизводитсяНумерованные шаги, одна переменная за раз
В "ожидаемом" описан фактический результатРазработчик путает цельДва отдельных поля: ожидание по ТЗ и факт
Нет сборки, стенда, роли пользователяНельзя сравнить окруженияБлок Environment обязателен
Severity = Priority "на глаз"Неверная очередь в спринтеРазделить "насколько больно" и "насколько срочно" — таблица выше
Скрин без шаговКонтекст теряетсяСкрин дополняет шаги, не заменяет
В описании правят требования без пометкиСкрытое изменение ТЗПредложение на изменение — отдельно от бага
Цепочка терминов

Ошибка (mistake) человека → дефект в артефакте → сбой при работе → тикет в трекере. Подробная схема и пример — в основах тестирования.

Пример полного баг-репорта​

Баг-репорт фиксирует несоответствие между фактическим и ожидаемым поведением и служит основанием для работы разработчика.

Баг-репорт #BUG-2026-0458: Неправильная сортировка товаров по возрастанию цены

Заголовок:

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

Описание проблемы:

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

Ссылка на требование:

REQ-CAT-004: "Система должна обеспечивать сортировку товаров по цене в прямом и обратном порядке."

Ожидаемый результат:

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

Фактический результат:

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

Приоритет: Высокий

Срочность: Средняя

Окружение и детали:

  • Версия приложения: 2.1.0 (Build 20260315)
  • Платформа: Windows 11, браузер Google Chrome 120.0.6099.109
  • Модуль: Каталог товаров -> Электроника
  • Шаги воспроизведения:
    1. Перейти на страницу категории "Электроника".
    2. Нажать на выпадающий список "Сортировать по".
    3. Выбрать пункт "Цена: от дешевых к дорогим".
    4. Зафиксировать порядок отображения товаров.
  • Дополнительные данные:
    • Скриншот экрана с текущим порядком: screenshot_bug_0458.png
    • Логи сети: network_log_0458.txt
    • Данные о товаре с минимальной ценой: ID PROD-100, цена 500 руб.
    • Данные о товаре с максимальной ценой: ID PROD-999, цена 150000 руб.

Статус: Открыт

Исполнитель: Команда разработки (Backend Team)

Назначенная дата исправления: 17 марта 2026 года

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

Smoke, sanity и регресс — когда что запускать​

Эти термины часто смешивают; на практике различие простое:

ТипКогдаГлубинаПример
SmokeНовая сборка только что приехала15–30 мин, "дышит ли"Логин, главная, одна оплата
BVTТа же новая сборкаSmoke + чуть глубже по рискуКритичные API и интеграции после деплоя
SanityПочинили один модуль после багаУзкая зона + соседиТолько каталог + корзина после фикса сортировки
RegressionПеред релизом или после крупных измененийШирокий набор кейсовВесь регрессионный suite за ночь

Smoke не заменяет полный регресс: он отвечает "можно ли вообще начинать тестировать эту сборку".

Навигация по разделу "Тестирование"​

Содержание