Что делать, если задача реализована по ТЗ, но есть более удобный вариант для пользователя
Что проверяют
Отличаете ли вы дефект от предложения и умеете ли продвигать улучшение, не блокируя релиз. Тестировщик, который ставит блокер по вкусовщине, быстро теряет вес: его дефекты перестают читать.
Как отвечать
Сначала перепроверить, действительно ли всё сделано по требованиям. Часто «более удобный вариант» это на самом деле противоречие внутри самих требований: макет говорит одно, текст другое, а соседний экран продукта ведёт себя иначе. Тогда это не улучшение, а дефект, и заводить его надо как дефект.
Разделять три случая:
- расхождение с требованиями или с поведением остального продукта: дефект, обычный приоритет;
- риск для пользователя: потеря введённых данных, необратимое действие без подтверждения, недоступность с клавиатуры. Это тоже дефект, и сказать о нём стоит до релиза;
- собственная идея, как сделать удобнее: отдельная задача на улучшение, выпуск она не блокирует.
Предложение оформляется как сценарий, а не как ощущение. Полезно показать: вот путь пользователя, вот сколько в нём лишних шагов, вот обращения в поддержку или место, где люди отваливаются. Адресат такого тикета аналитик или владелец продукта, решение принимает он, а не разработчик в личной переписке.
И отдельно: если идею отклонили, задача остаётся в бэклоге. Это нормальный исход, а не повод спорить в комментариях.
Где спотыкаются
Заводят вкусовщину блокером и останавливают выпуск. После пары таких случаев приоритеты от этого тестировщика перестают воспринимать всерьёз, включая настоящие блокеры.
Молчат, потому что «по требованиям же сделано». Тестировщик единственный, кто проходит сценарий целиком и свежим взглядом, и его наблюдение больше никто не сделает.
Аргументируют словами «неудобно» и «некрасиво» либо подпирают выдуманной цифрой вроде роста удовлетворённости на двадцать процентов. Ощущение без сценария отклоняют, а придуманная метрика проверяется одним вопросом о том, как её замерили.