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

Требования — это формализованное описание того, что должна делать система, как она должна себя вести и каким ограничениям соответствовать. Виды требований: Бизнес-требования — описывают цель продукта и его ценность для бизнеса. Пользовательские требования — описывают сценарии использования системы. Функциональные требования — описывают, что именно должна делать система. Нефункциональные требования — описывают характеристики системы, такие как производительность, безопасность, надежность и удобство использования. Свойства требований: Однозначность — требование нельзя трактовать по-разному. Полнота — достаточно информации для реализации и тестирования. Непротиворечивость — не конфликтует с другими требованиями. Проверяемость — можно однозначно проверить результат. Трассируемость — можно связать с тестами и задачами. Источники требований: ТЗ, ЧТЗ, ПМИ, спецификации, user stories, макеты, API-документация, устные договоренности.

Цель анализа требований — понять, что именно нужно тестировать, и выявить проблемы до начала разработки и тестирования. Типичные проблемы: Неполные требования — отсутствуют важные сценарии. Противоречия — разные требования конфликтуют между собой. Неоднозначность — требование можно трактовать по-разному. Непроверяемость — невозможно определить ожидаемый результат. Пример: В требовании указано "показать ошибку при неверном вводе", но не описано, какая именно ошибка и при каких условиях. Это делает требование неоднозначным.

Тестировщик анализирует источник требований и выделяет: Действия пользователя. Реакцию системы. Ограничения и проверки. Далее требования формализуются и разбиваются на сценарии: Позитивные. Негативные. Граничные. Пример: Регистрация пользователя: Ввод email. Проверка формата. Проверка уникальности. Создание аккаунта.

Трассировка требований — это установление связи между требованиями, тестами и результатами тестирования. Она позволяет: Понимать, какие требования покрыты тестами. Находить пропущенные сценарии. Оценивать влияние изменений. Пример: Требование "пользователь может авторизоваться" должно быть связано с тестами: Успешный вход. Ошибка при неверном пароле. Ошибка при пустых полях.

Достаточное покрытие означает, что протестированы все важные сценарии с учетом рисков. Проверяется: Основные пользовательские сценарии. Альтернативные варианты. Ошибки и некорректные данные. Пример: Если проверен только успешный логин, но не проверены ошибки, покрытие считается недостаточным.

Тестировщик активно участвует в уточнении требований: Задает конкретные вопросы. Выявляет противоречия. Предлагает варианты поведения системы. Фиксирует договоренности. Пример: Если не указано, что происходит при повторной регистрации, тестировщик уточняет — должна быть ошибка или обновление данных.

Нужно: Выявить проблему. Использовать дополнительные источники (макеты, API, логика системы). Предложить варианты поведения. Согласовать решение. Пример: В макете поле обязательное, а API принимает пустое значение. Тестировщик уточняет корректное поведение и фиксирует его.

Используется исследовательское тестирование. Тестировщик: Опираться на UX и здравый смысл. Анализирует поведение системы. Использует аналоги. Общается с командой. Пример: Если нет требований к фильтру, можно проверить его поведение по аналогии с другими сервисами.

Анализ рисков направлен на выявление мест, где ошибки наиболее вероятны и критичны. Выделяются: Критичные функции (например, платежи). Сложная бизнес-логика. Интеграции. Оценивается влияние ошибки и вероятность ее возникновения. После этого тестирование приоритизируется. Пример: Ошибка в оплате критичнее, чем ошибка в отображении аватара, поэтому платежи тестируются глубже.