Моя хорошая знакомая шутит, что тестировщик - это крыса проекта: жалуется на всех кто не дозаполнил доку и всех, кто плохо реализовал задачу в коде.
Как бы да… но нет.
？Почему неточности - это плохо?
Аналитик ставит задачу как художник: он так видит.
Его понимание задачи нередко строится на бизнес-процессе, а не технических сущностях и это отражается в постановке. А тестировщик - технический задрот, интересующийся каждой циферкой в обсуждаемой задаче.
Любой тестировщик был в ситуации, когда приходится ходить по чатам, организовывать созвоны, искать ответственных “хранителей знания”, уточнять детали.
Всё это конвертируется в долгое время тестирования и самые простые задачи “висят” незарелиженными неделями.
🔧 Что делат тестировщику?
Задача тестировщика - стать полицейским постановок, на самом раннем этапе, в идеале еще до разработки, подмечать “серые области” и неточные формулировки в задаче. Уточнять их значение и настаивать на добавлении их в текст задачи в более точном виде.
Без софт-скилз здесь не обойтись: мало кто кайфует от написания документации, все хотят только строить крутые сервисы, выкатывать новые фичи, но никак не “прописывать обязательные поля запросов”.
Но регулярно просматривать все задачи без процесса - просто невозможно. Закопаешься.
👯♀️ Как убедить команду?
Круто помогают общепринятые в команде практики, зафиксированные в письменном виде. Если замечаешь, что часто уточняешь одни и те же моменты по разным задачам, не стесняйся делиться этим с командой, только будь немножечко стратегом:
- Собери несколько примеров задач, которые вызвали долгие обсуждения и выяснение неточностей.
- Попробуй провести между ними аналогию: чего во всех этих задачах нехватает? Какого рода это задачи? Мы ищем тенденцию, а не уникальный прецедент.
- Твой посыл - не претензия, а предложение по оптимизации, поэтому принеси и классное предложение, уже оформленное в крутой пример.
Можешь сам взять задачу, имеющую серую зону, внести в текст ясность и предложить в будущем делать “так” со всеми однотипными задачами. Буквально покажи скрин задачи ДО и ПОСЛЕ. Не забудь произнести волшебные слова:
🪄Если бы задача выглядела так с самого начала, тестирование заняло бы меньше времени.🪄”
- Пример сделает твое предложение осязаемым, а неоспоримым его сделает еще и адресат: кто из всей команды может добавлять недостающую информацию, на каком этапе процесса?
Будь точным в формулировках и оставляй свои идеи открытыми для диалога. Может команда предложит еще что-то более крутое и удобное.
И, если думаешь, что твоя работа сделана после того как все с тобой согласились после обсуждения - у меня для тебя плохие новости.
❗️ Все только начинается.
Новые практики долго приживаются в команде и именно тестировщики в этом случае должны выступать валидаторами и полисменами задач. Сразу после встречи отправь в общий чат\почту meeting-notes и немедленно принимайся за работу: запрашивай уточнения по текущим задачам и тем, что еще в разработке\бэклоге.
Каждую неделю снимай статус команды по новой практике:
- Есть ли необходимость что-то изменить в выбранном формате работы с задачами?
- Есть ли у кого-то сложности с привыканием и предложения по улучшениям?
Ты выбрал путь самурая и да прибудет с тобой рок-н-ролл 🤘
Я использовал такой подход многократно и результат всегда стоит того, чтобы немного покопаться и подготовиться. Команда в итоге видит ускорение и также радуется понятным задачам, не меньше тебя.
tg: t.me/eddytester
inst: @eddytester
♥️