Требование – это то, что система обязана делать, записанное так, что по нему можно написать тест. Всё остальное – пожелание. Здесь: какие бывают требования, по каким свойствам их проверяют, как читать спеку глазами тестировщика и какие дефекты встречаются чаще всего. В конце – тренажёр: дано требование, найди в нём дефект.
Одна бизнес-цель разворачивается в десятки конкретных требований. Тестировщику уровень важен по практической причине: он подсказывает, у кого спрашивать, когда в спеке дырка. Про сроки релиза спрашивают продакта, про текст ошибки – аналитика.
Цель, ради которой продукт вообще делают. Живут в концепции продукта, в презентации для инвесторов, в голове у владельца.
Тестировщик их не проверяет напрямую, но именно они объясняют, почему фича важнее другой.
Что человек делает с системой и ради чего. Чаще всего оформляются как User Story с критериями приёмки.
Отсюда растут сквозные сценарии и приёмочное тестирование.
Конкретное поведение: что система делает в ответ на действие или событие. Формула "при условии X система делает Y".
Основной хлеб тест-дизайна: из них получаются тест-кейсы почти один в один.
Качество работы, а не набор функций. Их забывают чаще всего, а стоят они дороже всего: под нагрузку и безопасность архитектуру переделывают, а не докручивают.
Когда спрашиваешь аналитика "а нефункциональные требования у нас есть?", полезно назвать конкретные категории. Модель качества ISO/IEC 25010 даёт готовый список, по которому удобно идти пунктом за пунктом.
| Характеристика | О чём вопрос | Требование, которое можно проверить |
|---|---|---|
| Функциональная пригодность | Функции есть, они полные и корректные? | Калькулятор скидки считает по прайсу из справочника, расхождение 0 копеек. |
| Производительность | Быстро? Сколько ресурсов ест? | Главная отрисовывается за 2 с на 4G при 1000 одновременных сессий. |
| Совместимость | Уживается с соседями? | Работает в Chrome, Safari и Firefox двух последних версий. |
| Удобство (usability) | Человек справится? | Новый пользователь оформляет заказ за 5 шагов без подсказок. |
| Надёжность | Падает? Как восстанавливается? | Доступность 99,9% в месяц, восстановление после отказа узла до 60 с. |
| Безопасность | Данные защищены? | Все запросы только по HTTPS, сессия истекает через 30 минут простоя. |
| Сопровождаемость | Легко чинить и менять? | Покрытие модуля оплаты юнит-тестами не ниже 80%. |
| Переносимость | Переедет на другое окружение? | Сервис поднимается из образа на любом хосте с Docker, без правки кода. |
Список из стандарта ISO/IEC/IEEE 29148:2018 – он про инженерию требований и перечисляет, каким должно быть каждое отдельное требование. Это удобный чек-лист для ревью: идёшь по строке и спрашиваешь у требования каждый пункт.
| Свойство | Что проверяешь | Пример нарушения |
|---|---|---|
| Необходимое necessary | Без него система не решает задачу. Убери требование – что сломается? | "Добавим поддержку факса, вдруг попросят". |
| Уместное appropriate | Уровень детализации соответствует уровню документа: бизнес-требование не диктует цвет кнопки. | В бизнес-требованиях расписан SQL-запрос к таблице заказов. |
| Недвусмысленное unambiguous | Все читают одинаково. Термины определены, местоимения понятны. | "Система должна обеспечивать прозрачное шифрование". Прозрачное для кого? |
| Полное complete | Всё нужное внутри, без "и так далее" и ссылок в никуда. | "Экспорт в PDF, PNG и т. д.". Какие ещё форматы? |
| Единичное singular | Одно требование – одна способность. Ищи союз "и" между разными действиями. | "Кнопка неактивна при пустой корзине, а журнал хранит 20 записей". |
| Выполнимое feasible | Реализуемо в рамках технологий, бюджета и срока проекта. | "Система выдерживает любую нагрузку без деградации". |
| Проверяемое verifiable | Можно придумать проверку с однозначным вердиктом. Измеримо. | "Личный кабинет должен быть удобным". |
| Корректное correct | Точно передаёт потребность, из которой выросло. Не искажает бизнес-правило. | Скидка пенсионерам 10%, в требовании написано 15%. |
| Соответствующее conforming | Написано в принятом на проекте шаблоне и стиле. | Половина спеки – User Story, половина – проза в чате. |
Отдельное требование может быть безупречным, а спека целиком – мусором. Поэтому тот же стандарт отдельно описывает свойства набора.
Все нужды закрыты, дырок нет. Проверяется трассировкой: у каждой потребности есть хотя бы одно требование.
Два требования не требуют взаимоисключающего. Классика: "гость оформляет заказ" на одной странице и "заказ только для авторизованных" на другой.
Каждое по отдельности реально, а все вместе – в срок и бюджет? Часто ответ отрицательный, и это повод для приоритизации.
Читатель из целевой аудитории разбирается без переводчика. Если спеку понимает только автор, набор непонятен.
Заказчик может подтвердить: да, если это сделать, моя задача решена.
Проранжированность (приоритеты расставлены) и модифицируемость (правка одного требования не заставляет переписывать полдокумента). В 29148 они спрятаны внутри других пунктов, но на проекте болят отдельно.
В рунете гуляет список из десяти свойств: завершённость, атомарность, непротиворечивость, недвусмысленность, выполнимость, обязательность, прослеживаемость, модифицируемость, проранжированность, проверяемость. Это пересказ книги Карла Вигерса "Разработка требований к программному обеспечению", а не стандарта. Собеседующие часто спрашивают именно его, так что вот перевод.
| Список из 10 | Что это в терминах 29148:2018 |
|---|---|
| Завершённость | Complete (полное) |
| Атомарность | Singular (единичное) |
| Недвусмысленность | Unambiguous |
| Выполнимость | Feasible |
| Обязательность | Necessary (необходимое) |
| Проверяемость | Verifiable |
| Непротиворечивость | Consistent – свойство набора, не отдельного требования |
| Прослеживаемость | Отдельный атрибут, реализуется матрицей трассировки |
| Модифицируемость | Свойство набора и структуры документа |
| Проранжированность | Атрибут приоритета, свойство набора |
Отвечать на собеседовании можно любым списком. Сильный ответ – назвать список и добавить, откуда он: "классический набор Вигерса, в стандарте 29148 он переформулирован в девять свойств требования плюс свойства набора".
Код запускать не нужно, работающей системы ещё нет. Ты читаешь документ и ищешь в нём дефекты. Ценность простая: дефект требования, пойманный на ревью, стоит правки строчки в Confluence. Тот же дефект, доехавший до прода, стоит переписанного модуля, хотфикса и разговора с заказчиком.
| Вид ревью | Как проходит | Когда применять |
|---|---|---|
| Неформальное | Позвал коллегу, прочитали вместе, оставили комментарии. Без протокола и ролей. | Черновик спеки, мелкая фича, короткий спринт. |
| Сквозной просмотр walkthrough | Автор ведёт группу по документу и объясняет логику, остальные задают вопросы. | Ввести команду в новую предметную область, собрать разные точки зрения. |
| Техническое ревью | Документ читают эксперты, есть модератор и повестка. Автор не ведёт встречу. | Архитектурно значимые куски, интеграции, нефункциональные требования. |
| Инспекция | Самый формальный вид: роли, чек-листы, метрики, протокол, повторная проверка. Дорого и медленно. | Медицина, банки, авиация – где цена ошибки измеряется не деньгами. |
Классификация по ISTQB Foundation. На типичном продуктовом проекте живут первые два вида, остальные два называют, но редко проводят по букве.
Читаешь строку спеки и прогоняешь её через семь вопросов. Если хоть на один нет ответа в документе, у тебя дефект требования.
Не можешь придумать шаги и ожидаемый результат – требование непроверяемое. Самый быстрый фильтр из всех.
Спека описывает счастливый путь. Спроси про пустое значение, отмену, обрыв сети, дубль, таймаут, чужие права.
"Быстро", "много", "большой файл" превращай в число с единицей измерения и условиями замера.
"Данные сохраняются" – кем и куда? Пассивный залог прячет исполнителя, а вместе с ним и половину логики.
Ищи то же понятие в других разделах и в старых требованиях. Противоречия почти всегда между документами, а не внутри абзаца.
Лимит 20 записей, таймаут 30 секунд, срок хранения 90 дней. У каждой магической константы есть источник: закон, договор, чья-то догадка. Догадку надо подтвердить.
Требование меняет данные, которые читает другой сервис, отчёт или мобильное приложение? Это не написано ни в одной спеке ни разу.
Комментарий к строке документа или задача в трекере с типом "дефект требования". Не в личку аналитику: находка должна быть видна и через полгода, когда все будут спорить, откуда взялось это поведение.
Неявные требования никто не записал, но их нарушение всё равно заведут как баг. Формулировка "этого нет в требованиях" защищает ровно до момента, пока продукт не начнёт нарушать закон или ожидания пользователя.
| Источник | Что оттуда достаёшь |
|---|---|
| Законы и регламенты | Хранение персональных данных, возрастные ограничения, обязательные реквизиты чека, доступность для людей с инвалидностью. |
| Старые баг-репорты | Поведение, которое однажды признали неправильным. Это требование, просто записанное задом наперёд. |
| Существующая система | Пока фича не переписана, "как раньше" – действующее требование. Проверяй на текущем проде. |
| Рекламные материалы и лендинг | Маркетинг обещал экспорт в Excel. Обещание опубликовано, значит, это требование. |
| Чаты, почта, комментарии в трекере | Половина решений принимается в переписке. Найденное фиксируй в спеке, а не в закладках. |
| Макеты и прототипы | Состояния кнопок, пустые экраны, тексты ошибок. Часто это единственное место, где они вообще есть. |
| Конкуренты | Не источник истины, но хороший генератор вопросов: у всех есть, у нас нет – это осознанное решение? |
| Здравый смысл и опыт | Кнопка "Назад" работает, деньги не пропадают, повторный клик не создаёт два заказа. |
Шесть типов покрывают почти всё, что встретишь на ревью. Названия полезно знать дословно: с ними находка звучит как диагноз, а не как придирка.
Разработчик и тестировщик прочитали одну строку и поняли разное. Дефект вылезет на приёмке, когда переделывать поздно. Ищи оценочные слова, местоимения без хозяина, союз "или" и слова, у которых на проекте нет определения.
Требование звучит красиво, но вердикт зависит от настроения проверяющего. Маркеры: удобный, быстрый, интуитивный, надёжный, современный, релевантный, оптимальный.
Удобство измеряется тоже, просто не словом "удобно": время выполнения задачи, число шагов, доля пользователей, дошедших до конца.
Выполнить оба физически нельзя. Внутри одного абзаца такое встречается редко, обычно противоречат разные разделы, разные документы или новая фича и старое поведение. Найти можно только поиском по понятию, а не чтением подряд.
Склеенные требования нельзя приоритизировать по отдельности, нельзя нормально протрассировать и нельзя закрыть наполовину. Статус "выполнено частично" – симптом неатомарности.
"И" не всегда враг: "система сохраняет заказ и отправляет письмо" может быть одной неделимой операцией, если письмо без заказа бессмысленно. Смотри на смысл, а не на союз.
Часть информации осталась в голове у автора. Верные признаки: "и т. д.", "и другие", "аналогично", ссылка на несуществующий раздел, TBD, описан только успешный сценарий.
Требование недостижимо физически, либо недостижимо на этом бюджете и сроке. Абсолютные слова выдают его сразу: любой, все возможные, никогда, всегда, 100%, без единой ошибки.
Никто не помнит, зачем оно, но все боятся выкинуть. Тест-кейсы на него пишут годами. Задай вопрос "чья это потребность?" – и половина таких требований умрёт.
"Список хранится в Redis" вместо "список отдаётся за 50 мс". Спека связывает руки разработчику и не проверяет то, что нужно бизнесу.
"Пользователь вводит дату" – в каком формате, в какой таймзоне, календарём или руками? Автор считает это очевидным. Для разработчика из другого часового пояса это не очевидно.
Дана строка из спеки. Определи, какой дефект в ней главный, и нажми на вариант. Разбор появится сразу, вместе с переписанным требованием. Восемь строк, все взяты из живых документов и обезличены.
Загрузка…
Какой дефект здесь главный?
От формата зависит, что ты сможешь проверить. Один и тот же продукт бывает описан толстой спекой, набором историй в Jira или только макетами в Figma.
Формат по умолчанию в Agile-командах. Сама история – это напоминание поговорить, а не спецификация. Всё проверяемое живёт в критериях приёмки.
US-014 · Вход по email Как зарегистрированный пользователь Я хочу войти по email и паролю Чтобы попасть в личный кабинет Критерии приёмки 1. Поля Email и Пароль, кнопка "Войти". 2. Кнопка неактивна, пока оба поля пусты. 3. Верная пара -> редирект на /account. 4. Неверная пара -> текст "Неверный email или пароль", поле Пароль очищается, Email остаётся. 5. После 5 неверных попыток подряд вход по этому email блокируется на 15 минут, показывается время до разблокировки. 6. Email проверяется на формат до отправки формы.
Проверь критерии на измеримость: пункт "интерфейс понятный" в этом списке был бы дефектом.
Тот же критерий приёмки, но в структуре "дано – когда – тогда". Удобен тем, что заставляет назвать предусловие, которое обычно забывают.
Дано: пользователь с email a@b.ru существует И: он не входил в систему Когда: он вводит верный пароль и жмёт "Войти" Тогда: открывается /account И: в шапке видно его имя Дано: пользователь ввёл неверный пароль 4 раза подряд Когда: он вводит неверный пароль в 5-й раз Тогда: вход блокируется на 15 минут И: показывается оставшееся время
Из такого сценария тест-кейс собирается почти без работы. Обратная сторона: на сложной логике сценариев становится сотни, и их поддержка съедает время.
Формальный документ с нумерованными требованиями. Шаблон и структура описаны в ISO/IEC/IEEE 29148. Живёт там, где спеку читает заказчик, регулятор или подрядчик. Плюс – однозначные ID для трассировки. Минус – устаревает на второй неделе, если её никто не ведёт.
Взаимодействие актора с системой ради цели: основной сценарий плюс альтернативные и исключительные ветки. Ценность для тестировщика именно в ветках: там записаны те самые "а что, если", которые User Story обычно пропускает.
Часто единственный источник требований к интерфейсу: тексты, состояния, пустые экраны, поведение при длинном имени. Кликабельный прототип отвечает на вопросы раньше, чем код написан. Проверяй, какая версия макета актуальна – в Figma их обычно три.
Штатная ситуация, а не катастрофа. Тогда источники такие: текущий прод, разговор с продактом, макеты, старые баги, здравый смысл. Свои выводы записывай в чек-лист или прямо в тест-кейсы и показывай команде – так устная договорённость становится документом.
Договорённость команды: история берётся в спринт, только если у неё есть критерии приёмки, оценка, макет (для UI) и понятная ценность. Тестировщик в этом списке – голос за критерии приёмки. Без DoR спека дописывается в середине спринта, а тесты переписываются трижды.
Когда история считается сделанной: код влит, тесты прошли, критерии приёмки выполнены, баги заведены или закрыты. DoD – это не критерии выхода из тестирования, они шире и живут в тест-плане.