Разрабатывая тест-план.

Я убежден, что нисходящий подход требований программ наиболее полезен при создании тест-плана. Под подходом "сверху вниз" я понимаю, что сперва создается общий план, а затем он заполняется конкретными деталями. Это контрастирует с подходом "снизу вверх", когда сперва описываются конкретные особенности небольших разделов, и чем больше и больше малых особенностей описывается, тем яснее становится общая картина.

Рассматривая требования, я могу мысленно разделить их на три секции:

1. Ввод (задание параметра):

FUN-PARAMETER.

2. Вывод (отображение сообщений и результатов):

FUN-STARTUP-MESSAGE; • FUN-UNDERWEIGHT; • FUN-NORMALWEIGHT;

FUN-OVERWEIGHT.

3. Выполнение:

NF-PERF-TIME

Как я определил, как с этим разобраться? Я посмотрел на требования, которые были связаны друг с другом, и поместил каждое из них в "кластер". У программы, с которой вы работаете, скорее всего, не будет точно таких кластеров (ну если только вы не создаете программу по взвешиванию котов — в этом случае вам повезло). Для больших программ эти кластеры будут часто развиваться вокруг конкретных особенностей (например, для онлайнового магазина это будут корзина покупок, отображение товаров, оплата) или различных подсистем (например, для видеоигры это будут пользовательский интерфейс, искусственный интеллект врагов и графика). Не существует правильного ответа, как кластеризовать требования для тестирования, и улучшение понимания системы может привести к изменению кластеризации. Однако имея общий план, вы начнете разбираться с тем, как тестировать систему в целом.

Рассматривая тот набросок тест-плана, который мы здесь создали, мы понимаем, что у второй секции (вывод), безусловно, больше всего требований, и это необязательно означает, что ее тестирование займет больше всего времени или потребует больше всего работы. Фактически FUN-STARTUP-MESSAGE является очень простым и неизменяемым, а три других требования включают математически чистые функции, и написать тесты для них будет сравнительно легко. В повседневной жизни тестирование некоторых требований может занять намного больше времени, чем других! Тестирование требований производительности и безопасности может оказаться значительно сложнее, чем может показаться по длине их описаний.