Ручное тестирование ПО: основы и практика

Роль QA и основы жизненного цикла разработки

Зачем в команде нужен QA

QA (Quality Assurance) — это роль и набор практик, которые помогают команде выпускать продукт предсказуемого качества. В рамках курса по ручному тестированию нас больше всего интересует практическая часть работы QA-специалиста: как находить риски, предотвращать дефекты и проверять, что продукт соответствует ожиданиям пользователя и требованиям.

Важно различать два близких понятия:

QA (обеспечение качества) — процессный подход: как команда строит работу так, чтобы качество было высоким.

Тестирование (testing) — проверка продукта: поиск несоответствий, дефектов и рисков.

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

Что такое качество ПО простыми словами

Качество программного обеспечения — это не «всё работает». Это баланс нескольких ожиданий:

продукт решает задачу пользователя

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

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

изменения не ломают старые функции

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

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

QA помогает договориться, что именно считается качеством в конкретном проекте, и организовать проверки так, чтобы команда это качество достигала.

Основные роли в продуктовой команде и как QA с ними взаимодействует

Ниже — типичные роли (в разных компаниях названия могут отличаться):

Заказчик / бизнес — формулирует бизнес-цели.

Product Owner / Product Manager — определяет приоритеты, ценность и развитие продукта.

Аналитик — уточняет требования, описывает бизнес-правила и сценарии.

Дизайнер — отвечает за пользовательский опыт и макеты.

Разработчик — реализует функциональность.

QA / тестировщик — помогает сделать функциональность проверяемой и проверяет её.

DevOps / инженер инфраструктуры — помогает с окружениями, релизами, мониторингом.

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

Ключевая идея: QA — не «контролёр на конце конвейера», а участник команды, который подключается как можно раньше, чтобы снижать риск ошибок ещё до написания кода.

Жизненный цикл разработки ПО (SDLC)

SDLC (Software Development Life Cycle) — это жизненный цикл разработки: от идеи до поддержки продукта в эксплуатации.

!Цикл этапов разработки ПО и место тестирования в общем процессе

Типовые этапы SDLC

Ниже — базовая модель, которая встречается и в классических, и в гибких процессах (меняется только то, как часто и в каком объёме проходят этапы):

Идея и цели

Команда понимает, какую проблему решает продукт и для кого.

Сбор и уточнение требований

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

Проектирование

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

Разработка

Создаётся код, настраиваются интеграции, добавляются изменения в базу данных и т.д.

Тестирование

Проверяется соответствие требованиям, выявляются дефекты и риски.

Релиз

Изменения доставляются пользователям (в магазин приложений, на сервер, в облако и т.п.).

Поддержка и улучшения

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

В реальности тестирование не является «одним этапом в конце». Оно присутствует на всём протяжении SDLC — просто на разных этапах меняются цели QA.

Где QA приносит максимальную пользу на каждом этапе

На этапе требований

QA помогает:

обнаружить противоречия и пробелы в требованиях

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

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

Критерии приемки — это короткие проверяемые утверждения. Например: «При неверном пароле показывается сообщение об ошибке, а аккаунт не блокируется при одной неудачной попытке».

На этапе проектирования

QA помогает:

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

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

продумать тестовый подход: что проверять вручную в первую очередь

На этапе разработки

QA помогает:

синхронизироваться с разработкой по готовности функциональности

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

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

На этапе тестирования и перед релизом

QA:

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

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

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

После релиза

QA:

анализирует дефекты «с продакшена», ищет причины утечек

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

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

Жизненный цикл тестирования (STLC) как часть SDLC

STLC (Software Testing Life Cycle) — жизненный цикл тестирования. Это набор шагов, которые помогают организовать тестирование системно.

Типовые шаги STLC

Анализ требований

Что нужно проверить, какие есть риски, что непонятно.

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

Чем и как будем проверять: объём, приоритеты, подход, окружения.

Проектирование тестов

Подготовка тест-кейсов (если они нужны), чек-листов, тестовых данных.

Подготовка тестового окружения

Доступы, сборки, конфигурации, тестовые аккаунты.

Выполнение тестов

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

Завершение и отчётность

Подведение итогов: что проверено, что не проверено, какие риски остались.

STLC не обязательно выглядит как строгая последовательность. В Agile-командах эти шаги часто идут параллельно и повторяются короткими итерациями.

Waterfall и Agile: что важно понять тестировщику

Есть разные модели организации разработки. Две самые известные — Waterfall (каскадная) и Agile (гибкие подходы).

Waterfall (каскадная модель)

Признаки:

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

изменения после утверждения требований обходятся дорого

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

Agile (гибкие подходы)

Признаки:

работа идёт короткими итерациями, продукт развивается постепенно

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

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

Полезный первоисточник по ценностям Agile:

Манифест Agile

Если команда работает по Scrum, полезен официальный гайд:

The Scrum Guide

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

Артефакты, с которыми чаще всего работает QA

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

Требования и договорённости

пользовательские истории (user story) и критерии приемки

спецификации и описания бизнес-правил

макеты и прототипы

Тестовая документация

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

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

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

Дефекты

Дефект (bug) — несоответствие фактического поведения ожидаемому.

Хорошее описание дефекта обычно содержит:

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

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

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

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

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

Позиция QA в команде: ответственность без иллюзий

QA помогает команде управлять качеством, но не может «гарантировать отсутствие багов». Реалистичная цель — сделать качество прозрачным и управляемым:

выявлять дефекты как можно раньше

предотвращать дефекты через уточнение требований и критериев приемки

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

поддерживать предсказуемость релизов

Для определения терминов в тестировании удобно использовать глоссарий ISTQB:

ISTQB Glossary

Итоги

QA — это про процессы и предотвращение проблем, тестирование — про проверки и обнаружение несоответствий.

SDLC описывает весь путь продукта от идеи до поддержки, а STLC — системный подход к тестированию.

Тестирование эффективно, когда начинается на этапе требований и сопровождает разработку, а не откладывается «на потом».

В реальной работе QA постоянно взаимодействует с аналитиками, разработчиками, продуктом и поддержкой.

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

Зачем тестировщику разбираться в требованиях

В предыдущей статье мы говорили, что QA приносит максимум пользы, когда подключается как можно раньше — уже на этапе требований в SDLC. Это не «чужая зона ответственности», а точка, где можно дешево предотвратить дорогие дефекты.

Для ручного тестирования требования важны по двум причинам:

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

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

Если требования неполные или неоднозначные, то тестирование превращается в угадывание, а команда рискует сделать «не то», даже если всё работает без ошибок.

Что такое требование

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

Важно отличать требование от похожих формулировок:

Идея — направление («сделаем оплату в 1 клик»).

Пожелание — хочется, но не обязательно («желательно темная тема»).

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

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

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

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

