Что такое тестирование требований и документации?
Тестирование требований — это анализ и проверка полноты, корректности и реализуемости требований к продукту. Качественная документация — залог успешного тестирования и разработки.
- Проверка полноты и непротиворечивости требований
- Анализ реализуемости и тестируемости
- Работа с различными видами документации
Советы по работе с документацией
- Задавайте уточняющие вопросы
- Используйте чек-листы для проверки требований
- Документируйте все изменения
Что такое требование?
Требование (requirement) — это спецификация того, что должно быть реализовано. В нем описывается поведение и атрибуты системы.
Какую документацию нужно тестировать?
Проектная документация:
- требования к программному продукту (product requirements)
- функциональные спецификации (functional specifications)
- архитектура и дизайн
- план проекта и тестовый план
- тест кейсы и сценарии
Сопроводительная документация:
- интерактивная помощь (on-line help)
- руководства по установке и использованию
Типы требований
Функциональные требования — что система должна делать
Нефункциональные требования — как система должна это делать (надежность, эффективность, сопровождаемость, переносимость и др.)
Уровни требований
Пути выявления требований
- Интервью
- Семинары
- Наблюдение
- Анкетирование
- Прототипирование
- Самостоятельное описание
Свойства хорошего требования
Каждое требование должно быть:
- Завершённым (complete)
- Непротиворечивым (consistent)
- Корректным (correct)
- Недвусмысленным (unambiguous)
- Проверяемым (verifiable)
Наборы требований должны быть:
- Модифицируемыми (modifiable)
- Прослеживаемыми (traceable)
- Проранжированными по важности, стабильности и срочности
Завершённость: Проблемы незавершённости — отсутствие нефункциональных требований, неясно КАК система должна работать.
Непротиворечивость: Противоречия между требованиями, таблицами, текстом, прототипом.
Корректность: Ошибки из-за опечаток, устаревших требований, технически невыполнимых требований.
Недвусмысленность: Если требование можно понять по-разному, его поймут по-разному.
Проверяемость: Если не удаётся придумать тесты для требования — оно непроверяемо.
Модифицируемость: После обновления требований сложно отследить все противоречия.
Прослеживаемость: Нет нумерации, оглавления, перекрёстных ссылок — хаос.
Техники тестирования требований
- Взаимный просмотр (peer review)
- Вопросы
- Тест кейсы
- Рисунки, схемы и т.д.
Взаимный просмотр: Неформальный, технический, формальная инспекция.
Вопросы: Задавайте как можно больше вопросов, уточняйте детали.
Тест кейсы: Как будете тестировать требование? Какие тесты покажут, что оно реализовано правильно?
Рисунки, схемы: Визуализируйте требования для лучшего понимания.
Форматы представления требований
- Общая концепция (Vision)
- Варианты использования (Use cases)
- Истории использования (User Stories)
- Функциональные спецификации (Functional specs)
- Технические изменения (Technical change)
- Готовое приложение (legacy system, конкурентный продукт)
Проблемы спецификаций
- Противоречия между картинкой и текстом
- Противоречия между новой и старой картинкой
- Противоречия внутри одной картинки
- Непонятная логика работы функций
- Длинные спецификации, сложно редактировать и отслеживать изменения
- Много страниц, трудно читать и работать с документом
Что важно выяснить при работе с требованиями?
- Где хранятся требования?
- Какие источники требований у нас есть?
- Кто помещает требования в официальное хранилище?
- Как мы узнаем об изменениях в требованиях?
- Что более правильно — изначальные спецификации, письма, прототип?
- Кто утверждает окончательные требования?
- Как найти новые/изменённые требования?
- Как предложить изменения?
- Кому задавать вопросы?
- Кому и как сообщать о проблемах с требованиями?
- Если не отвечают — кого спрашивать дальше?