Тестируемость.

С точки зрения тестировщика, одним из самых важных аспектов требований является то, могут ли они быть протестированы или нет. С точки зрения цикла разработки программного обеспечения формулировка "тестируемые требования" является синонимом "хороших требований". Невозможно доказать, что требование, которое нельзя протестировать, выполнено. Давайте рассмотрим пример с двумя требованиями и постараемся определить, какое из них лучше. Обратите внимание, что оба они семантически и синтаксически верные и содержат это крайне важное слово "должен":
1. Система должна увеличивать счетчик ПОСЕТИТЕЛЕЙ на единицу каждый раз, когда сенсор ТУРНИКЕТА активируется без ошибок.
2. Система должна работать со счетчиком каждый раз, когда кто-то проходит.
Заметим, что первое требование очень определенное; оно обозначает, что должно быть сделано, какие входные данные отслеживать и какого поведения ожидать. А именно: каждый раз, когда датчик ТУРНИКЕТА активируется, мы ожидаем, что счетчик ПОСЕТИТЕЛЕЙ (который может быть переменной, дисплеем или чем-то еще — это следует определить в описании полных требований) увеличивается на единицу. Второе требование очень неоднозначное сразу по нескольким причинам. Что делать со счетчиком? Как он узнает, что кто-то прошел? Что означает, что ктото проходит? Невозможно создать тест для такого требования.
Теперь, когда мы увидели примеры тестируемых и нетестируемых требований, можем ли мы подробно описать, что значит для требования быть тестируемым?
Для того чтобы требования были тестируемыми, они должны соответствовать пяти критериям, каждое из которых мы рассмотрим отдельно. Им следует быть:
1. полными;
2. последовательными;
3. недвусмысленными;
4. количественными;
5. выполнимыми для тестирования.
Требования должны покрывать всю работу системы. Это то, что мы подразумеваем, когда говорим, что спецификация требований должна быть полной. Всё, что не покрыто требованиями, будет интерпретировано по-разному разработчиками, дизайнерами, тестировщиками и пользователями. Если что-то важно, оно должно быть определено точно.
Требования должны быть последовательными, т. е. они не должны противоречить друг другу или законам Вселенной (или той области, в которой вы работаете). Требования, которые не противоречат друг другу, являются внутренне последовательными; требования, которые не противоречат миру вне системы, называются внешне последовательными.
Вот пример группы требований, которые не являются внутренне последовательными:
INCONSISTENT-REQ-1 — система должна отображать сообщение: "ВНИМАНИЕ: ИЗБЫТОЧНОЕ ДАВЛЕНИЕ" на консоли, когда давление составляет 100 PSI или более;
INCONSISTENT-REQ-2 — система должна отключить консоль и не отображать информацию до тех пор, пока давление меньше 200 PSI.
Что должна делать система, если давление лежит в границах от 100 до 200 PSI? В данном случае вы можете использовать разбиение на классы эквивалентности, чтобы определить, что требования не являются внутренне последовательными.
Требованиям необходимо быть недвусмысленными, т. е. они должны определять всё настолько точно, насколько возможно для той области программного обеспечения, с которой вы работаете. Допустимый уровень однозначности будет значительно отличаться в зависимости от того, какой тип программного обеспечения вы разрабатываете. Например, если вы создаете игру для детей, возможно, достаточно оговорить, что некая площадь должна быть "красной". Если же вы описываете требования к интерфейсу ядерного реактора, для предупредительного сигнала должен быть указан точный оттенок красного цвета в цветовой модели Pantone.
С учетом вышесказанного не загоните себя в угол слишком строгими требованиями. Например, если ваши требования говорят, что какая-то страница должна быть определенного размера в пикселах, у вас могут возникнуть трудности с конвертацией ее для мобильных устройств. Тем не менее требования не должны принимать следующую форму:
AMBIGUOUS-REQ-1 — система должна выключать всё, когда нажата кнопка Выключение.
Что значит "выключать всё"? Разговаривая с друзьями или коллегами, мы можем использовать такие неопределенные термины, потому что человеческий мозг удивительно хорош в распознании двусмысленностей. Однако двусмысленные требования могут привести к тому, что разработчики или другие заинтересованные лица могут интерпретировать их по-разному. Классический пример — провал запущенной NASA миссии Mars Climate Orbiter, когда часть разработчиков использовала имперскую систему мер, а другая — метрическую. Обе группы думали, что правильный путь получения результатов очевиден, но они использовали различные реализации.
Насколько это возможно, требования должны быть количественными (как противоположность качественным), т. е. если нужно использовать в требованиях численные значения, то используйте их. Следует избегать любых субъективных терминов вроде "быстрый", "легко реагирующий", "практичный" или "офигенный". Если вам необходимо указать, что система должна сделать, — указывайте. Например, следующее требование качественное, но не количественное:
QUALITATIVE-REQ-1 — система должна возвращать результат предельно быстро.
Что мы хотим этим сказать? Тестировать это требование невозможно без определения, что мы понимает под "предельно быстро" и какой результат должен быть получен быстро.
В итоге должен присутствовать некий здравый смысл при написании требований. Можно написать требование, которое теоретически можно протестировать, но в реальной жизни по разным причинам этого сделать нельзя. Такое требование невыполнимо для тестирования. Скажем, у нас есть следующие требования для тестирования нашего датчика давления:
INFEASIBLE-REQ-1 — система должна быть способна выдерживать давление до 9,5 ⋅ 1011 фунтов на квадратный дюйм;
INFEASIBLE-REQ-2 — при нормальных рабочих условиях (определенных где-то в другом разделе) система должна оставаться работоспособной в течение 200 лет непрерывного использования.
Оба эти требования, конечно, можно протестировать. В первом случае просто поместите систему в эпицентр относительно мощного термоядерного взрыва и определите, ухудшилось ли качество системы после детонации. Второе требование еще проще: просто нужно ездить с датчиком давления воздуха в колесах 200 лет. Так как продолжительность жизни человека заметно меньше, вам, вероятно, понадобятся несколько поколений тестировщиков. Передавать ли должность "тестировщик датчика давления" по наследству или использовать подход "мастер — ученик", зависит только от вас.
Когда дело касается физических явлений, становится очевидным, что глупо тестировать такие требования. (Если они не кажутся глупыми вам, сколько тестировщиков вы знаете, у которых в распоряжении имеется ядерное оружие? Вероятно, меньше пяти.) Однако зачастую более сложно определить, что требование является невыполнимым, когда вы имеете дело с программным обеспечением. Функционируя в реальном физическом мире, человеческий мозг очень часто сталкивается с трудностью определения, насколько выполнимым является требование к программе (существующей в виртуальном мире), которое нужно протестировать.