Особенности национального юзабилити тестирования.

Доклад на первой конференции русскоязычного комьюнити тестировщиков.

21 апреля 2007г

Докладчик Сергей Мартыненко.

Я хочу начать свой доклад с неожиданного утверждения: «Профессионального юзабилити тестирования  в нашей стране нет». Под «профессиональным» тестированием я имею в ввиду то, которое способствует устранению большей части серьезных проблем пользователя при использовании ПО и способствует увеличению качества продуктов при снижении их стоимости.

В развитии юзабилити в нашей стране я хочу выделить два последних этапа. И начну с последнего из них. Год или два назад в среде проектировщиков ПИ всерьез заговорили о коридорном тестировании. Я связываю это с продвижением оборудования (и весьма недешевого!) для такого тестирования. Оставляя в стороне вопрос о необходимости инструментария, посмотрим, какую пользу может принести такое тестирование.

Приведу метафору. Представим себе, что некая бригада строителей построила офисное здание. После чего приходит специалист и предлагает провести исследование на тему: «Как классно тут работать!». Устанавливаются  камеры и микрофоны, служащих просят комментировать свои действия.

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

Допустим, мы получили результат исследования: «Офис к эксплуатации непригоден». Что дальше? Чтобы что-то изменить, нужны средства сопоставимые с новым строительством. Строительная бригада говорит: «Что выросло, то выросло. Не хотите – не ешьте. А мы менять ничего не будем».

С программным обеспечением примерно тоже самое. Если по результатам коридорного тестирования окажется, что продукт непригоден для эксплуатации, то на переделку может понадобиться 50-80% от первоначального бюджета. На стадии опытно промышленной эксплуатации коридорное тестирование почти бесполезно. Оно может иметь смысл если: 

  • переделать нужно совсем чуть-чуть. Т.е. проблемы удобства использования были выявлены и исправлены задолго до этого. Например, если в первую версию поставили клиенту чуть –чуть функциональности с новыми контролами, а во всех последующих 20 версиях от них отказались.
  • Это пилотный проект, на котором просто отрабатывались подходы. Далее, проект выбрасывается и все делается с нуля. Как вариант, можно сделать функционирующий  прототип. Но с ним другие проблемы, выходящие за рамки статьи.

В феврале 2007 года я был по делам в фирме Softkey. В частности, речь зашла об их сайте. Я сказал, что пользоваться сайтом неудобно и пообещал прислать описание ошибок. Через несколько дней я прислал им краткий обзор, в котором указал по одной ошибке на три метода тестирования удобства:

  • Соответствие объектам предметной области
  • Разбиение на области
  • Используемые лексемы

Заключение: «Что с этим делать, решайте сами. Мое мнение – косметическими мерами дизайн не исправить».

Если Softkey сможет переделать свой сайт, то останется только преклониться перед их уважением к пользователем.

Ну а теперь поговорим о предыдущей волне юзабилити. Это была волна повсеместного увлечения шрифтами, цветом, выравниванием. Дизайнеры до хрипоты спорили об уместности использования фреймов и запрещенных цветовых парах. Я согласен, что темно синий шрифт, высотой пять точек, читать на темно зеленом фоне неудобно. Особенно, если он реализован в виде бегущей строки. Но это даже не вершина айсберга! Ну, нельзя «тщательно обработав напильником» получить из паровоза истребитель.  Приходит этакий дизайнер к владельцу вышеописанного офиса и говорит: «Да тут все просто. Нужно, чтобы дверь имела золотое сечение, батареи (те, которые снаружи) нужно покрасить в контрастный по отношению к стене цвет. И вот еще что. Неплохо, если бы окна могли менять прозрачность». К сожалению, это не очень поможет. Если здание изначально спроектировано неправильно, то покраской ограничься нельзя. Не поможет.

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

Сейчас я хочу представить метод, основанный на проверке соответствия вариантам использования.

