Требование (requirement) — описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи. Спецификация требований программного обеспечения (англ. software requirements specification, SRS) — структурированный набор требований/запросов (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. Также данный термин часто называют "спекой". Тестирование требований (спецификации) — это их проверка, чтобы найти ошибки до начала разработки. Как мы знаем из части 7, где говорили о жизненном цикле тестирования, тестирование начинается с анализа документации (в частности спецификации к продукту). Это очень важный этап, ибо ранее выявление и исправление ошибок в требованиях намного дешевле, чем исправление ошибок уже в реализованном продукте. Помним про правило: Чем позднее была обнаружена ошибка, тем сложнее, дольше и дороже будет её исправление
Требование (requirement) — описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Спецификация требований программного обеспечения (англ. software requirements specification, SRS) — структурированный набор требований/запросов (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. Также данный термин часто называют "спекой".
Тестирование требований (спецификации) — это их проверка, чтобы найти ошибки до начала разработки.
Как мы знаем из части 7, где говорили о жизненном цикле тестирования, тестирование начинается с анализа документации (в частности спецификации к продукту). Это очень важный этап, ибо ранее выявление и исправление ошибок в требованиях намного дешевле, чем исправление ошибок уже в реализованном продукте. Помним про правило:
Чем позднее была обнаружена ошибка, тем сложнее, дольше и дороже будет её исправление.
Каждое требование на данном этапе проверяется на соответствие критериям "хороших требований". Списков таких критериев довольно много. Я бы хотел остановиться на следующем:
- Корректность — каждое требование должно точно описывать желаемый функционал.
- Проверяемость — требование должно быть сформулировано так, чтобы существовали способы однозначной проверки, выполнено оно или нет.
- Полнота — каждое требование должно содержать всю информацию, необходимую разработчику, чтобы правильно спроектировать и реализовать требуемую функциональность.
- Недвусмысленность — требование описано без неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание. Отсутствуют качественные определения: "некрасиво", "не работает" и так далее. Также стоит определить, что вся терминология в спецификации однозначно задана.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — приоритет требования представляет собой количественную оценку степени значимости (важности) требования.
- Атомарность — требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
- Модифицируемость — характеризует простоту внесения изменений в отдельные требования и в набор требований.
- Прослеживаемость — у каждого требования должен быть уникальный идентификатор, по которому на него можно сослаться.
Для проверки на полноту требований:
- Проверьте каждый объект по CRUDL (Create, Read, Update, Delete (или Deactivate), List)
- Подумайте о том, что может пойти не так, какие негативные сценарии и граничные условия могут быть. Хорошая техника — составление сценариев использования
- Проверьте, что в сложных условиях «если — то», описаны все варианты. Хорошей помощью может быть таблица решений
- Подумайте о заинтересованных лицах — не забыли ли учесть чьи-то интересы, например спросить техподдержку
- Проверьте, что нет отсылок на неопределённую информацию. Если в требованиях автор пишет «Спроси об этом Машу», то когда дойдёт дело до разработки Маша может быть недоступна
Хочу отметить, что нужно чётко контролировать и избегать следующих ситуаций:
- Замкнутый круг «У тестировщиков много работы, потому что требования низкого качества → У тестировщиков нет времени на тестирование требований → У тестировщиков много работы, потому что требования низкого качества»
- Новые требования не фиксируются в общем документе, а остаются на словах или в переписках
Источники:
Тестирование требований: // --. URL: https://tlroadmap.io/roles/technical-lead/product-quality/testing/testing-requirements.html (Дата обращения: 22.01.2023).
В следующей статье мы поговорим об ещё одной активности первого этапа жизненного цикла тестирования - планировании и составлении тест-плана.
Буду рад вашим вопросам в комментариях!