Про этап тестирования на прототипах

Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают. А здесь как-то странно: сначала делаем, потом обнаруживаем траблы, переделываем; по результатам переделывания обнаруживаем ещё более стрёмные траблы, уже труднее решаемые, переделываем. Цикл может повторяться до момента, когда руководство разочаровывается в проекте, что автоматически означает — разочаровывается в разработчиках, этот проект наваявших. И правильно, кто виноват в том, что программа “не пошла”? Ессно, программеры. Собирается новая команда, которая получает исходные коды предыдущей версии с задачей “переделать”.

Но, извиняюсь, что такое “думать, потом разрабатывать”? Кто конкретно должен думать и о чём? Чем занимается штаб “думателей” до момента, когда программер создал пустой ещё проект и написал свою первую строчку кода? Это у кого как. Хорошо, когда думают все участники процесса, начиная от заказчика и дальше постановщиков (для непосредственных разработчиков на самом деле, как правило, и разницы-то никакой нет). Наблюдаю неоднократно (а, значит, локализовываем ещё один опасный камушек как не случайный) такое замечательное явление: заказчик предлагает разработать сервис (не важно, веб или виндовз приложение), основываясь на своей личной необходимости в нём. Как правило, такое происходит, когда у заказчика есть какой-то процесс, который он пытается автоматизировать с помощью компьютерных технологий и, видимо, находит для этого некие инструменты, программы или веб-сервисы, тестирует их, пытается использовать в работе и находит кучу недостатков. Знакомая ситуация, так ведь?

Поэтому когда заказчик говорит о том, что “рынок нуждается в нормальном инструменте для *таких-то целей*, есть много много людей, которые хотят такой инструмент, он будет продаваться, его только нужно сделать по-грамотному” – он (понятно, что речь вряд ли идёт об одном человеке) всё-таки опирается на свой какой-то уже наработанный опыт, и этот опыт автоматически распространяется на ВСЮ потенциальную аудиторию этого инструмента. Формулируются требования, пишется ТЗ, собирается команда, которая это ТЗ анализирует и приступает к работе. Не углубляясь в подробности описания жизненного цикла разработки сложного программного продукта перейду сразу к этапу тестирования сценариев поведения пользователя в программе на прототипах экранных форм.

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

Получается, что мы должны (пусть ещё и в начале разработки, но всё же уже на лету) менять постановку задачи в целом: для кого всё-таки пишется инструмент? Если заказчик планирует выйти с ним на рынок и рекламировать для универсального пользователя, тех же домохозяек в том числе, он и должен получить продукт для универсального пользователя и домохозяек в том числе; ни к чему тогда такая развёрнутая функциональность, сложные формы, диаграммы и визарды разрешения конфликтов синхронизации данных (долго писать, но как раз этот визард, просто шедевр проектирования с моей точки зрения, удобный и понятный для всех наших и даже одобренный заказчиком, поставил в тупик 100% тестировавших из той самой фокус-группы неподготовленных пользователей). Да, разрабатывается совсем другая программа. И пусть весь интерфейс сводится к двум кнопкам, например, зелёной и красной (да, одной не обойдёшься, бывает), зато легко будет разобраться.

Всё-таки с большим подозрением отношусь пока к тестированию на экранных прототипах. К сожалению, не могла присутствовать лично — мы здесь, они там, за океаном, но что-то там недоработано имхо. Верится с трудом, к примеру, что на достаточно равномерном (скажем, тёмно-синем, ближе к чёрному, с белым текстом) интерфейсе с элементами форм в той же цветовой гамме – тёмно-синие бэкграунды и светлые+белые foreground`ы учасники фокус-группы не смогли выполнить “удалить пользователя” не смотря на то, что кнопка “Delete” – единственная ярко-красная, ещё и с соответствующим текстом. Может, что-то не то было в формулировке задачи?

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

Да, когда он на одной картинке “заполняет” формуляр поиска и “нажимает” кнопку поиска (ему перелистывают следующую картинку) и дальше получает экран с результатами поиска, и его спрашивают: где же список тех людей, которых ты искал, а он не может ответить на этот вопрос… Первая реакция у нашей команды: ну, наверное он совсем даун. На самом же деле он нормально сориентируется в том же экране при интерактивном интерфейсе: действие, и там, где была форма+пусто, появился список, не важно, боковым ли зрением заметит пользователь изменение или у него хватит мозгов смотреть в зону, в которой он заполнял форму и нажимал на кнопки.
Т.е. мне всё же кажется, что механизм тестирования на экранных прототипах должен быть либо как-то круто автоматизирован, чтобы совсем уж имитировать действие программы, или он на самом деле даёт огромную погрешность в результатах тестирования, из-за того же отсутствия интерактивности.

И третье, что беспокоит: всё-таки отсутствие мотивации работы с программой. Почему заказчику пришла идея разработать этот инструмент? У него была необходимость, он работал с уже существующими аналогами, и необходимость у него остаётся. Какая же мотивация у тех участников фокус-группы, которые тестировали прототипы? Разобраться с интерфейсом и поскорее реализовать свою задачу на этом инструменте? Вовсе нет. Время в фокус группе оплачивается, что-то от 10 до 20 уе за час работы. На этом цель обычно заканчивается. “Всё равно на улице скучно”, “и друзья попросили там помочь”, “и десять баксов-то не лишние”, ни один мотив не сходится с мотивом потенциального пользователя программы. А вот 10 баксов за то, что он в этой программе исполнит что-то продаваемое (т.е. если исполнит – получит $10, не исполнит – не заработает), и мы получаем фокус-группу совсем других участников, и смотреть они будут на программу совсем другими глазами.

Как вариант, сделать работающую версию программы в качестве прототипа для того же тестирования. Делаем. С тестовой базой данных. С ни разу не вылизанными до стерильности визуальными штучками интерфейса. Но со всеми теми же самимы положенными формами, кнопками, со всей предполагаемой интерактивностью. Всё равно огромный объём работ, функциональность-то по-любому сложная, и здесь уже программеры настороже: неужели опять недели рабочих подвигов сведутся к тому, что, (как в первом абзаце было) написали, не понравилось, переделываем?