Комментарии 5
Проблема дискоммуникации внутри команды не должна решаться путём привлечения большего количества людей на встречи. Эффективность встречи на практике почти всегда обратно пропорциональна количеству участников. Если проблему можно решить двумя людьми - её должны решать два человека. Тестировщик должен не из разговоров с обсуждениями реализации узнавать о новых фичах или иных изменениях, а из документации к проекту, описанию маппингов, контрактов и прочего. Ну или на каких-то общекомандных митингах, хотя бы. На моём текущем проекте команда тестирования и без того слишком перегружена из-за недостатка кадров, грузить их ещё и лишними обсуждениями совсем не хочется. Пусть держат в голове только конечное требование к системе, а не набор предложений и рассуждений, иначе потом у человека может начаться каша в голове, из набора реальных требований и того, что он когда-то где-то услышал на встрече.
Также, я как разработчик не хочу во время обсуждения некой задачи с анализом отвлекаться ещё на то, чтобы объяснить какие-то тонкости тестировщику. Если тестировщику будет что-то не понятно после того, как он прочитает описание задачи постфактум, то тогда пожалуйста, пусть приходит. Но в процессе некоего мозгового штурма я хочу как можно меньше отвлекаться. Так же думаю и со стороны анализа.
Речь не обязательно о конкретно троице разраб-тестировщик-аналитик. Как я уже писал выше: если команде для решения проблемы достаточно меня и одного другого члена команды, тогда все остальные люди на встрече - лишние. Кто бы что не говорил, но когда кого-то зовут на встречу просто из соображения "вдруг будет другое мнение", то этот человек скорее всего будет в пол уха слушать, а на деле заниматься более важными для себя задачами.
Не дам пример правильного решения, потому что правильного не знаю, но приведённое в статье "решение" никак не решает настоящую проблему.
Если я правильно понял исходную проблему (вроде успешно договорились, а по факту каждый участник ушёл с беседы со своей "картинкой"), то есть решение лучше.
Спору нет, развивать софт-скилы и помогать коллегам находить общий язык это всегда полезно.
Но с точки зрения качества разработки проблему "синхронизации картинки" внутри команды лучше решать через этап согласования документа (ТЗ, бизнес-постановка, техническое решение - у всех по разному).
Мы работаем в Редмайн, у каждой крупной фичи есть задача "Проектирование". Когда аналитик заканчивает создание ТЗ, переводит задачу в статус "Согласование". Тестировщик проверяет документ на соответствие базовым требованиям (полнота, непротиворечивость, однозначность, тестируемость и прочее). При необходимости общается с разработкой, архитектором и может вернуть аналитику на доработку. Перед сменой статуса Проектирования с "Согласование" на "Решено" тестировщик должен выставить в задаче "ожидаемое время выполнения" и перечислить основные запланированные проверки.
Если аналитик и тестировщик хорошо сделают свою работу по созданию/приёмке ТЗ - шансы что у команды "картинки разойдутся" - минимальны.
чтобы не было разногласий, я как тестировщик всегда тестирую требования -в этот момент вылазит непонятное, недоговоренное, необсужденное.
Как написали в комментариях, проблема с поздним подключением тестирования. Просто нужно применять на проекте Shift Left Testing с отдельной фазой анализа требований.
Плюс можно создать отдельный чат для всех участников команды, которые так или иначе работают с требованиями и дизайном, подсвечивая там все нестыковки, противоречия и уточняющие вопросы.
Как обычно, все проблемы из-за неэффективной коммуникации.
Я теперь, пожалуй, вижу проблемы весьма абстрактно написанного примера в статье, который несколько дезинформировал читателей фразой "вот-вот отдадут на тестирование". На тот момент только появился первый микросервис, назовем его опытный образец, который сделали в период, когда требования еще оформлялись в виде документации.
Встречи по типу 3 Амиго и живут в парадигме сдвига влево, и являются одним из инструментов проведения анализа требований. Отчасти это и было внедрение сдвига влево только еще левее, чем ревью документации.
Чаты неизбежное появившееся в удаленной работе и, как показывает практика, часто неэффективное: пропустить вопрос легко, переключение между контекстами текущая выполняемая задача/вопросы в чатах - это значительная потеря времени. Запланированные созвоны показали себя более продуктивными.
Принцип «Трёх Амиго» в действии. Опыт с точки зрения тестировщика