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

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Тестировщику Разработчику Аналитику

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

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

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

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

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

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

План тестирования содержит информацию:

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

Чек-лист, содержащий набор проверок и статусов (состояний - выполнен/не выполнен, успешно/неуспешно).
Тестовый сценарий, содержащий верхнеуровневый алгоритм проверки.
Тест-кейсы, более низкоуровневые детали, содержащие:

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

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

отчеты;
данные;
инструменты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

System 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) или, наоборот, усиленную валидацию на поздних этапах.

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

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

Важно понимать: вложения в раннее тестирование многократно окупаются за счёт снижения стоимости исправления дефектов. По оценкам, исправление ошибки на этапе 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 проводит проверки.

Чек-лист

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

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

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

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

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

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

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

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

Тест-кейс

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

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

Номер: TC-CART-005

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

Описание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель набора:

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

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

Тест-кейсы проверки методов оплаты:
- TC-PAY-001: Оплата банковской картой (Visa/Mastercard)
- TC-PAY-002: Оплата через электронный кошелек (PayPal)
- TC-PAY-003: Оплата криптовалютой
- TC-PAY-004: Оплата через систему быстрых платежей
Тест-кейсы проверки обработки ошибок:
- TC-PAY-ERR-001: Обработка истечения срока действия карты
- TC-PAY-ERR-002: Обработка недостаточных средств
- TC-PAY-ERR-003: Обработка отказа банка-эквайера
- TC-PAY-ERR-004: Обработка сбоя соединения с платежным шлюзом
Тест-кейсы безопасности:
- 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)
Всего	15	12 исправлено, 3 требуют внимания

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

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

5. Риски

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

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

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

Баг-репорт

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

Баг-репорт #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 года

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