Возьмем, к примеру, движок блога, используемый сайтом software-testing.ru (сайт на данный момент мертв). И рассмотрим такую простую функцию, как вставка картинки. На этом месте моего доклада, Вячеслав Панкратов, создатель и владелец ресурса начинает тянуть руку и восклицает: «Я знаю, о чем идет речь». Вячеслав, претензия не к вам. Вы всего лишь используете неудачный движок. Кроме того, это небольшой контент-проект, которому поростительно иметь ошибки. Вот для живого журнала подобные ошибки могут оказаться фатальны.

Рассмотрим, как может выглядеть прецедент вставки картинки в статью:

  1. Пользователь отдает команду загрузить картинку
  2. Система предлагает указать местоположение файла
  3. Пользователь выбирает файл
  4. Система загружает файл
  5. Пользователь указывает место в тексте и отдает команду «вставить картинку»
  6. Система вставляет картинку в текст

Как реализовано:
Сначала нужно закачать файл, средствами не блога, но форума.
Затем смотрим свойства миникартинки (адрес самого рисунка динамический и его в блоге использовать нельзя!)
http://forums.software-testing.ru/uploads/…05214_thumb.jpg
вручную преобразуем к такому виду:
http://forums.software-testing.ru/uploads/…-1138205214.png
убирая “_thumb” и восстанавливая исходное расширение файла.
И только после этого можно вставить линк на картинку.

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

Рассмотрим другой пример. Яндекс-деньги, оплата за скайп. Коммерческий сервис, рассчитанный на массовое использование.

Напишем прецедент.
Основное действующее лицо: пользователь.
SuD (обсуждаемая система): сервис яндекс-деньги + платежная система скайп
Заинтересованные лица: правовая система
Контекст использования: ОДЛ просматривает список доступных платежей.
Основной сценарий.

  1. ОДЛ выбирает «осуществить платеж»
  2. Система подтверждает, что ОДЛ авторизированно на сайте
  3. Система подтверждает наличие средств для совершения минимального платежа
  4. Система формирует список возможных платежей, исходя из количества денег в кошельке
  5. Система предлагает заполнить реквизиты платежа, смотри описание объекта «платеж»
  6. ОДЛ заполняет реквизиты платежа
  7. Система подтверждает корректность данных
  8. Система предлагает подтвердить личность владельца кошелька
  9. ОДЛ вводит платежный пароль
  10. Система подтверждает правильность платежного пароля
  11. Система осуществляет платеж

Этот прецедент очень интересен необходимостью учитывать интересы всех заинтересованных лиц. Именно благодаря им появляются шаги 7-9. Попутно отмечу, что при использовании модели «Действующие лица и цели» эти шаги могут оказаться пропущенными (см. Немного критики в адрес RUP).

Альтернативный сценарий.
3.а.1 Система сообщает о невозможности платежа.

Прикинем эскизы форм по основному сценарию.
 Первая экранная форма платежа

Вторая экранная форма платежа

И все.

Проектирование закончено. После чего останется «обработка напильником», такая как выравнивание, подбор шрифтов и пр.

Посмотрим, как это реализовано сейчас (мои коментарии выделены жирным):

======================================================


 
Эта страница лишняя. Я совершаю оплату регулярно и каждый раз попадать на эту страницу для меня пустая трата времени. Стандартом дефакто для подобного случая является наличие флажка “Больше не показывать эту страницу”.

————————————————————————————–


Отлично, но зачем при совершении платежа нужно вводить пароль получателя? Здесь явный промах. Не важно, у команды яндекса или скайпа. Важно, что система в целом спроектирована неправильно.

————————————————————————————–


А это реквизиты платежа. Их явно надо было вводить страницей раньше.

————————————————————————————–


Вот с этой страницей я согласен.

======================================================

Но! Система не проверила мою платежеспособность. Я вводил логин, пароль, сумму напрасно. Очевидно, что сообщить о невозможности платежа нужно было раньше. Т.е.  кроме всего прочего нет соответствия альтернативному сценарию.

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

 

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.