цели бизнеса и метрики продукта

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

сообщения поддержки и реальные инциденты

дизайн-макеты и прототипы

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

ограничения платформы, API, инфраструктуры

И фиксируются тоже по-разному:

задачи в трекере (Jira, YouTrack и аналоги)

спецификации (документы, страницы в Confluence)

пользовательские истории (user stories)

критерии приемки (acceptance criteria)

протоколы встреч и договоренности в переписке

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

Уровни и типы требований

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

!Уровни требований помогают понять, на каком уровне возникло противоречие и что именно нужно уточнять

По уровню (о чем договоренность)

Бизнес-требования: зачем это компании (цель, ценность).

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

Системные (продуктовые) требования: что должна делать система, чтобы удовлетворить потребности.

По содержанию (что именно описываем)

| Тип | Что описывает | Пример | Как тестировщику проверять | |---|---|---|---| | Функциональные | Поведение и функции системы | «Пользователь может сбросить пароль по email» | Сценарии, негативные проверки, граничные случаи | | Нефункциональные | Свойства качества и ограничения по качеству | «Страница поиска открывается не дольше 2 секунд при 1 000 одновременных пользователях» | Замеры (если возможно), проверки условий, уточнение метрик | | Ограничения | Запреты и рамки решения | «Пароли храним только в виде хеша», «Поддерживаем iOS 16+» | Проверки соответствия ограничениям, совместимость | | Бизнес-правила | Логика предметной области | «Скидка 10% действует только при сумме заказа от 3 000 ₽» | Таблицы решений, наборы проверок по комбинациям |

Если требования не делят на типы явно, тестировщик может сделать это сам — так проще найти пробелы. Частая ситуация: функциональность описана, а нефункциональные требования не определены (скорость, безопасность, логирование, совместимость).

Форматы требований, с которыми чаще всего работает QA

Пользовательская история (user story)

Пользовательская история — короткое описание потребности пользователя, часто в виде шаблона:

«Как роль, я хочу действие, чтобы ценность.»

Важно: история сама по себе почти всегда недостаточна для тестирования. Ей нужны критерии приемки.

О Scrum и том, как команда работает с бэклогом, можно посмотреть в официальном гайде: The Scrum Guide.

Критерии приемки (acceptance criteria)

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

Критерии приемки полезны тем, что:

задают границы (что входит и что не входит)

уменьшают неоднозначность («как должно быть»)

дают основу для тестов

Use case (сценарий использования)

Use case — описание взаимодействия пользователя и системы шаг за шагом:

основной успешный поток

альтернативные потоки

ошибки и исключения

Такой формат особенно удобен, когда много правил и развилок.

Спецификация (SRS/PRD)

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

Если хочется увидеть, как требования описывают в стандартах, можно ориентироваться на описание стандарта ISO/IEC/IEEE 29148.

Анализ требований: что именно делает ручной тестировщик

Когда QA «анализирует требования», это не про поиск грамматических ошибок. Это про снижение рисков разработки и будущего тестирования.

Практический набор действий:

Понять цель изменения: какую проблему решаем и для кого.

Определить объекты тестирования: экраны, API, роли, интеграции, отчеты.

Вытащить бизнес-правила: условия, исключения, ограничения.

Найти пробелы: что не описано (ошибки, пустые значения, лимиты, статусы).

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

Сформулировать вопросы и согласовать решения.

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

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

Шаблон вопросов QA к требованию

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

Контекст и границы

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

Что входит в задачу, а что явно не входит?

Какие роли участвуют и чем отличаются права?

Данные

Какие поля обязательны, какие опциональны?

Какие форматы, длины, допустимые символы?

Что делаем с пустыми значениями?

Бизнес-правила

Какие условия включают/выключают поведение?

Какие лимиты и пороги (сумма, количество, время)?

Есть ли исключения из правил?

Ошибки и сообщения

Какие ошибки возможны и как их показываем пользователю?

Какие коды/тексты сообщений нужны?

Что происходит с данными при ошибке: сохраняем, откатываем, частично применяем?

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

С какими внешними системами взаимодействуем?

Какие таймауты и поведение при недоступности интеграции?

Какие состояния сущности существуют и как между ними переходить?

Нефункциональные требования

Какая ожидаемая скорость/нагрузка/устойчивость?

Какие требования к безопасности и доступам?

Какие браузеры/устройства/версии ОС поддерживаются?

Что такое неоднозначность и почему она опасна

Неоднозначность — это когда требование можно прочитать по-разному и оба прочтения выглядят «логичными».

Опасность неоднозначности:

разработчик реализует одно понимание, бизнес ожидает другое

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

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

Часто неоднозначности прячутся в «обычных» словах.

Слова-маркеры неоднозначности

| Маркер в требовании | Почему это риск | Как уточнять | |---|---|---| | «быстро», «не тормозит» | нет измерения | «За сколько секунд и при каких условиях?» | | «удобно», «понятно» | субъективно | «Какие конкретные элементы/правила UX считаем обязательными?» | | «по возможности», «желательно» | непонятен приоритет | «Это обязательное требование или nice-to-have?» | | «поддерживает» | непонятен объем | «Какие версии/форматы/кейсы поддерживаем, а какие нет?» | | «и т.п.», «и другие» | бесконечный список | «Дайте полный перечень или критерий включения» | | «обычно», «как всегда» | скрытые допущения | «Опишите точное правило и исключения» |

Типовые проблемы качества требований

Неполнота: не описаны ошибки, ограничения, статусы, роль, данные.

Противоречие: разные части документа говорят разное.

Непроверяемость: нельзя однозначно проверить («должно быть красиво»).

Нереализуемость: технически/по срокам невозможно, но это не проговорено.

Тестировщик не обязан «чинить» требования в одиночку, но обязан подсветить риск и добиваться прояснения.

Практические техники поиска неоднозначностей

Перефразирование и согласование смысла

Один из самых сильных приемов — коротко пересказать требование своими словами и попросить подтвердить:

«Правильно ли я понимаю, что ...?»

«То есть при условии X мы всегда делаем Y, а при Z — делаем W?»

Это быстро выявляет расхождения в понимании.

Примеры и контрпримеры

Просите примеры:

положительный пример («как должно быть»)

отрицательный пример («как точно не должно быть»)

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

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

Граничные значения — это значения «на границе правила» и рядом с ней. Например, если скидка включается от 3 000 ₽, то важны проверки:

2 999 ₽ (не должно сработать)

3 000 ₽ (должно сработать)

3 001 ₽ (должно сработать)

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

Таблица решений для бизнес-правил

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

Польза для QA:

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

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

Диаграмма состояний для сущностей

Если у сущности есть статусы (заказ: создан → оплачен → отправлен → доставлен → отменен), полезно прояснить:

какие статусы существуют

какие переходы разрешены

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

