Мнение пользователей о продукте — основное мерило качества работы всей команды. В каждом спринте мы делаем все возможное, чтобы подготовить стабилизированный и соответствующий ожиданиям пользователей релиз. Хотя баги — часть нашей профессии, неприятно узнавать о том, что какие‑то из них проскользнули в продакшн. Мы регулярно проводим работу над ошибками, благодаря чему стали использовать кросс‑ревью: практику, которая раз за разом помогает нам расширять список проверок и грамотно их структурировать, позволяя получать при тестировании больший профит при меньших трудозатратах. Меня зовут Михаил Михайлов, я руковожу отделом тестирования Polymatica BI, и в сегодняшней статье расскажу, как сейчас устроен этот процесс в нашей команде.
Командная работа
Во многих командах принято перекладывать формирование тестовой стратегии на плечи одного тестировщика, а затем ревьюить силами другого тестировщика. В результате возникает когнитивная замкнутость: повторяются одни и те же паттерны ошибок.
Но почему, имея целую команду, нужно замыкаться на паре сотрудников, хоть и, безусловно, крутых? И зачем столь интересный процесс превращать в сухую рутину типа «давай весь день обсуждать два кейса», причем делая это в комментариях?
Так в процессе творческого поиска мы решили опробовать кросс‑ревью, которое потом стало неотъемлемой частью нашей работы.
Чек‑лист кросс‑ревью
Хочу напомнить о том, что не следует пренебрегать грумингом фич прежде, чем передавать их технической команде. Хорошая статья на Хабре на эту тему.
Пристроить фичу в надежные руки: шефство над ней берет конкретный тестировщик по своему желанию или по настоянию тимлида, принявшего такое решение ввиду, например, специфики новой функциональности.
Погрузиться: ответственный тестировщик проверяет документацию и готовит полный набор тест‑кейсов для дальнейших проверок, чтобы досконально изучить грядущую доработку.
Подготовиться к обсуждению: тестировщик готовит тестовую документацию и назначает встречу с командой, предварительно обозначив тему (кросс‑ревью такой‑то фичи).
Провести встречу: фасилитатор встречи, то есть ответственный за фичу тестировщик, начинает с небольшого демо по грядущей доработке, в общих чертах описывая что, где и для чего. Далее вся команда по изученным заранее требованиям и макетам разбирает каждый пункт. После обсуждаются целевые сценарии использования фичи, то есть сценарии, которые 100% нужны будут пользователю (формируем эти сценарии из бизнес‑требований и юзер‑кейсов, описанных в исходной задаче)
Подвести итоги: по итогам кросс‑ревью необходимо решить накопившиеся по документации вопросы и внести коррективы в тест‑кейсы.
Порой можно проводить кросс‑ревью параллельно с процессом разработки. Очевидный плюс — запас времени на выяснение нюансов и необходимые коррективы с каждой из сторон. В некоторых случаях уместно брейнстормить фичу по завершении первой итерации тестирования: имея хоть сколько‑то рабочую функциональность, в ней становится намного проще ориентироваться.
Примеры из нашей практики
Приведу пару кейсов из практики, где кросс‑ревью показало свою эффективность.
Первый случай: между двумя приложениями настроена синхронизация через N минут, указанных в параметре конфига. На кросс‑ревью коллега предложил проверить работу параметра со значением «через сутки» (релевантно для пользователя: синхронизировать данные каждый день). Оказалось, что большой временной диапазон не обрабатывается корректно.
В душу тестировщика закралась тень сомнения… Дополнительные проверки показали, что и синхронизация на количество минут, кратное десяти (10, 20, 50), тоже не работает. А в довесок нашлись еще несколько мелких багов, которые ловко спрятались при первой итерации тестирования.
Другой показательный случай связан с редизайном и рефакторингом настроек форматирования. Мы решили сделать упор на широкой стратегии для того, чтобы за один проход протестировать доработку целиком. Потратив менее часа на четверых, команда успела найти с десяток неочевидных, но важных моментов, а также расширить тестовое покрытие почти в полтора раза — без «дробления» на избыточные проверки.
После подобных случаев необходимость кросс‑ревью уже не вызывает вопросов. Для сложных фич это особенно важно: чем сложнее логика, тем выше вероятность пропустить детали. Совместное обсуждение позволяет охватить больше сценариев.
Пользуемся с умом: риски и ограничения кросс-ревью
-
Потеря времени — что обсуждаем
Чтобы встреча не превратилась в бесполезную болтовню, важно ограничить повестку, приоритизировать критичные сценарии и следить за таймингом.
-
Сложность фасилитации — как обсуждаем
Без четкой структуры и фиксации результатов смысл встречи растворяется в воздухе. Фасилитатор должен вести дискуссию по сценарию: от постановки задачи → через разбор кейсов → к конкретным действиям, с обязательным протоколом итогов.
-
Перегруженность команды — кто обсуждает
Слишком большое число участников снижает эффективность, особенно если часть присутствует «для галочки». В большой команде ограничивайте участие до ключевых ролей.
Существование ошибок — необходимое зло, с которым приходится мириться, но время и место, где их находят, — вот что по‑настоящему важно. Помните о принципе «чем позже, тем дороже»: исправление дефекта из продакшена будет стоить кратно больше, чем исправление этого же дефекта в контуре команды (а если прибавить сюда еще и репутационные потери, каждый пропущенный дефект становится «на вес золота»). Кросс‑ревью позволяет разносторонне подойти к тестированию: на стыке взглядов рождаются самые неудобные вопросы.
Когда мы внедрили практику кросс‑ревью тест‑кейсов и требований, количество дефектов, найденных до релиза, кратно выросло, благодаря чему релизы стали более предсказуемыми.