tестирование dot com
Шрифт:
81
Причина неверного толкования спека может быть связана
• с одной стороны, с возможностью множественного тол-
кования некой части спека и,
• с другой — с тем фактом, что многие вещи в этой жизни,
для того чтобы быть адекватно понятыми разными людь-
ми, нуждаются в многоплановой презентации.
Кстати, именно
двигателя мотоцикла) последний обычно изображается с трех сторон:
вид спереди, вид сверху и вид слева.
Тезис
Тестировщики должны настаивать, чтобы спеки по максимуму
иллюстрировались:
• макетами (mock-up),
• блок-схемами (flow chart),
• примерами (example).
Аргументация
С примерами все понятно: написал что-то — придумай пример
для иллюстрации, заодно и сам лучше поймешь, о чем пишешь.
Народная мудрость гласит: "Лучше один раз увидеть, чем сто раз
услышать". Отличной идеей является разработка продюсером
макетов интерфейса пользователя (User Interface или просто UI —
"ю-ай"). Делается это так:
во время (или после) написания спека продюсер берет генератор
веб-страниц типа Microsoft FrontPage и путем нехитрых манипу-
ляций создает веб-страницу с кнопками, полями, картинками и
прочими милыми деталями интерфейса.
Затем эта страничка "подшивается" к спеку и помогает всем за-
интересованным лицам увидеть, ЧТО, по замыслу продюсера,
должен будет увидеть пользователь.
Кстати, если спецификация предусматривает, что пользователь будет
проходить через несколько веб-страниц для совершения какого-либо
действия (например, покупки книги), то макеты этих веб-страниц могут
не только являться частью спека, но и служить в качестве обоев, если
их развесить на стенах офиса в том порядке, в котором их будет видеть
пользователь.
82
Тестирование Дот Ком. Часть 1
Пример
Вольное изложение опека #1023 "Регистрация нового пользователя":
Регистрация пользователя состоит из трех страниц, идущих в следую-
щем
• первая страница (1) — поле для индекса места жительства
пользователя и кнопка "Продолжить регистрацию";
• вторая страница (2) — поля для имени, фамилии, е-мейла и па-
роля/подтверждения пароля пользователя, кнопка "Зарегистри-
роваться";
• третья страница (3) — текст с подтверждением регистрации.
Все поля обязательны для заполнения, и если на странице (1) или (2)
вводится недействительное либо пустое значение любого поля, то
пользователю показывается та же страница, но с сообщением об
ошибке (error message). (В данном случае мы не будем говорить о том,
какой ввод действителен (легитимен) для каждого из полей, так как это
сейчас неважно.)
Продюсер разрабатывает три страницы, распечатывает их в двух ком-
плектах, один из которых подшивает к спеку, а другой развешивает на
стене в порядке появления перед пользователем: страница (1), стра-
ница (2), страница (3).
Оговорка 1: Макеты могут быть разной степени детализации, и
вполне допустимо, когда элементы интерфейса, не имеющие от-
ношения к иллюстрируемому спеку, не включаются в макет, на-
пример, в случае с макетами для регистрации нас не интересуют
картинки на веб-странице.
Оговорка 2: Понятно, что макеты интерфейса пользователя не
создаются, если спек полностью посвящен бэк-энду веб-сайта
(например, спек "Автоматизация отчетов по продажам"), так как
детали интерфейса пользователя, т.е. фронт-энд, в таком спеке
просто не упоминаются.
Проблема макетов (даже развешанных правильно) заключается в
том, что они позволяют увидеть в первую очередь интерфейс
пользователя, а не логику работы кода позади интерфейса, на-
зываемую алгоритмом программы.
Интерфейс — это то, ЧТО видит пользователь, а алгоритм —
это то, ПОЧЕМУ пользователь видит то, что он видит.
Для графической презентации алгоритмов используются блок-