Это помогает найти пробелы: «а что если отменить уже оплаченный заказ?»

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

Ниже — типичная «плохая» формулировка и вариант, который легче тестировать.

| Было | Стало | |---|---| | «Система должна работать быстро» | «Главная страница открывается не дольше 2 секунд при скорости сети от 20 Мбит/с на браузерах Chrome и Firefox последних двух версий» | | «При ошибке показывать сообщение» | «При неверном пароле показывается текст “Неверный логин или пароль”, поле пароля очищается, счетчик попыток увеличивается на 1» | | «Поддержать загрузку файлов» | «Разрешены форматы PDF и JPG, размер до 10 МБ; при превышении размера показывается ошибка; успешный файл отображается в списке вложений» |

Ключевой принцип: критерий приемки должен отвечать на вопрос тестировщика «как понять, что сделано правильно?» без дополнительных догадок.

Мини-чек-лист QA перед стартом разработки

Понятны роли и права доступа.

Описаны данные, форматы, обязательность и ограничения.

Описаны ошибки и поведение системы при сбоях.

Зафиксированы бизнес-правила и исключения.

Определены нефункциональные ожидания (где критично).

Нет слов-маркеров без уточнения (или заведены вопросы/решения).

Понятны зависимости: интеграции, другие команды, миграции данных.

Согласованы критерии приемки.

Итоги

Требования — основа для того, чтобы тестирование было воспроизводимым и полезным.

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

Главная ценность QA на этапе требований — находить неполноту и неоднозначности до разработки.

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

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

Связь с предыдущими темами курса

В прошлых статьях мы разобрали:

роль QA в SDLC и STLC и почему тестирование начинается уже на этапе требований

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

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

не забыть важные сценарии

покрыть риски (ошибки, границы, правила)

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

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

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

Результат тест-дизайна чаще всего оформляют как:

чек-лист

тест-кейсы

набор тестовых данных

матрица покрытия (простая таблица соответствия: что требование X проверено тестами Y)

Термины удобно сверять с ISTQB Glossary.

Чек-лист и тест-кейс: что выбрать

Чек-лист — краткий список проверок без детальных шагов.

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

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

хуже воспроизводится другим человеком, если проверки сложные

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

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

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

дороже в создании и поддержке

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

если проверка простая и очевидная, часто достаточно чек-листа

если проверка сложная, рискованная или часто повторяется, лучше тест-кейс

Из чего состоит хороший тест-кейс

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

ID: уникальный идентификатор

Название: коротко и по сути (что проверяем)

Предусловия: состояние системы до теста (роль, настройки, данные)

Шаги: действия тестировщика

Тестовые данные: конкретные значения, которые нужно вводить

Ожидаемый результат: что должно получиться

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

Приоритет: насколько важно прогнать тест именно сейчас

Главное для качества тест-кейса:

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

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

привязка к требованию или риску (зачем этот тест существует)

Как строится тест-дизайн на практике

Ниже — типовой процесс, который хорошо ложится на STLC и на работу с требованиями из предыдущей темы.

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

Удобно идти такими шагами:

Уточнить «источник истины» по задаче (текст, макет, критерии приемки).

Выписать тестируемые объекты (экраны, поля, роли, статусы, интеграции).

Вытащить правила и ограничения (форматы, лимиты, условия, исключения).

Сформировать тестовые условия.

Подобрать техники тест-дизайна (в зависимости от типа логики).

Оформить проверки как чек-лист или тест-кейсы.

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

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

Пример:

«Проверить, что при неверном пароле показывается сообщение об ошибке»

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

Базовые техники тест-дизайна

Техники помогают не «придумывать тесты из головы», а системно покрывать поведение.

Классы эквивалентности

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

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

поля ввода (email, сумма, возраст)

фильтры, диапазоны, ограничения по длине

Пример требования:

«Возраст пользователя должен быть от 18 до 65 включительно»

Классы эквивалентности:

валидный класс: 18–65

невалидный класс: меньше 18

невалидный класс: больше 65

невалидный класс: не число (если поле текстовое)

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

Граничные значения

Анализ граничных значений дополняет классы эквивалентности и фокусируется на «краях», где чаще всего бывают ошибки.

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

17 (сразу ниже границы)

18 (граница)

19 (сразу выше границы)

64 (сразу ниже верхней границы)

65 (верхняя граница)

66 (сразу выше)

Если вы делаете только «середину диапазона», вы часто пропускаете дефекты типа «не включили границу».

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

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

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

скидки, тарифы, доступы по ролям

правила «если A и B, то X; если A и не B, то Y»

Пример правила:

«Скидка 10% применяется, если сумма заказа от 3000 ₽ и пользователь авторизован»

| Условие | Набор 1 | Набор 2 | Набор 3 | Набор 4 | |---|---|---|---|---| | Сумма >= 3000 | Да | Да | Нет | Нет | | Пользователь авторизован | Да | Нет | Да | Нет | | Ожидаемый результат | Скидка 10% | Нет скидки | Нет скидки | Нет скидки |

Плюсы для QA:

видно, какие комбинации покрыты

проще превращать комбинации в тест-кейсы

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

Тестирование переходов состояний применяется, когда объект системы имеет статусы, а поведение зависит от статуса.

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

заказ (создан, оплачен, отменен)

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

Что важно выяснить из требований:

полный список состояний

допустимые переходы

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

что запрещено (недопустимые переходы)

Тесты обычно строят так:

пройти допустимые переходы

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

Парное тестирование (pairwise)

Pairwise — техника снижения количества комбинаций, когда есть много параметров и значений.

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

настройки (язык, валюта, роль)

комбинации браузер + ОС + тип аккаунта

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

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

Важно понимать ограничение:

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

Сценарное тестирование на основе use case

Если требования описаны как сценарий (use case), тест-дизайн удобно строить от потоков:

основной успешный поток

альтернативные потоки

ошибки и исключения

На практике это часто превращается в:

1–2 детальных тест-кейса на основной поток

отдельные тесты на ключевые отклонения и ошибки

Негативное тестирование и «предположение об ошибках»

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

Типовые источники негативных тестов:

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

неверный формат (email без @)

превышение лимитов (слишком длинный текст)

отказ внешней системы (интеграция недоступна)

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

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

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

где чаще всего ломали при изменениях

Мини-пример: как из требования получить набор тестов

Возьмем короткое требование:

«Поле “Email” обязательно. Допустимая длина 5–254 символа. Разрешены латинские буквы, цифры, . и @. При неверном формате показываем сообщение “Некорректный email”.»

Как это превращать в тестовые условия:

Проверка обязательности.

Проверка валидного формата.

Проверка невалидного формата.

Проверка границ длины.

Проверка недопустимых символов.

Какие техники применяем:

классы эквивалентности (валидные и невалидные форматы)

