Уровни требований
Требования делятся на уровни: от общей бизнес-цели до конкретных действий системы. Понимание этой иерархии помогает тестировщику задавать правильные вопросы.
Бизнес-требования (Зачем?)
Верхний уровень, отвечающий на вопрос о цели продукта. Какую проблему бизнеса он решает?
- Повысить количество заявок на 20%.
- Обеспечить круглосуточный доступ к курсам валют.
Пользовательские требования (Что?)
Описывают, что пользователь может делать с системой для достижения своих целей. Часто оформляются в виде User Stories.
- Пользователь может войти в систему по логину и паролю.
- Администратор может просматривать список активных пользователей.
Функциональные требования (Как?)
Конкретизируют, как именно система должна себя вести. Описывают логику, реакции на действия и внутренние процессы.
- Система должна проверять email на валидность формата.
- При неверном пароле система должна выводить ошибку "Неверный email или пароль".
Нефункциональные требования (Насколько хорошо?)
Определяют качественные атрибуты системы: скорость, безопасность, надежность, удобство использования.
- Страница должна загружаться не более 2 секунд.
- Система должна выдерживать одновременную нагрузку в 1000 пользователей.
Свойства качественных требований
Хорошо написанное требование — залог успеха проекта. Нажмите на свойство, чтобы увидеть его описание и примеры.
Документирование требований
Требования нужно где-то фиксировать. На современных проектах чаще всего используются Пользовательские истории (User Stories).
Пользовательская история (User Story)
Это краткое описание функции от лица пользователя, которое объясняет, что он хочет сделать и зачем.
Пример полной истории:
ID: US-001 Название: Аутентификация пользователя Как: зарегистрированный пользователь Я хочу: ввести email и пароль на странице входа Чтобы: получить доступ к личному кабинету Acceptance Criteria (Критерии приёмки): - На странице есть поля Email, Пароль и кнопка "Войти". - При верных данных - переход на главную страницу. - При неверных данных - сообщение об ошибке. - Email валидируется на корректный формат. - Кнопка "Войти" неактивна, если поля пустые.
Варианты использования (Use Cases)
Это более формальный способ описания взаимодействия пользователя (актора) с системой для достижения цели. Часто изображается в виде диаграммы.
Макет (Mockup)
Реалистичная визуальная модель интерфейса. Тестировщики используют макеты для проверки frontend: расположения элементов, их стилей и размеров.
Алгоритм работы с требованиями
Процесс работы с требованиями может быть идеальным или... реальным. Вот как это выглядит на практике.
✅ Идеальный процесс
- Аналитики создают требования с макетами.
- Тестировщик проверяет их на качество и полноту.
- Неточности отправляются на доработку.
- После согласования требования берутся в разработку.
- Тест-кейсы пишутся до начала кодирования.
- Требования в спринте не меняются.
⚠️ Неидеальный (но частый) процесс
- Требования уточняются уже в процессе разработки.
- Тестовая документация пишется после того, как код готов.
- Требования могут вообще не документироваться и существовать только в устной форме или в чатах.
Неявные требования
Не все требования записаны в документах. Опытный тестировщик умеет находить их в других источниках, чтобы обеспечить полное покрытие.
Где искать неявные требования?
- Законы и регламенты
- Существующие баг-репорты
- Руководства пользователя
- Рекламные материалы
- Интервью с командой
- Email-переписка и чаты
- Дизайн-макеты и прототипы
- Анализ конкурентов
- Личный пользовательский опыт
