1.2. Тестирование документации и требований

1.2. Тестирование документации и требований

1.2.1. Что такое «требование»

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

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

1.2.2. Важность требований

Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа множества людей будет выполнена впустую.

· Брайан Хэнкс, описывая важность требований, подчёркивает, что они:

· Позволяют понять, что и с соблюдением, каких условий система должна делать.

· Предоставляют возможность оценить масштаб изменений и управлять изменениями.

· Являются основой для формирования плана проекта (в том числе плана тестирования).

· Помогают предотвращать или разрешать конфликтные ситуации.

· Упрощают расстановку приоритетов в наборе задач.

· Позволяют объективно оценить степень прогресса в разработке проекта.

Вне зависимости от того, какая модель разработки ПО используется на про-екте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её ре-шение. А в самом начале («водопада», «спуска по букве v», «итерации», «витка спирали») идёт планирование и работа с требованиями.

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

1.8.jpg

Рисунок 1 Стоимость исправления ошибки в зависимости от момента её обнаружения.

Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль на простом примере. Допустим, вы с друзьями составляете список покупок перед поездкой в гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько

«стоит» дописать, вычеркнуть или изменить пару пунктов, пока вы только-только составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в торговый зал и тратить время. Если проблема выяснилась по пути домой или даже дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке изначально было что-то уж совсем неправильное (например, «100 кг конфет — и всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут выясняется, что «ну мы же пошутили».

Ещё одним аргументом в пользу тестирования требований является то, что, по разным оценкам, в них зарождается от ½ до ¾ всех проблем с программным обеспечением. В итоге есть риск, что получится так, как показано на рисунке 2.2.b.

Поскольку мы постоянно говорим «документация и требования», а не просто «требования», то стоит рассмотреть перечень документации, которая должна подвергаться тестированию в процессе разработки ПО (хотя далее мы будем концентрироваться именно на требованиях).

1.9.jpg

Рисунок 2 Типичный проект с плохими требованиями.

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

· Продуктная документация (product documentation, development documenta-tion52) используется проектной командой во время разработки и поддержки продукта. Она включает:

· План проекта (project management plan53) и в том числе тестовый план (test plan54).

· Требования к программному продукту (product requirements document, PRD55) и функциональные спецификации (functional specifications56 doc-ument, FSD57; software requirements specification, SRS58).

· Архитектуру и дизайн (architecture and design59).

· Тест-кейсы и наборы тест-кейсов (test cases60, test suites61).

· Технические спецификации (technical specifications62), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

· Проектная документация (project documentation63) включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она включает:

· Пользовательскую и сопроводительную документацию (user and accompanying documentation64), такую как встроенная помощь, руководство по установке и использованию, лицензионные соглашения и т.д.

· Маркетинговую документацию (market requirements document, MRD65), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке).

В некоторых классификациях часть документов из продуктной документации может быть перечислена в проектной документации — это совершенно нормально, т.к. понятие проектной документации по определению является более широким. Поскольку с этой классификацией связано очень много вопросов и непонимания, отразим суть ещё раз — графически (см. рисунок 2.2.c) — и напомним, что мы до-говорились классифицировать документацию по признаку того, где (для чего) она является наиболее востребованной.

1.10.jpg

Рисунок 3 Соотношение понятий «продуктная документация» и «проектная документация».

Степень важности и глубина тестирования того или иного вида документации и даже отдельного документа определяется большим количеством факторов, но неизменным остаётся общий принцип: всё, что мы создаём в процессе разработки проекта (даже рисунки маркером на доске, даже письма, даже переписку в скайпе), можно считать документацией и так или иначе подвергать тестированию (например, вычитывание письма перед отправкой — это тоже своего рода тестирование документации).