граничные значения (4, 5, 6 и 253, 254, 255 символов)

Пример одного тест-кейса (в компактном стиле):

Название: «Email: ошибка при пустом значении»

Предусловия: открыта форма регистрации

Шаги: оставить поле Email пустым, нажать «Зарегистрироваться»

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

Обратите внимание: в требовании указано сообщение только про неверный формат, но не про пустое поле. Это типичный момент, где QA возвращается к анализу требований и задает вопрос: какой текст должен быть при пустом значении?

Как проверять качество собственных тестов

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

Есть ли тесты на роли и права, если они упоминаются?

Есть ли тесты на ошибки, пустые значения и невалидные данные?

Проверены ли границы (лимиты, диапазоны, длины)?

Есть ли тесты на бизнес-правила и исключения?

Понятно ли из теста, что считать успехом и что считать провалом?

Не дублируют ли тесты друг друга без причины?

Итоги

Тест-дизайн превращает требования и риски в системный набор проверок.

Чек-лист быстрее, тест-кейс воспроизводимее; выбор зависит от сложности и критичности.

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

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

Тестовая документация: чек-листы, тест-планы, отчёты

Зачем тестировщику тестовая документация

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

Тестовая документация нужна не «для галочки», а чтобы:

сохранять общий контекст: что проверяем и зачем

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

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

ускорить повторные прогоны: смоук и регресс

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

Какие документы чаще всего встречаются в ручном тестировании

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

Чек-лист: краткий список проверок.

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

Тест-план: договорённость как и в каком объёме тестируем (подход, границы, риски, ресурсы).

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

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

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

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

Целенаправленность: каждый документ отвечает на конкретный вопрос (например, «что проверить перед релизом?»).

Проверяемость формулировок: минимум слов вроде «быстро» и «корректно» без уточнения условий.

Актуальность: лучше короткий документ, который обновляют, чем идеальный, который устарел.

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

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

Чек-листы

Что такое чек-лист

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

Чек-листы особенно полезны для:

смоук-тестирования (быстрая проверка, что сборка «живая»)

короткого регресса перед релизом

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

Чтобы не вводить новый термин без пояснения:

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

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

Когда чек-лист лучше тест-кейса

Чек-лист обычно лучше, когда:

сценарий простой и понятный без пошаговой инструкции

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

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

Тест-кейс обычно лучше, когда:

правила сложные и важна точность

проверку будет выполнять другой человек или новичок

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

Как писать чек-лист, чтобы он работал

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

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

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

группируйте пункты по объектам (экраны, роли, интеграции) или по типам проверок (валидации, права, ошибки)

Мини-шаблон чек-листа

| Раздел | Пункты проверки | |---|---| | Доступы и роли | Права роли Пользователь на просмотр профиля | | Основные сценарии | Создание сущности проходит успешно при валидных данных | | Валидации | Обязательные поля не позволяют сохранить форму без ввода | | Ошибки и сбои | При недоступности сервиса показывается понятное сообщение | | Данные | Корректно сохраняются и отображаются значения после обновления страницы |

Пример: чек-лист для формы регистрации

| Раздел | Пункты проверки | |---|---| | Позитивные проверки | Регистрация успешна при валидных данных | | Обязательные поля | Пустое поле email блокирует отправку формы | | Формат данных | Email без @ не принимается | | Границы | Пароль минимальной длины принимается | | Сообщения | Текст ошибки соответствует договорённости в требованиях |

Тест-план

Что такое тест-план и чем он не является

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

Тест-план не должен превращаться в:

переписывание требований

огромный документ ради процесса

«список всех тестов» (для этого лучше подходят чек-листы и тест-кейсы)

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

Когда тест-план особенно нужен

Тест-план почти обязателен, если:

релиз рискованный (платежи, персональные данные, много интеграций)

несколько команд и много зависимостей

нужно явно согласовать, что не успеваем тестировать и какие риски принимаем

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

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

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

| Раздел | Что фиксируем | Зачем это нужно | |---|---|---| | Цель и контекст | что за релиз/фича, какая ценность | чтобы все одинаково понимали, что делаем | | Объём тестирования | что входит и что не входит | чтобы не было скрытых ожиданий | | Объекты тестирования | модули, экраны, интеграции | чтобы не забыть важное | | Подход | что проверяем вручную, что смоуком, что регрессом | чтобы расставить приоритеты | | Окружения | где тестируем, версии, конфигурации | чтобы результаты были сравнимы | | Роли и ответственность | кто делает что | чтобы не было «я думал, это проверят другие» | | Риски | что может пойти не так и как снижаем риск | чтобы управлять качеством осознанно | | Критерии входа и выхода | когда начинаем и когда считаем, что можно выпускать | чтобы решение о релизе опиралось на факты | | Артефакты | ссылки на чек-листы, кейсы, отчёты | чтобы собрать всё в одном месте |

Чтобы не вводить термин без пояснения:

Критерии входа — условия, при которых тестирование имеет смысл начинать (например, «развернули сборку, есть доступы, стабильно открывается приложение»).

Критерии выхода — условия, при которых тестирование можно завершать или рекомендовать релиз (например, «смоук пройден, критические дефекты закрыты или приняты, остаточные риски описаны»).

Мини-пример тест-плана для фичи

| Поле | Пример | |---|---| | Цель | Проверить релиз фичи «Сброс пароля по email» | | In scope | Восстановление по email, тексты ошибок, лимиты попыток | | Out of scope | Изменение политики паролей, редизайн формы логина | | Окружение | Staging, Chrome последней версии, тестовый SMTP | | Подход | Смоук: 10 мин, Функциональное: чек-лист, Регресс: критичный поток логина | | Риски | Письма не доходят; токен сброса протухает раньше/позже; утечка токена в логах | | Критерии выхода | Смоук пройден; нет дефектов уровня blocker/critical; риски зафиксированы в отчёте |

Если в команде используют уровни серьёзности дефектов, важно заранее договориться о значениях. Часто используют:

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

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

Тестовые отчёты

Зачем нужны отчёты

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

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

что не проверено и почему

какие дефекты найдены и насколько они критичны

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

Отчёты бывают двух основных типов:

Статус-отчёт: регулярная короткая сводка в процессе тестирования.

Итоговый отчёт: фиксация итогов перед релизом или по завершении тестового цикла.

Что включать в статус-отчёт

Статус-отчёт должен быть коротким и обновляемым. Типовой состав:

| Поле | Пример смысла | |---|---| | Период | «за сегодня», «за спринт», «за последние 2 дня» | | Прогресс | сколько проверок выполнено, что осталось | | Блокеры | что мешает продолжать (окружение, доступы, баги) | | Дефекты | сколько заведено и сколько критичных | | Риски | что вызывает сомнения и что нужно уточнить | | План | что будет сделано дальше |

