Разработчики хотят делать понятные и удобные программные продукты.
Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:
Если к программе можно написать плагин, то она удобная и расширяемая. Если можно поменять в конфиге цвет фона окна сообщения — гибкая. Нормальному же пользователю от такой гибкости ни тепло ни холодно, ему свои задачи надо решать, а не плагины писать.
Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:
Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.
Готовьте сценарии, приближенные к реальным. Важно приготовить сценарии с реальными данными: договоры и акты с реальными именами, а не «тестовый документ», реальные пользователи и организационная структура в системе. Если просто дать потыкать систему, такого эффекта не будет.
Адаптируйте сценарии в ходе тестирования. Если у первых двух пользователей возникли проблемы — изменяйте сценарий. Можно непосредственно в процессе придумывать новые ситуации взаимодействия с системой.
Тестируйте на разных пользователях. Для нас самые интересные пользователи, которые дали больше всего полезного фидбека, — новички или вообще не знакомые с системой. У них еще не замылен взгляд и нет пагубных привычек от работы с предыдущими версиями. От старичков, особенно разработчиков, в основном получаются замечания по тому, что не работает их любимая горячая клавиша, но игнорировать таких пользователей тоже нельзя.
Исключите бюрократию из процесса. Выделить 15–20 минут готов почти любой в компании, не нужно никаких суровых согласований с руководителями и выбора людей, достаточно написать в коммуникаторе и договориться о времени. Откликаются почти все без проблем; не откликнулся один — всегда есть, кого позвать вместо уклониста.
Ограничивайте количество подопытных. Чтобы найти основные проблемы достаточно 8–10 человек с разным уровнем подготовки и функциональными обязанностями. По итогам одного из коридорных тестирований посчитали количество обнаруженных багов и количество новых багов для каждого пользователя. Видно, что последние пользователи уже не говорят практически ничего нового:
Добейтесь естественного окружения. Клавиатура, монитор, система, языки и другое окружение должны быть стандартными и привычными, чтобы не мешать и не отвлекать людей.
Тестируйте на бета-версии. Тестировать на сыром продукте — нормально. Не страшно, если вылезет пара багов. Коридорное тестирование мы делаем в конце спринта. Тут уже почти все работает и есть время, чтобы что-то быстро исправить или проанализировать и запланировать на исправление в следующем спринте.
Можете создавать сценарии и до разработки, они пригодятся и на проектировании, и на планировании (понимать, что надо сделать), и во время разработки для проверки и тестирования, и на демо.
Записывайте все. Фиксируйте не только проблемы, но и то, с чем проблем не возникло. Это нужно, чтобы потом не испортить то, что хорошо работает сейчас.
Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:
Если к программе можно написать плагин, то она удобная и расширяемая. Если можно поменять в конфиге цвет фона окна сообщения — гибкая. Нормальному же пользователю от такой гибкости ни тепло ни холодно, ему свои задачи надо решать, а не плагины писать.
Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:
- Пользователям некогда оформлять замечания к продукту. Особенно если это касается удобства использования программы, а не функционала.
- Не понятно, насколько интуитивен интерфейс. Можно, конечно, проводить опросы, но они обычно малоинформативны.
- Замечания поступают слишком поздно. У разработчика остается меньше времени на их исправление.
Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.
Наши рекомендации по проведению КТ
Готовьте сценарии, приближенные к реальным. Важно приготовить сценарии с реальными данными: договоры и акты с реальными именами, а не «тестовый документ», реальные пользователи и организационная структура в системе. Если просто дать потыкать систему, такого эффекта не будет.
Адаптируйте сценарии в ходе тестирования. Если у первых двух пользователей возникли проблемы — изменяйте сценарий. Можно непосредственно в процессе придумывать новые ситуации взаимодействия с системой.
Тестируйте на разных пользователях. Для нас самые интересные пользователи, которые дали больше всего полезного фидбека, — новички или вообще не знакомые с системой. У них еще не замылен взгляд и нет пагубных привычек от работы с предыдущими версиями. От старичков, особенно разработчиков, в основном получаются замечания по тому, что не работает их любимая горячая клавиша, но игнорировать таких пользователей тоже нельзя.
Исключите бюрократию из процесса. Выделить 15–20 минут готов почти любой в компании, не нужно никаких суровых согласований с руководителями и выбора людей, достаточно написать в коммуникаторе и договориться о времени. Откликаются почти все без проблем; не откликнулся один — всегда есть, кого позвать вместо уклониста.
Ограничивайте количество подопытных. Чтобы найти основные проблемы достаточно 8–10 человек с разным уровнем подготовки и функциональными обязанностями. По итогам одного из коридорных тестирований посчитали количество обнаруженных багов и количество новых багов для каждого пользователя. Видно, что последние пользователи уже не говорят практически ничего нового:
Добейтесь естественного окружения. Клавиатура, монитор, система, языки и другое окружение должны быть стандартными и привычными, чтобы не мешать и не отвлекать людей.
Тестируйте на бета-версии. Тестировать на сыром продукте — нормально. Не страшно, если вылезет пара багов. Коридорное тестирование мы делаем в конце спринта. Тут уже почти все работает и есть время, чтобы что-то быстро исправить или проанализировать и запланировать на исправление в следующем спринте.
Можете создавать сценарии и до разработки, они пригодятся и на проектировании, и на планировании (понимать, что надо сделать), и во время разработки для проверки и тестирования, и на демо.
Записывайте все. Фиксируйте не только проблемы, но и то, с чем проблем не возникло. Это нужно, чтобы потом не испортить то, что хорошо работает сейчас.
