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