Что включать в итоговый отчёт

Итоговый отчёт полезен как «снимок состояния качества» на момент решения о релизе.

| Раздел | Что фиксируем | |---|---| | Что тестировали | объём и ссылки на артефакты | | Что не тестировали | явные пробелы и причины | | Результаты | что прошло, что упало, что заблокировано | | Дефекты | список ключевых дефектов и их статус | | Остаточные риски | что может пойти не так в продакшене | | Рекомендация | выпускать или нет, при каких условиях |

Важно: итоговый отчёт не «гарантия качества», а прозрачное описание фактов и рисков, чтобы команда приняла осознанное решение.

Как связать требования, тесты и отчётность в одну систему

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

хранить проверки в удобном виде

отслеживать, что уже покрыто

показывать прогресс и риски

Практичный минимум трассируемости:

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

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

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

!Схема показывает, как требования превращаются в проверки и как результаты попадают в отчётность

Частые ошибки в тестовой документации и как их избегать

Ниже — типовые проблемы, которые делают документы бесполезными.

Документы слишком большие: оставляйте только то, что помогает принимать решения.

Нет границ: обязательно фиксируйте in scope и out of scope в тест-плане.

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

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

Не обновляют: лучше упрощать формат, чем поддерживать «идеальный», который никто не ведёт.

Итоги

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

Тест-план фиксирует объём, подход, окружения, риски и критерии готовности; это договорённость команды, а не формальность.

Отчёты делают тестирование прозрачным: показывают прогресс, дефекты и остаточные риски.

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

Баг-репорты: приоритеты, серьёзность, жизненный цикл дефекта

Связь с предыдущими темами курса

Ранее в курсе мы разобрали, как тестирование встроено в SDLC и STLC, как анализировать требования и превращать их в проверки (тест-дизайн), а также как оформлять тестовую документацию (чек-листы, тест-планы, отчёты).

Баг-репорт логично продолжает эту цепочку:

требования и критерии приемки задают ожидаемое поведение

тесты помогают сравнить ожидаемое и фактическое

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

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

Что такое дефект и что такое баг-репорт

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

Баг-репорт — это запись о дефекте в понятном для команды формате. Его задача не «пожаловаться», а передать информацию для действий:

что именно сломано

где и в каких условиях

как воспроизвести

почему это важно (влияние и риск)

Зачем нужны баг-репорты

Хороший баг-репорт помогает команде делать три вещи:

быстро воспроизвести: без «а у меня не повторяется»

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

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

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

Анатомия хорошего баг-репорта

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

| Поле | Что писать | Зачем это нужно | |---|---|---| | Заголовок (Summary) | Коротко: что и где | Быстрый поиск и понимание сути | | Окружение (Environment) | Платформа, ОС, браузер, версия сборки, стенд | Чтобы воспроизвести в тех же условиях | | Предусловия | Роль, состояние данных, настройки | Чтобы не гадать, с чего начинать | | Шаги воспроизведения | Нумерованный список действий | Чтобы другой человек повторил один-в-один | | Фактический результат | Что произошло | Фиксация наблюдения | | Ожидаемый результат | Как должно быть по требованиям/договорённости | Точка сравнения | | Вложения | Скриншот, видео, логи, HAR (если веб) | Ускоряет диагностику | | Severity (серьёзность) | Насколько сильно влияет дефект | Помогает оценить риск | | Priority (приоритет) | Насколько срочно исправлять | Помогает планировать работу | | Дополнительно | Частота, workaround, затронутые модули | Помогает принимать решение |

Заголовок: как писать, чтобы он работал

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

Плохо: Не работает кнопка

Лучше: Профиль: кнопка "Сохранить" неактивна при изменении поля "Телефон"

Ещё лучше (если важно): Профиль: "Сохранить" неактивна при телефоне в формате +7… (Chrome 121)

Шаги воспроизведения: правило воспроизводимости

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

атомарными (одно действие — один шаг)

без догадок (никаких «нажать куда-нибудь»)

с конкретными данными, если данные важны

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

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

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

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

спецификация/договорённость

макет (если поведение явно следует из UX)

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

Частота (Frequency) и workaround

Эти пункты часто решают судьбу дефекта:

частота: всегда, 1 из 10, только на медленном интернете

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

Серьёзность (Severity) и приоритет (Priority)

Эти понятия путают чаще всего, поэтому важно разделить.

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

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

Один и тот же дефект может быть:

высокой серьёзности, но низкого приоритета (редкий кейс, затрагивает мало людей и не в этом релизе)

низкой серьёзности, но высокого приоритета (мелкая ошибка на главной странице перед маркетинговой кампанией)

Пример типовой шкалы Severity

Шкалы зависят от компании, но часто используют такую логику:

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

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

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

Minor: небольшое отклонение, не мешает выполнению задачи

Trivial: косметика, тексты, выравнивание, без влияния на функциональность

Пример типовой шкалы Priority

P1: нужно исправить как можно скорее (обычно до релиза/в рамках спринта)

P2: важно, но может подождать, если не успеваем

P3: можно отложить

P4: не планируем в ближайшее время

Матрица: как Severity и Priority встречаются на практике

| Ситуация | Severity | Priority | Пример | |---|---|---|---| | Полная блокировка ключевого потока | Blocker/Critical | P1 | Нельзя оплатить заказ | | Дефект серьёзный, но встречается редко | Critical/Major | P2–P3 | Падение только на Android 15 beta | | Мелочь, но на самом видимом месте | Minor/Trivial | P1–P2 | Опечатка в заголовке лендинга перед запуском рекламы | | Некритично и незаметно | Minor/Trivial | P3–P4 | Редкий UI-артефакт в глубоком разделе |

Важно: тестировщик обычно предлагает severity и priority, но итоговые значения часто определяются на триаже вместе с продуктом и разработкой.

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

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

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

Типовые статусы и что они означают

Чтобы не возникало «мы по-разному понимаем статус», ниже — распространённые значения.

