Антон Колчеданцев
27 марта 2014

Здравствуйте, у меня проблема.

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

Как реагировать на замечания: «Вот эта кнопка выглядит неправильно», «Здесь лучше синее, а не зелёное» и т. п.? Должен ли тестировщик обращать внимание на работу сторонних сервисов, установленных на сайте (например, Яндекс.Карты)?



Антон!

Похоже, вам попался хороший тестировщик, его заботит продукт, а не проход по чеклисту и составление списка багов. Берегите его.

Конечно, планировать тестирование под конец проекта неэффективно, на исправление ошибок не остаётся времени.

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

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

С замечаниями тестировщика поступают как с любыми другими: с благодарностью выслушивают и придирчиво анализируют — вдруг и правда есть проблема. Начните с открытых вопросов:
— Вот эта кнопка выглядит неправильно!
Ух-ты, а почему ты так считаешь?

— Здесь лучше синее, а не зелёное!
— Хм, как, на твой взгляд, другой цвет улучшит интерфейс?

Рассказ «Идеальный тестер»
P. S.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
P. P. S.

Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии

Денис Братчук
27 марта 2014

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

Что с ними делать — вопрос второй, но не менее важный. Мы в обязательном порядке согласовываем список дальнейших шагов для каждой из найденных проблем: должна ли она быть исправлена до запуска, либо сразу после него, либо в течение недели, или же не исправлена вовсе. По истечение не более чем недели после запуска мы всегда проводим повторное тестирование, чтобы убедиться, что критические и просто важные вещи были исправлены в первую очередь.

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

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




Недавно всплыло

Как создавался новый сайт бюро. Часть третья 1 2 Как сделать плавный переход от общения с администратором к директору? 1 Кто ты? 1