Читаем без скачивания Время — деньги. Создание команды разработчиков программного обеспечения - Эд Салливан

• Тестирование

Тестирование программы также сильно зависит от её интерфейса. Традиционно тестировщики просят разработчиков предоставить им подробные спецификации функций программы, точно описывающие все особенности её работы. К сожалению, полностью описать пользовательский интерфейс, особенно современный, практически невозможно. Лучшая замена описанию — прототип. Если предоставить тестировщикам прототип интерфейса, то, ознакомившись с программой и разобравшись в основах и принципах работы её функций, предназначенных для конечных пользователей, они смогут улучшить разработанные ими планы тестирования. Это не значит, что описание функций не имеет значения или можно пренебречь им, просто я хочу подчеркнуть, что прототип — один из лучших способов демонстрации особенностей продукта. Обладая прототипом пользовательского интерфейса, тестировщики смогут изучить продукт вдоль и поперёк, а разобравшись в работе функций программы, команда сможет подготовить лучшие планы тестов и испытаний до окончания разработки программы.

Возможно, дочитав до этого места, вы спросите: «Все это здорово, но как создать прототип?» Подход к созданию прототипов пользовательского интерфейса, который исповедует NuMega, основан на трёх простых принципах. Сначала мы определяем наиболее важные задачи, которые приходится решать пользователям. Затем мы быстро моделируем эти задачи на ранних стадиях работы над проектом, ещё до подготовки плана проекта в окончательном виде: это увеличивает шансы правильно оценить объём предстоящей работы. Наконец, мы очень быстро доводим прототип, внося в него ряд последовательных изменений, демонстрируя как внутренние, так и внешние его особенности. Такой подход позволяет тестировать прототип вместе с пользователями. Возможность быстрой доработки прототипа — ключевой фактор успеха, позволяющий как можно раньше привести его к окончательному виду.

Решив эти задачи, команда получит прототип пользовательского интерфейса, понятный всем её участникам ещё до создания самой программы. Только подумайте, какое значение это имеет для проекта: разработчики, тестировщики, технические писатели — короче, все получат чёткое представление о внешнем виде программы даже раньше, чем она будет создана. Представьте, насколько возрастёт эффективность и производительность труда каждого участника команды благодаря прототипу пользовательского интерфейса. Кроме того, администраторы, менеджеры по продукции, работники из отделов сбыта и технической поддержки смогут «увидеть» программу раньше, чем она появится на свет. Это поможет устранить равнодушное отношение к проекту, создать уверенность в его успехе и предвидеть возможные проблемы — в общем, создать особую атмосферу работы с высокими технологиями, направляющую усилия всех участников проекта в единое русло. И не будем забывать о самом важном: чем раньше будет протестирован интерфейс, тем больше шансов на то, что получится хороший продукт, так как тогда множество людей смогут познакомиться с программой и опробовать её прежде, чем она будет написана.

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

На первом этапе создания пользовательского интерфейса нужно определить самые важные задачи, которые потребуется решать пользователям. Число задач может варьироваться в зависимости от сложности продукта; попробуйте выделить хотя бы следующие категории:

• Задачи, которые скорее всего придётся решать новым пользователям программы

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

• Задачи, которые чаще всего решают постоянные пользователи программы

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

Когда основные задачи определены, всё готово к созданию прототипа пользовательского интерфейса. При этом очень важно выбрать инструмент, позволяющий создать прототип легко и быстро. Затем надо проверить свои варианты дизайна прототипа, разрешить все проблемы и вновь оперативно проверить результат. Познакомимся с наиболее популярными методиками создания прототипов и посмотрим, как с их помощью решать собственные проблемы. Вот эти методики по порядку, начиная с самой лучшей.

• Прототипы на бумаге

Для создания такого прототипа нужно просто нарисовать фрагменты пользовательского интерфейса на бумаге. Чтобы облегчить художникам и пользователям работу с таким прототипом, рисовать каждый элемент интерфейса надо на отдельном листе бумаги соответствующего размера. Расположите нарисованные меню, панели инструментов, командные кнопки, поля и другие элементы так, чтобы результат напоминал пользовательский интерфейс программы. Например, каждый раскрывающийся список и каждое диалоговое окно в этом случае будет на своём кусочке бумаги. Не обязательно добиваться точности воспроизведения — достаточно, чтобы эти кусочки бумаги давали чёткое представление об элементах пользовательского интерфейса.

Преимущество бумажных прототипов в том, что их легко собирать и изменять. Изолируя основные элементы интерфейса, можно легко изменить ход управления, условия работы, а также их расположение или размер. Нетрудно стирать линии или даже перерисовывать отдельные страницы или прототип целиком. Благодаря тому, что бумажные прототипы так легко менять, их можно обновлять и модифицировать прямо во время демонстрации конечным пользователям, это позволяет тут же проверять новые идеи.

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

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

Из собственного опыта

Бумажные прототипы могут быть чрезвычайно эффективны, но если команда не верит в результативность этой методики, использовать её нельзя. Чтобы побороть эту проблему в NuMega, мы отправили всю команду на однодневный методический курс, который читали в институте UEI (Usability Engineering Institute). Особое внимание в этом курсе уделялось работе с бумажными прототипами. Это был замечательный способ продемонстрировать участникам команды, насколько важны и эффективны могут быть прототипы на бумаге. Этот курс изменил наши представления о разработке ПО.

• Инструменты RAD

Создание прототипов с помощью инструментов для быстрой разработки приложений (RAD, Rapid Application Development), — вероятно, самая популярная методика. Подходящим можно считать любой инструмент, позволяющий быстро создать наглядную функционирующую модель пользовательского интерфейса.

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