| Статус | Смысл | |---|---| | Новый (New) | Дефект зарегистрирован, ещё не рассмотрен | | Триаж (Triage) | Команда уточняет, действительно ли это дефект, насколько он важен, кто будет исправлять | | В работе (In Progress) | Разработчик занимается исправлением | | Исправлено (Fixed/Resolved) | Разработчик считает проблему исправленной и передаёт на проверку | | Готово к проверке (Ready for QA) | Сборка/изменение доступно тестировщику | | Проверено (Verified) | QA подтвердил, что дефект исправлен и не воспроизводится в нужных условиях | | Закрыто (Closed) | Баг закрыт процессно (часто после verification) | | Переоткрыт (Reopened) | Дефект снова воспроизводится или исправление неполное | | Дубликат (Duplicate) | Уже есть баг про то же самое | | Не баг (Not a bug/By design) | Поведение соответствует договорённости или задумано так | | Не воспроизводится (Cannot reproduce) | Повторить не удалось, недостаточно данных или плавающая проблема | | Отложено (Deferred) | Решили не чинить сейчас, вернуться позже | | Не будем исправлять (Won't fix) | Решили не чинить вообще (дорого, нет ценности, продукт меняется) |

Что важно при переходе в "Исправлено"

Чтобы QA мог проверить исправление без потери времени, полезно, когда разработчик добавляет:

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

что изменилось по логике (если есть нюансы)

как проверить (если сценарий сложный)

Триаж дефектов: как принимаются решения

Триаж — это разбор дефектов и принятие решений по ним: баг или не баг, когда исправляем, кто владелец.

На триаже обычно уточняют:

это действительно дефект или не хватает требований

severity и priority

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

нужна ли дополнительная диагностика (логи, метрики, шаги)

Если у дефекта нет чётких шагов или окружения, он часто уходит в "Не воспроизводится" или возвращается автору на уточнение.

Частые ошибки в баг-репортах и как их избежать

Нет конкретных шагов: заменяйте общие фразы на действия и данные.

Смешаны факты и предположения: отделяйте наблюдаемое (факт) от гипотезы причины.

Нет окружения: указывайте стенд, версию сборки, браузер/ОС, роль пользователя.

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

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

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

Пример баг-репорта (шаблон с заполнением)

Итоги

Баг-репорт — инструмент коммуникации: он должен помогать воспроизвести, оценить риск и принять решение.

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

Severity — сила влияния дефекта на продукт, Priority — срочность исправления.

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

Практика тестирования: web, mobile, API на базовом уровне

Как эта тема связана с предыдущими статьями курса

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

На этапе SDLC QA участвует в обсуждении и уточнении требований.

Требования превращаются в проверяемые критерии приемки.

По критериям приемки и рискам строится тест-дизайн (чек-листы и тест-кейсы).

Результаты тестирования фиксируются в тестовой документации и отчётах.

Найденные несоответствия оформляются как баг-репорты.

Эта статья отвечает на практический вопрос: как именно выполнять проверки руками в трёх самых частых направлениях — web, mobile и API — на базовом уровне, чтобы ваши тесты и баг-репорты были воспроизводимыми и полезными для команды.

!Схема показывает, что web и mobile обычно являются клиентами, которые обращаются к API, а проблемы могут быть на любом слое.

Общая база перед практикой: что подготовить и как не потерять контекст

Что такое окружение и почему оно важно

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

Если вы не фиксируете окружение, то:

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

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

отчёт по тестированию будет неинформативным

Минимальный набор информации, который стоит фиксировать всегда

Стенд или адрес системы.

Версия приложения или номер сборки.

Платформа: web или mobile.

Для web: браузер и версия.

Для mobile: устройство, ОС, способ установки.

Тестовый пользователь: роль и важные данные (например, тариф, регион).

Базовый цикл ручной проверки

Понять ожидаемое поведение по требованиям и критериям приемки.

Подготовить данные и предусловия.

Выполнить проверку и сравнить факт с ожиданием.

Зафиксировать результат: пройдено, не пройдено, заблокировано.

Если найден дефект — оформить баг-репорт с шагами и окружением.

Практика web-тестирования (браузер)

Что обычно проверяют в web на базовом уровне

Основные пользовательские сценарии: регистрация, логин, поиск, оформление заказа.

Формы: обязательность, форматы, ошибки.

Навигация: переходы, ссылки, кнопки.

Отображение данных: списки, карточки, статусы.

Поведение при ошибках: понятные сообщения, отсутствие «падений».

Типовые особенности web, о которых важно помнить

Приложение зависит от браузера и его настроек.

На поведение влияют cookies и localStorage.

Ошибки часто проявляются только при определённых сетевых условиях.

Рендер и данные приходят асинхронно, поэтому возможны состояния «в процессе загрузки».

Инструменты web-тестировщика: DevTools на базовом уровне

DevTools (инструменты разработчика) есть в большинстве браузеров. На базовом уровне вам особенно полезны вкладки:

Network: посмотреть запросы, статусы, время, ответы.

Console: увидеть ошибки JavaScript.

Application: проверить cookies, localStorage, sessionStorage.

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

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

MDN Web Docs: Инструменты разработчика

Что смотреть в Network: минимальный практический чек

Статус ответа: 200, 400, 401, 403, 404, 500.

Корректность запроса: URL, метод, параметры.

Время ответа: резкие деградации и таймауты.

Ответ сервера: есть ли ожидаемые поля.

Частые web-дефекты и как их быстро локализовать

| Симптом | Вероятная причина | Что сделать тестировщику | |---|---|---| | Нажали кнопку, «ничего не произошло» | JS-ошибка или запрос не ушёл | Проверить Console и Network | | Данные не обновились после действия | Кэш, фронт не обновил состояние, API вернул старое | Проверить ответ API в Network, перезагрузить страницу | | «Вылогинивает» при переходах | Проблемы с cookie или сессией | Проверить cookies в Application | | Ошибка только у части пользователей | Роль, регион, данные | Сверить роль, настройки, тестовые данные |

Мини-практика: как оформить проверку формы как тест-кейс

Пример структуры тест-кейса для web-формы:

| Поле | Пример | |---|---| | Название | Профиль: сохранение телефона в формате +7XXXXXXXXXX | | Предусловия | Пользователь авторизован | | Шаги | Открыть профиль → изменить телефон → нажать «Сохранить» | | Ожидаемый результат | Телефон сохранён, отображается новый номер, показано подтверждение | | Данные | +79001234567 |

Практика mobile-тестирования (iOS/Android)

Чем mobile отличается от web с точки зрения ручного тестирования

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

Есть разрешения ОС: камера, геолокация, уведомления.

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

Есть разнообразие устройств, экранов и версий ОС.

Базовый набор проверок для mobile-приложения

Установка и запуск.

Регистрация и логин.

Разрешения: запрос, отказ, повторный запрос, поведение без разрешения.

Офлайн и плохая сеть: корректные сообщения, отсутствие «вечной загрузки».

Смена ориентации экрана, если поддерживается.

Фоновые сценарии: свернули, вернулись, приложение не «забыло» состояние.

Разрешения: как тестировать системно

Первый запуск: приложение запрашивает разрешение.

Пользователь выбирает «Разрешить».

Пользователь выбирает «Запретить».

Пользователь меняет разрешение в настройках ОС.

Приложение корректно объясняет, зачем нужно разрешение.

Прерывания и устойчивость: базовые сценарии

Свернуть приложение во время загрузки и вернуться.

Переключить Wi‑Fi на мобильную сеть.

Включить авиарежим и выключить.

Получить push-уведомление и открыть приложение по нему.

Что обязательно указывать в баг-репортах для mobile

Устройство и модель.

Версия ОС.

Версия приложения и тип сборки.

Тип установки: магазин, TestFlight, APK.

Сеть: Wi‑Fi или LTE.

Частые mobile-дефекты

| Категория | Пример | |---|---| | UI и адаптация | Элемент не помещается на маленьком экране | | Разрешения | Камера работает только после перезапуска | | Жизненный цикл | После сворачивания приложение возвращается на главный экран вместо текущего | | Сеть | При пропаже интернета нет сообщения об ошибке |

Практика API-тестирования (базовый уровень)

Что такое API простыми словами

API — это интерфейс, через который одна программа запрашивает данные или действия у другой программы.

В типичном продукте:

web или mobile отправляет запрос

сервер возвращает ответ

пользователь видит результат в интерфейсе

HTTP-основа, которую нужно знать ручному тестировщику

| Термин | Смысл | |---|---| | URL | адрес ресурса, например /api/orders/123 | | Метод | действие: GET, POST, PUT, PATCH, DELETE | | Заголовки (headers) | метаданные запроса и ответа, например Authorization | | Тело (body) | данные запроса или ответа, часто JSON | | Статус-код | результат обработки: 200, 400, 401, 403, 404, 500 |

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

MDN Web Docs: HTTP status codes

Как тестировать API на базовом уровне

Даже если в команде есть автотесты, ручная базовая проверка API полезна, чтобы быстро изолировать проблему: UI это или backend.

Типовой подход:

Найти описание API (Swagger/OpenAPI, документация, коллекция запросов).

Определить предусловия: какой пользователь, какие данные нужны.

Отправить запрос.

Проверить статус-код.

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

Проверить негативные случаи: неверные данные, отсутствие авторизации.

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

Один из популярных вариантов — Postman.

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

Минимальный набор проверок для одного endpoint

Предположим, есть endpoint создания заказа POST /api/orders.

Проверки базового уровня:

Позитивный сценарий: валидный запрос создаёт заказ.

Валидации: отсутствие обязательного поля возвращает 400.

Авторизация: без токена возвращает 401.

Права: пользователь без роли не может создать заказ (например, 403).

Контракт: ответ содержит id, status, total.

Как связать API-дефект с UI-дефектом

Если UI показывает ошибку, полезно определить, где источник:

В DevTools Network видно, что API вернул 500.

UI показал «Что-то пошло не так».

Тогда дефект может быть:

backend-дефект (500 при валидных данных)

UX-дефект (неинформативное сообщение)

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

Сквозная практика: как тестировать сценарий «Web + API» или «Mobile + API»

Пример сквозного сценария

Сценарий: пользователь применяет промокод в корзине.

Что проверять по слоям:

UI: поле ввода промокода, кнопка, сообщения.

API: запрос применения промокода, статус-код, сумма и скидка в ответе.

Данные: итоговая сумма обновилась и корректно отображается.

Как оформить результаты, чтобы это помогло команде

В чек-листе отметьте прогон по основным потокам.

В отчёте зафиксируйте, что именно проверено и на каком стенде.

В баг-репорте приложите подтверждение: скриншот UI и детали запроса из Network или Postman.

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

Путают отсутствие требования с дефектом.

Не фиксируют окружение и версии.

Описывают шаги без данных, из-за чего баг не воспроизводится.

Проверяют только «позитив», пропуская ошибки и границы.

Не разделяют проблемы разных слоёв, когда это нужно.

Итоги

Web-тестирование на базовом уровне опирается на сценарии, формы, сообщения об ошибках и DevTools (Network, Console, Storage).

Mobile-тестирование добавляет установку, разрешения ОС, прерывания, сети и разнообразие устройств.

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

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

Инструменты и процессы: Jira, TestRail, Scrum и релизы

Как эта тема связана с предыдущими статьями курса

В прошлых темах мы выстроили «скелет» работы ручного тестировщика:

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

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

фиксируем результаты в тестовой документации и отчётах

несоответствия оформляем в баг-репорты с понятным жизненным циклом

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

как устроена работа в Jira (задачи, баги, статусы, связи)

как использовать TestRail (хранение тестов и прогоны)

как выглядит Scrum «вживую» и где в нём место QA

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

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

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

Когда продукт растёт, «проверили на словах» перестаёт работать. Инструменты нужны, чтобы:

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

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

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

строить трассируемость: требование → тесты → результаты → дефекты

На практике чаще всего используют связку:

Jira (или аналог): управление задачами и дефектами

TestRail (или аналог): хранение тестов и фиксация результатов прогонов

Scrum (или другой процесс): правила, по которым команда планирует и поставляет изменения

Jira для тестировщика: как устроена работа с задачами и багами

Что такое Jira и что в ней важно знать QA

Jira — система управления задачами и процессами разработки. Официальный сайт:

Jira Software

Тестировщику важно понимать три вещи:

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

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

связи (как связать требование, тесты, баги и релиз)

Типовые типы задач

В разных командах названия отличаются, но смысл обычно такой:

Epic: крупная инициатива, объединяющая множество задач

Story: пользовательская история с ценностью и критериями приемки

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

Bug: дефект, найденный в тестировании или в эксплуатации

Sub-task: подзадача внутри основной задачи

QA чаще всего работает со Story/Task (как объект тестирования) и Bug (как результат несоответствия).

Что в задаче нужно QA, чтобы начать тестирование

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

описание изменения и его цель

критерии приемки (проверяемые условия)

ссылки на макеты/прототипы (если есть UI)

границы: что входит и что не входит

окружение/фича-флаги/особые настройки (если применимо)

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

Workflow в Jira: почему статусы важны

Workflow — это набор статусов и правил перехода задачи. Для QA особенно полезно договориться о смысловых состояниях:

«можно начинать тестировать»

«тестирование выполнено, есть результаты»

«нужны правки / есть дефекты»

«готово к релизу»

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

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

Полезные типы связей:

bug «найден в» story/task (или «is caused by»)

bug «дубликат» другого bug

story/task «связана с» epic

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

ссылку на тест-ран в TestRail в задачу или в комментарий

ссылки на ключевые баги в итоговый комментарий к релизной задаче

Практика: как QA работает с задачей в Jira

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

Открыть story/task и проверить, что понятны критерии приемки и границы.

Составить чек-лист или тест-кейсы (часто это будет ссылка на TestRail).

Получить сборку/доступ к стенду и выполнить тестирование.

Зафиксировать результат: комментарий, статус, ссылка на тест-ран.

Если найден дефект, завести bug и связать его с исходной задачей.

TestRail для тестировщика: тест-кейсы и прогоны

Что такое TestRail и зачем он нужен

TestRail — система управления тестированием: хранение тестов, запуск прогонов, отчётность. Официальный сайт:

TestRail

Если Jira отвечает на вопрос «что делаем и какие проблемы нашли», то TestRail отвечает на вопрос:

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

какие из них мы запускали

какой результат прогона

Базовые сущности в TestRail

Обычно встречаются такие элементы:

Test Case: тест-кейс

Test Suite: набор кейсов по модулю/фиче

Test Run: конкретный прогон набора кейсов на конкретной сборке/стенде

Test Plan: набор прогонов (например, по разным браузерам или платформам)

Ключевая идея: тест-кейсы — это «база знаний», а тест-ран — это «факт выполнения».

Статусы результатов и что они означают

Стандартные статусы могут отличаться, но смысл обычно такой:

Passed: проверка прошла

Failed: проверка упала (и обычно есть баг)

Blocked: не можем выполнить (нет окружения, дефект блокирует, нет доступа)

Retest: нужно перепроверить после фикса

Важно: если тест упал, полезно указывать ссылку на bug в Jira прямо в результате кейса — это ускоряет коммуникацию.

Как связать Jira и TestRail на практике

Цель связки — трассируемость. Минимально рабочая схема:

в Jira-задаче есть ссылка на тест-ран или тест-план в TestRail

в результатах TestRail у неуспешных кейсов есть ссылки на баги в Jira

Так команда видит:

какие требования реально прогнали

какие дефекты блокируют релиз

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

Когда TestRail особенно полезен, а когда можно обойтись чек-листом

TestRail особенно полезен, когда:

есть регулярный регресс

тестируют несколько людей

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

есть аудит/комплаенс, где важно фиксировать факты проверок

Можно обойтись чек-листом в задаче или документе, когда:

продукт маленький, команда небольшая

изменения редкие

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

Но даже в небольших командах важно не путать «быстро» и «хаотично»: результаты всё равно должны быть воспроизводимыми.

Scrum для тестировщика: как выглядит процесс и где место QA

Что такое Scrum простыми словами

Scrum — фреймворк, который помогает команде поставлять продукт итерациями. Первоисточник:

The Scrum Guide

Суть: команда работает короткими циклами (спринтами), в конце каждого цикла получает готовый инкремент продукта.

Роли в Scrum

В Scrum формально три роли:

Product Owner: отвечает за ценность и приоритеты

Scrum Master: помогает команде следовать Scrum и улучшать процесс

Developers: все, кто создаёт инкремент (в некоторых командах сюда входит и QA)

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

События Scrum и что делает QA

Sprint Planning: QA помогает уточнять критерии приемки, риски, объём тестирования, зависимости по окружениям.

Daily Scrum: QA синхронизируется по готовности функциональности, блокерам, дефектам.

Sprint Review: QA помогает честно показать, что реально готово, а что имеет риски.

Sprint Retrospective: QA участвует в улучшении процесса (например, почему баги утекли, где не хватило критериев).

Артефакты Scrum и связь с тестированием

| Артефакт | Что это | Как участвует QA | |---|---|---| | Product Backlog | общий список работ | уточняет требования, помогает находить пробелы и риски | | Sprint Backlog | работы на спринт | планирует проверки, договорённости по готовности | | Increment | результат спринта | тестирует, фиксирует статус и остаточные риски |

Definition of Done и почему это важно для QA

Definition of Done — это общая договорённость команды, что значит «задача сделана». Это не только «код написан», но и, например:

критерии приемки выполнены

тестирование проведено (в каком объёме — договорились)

нет критических дефектов или они приняты

обновлена документация (если требуется)

Если DoD нет или он формальный, QA постоянно будет сталкиваться с ситуацией «вроде готово, но тестировать нечего».

!Цикл Scrum и места, где QA влияет на качество

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

Базовые понятия релизного процесса

Термины, которые часто встречаются в командах:

Build (сборка): конкретная версия приложения/сервиса, которую можно установить или развернуть

Staging (тестовый стенд): окружение, максимально похожее на продакшен

Release Candidate (RC): кандидат в релиз, сборка, которую команда рассматривает как «готовую к выпуску»

Go/No-Go: решение выпускать или не выпускать на основе фактов и рисков

Hotfix: срочное исправление в продакшене, обычно вне планового релиза

Что обычно включает подготовка релиза

Практичный минимальный набор шагов:

Зафиксировать состав релиза: какие задачи входят.

Убедиться, что критерии приемки по ключевым задачам закрыты.

Прогнать смоук на RC-сборке.

Прогнать регресс по критичным пользовательским потокам.

Собрать список известных проблем и остаточных рисков.

Принять решение Go/No-Go.

Тестировщик здесь отвечает за прозрачность: что проверено, что не проверено, какие риски остались и почему.

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

Ниже — пример того, что команда может считать «достаточным» (это не универсальный стандарт, а шаблон для обсуждения):

смоук пройден на RC

нет дефектов уровня blocker/critical в статусе «открыт»

по major-дефектам есть решение: исправляем сейчас или принимаем риск

прогнан минимальный регресс ключевых потоков

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

Как QA помогает релизу быть предсказуемым

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

вести короткий статус по тестированию (как мы обсуждали в теме про отчёты)

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

разделять проблемы по слоям (UI/API/данные), чтобы быстрее диагностировали

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

Типовые ошибки в релизах и как QA может их предотвратить

«Тестировали не ту сборку»: всегда фиксируйте номер версии/сборки в отчёте и в баг-репортах.

«Не договорились, что не тестируем»: в тест-плане или релизной задаче явно пишите out of scope.

«Регресс не успели и выпустили вслепую»: сокращайте регресс до риск-ориентированного минимума, а не пытайтесь прогнать всё.

«Баги закрыты статусом, но не проверены»: разделяйте “Fixed” и “Verified” и следите за этим в workflow.

Как собрать это в единый рабочий процесс

Ниже — практичный «сквозной» подход, который хорошо сочетается с материалом всего курса:

В Jira есть story/task с критериями приемки и границами.

QA делает тест-дизайн и создаёт проверки: чек-лист или тест-кейсы в TestRail.

На конкретной сборке создаётся тест-ран (TestRail), выполняются проверки.

По найденным дефектам заводятся баги в Jira и связываются с исходными задачами.

После фикса дефекты уходят на ретест, результаты фиксируются.

Перед релизом QA даёт статус: прогресс, список дефектов, остаточные риски, рекомендация.

Так инструменты становятся не «административной нагрузкой», а системой, которая помогает выпускать продукт предсказуемо.

Итоги

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

TestRail хранит тест-кейсы и фиксирует факты прогонов; полезен для регресса и отчётности.

Scrum задаёт ритм работы команды; QA наиболее эффективен, когда участвует с этапа требований и влияет на Definition of Done.

Релиз — это управляемое решение на основе проверок и рисков; задача QA — сделать качество измеримым и понятным через результаты и остаточные риски.