Разработчики хотят делать понятные и удобные программные продукты.
Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:

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

Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:

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

Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.

Наши рекомендации по проведению КТ

Готовьте сценарии, приближенные к реальным. Важно приготовить сценарии с реальными данными: договоры и акты с реальными именами, а не «тестовый документ», реальные пользователи и организационная структура в системе. Если просто дать потыкать систему, такого эффекта не будет.

Адаптируйте сценарии в ходе тестирования. Если у первых двух пользователей возникли проблемы — изменяйте сценарий. Можно непосредственно в процессе придумывать новые ситуации взаимодействия с системой.

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

Исключите бюрократию из процесса. Выделить 15–20 минут готов почти любой в компании, не нужно никаких суровых согласований с руководителями и выбора людей, достаточно написать в коммуникаторе и договориться о времени. Откликаются почти все без проблем; не откликнулся один — всегда есть, кого позвать вместо уклониста.

Ограничивайте количество подопытных. Чтобы найти основные проблемы достаточно 8–10 человек с разным уровнем подготовки и функциональными обязанностями. По итогам одного из коридорных тестирований посчитали количество обнаруженных багов и количество новых багов для каждого пользователя. Видно, что последние пользователи уже не говорят практически ничего нового:

Добейтесь естественного окружения. Клавиатура, монитор, система, языки и другое окружение должны быть стандартными и привычными, чтобы не мешать и не отвлекать людей.

Тестируйте на бета-версии. Тестировать на сыром продукте — нормально. Не страшно, если вылезет пара багов. Коридорное тестирование мы делаем в конце спринта. Тут уже почти все работает и есть время, чтобы что-то быстро исправить или проанализировать и запланировать на исправление в следующем спринте.

Можете создавать сценарии и до разработки, они пригодятся и на проектировании, и на планировании (понимать, что надо сделать), и во время разработки для проверки и тестирования, и на демо.

Записывайте все. Фиксируйте не только проблемы, но и то, с чем проблем не возникло. Это нужно, чтобы потом не испортить то, что хорошо работает сейчас.

Как мы практикуем коридорное тестирование