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

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

Введение

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

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

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

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

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

• Что система должна делать?
• Как она должна это делать?

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

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

Описывают конкретные функции и поведение системы:

• «Пользователь может зарегистрироваться по email»
• «Система отправляет письмо с подтверждением»
• «Кнопка "Купить" добавляет товар в корзину»

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

Описывают характеристики системы, не связанные с конкретными функциями:

Откуда берутся требования

Требования создаются и приходят от разных людей:

• Бизнес-аналитики — формализуют пожелания заказчика
• Product Owner — определяет приоритеты и видение продукта
• Клиенты — озвучивают потребности и боли
• Юридический отдел — добавляет требования по законам и регуляциям
• UX-дизайнеры — формулируют требования к пользовательскому опыту

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

Требования могут быть оформлены по-разному:

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

Как [роль], я хочу [действие], чтобы [польза].
Пример: Как зарегистрированный пользователь,
я хочу сохранять товары в избранное,
чтобы легко вернуться к ним позже.

Use Case (Сценарий использования) Подробное описание взаимодействия пользователя с системой по шагам, включая основной сценарий и альтернативные пути.

Формальная спецификация Документ с детальным описанием каждого требования, часто с уникальными идентификаторами (REQ-001, REQ-002...).

Почему требования важны для тестировщика

Без чётких требований тестировщик не может:

• Определить, что является багом, а что — фичей
• Написать осмысленные тест-кейсы
• Оценить покрытие — всё ли протестировано
• Защитить своё мнение перед командой

Пример: Если требование говорит «поле телефона обязательно», а приложение позволяет сохранить форму без телефона — это баг. Но если требования молчат об этом, тестировщик не знает, считать ли это ошибкой.

Распространённые ошибки

• Тестировать без требований — угадывать ожидаемое поведение по интуиции
• Не читать требования целиком — упускать важные детали и ограничения
• Не задавать вопросы — принимать неясные требования как данность
• Игнорировать нефункциональные требования — тестировать только функции, забывая о производительности и безопасности

Что мы запомним

• Требования описывают что система делает и как она себя ведёт
• Требования бывают функциональные (функции) и нефункциональные (характеристики)
• Источники требований: бизнес-аналитики, Product Owner, клиенты, юристы
• Формы: User Story, Use Case, формальная спецификация
• Без требований нет базы для тестирования — неясно, что считать багом