Про вовлеченность

Можно быть трижды прилежным тестировщиком, но какой в этом толк, если разработчик не вовлечен в задачу?

Бывает такое: тестировщик проводит качественный анализ задачи, быстро собирает стенд, делает тест-дизайн и начинает тестирование. В ходе работ возникает блокер — требуется помощь разработчика. И вот старательный тестировщик собирает лог, приходит к разработчику, объясняет суть выполняемого сценария, дает все необходимые вводные и слышит: посмотрю позже. Позже — понятие растяжимое, быстро растекается на сутки. Такой разработчик плохо «пингуется». Слова в духе: «задача долго висит», «посмотри как можно скорее» пролетают мимо, потому что «свою» часть работы он уже выполнил, задача в тестировании и по срокам приходят не к нему.

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

Что можно делать?

✔️ Формулировать запрос с фокусом на влияние

Не «мне надо», а «если не разобраться с этим сейчас — дефект уплывёт в релиз / упадет прод». Люди лучше реагируют на последствия, чем на просьбы.

✔️ Создавать баг-репорты

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

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

✔️ Создавать культуру взаимной ответственности

Если тестировщик воспринимается как «человек, который проверит после нас» — это беда. Хорошие команды понимают: мы вместе делаем продукт, и его качество — общее дело.

Здесь имеет смысл вынести проблему на общее обсуждение в рамках scrum-мероприятий, например, на ретро.

✔️ Потеснить застенчивость

Порой человек стесняется проявить настойчивость, чтобы не казаться «проблемным». Такая стратегия не ведет к решению проблемы, но почти наверняка ведет к выгоранию. Рекомендация одна: сначала — спокойно и по-доброму. Потом — системно и по правилам. А если не работает — эскалировать на руководителя. Без чувства вины.

Хорошо быть прилежным тестировщиком, еще лучше — работать в команде вовлеченных людей.