Собственно тестирование

Постановка задачи

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

Нужно иметь несколько пользователей, которые ни разу не видели текущего состояния системы. За исключением редких случаев, когда ваша система рассчитана на продвинутых пользователей (power user), нужно подбирать не слишком опытных субъектов. Тестерам дается задание, они его выполняют, после чего результаты анализируются.

Достаточно помнить следующее:

Тестирование на одном пользователе позволяет найти примерно 60 ошибок. Соответственно решайте сами, сколько пользователей необходимо для одного сеанса.

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

Никогда не прерывайте пользователя.

Никогда не извиняйтесь за несовершенство тестируемой системы. Никогда не говорите «Мы потом это исправим». Никого не обвиняйте.

Никогда не называйте процесс тестирования «пользовательским тестированием» – пользователь решит, что тестируют его, и будет бояться.

Один из самых простых видов тестирования – проверка посредством наблюдения за пользователем. Пользователю дается задание, он его выполняет, его действия фиксируются для дальнейшего анализа какой-либо программой записи состояния экрана (удобен Lotus ScreenCam). Чтобы пользователь не тревожился и не стеснялся, его лучше всего оставить в одиночестве. Метод исключительно полезен для выявления неоднозначности элементов интерфейса. Поскольку каждая неоднозначность приводит к пользовательской ошибке, а каждая такая ошибка фиксируется, обнаружить их при просмотре записанного материала очень легко.

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

Метод «Мыслим вслух» довольно нестабильный, но порой дающий интересные результаты (очень зависит от разговорчивости пользователя-испытателя). Соответствует проверке посредством наблюдения за пользователем, но тестера при этом просят также устно комментировать свои действия. Затем комментарии анализируются.

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

Тест на проверку качества восприятия позволяет определить, насколько легко интерфейсу обучиться. Поскольку существует разница между понятиями видеть и смотреть, а запоминается только то, что увидено, необходимо обладать уверенностью в том, что пользователь увидит если не всё, то уж хотя бы всё необходимое. А значит – запомнит, благодаря чему в будущем ему не придется обшаривать меню в поисках «чего-то такого, что, я точно знаю, где-то здесь есть».

Сама по себе методика проста. Пользователю даётся задание, связанное с каким-либо отдельным диалоговым окном. Пользователь его выполняет. Через несколько минут пользователя просят нарисовать (пускай даже грубо и некрасиво) только что виденное им окно. После чего рисунок сравнивается с оригиналом.

Разумеется, пользователь запоминает только то, что ему кажется актуальным в процессе работы с окном (плюс еще что-нибудь за того, что ему показалось интересным, да и то не всегда). Это один из тех редких случаев, когда срабатывает ограничение на объем кратковременной памяти, так что количество запомнившихся элементов управления не может быть выше порога.

Тестирование само по себе имеет существенный недостаток: если тестирование проблем не выявило, получается, что оно было проведено зря. Если выявило, придется проблемы решать, что тоже существенная работа.

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

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

Без тестирования эффективный интерфейс получить практически невозможно. Тестируя, вы многократно быстрее научитесь проектировать интерфейсы. Одно дело узнать о типичной ошибке из, например, конференции, и совсем другое – обнаружить её в своей работе. Вероятность того, что вы её не повторите, найдя её у себя, гораздо больше, нежели если вы о ней просто узнаете.

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

Тема 3.2 Дизайн информационных систем на конкретных примерах: дизайн и нформационно-поисковых, информационно-решающих и информационно-советующих систем (2 часа)

(написать в следующий раз)
Раздел 4 Поэтапная разработка ИС для внедрения в экономический сектор

Тема 4.1 Организация разработки ИС: каноническое и типовое проектирование (2 часа)

4.1.1 Каноническое проектирование ИС

Дата добавления: 2014-01-06