Тестирование и разработка требований связаны синергетически. Согласно мнению консультанта Dorothy Graham: «Чем лучше требования, тем качественнее тесты; чем качественнее анализ тестирования, тем лучше требования» (Graham, 2002). Требования обеспечивают основу для тестирования системы. Продукт следует тестировать на соответствие тому, что он, как записано в требованиях, должен делать, а не на предмет архитектуры или кода. Тестирование системы, выполненное на основе кода, может стать накликанной бедой. Продукт может вести себя именно так, как описано в вариантах тестировании, созданных на основе кода, но это не означает, что он соответствующим образом реализует пользовательские или функциональные требования. Подключите тестеров к экспертизе требований, чтобы убедиться, что требования поддаются проверке и могут служить основой для тестирования системы.
| Что тестировать? Участник семинара как-то заметил: «Я работаю в группе тестирования. У нас нет написанных требований, поэтому мы должны протестировать систему на предмет того, что она с нашей точки зрения должна делать. Иногда мы ошибаемся, тогда мы узнаем у разработчиков, каковы функции системы, и тестируем ее снова». Тестирование того, что разработчики создали, — не то же самое, что тестирование того, что они должны были создать. Требования — это конечный документ для системных и пользовательских проверочных испытаний. Если требования к системе сформулированы плохо, то тестеры обнаружат множество предположений, реализованных разработчиками. Некоторые из них отражают соответствующие решения разработчиков, другие же отшлифованы или неверно истолкованы. Аналитик должен включить предположения и их источники в спецификацию требований к ПО, чтобы провести будущее повторное тестирование более эффективно. |
|
|
Тестеры проекты должны определить, как они будут проверять каждое требование. Возможных методов несколько:
· тестирование (выполнение ПО с целью поиска дефектов);
· экспертиза (проверка кода на предмет его соответствия требованиям);
· демонстрация (демонстрация того, что продукт работает, как ожидалось);
· анализ (обоснование того, как система должна работать при определенных условиях).
Само по себе обдумывание того, как проверить каждое требование, является ценным приемом работы над качеством. Используйте такие приемы анализа, как графики типа «причина-результат», чтобы составить варианты тестирования на основе логики, описанной в требовании (Myers, 1979). При этом обнаруживаются неясности, пропуски или предположения и другие проблемы. Необходимо, чтобы каждое функциональное требование можно было проследить по крайней мере до одного варианта тестирования в системном тестовом наборе, для того чтобы ни одна ожидаемая реакция системы не осталась непроверенной. Вы можете измерить прогресс тестирования по частям, высчитывая процент требований, которые прошли проверку. Опытные тестеры могут обогатить тестирование, основанное на требованиях, дополнительными тестами, основанными на истории продукта, предполагаемых сценариях использования, общих характеристиках качества и случайностях.
В тестировании на основе требований применяются различные стратегии тестирования: зависящие от выполняемых действий, отданных (включая анализ значений границ и разбиения на эквивалентные классы), от логики от событий и от состояния (Poston, 1996). Можно генерировать варианты тестирования автоматически, используя официальную спецификацию, однако если вы будете использовать более распространенные спецификации к требованиям, составленные на естественном языке, вам придется разрабатывать варианты тестирования вручную.
|
|
По мере продвижения разработки команда будет конкретизировать требования от высоких уровней абстракции, как, например, в вариантах использования, через детализированные функциональные требования к ПО к спецификациям для отдельных модулей кода. Авторитетный специалист в области тестирования Boris Beizer (1999) подчеркивает, что тестирование на основе требований должно выполняться на каждом уровне конструирования ПО, а не только на конечном пользовательском уровне. Масса кода в приложении не доступно пользователям напрямую, однако он необходим для внутренних взаимодействий. Каждый модуль должен удовлетворять собственной спецификации, даже если функция этого модуля невидима для пользователя. Как следствие, тестирование системы на основе пользовательских требований — необходимая, но не достаточная стратегия тестирования системы.