Тестирование требований клиентом

Разработчики программного обеспечения могут быть уверены, что они создают идеальный продукт, однако последнее слово все же остается за клиентом. Клиенты тестируют продукт, чтобы определить, удовлетворяет ли система критерию приемлемости. Если да, то клиент платит за продукт, разработанный согласно контракту. Критерий приемлемости – и, следовательно, проверка приемлемости – является показателем того, удовлетворяет ли продукт задокументированным требованиям и годится ли он для использования в предполагаемой операционной среде.

Поэтому делегирование разработки тестов на приемлемость пользователям – эффективная стратегия разработки требований. Чем раньше в процессе разработки пользователи продумают тесты на проверку приемлемости, тем скорее удастся отловить дефекты в требованиях и разрабатываемом программном обеспечении.

Проверку приемлемости следует сосредоточить на предполагаемых вариантах использования. Ключевым пользователям при принятии решения о способе оценки приемлемости системы стоит принять во внимание наиболее общие и важные варианты использования. Тесты приемлемости должны фокусироваться на нормальной линии поведения вариантов использования продукта, а не на более редких альтернативных направлениях или на том, обрабатывает ли система исключения соответствующим образом. Тестирование приемлемости также должно затрагивать нефункциональные требования и должно подтверждать, что цели, связанные с производительностью, достигаются на всех оговоренных платформах, а система в целом соответствует оговоренным атрибутам качества.

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

Разработка критерия приемлемости клиентами позволяет также упростить разработку требований, разрешая проблему неясности, размытости пользовательских требований. На этапе выявления требований появляется возможность оперировать не только вопросами типа «Что вы хотите делать с помощью системы?», но и вопросами типа «Как вы убедитесь, что система удовлетворяет ваше требование?». Такая постановка вопроса автоматически выявляет нечеткие требования пользователей, так как клиент будет не в состоянии описать, как он оценит, что конкретное требование удовлетворено системой.