Ситуация: разработчик передает в тестирование фичу, тестировщик находит баги, отправляет все назад в разработку, разработчик вносит правки. Затем новый прогон. Получается игра в пинг-понг, где в роли мяча — таска в трекере, а в роли третьего участника — бизнес, которому «срочно надо в прод». Можно ли это ускорить и упростить? Да, благодаря такому подходу как совместное тестирование. В статье расскажу, как это работает и кому подходит.
Привет, Хабр. На связи Лена Федорова, QA в IT-компании Garage Eight. 8 лет я работаю QA, совмещаю ручное и автоматизированное тестирование.
Недавно я начала осваивать бэкенд-разработку и задумалась, как тестировщикам и разработчикам не просто сосуществовать, а эффективно работать вместе. В какой-то момент моя команда столкнулась с похожей ситуацией, и я подняла вопрос на уровне команды, это было совместное решение.
В ходе обсуждений и экспериментов мы пришли к новой для нас практике — совместному тестированию. Это сработало. Об этом подходе я и хочу рассказать.
Статья будет полезна тем, кто чувствует, что команда устала от жонглирования фичами, недопонимания. Тем, кто хочет узнать, как внедрить совместное тестирование, что вы получите, на какие жертвы придется пойти и как понять, что подход работает.
Что такое совместное тестирование
Это формат, при котором тестировщик проверяет фичу не в одиночку, а вместе с разработчиками. Иногда подключается вся команда, включая аналитика, дизайнера и продакт-менеджера. Это зависит от задачи и договоренностей.
Близкие по духу практики — парное программирование, моббинг, коллаборация и любые другие формы совместной работы, где знания и внимание концентрируются в одном месте.
Например, при проверке дашборда на смартфоне аналитик замечает, что одна кнопка не видна на iPhone SE, дизайнер подкидывает идеи, а разработчик исправляет прямо в режиме реального времени.
Главная ценность подхода — объединение знаний и опыта обеих сторон:
Тестировщик смотрит на продукт глазами пользователя, знает, где всплывают баги, какие UX-флоу нестабильны и где есть подводные камни.
Разработчик понимает, как написан код, может быстро диагностировать проблемы и предложить варианты решения.
Если QA и dev работают вместе, получается идеальная команда по поиску и быстрому исправлению дефектов. Можно решить проблемы прямо на встрече в режиме онлайн и не откладывать их на потом.
Но очевидно, что начать так тестировать фичи «с понедельника» не получится. Нужна подготовка.
Как засетапить подход во флоу работы
Что делать, чтобы сесть и начать тестировать фичу совместно, а не просто терять время:
Определите цель. Зачем вы это делаете? Что именно хотите улучшить? Решите, для чего подход будет полезен: от сокращения времени на багфиксы до увеличения прозрачности процессов.
Соберите рабочую группу. Это может быть просто QA и разработчик, с которым он чаще всего работает. Если нужно, подключите других членов команды. К нашей команде иногда подключались также продакт‑оунеры и дизайнер.
Выберите простую задачу для пилота. Желательно ту, тестирование которой не займет много времени. Если выбрать что-то слишком сложное, остальные участники устанут и процесс остановится.
Проведите первую сессию. Опять же, не на 4 часа, иначе все быстро выгорят. Лучше провести несколько коротких встреч, либо делать перерывы.
Соберите обратную связь. Перечислите, что сработало, а что нет, и какие выводы можно сделать. Возможно, уже на этом этапе появятся идеи по улучшению формата.
Заложите время при планировании. Особенно если работаете по спринтам. Обсудите с командой заранее, будет ли в спринте место под совместную сессию.
Что дает совместное тестирование: плюсы от внедрения
Как и при проверке и внедрении любого другого подхода, вас обязательно спросят: «Реально ли это выгодно?». Поэтому разберем, какие преимущества можно получить от совместного тестирования, кроме того, что не нужно 3 раза кидать тикет туда-обратно.
Единое видение бизнес-ценности. Все участники понимают, как работает продукт в целом и в разрезе конкретной фичи. Видят его глазами друг друга, а значит — формируют общее понимание ценности продукта для конечного пользователя.
Прозрачность процессов. Когда разработчик просто кидает задачу в тестирование, он рискует забыть про нее и потерять контекст. Совместная работа делает статус фичи очевидным: все понимают, где она сейчас, что уже протестировано и исправлено.
Повышение доверия внутри команды. QA и разработчики начинают воспринимать друг друга как союзников, а не как контролёров или внутренних прокуроров. Появляется понимание вклада всех членов команды в общее дело. Коммуникация становится продуктивнее.
Кейс: совместное тестирование помогает учиться на чужих ошибках
Еще одно преимущество — более эффективное использование ресурсов. Приведу реальный кейс. В одной из частей нашего продукта мы реализовывали функционал комментирования на 3-х платформах: Android, iOS и web. И в одной из задач нужно было вывести список комментариев с пагинацией.
Android-разработчик закончил свою часть задачи первым. На этапе совместного тестирования мы обнаружили баг в работе пагинации — поправили, забыли и пошли дальше. Казалось бы, обычная ситуация. Но дальше, когда пришло время тестировать web, фронтенд-разработчик подошел ко мне и сказал: «Помнишь, на Android был баг с пагинацией? Я у себя нашел такой же и уже пофиксил».
Помогло то, что он присутствовал на тестировании Android-версии фичи. Услышал обсуждение ошибки, понял суть и заранее проверил у себя аналогичный сценарий.
В итоге:
Баг был отловлен еще на этапе написания кода перед передачей в тестирование.
Не потребовалось время на его воспроизведение и фиксы.
Мы сократили цикл тестирования Web-версии.
Совместное тестирование позволяет перенимать опыт между платформами и продуктами. Один общий звонок может спасти от десятка повторений типовых багов.
А в чем подвох? Недостатки и как их избежать
У любого метода есть оборотная сторона — совместное тестирование не исключение.
Требует ресурсов. Самая очевидная проблема — это время. Найти общий свободный слот в календаре у QA и разработчика (а тем более у всей команды) — сложно.
?Как решить: договариваться на этапе планирования. Если вы работаете по спринтам — заложите время заранее. Если без спринтов — оговорите слот, как только задача попадет в бэклог.
Конфликты и недопонимания. Люди разные, и их подходы к работе, процессы, предпочтительные комфортные условия и приоритеты могут различаться. Могут возникать недомолвки.
?Как решить: вовремя собирать обратную связь, проводить ретроспективы. Нужно обсуждать, что стоит улучшить или поменять. Самое главное — помнить, что не должно быть никакого принуждения.
Усталость и потеря фокуса. Если встреча слишком длинная, участники начинают «отваливаться», а со временем даже выгорать.
? Как решить: проявлять уважение друг к другу, соблюдать баланс между работой и отдыхом и ставить короткие сессии по 30–50 минут. Лучше чаще, но короче.
Кому подойдет совместное тестирование
Вы можете смело пробовать подход, если у вас:
Кросс-функциональная команда. Если есть широкий спектр навыков, то совместное тестирование даст возможность обмениваться экспертизой и лучше понимать продукт с разных точек зрения.
Команда, работающая по Agile или Scrum. Гибкие методологии подразумевают постоянные изменения в процессах. Для таких команд дополнительный процесс не станет проблемой и органично впишется во флоу работы.
Команда с ограниченными ресурсами и временем. Актуально для стартапов, которым важно быстрее выйти на рынок и начать собирать данные. Совместное тестирование позволяет не терять время на пинг-понг между разработкой и QA, а сразу закрывать фичи и собирать фидбек с продакшена.
Команда с частыми релизами. Если вы регулярно выкатываете обновления, совместное тестирование помогает минимизировать баги на проде, быстрее выявлять проблемы и принимать решения по ходу встречи.
А кому может не подойти
Подход не универсальный, и некоторым типам команд, возможно, стоит поискать альтернативные методы.
Среди тех, у кого может не взлететь:
Проекты с четкими и фиксированными требованиями. Когда точно известно, что и как нужно сделать. В таких проектах вероятность ошибки мала, и сложный процесс тестирования будет лишним.
Международные распределенные команды. Если команда разбросана по часовым поясам, провести синхронную встречу тяжело. Но даже если между сотрудниками 6 часов разницы (Москва–Бали), при желании можно договориться о едином слоте.
Команды со строгой иерархией. Если внутри компании строгое распределение ролей и каждый занимается своим делом, внедрить кросс-функциональное взаимодействие сложно.
Команды с низкой культурой тестирования. Если в компании нет QA-инженеров или на тестирование не выделяется время и внимание, то совместное тестирование — не тот инструмент, с которого стоит начинать улучшение процессов.
Крупные команды. Например, бэкенд-команда из 60 разработчиков и столько же членов из отдела QA. Между такими масштабными командами обычно низкий уровень коммуникации. Организовать совместное тестирование — почти невозможно.
? Как решить: подход можно попробовать адаптировать под свои условия работы, обговорить с командами и руководством. Возможно, он найдет отклик.
Как понять, что подход работает: метрики
Риск совместного тестирования — получить ситуацию «пообщались, время потратили и разошлись». Чтобы понять, насколько эффективно оно работает, можно опираться на следующие метрики:
Скорость разработки и тестирования:
Cycle time — сколько времени уходит на одну итерацию «разработка–тестирование».
Lead time — фактическое время от поступления требования до релиза на прод.
В нашей команде мы эти метрики не замеряли — просто заметили, что стало быстрее и проще. Но если у вас в компании принято собирать эти показатели — делайте это.
Качество продукта:
Число итераций до стабилизации фичи — сколько раз она возвращается на доработку.
Время реакции на баги — сколько времени проходит от обнаружения до фикса.
Количество повторяющихся багов — насколько часто баги фиксятся, но снова появляются.
Совместное тестирование может минимизировать повторяющиеся ошибки и ускорить фиксы за счет мгновенной обратной связи.
Удовлетворенность команды:
Анкеты и опросы.
Ретроспективы для обсуждения формата.
Например, я запускала короткий опрос: «Какие преимущества и недостатки ты видишь в этом процессе?».
Так ответили участники команды:
Если коротко:
Product owner одобрил совместное тестирование за то, что оно позволяет переиспользовать кейсы между платформами, быстрее принимать решения.
Backend developer сказал, что процесс помогает перенимать знания и опыт.
У нас тоже так работает: один из бэкенд‑разработчиков пришел из QA, а я сама начала осваивать бэкенд во многом благодаря совместному тестированию. Поэтому в нашей компании результатом стал нативный обмен знаниями в обе стороны.
Android developer отметил, что ему полезно смотреть на код со стороны, чтобы понять, что он мог упустить.
Минус, который выделили все: нужно заранее выделять время и быть готовым к тому, что часть ресурсов переключится от своих задач на тестирование.
Роль инициативы: кто должен быть драйвером
В большинстве случаев драйвить совместный процесс нужно тестировщикам. Я не считаю это недостатком, но некоторые могут думать иначе. QA чаще выступают инициаторами и у них больше экспертизы в тестировании.
Но инициаторами могут быть и разработчики. В нашей команде, например, разработчики сами периодически просят протестировать фичу вместе. Это показывает, что процесс воспринимается как полезный.
Итоги: не панацея, но инструмент, который мы полюбили
Совместное тестирование — подход для команд, которые готовы пробовать новое вместе, общаться и экспериментировать. Оно объединяет, дарит полезные инсайды, ускоряет процессы, устраняет дублирующиеся баги.
Что получает команда:
Повышение качества продукта.
Единые критерии оценки фичей.
Быстрая поставка функций пользователям.
Улучшение командной коммуникации.
Обмен опытом между разработчиками и тестировщиками.
Реальная, быстрая обратная связь.
На что важно опираться при внедрении:
Цель. Зачем вы это делаете? Если «потому что модно», лучше не начинать.
Метрики. Без анализа результатов вы не поймете, работает ли подход.
Обратная связь. Слушайте команду, адаптируйте процесс.
Здравый смысл. Если фича — сложная, новая, с несколькими сценариями, тестируйте вместе. Если задача небольшая — можно обойтись без этого.
Подход помогает достигать взаимопонимания и ускорять релизы. Но минус коллаборации QA и dev в том, что совместная работа не всем подходит. Оцените, какая у вас команда сейчас и готова ли она к таким изменениям. Если да, попробуйте! Возможно, вы увидите, что пинг-понг между тестированием и разработкой закончится.
Как вы считаете — сработает ли совместное тестирование у вас или нет? А если уже работает, поделитесь в комментариях, как вы к этому пришли и какие баги пофиксили успешно. Буду рада обсудить!