База для QA
К списку уроков
Блок 3 · Теория тестирования

Урок 10. Работа с требованиями

Как понять, что тестировать

Темы урока

Бизнес/функциональные/нефункциональные требования, свойства хороших требований, анализ требований, что делать если требований нет

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

Опытный тестировщик начинает работу с требований, а не с кнопок. Плохо написанное ТЗ — это уже баг. Просто очень дорогой: исправление на стадии требований обходится в 10–100 раз дешевле, чем на продакшне.

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

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

Виды требований

Три уровня: от бизнеса до системы

Уровень Что описывает Пример
Бизнес-требования Зачем создаётся продукт «Увеличить средний чек на 20%»
Пользовательские Что пользователь хочет сделать User Stories, Use Cases
Системные Конкретное поведение системы «При нажатии "Оформить заказ" система создаёт запись в БД»

Каждый следующий уровень уточняет предыдущий.

Функциональные vs Нефункциональные

Функциональные — «что делает система»:

  • Добавить товар в корзину
  • Применить промокод
  • Создать заказ

Нефункциональные — «как хорошо это делает»:

  • Производительность: «страница каталога открывается не дольше 2 секунд при 1000 товарах»
  • Безопасность: «данные передаются по HTTPS, пароль не хранится в открытом виде»
  • Доступность: «элементы управления доступны с клавиатуры, контраст — не ниже WCAG AA»

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

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

10 свойств хорошего требования

Свойство Суть
Полнота Всё описано, нет открытых вопросов, не нужно угадывать
Корректность Утверждения правдивы, не противоречат логике
Согласованность Требования не противоречат друг другу внутри документа
Ясность Одна интерпретация для всей команды
Тестируемость К требованию можно написать тест-кейс
Прослеживаемость Связано с бизнес-целью, зафиксировано в RTM
Атомарность Один смысл — одно требование
Выполнимость Реализуемо в рамках ресурсов и технологий
Модифицируемость Легко изменить без потери целостности
Ранжированность Приоритет определён

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

Если разработчик, тестировщик и аналитик читают требование и понимают разное — оно плохое.

Слова-ловушки: «корректно», «быстро», «удобно» — заменяем на числа, условия и действия.

Единая терминология: «Корзина» — везде корзина, не «bag», «cart», «список товаров».

Тестируемость — важнейшее свойство для QA

Простая проверка: можно ли написать тест-кейс? Можно ли сказать «соответствует» или «не соответствует»?

User Story без Acceptance Criteria — это ещё не требование, это идея. QA должен требовать AC до начала работы.

Техники анализа требований

Это то, что QA делает до первого тест-кейса — ищет дыры в документации.

CRUDL

Проверяем, описано ли поведение объекта для:

  • Create — создать
  • Read — прочитать
  • Update — обновить
  • Delete — удалить
  • List — список

Часто Update или Delete просто забывают описать.

Негативные сценарии

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

Граничные значения в требованиях

Где есть числа — там нужны пороги. «Сумма ≥ 500 рублей» — что при ровно 500? При 499.99?

Матрица трассируемости (RTM)

RTM — таблица «требование → тест-кейс». На каждое требование — минимум одна проверка.

Что даёт RTM:

  • Видно, какие требования покрыты тестами, а какие нет
  • Инструмент для оценки полноты тестирования
  • Помогает планировать регресс: что точно проверить при каждом релизе

Пример RTM для «Пиццаеда»

ID требования Требование Тест-кейс Статус
REQ-01 Промокод QA60 даёт скидку 10% TC-01: ввод валидного промокода ✅ Покрыто
REQ-02 При пустой корзине заказ оформить нельзя TC-05: попытка оформить пустую корзину ✅ Покрыто
REQ-03 Доставка бесплатна при сумме ≥ 1500 ₽ TC-09: сумма ровно 1500 ₽ ✅ Покрыто
REQ-04 Поле «телефон» обязательно при оформлении TC-12: отправка формы без телефона ✅ Покрыто
REQ-05 При уменьшении количества до 0 товар удаляется — ❌ Не покрыто

Из примера видно: REQ-05 не имеет тест-кейса. Это белое пятно в покрытии — QA должен добавить проверку до следующего регресса.

Форматы требований

Формат Когда встречается
SRS (Software Requirements Specification) Крупные и enterprise-проекты, полная спецификация
User Story Agile-команды: «Как [роль], я хочу [действие], чтобы [цель]»
Use Case Детальное описание: основной поток + альтернативные + исключения

User Story без Acceptance Criteria — не требование, а пожелание.

Что делать если ТЗ нет

Это нормальная ситуация, особенно в стартапах. Алгоритм:

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

Анализ требований «Пиццаеда»

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

Требование Дыра
«Доставка бесплатна при сумме ≥ 1500 рублей» До скидки или после? Не указано
«Поле телефон обязательно» Какой формат? +7? 8? С пробелами? Что валидно?
«При уменьшении количества до 0 товар удаляется» Что если ввести −1 или −999?

Именно такие дыры QA ищет до разработки — пока их исправление стоит дёшево.

Ключевые тезисы для теста

  • Требование — описание того, что должна делать система и как себя вести; основа для тест-кейсов и критериев приёмки.
  • 30% дефектов закладываются на этапе написания требований — до разработки.
  • Функциональные требования — «что делает», нефункциональные — «как хорошо делает».
  • НФ-требования без цифр и условий невозможно проверить.
  • Тестируемость — самое важное свойство для QA: к требованию должен писаться тест-кейс.
  • Слова «быстро», «удобно», «корректно» — красные флаги плохого требования.
  • RTM связывает каждое требование с тест-кейсами и показывает покрытие.
  • CRUDL — проверяй, описаны ли Create/Read/Update/Delete/List для каждого объекта.
  • Если ТЗ нет — декомпозиция интерфейса и зоны риска.
  • User Story без Acceptance Criteria — это идея, не требование.

Полезные ссылки