Или как получить неочевидные последствия, если отказаться от команды тестирования.
Полтора года назад мы разрушили команду тестирования: отказались от регресса, передали E2E автотесты на Selenium в поддержку разработчикам и разошлись по командам, которые пилят фичи, чтобы предотвращать ошибки «в зародыше». В розовых мечтах нам казалось, что так будет больше пользы: QA работают над качеством, тестирование начинается рано, а разработчики пишут автотесты сами и никто им не мешает.
Но не фартануло получилось не совсем так. Розовые мечты окрасились дополнительными оттенками: никто не думает о качестве, автотесты всё хуже, а у разработчиков без команды QA (внезапно) стало больше работы. Так проявились последствия второго порядка, к которым мы не были готовы. Сейчас мы их исправляем и можем рассказать, что это за последствия, как они возникают, какой урон наносят и как попробовать их предугадать, чтобы не было так больно.
Что такое последствия первого и второго порядка
У Рэя Далио в книге «Принципы» есть понятие «последствия второго порядка». Это неочевидные следствия наших решений, которые мы часто не можем предугадать. Например, в 60-х годах 20-го века в Китае развернули войну с воробьями. Воробьи съедали зерно, и чтобы они перестали его есть, Китай открыл охоту на птиц. За время охоты китайцы массово убили почти два миллиарда птиц.
В результате геноцида воробьёв через год урожая стало больше. Это последствия первого порядка. Но некому стало есть насекомых и расплодились саранча и гусеницы, которые стали уничтожать ещё больше зерновых, что привело к массовому голоду в Китае в следующие годы. Это последствия второго порядка.
Последствия первого порядка — прямые следствия наших решений и всегда лежат на поверхности. Последствия второго порядка не очевидны и часто долгосрочны. Чтобы их понять, нужно подумать и смоделировать ситуацию. Например:
- Если давать разработчикам оплату за количество строк кода, то кода будет больше, но качество — хуже. Со временем люди начнут хитрить и плодить всё больше и больше плохого кода, чтобы получать больше денег. Это последствия второго порядка.
- Если начать заниматься физическими упражнениями, то сначала будет больно и уходить много времени. Но через некоторое время (от недели до месяцев) возникнет привычка, а здоровье и внешний вид улучшатся. Это последствия второго порядка.
- Если каждую пятницу напиваться как поросенок, то вечером в пятницу будет хорошо. Но утром в субботу будет плохо — это последствия второго порядка. А если делать так регулярно, годами, то, возможно, это перерастет в алкоголизм и цирроз печени. Но это уже последствия третьего порядка и «совсем другая история».
У нас была команда QA и мы её «разогнали»
Теперь расскажу, как мы ощутили на себе последствия и первого и второго порядка. У нас была уютная выделенная команда тестировщиков из 7 человек: 4 из них писали автотесты, а 3 — тестировали вручную. Мы в какой-то момент решили разделиться и разойтись по командам. Почему?
Потому что разработчики получали обратную связь слишком поздно.
Баги находились на этапе, когда уже вся разработка «закончена», всё «интегрировано» и нужно проверить, что продукт готов к релизу. Приёмочного тестирования не было, его выполняли аналитики-продакты у которых не было навыков тестирования. Кроме этого тестировщики и разработчики находились в разных мирах и мало взаимодействовали.
Очевидное (тогда) решение — разойтись по командам, которые работают над определенными фичами (частями) системы, чтобы предотвращать баги «на корню». Бросать свой участок работы мы не хотели, поэтому решили передать разработчикам наши функции. Мы подумали про автотесты — передадим их разработчикам и они будут сами тестировать без проблем.
Гипотезу сначала решили проверить на себе «экспериментом»: покроем критические сценарии регресса автоматическими тестами и откажемся от ручного регресса. Если в результате опыта количество хотфиксов и откатов релиза не вырастет драматически, то можно считать эксперимент удачным. Так и случилось — хотфиксов больше не стало. Решено — расходимся.
Примечание. В компании есть продукт «Ресторан». В него входят все сервисы и наш монолит. Цель продукта — максимально автоматизировать и оптимизировать работу всех сотрудников ресторана. Сейчас наша работа направлена больше на предотвращение ошибок. Теперь мы QA в продукте «Ресторан»: развиваем качества в продукте, участвуем на всех этапах проработки задач.
Последствия первого и второго порядка
Прямые последствия. Как и ожидалось, мы стали подключаться к проработке задач с самого начала, участвовать в PBR, планингах, воркшопах и нести на них экспертизу тестирования. Мы стали ближе к командам разработки, а точнее её частью и наши проблемы были и проблемами команды. В командах стала расти экспертиза тестирования, обеспечения качества и широкое знание системы. Мы в свою очередь стали больше погружаться в работу разработчиков и понимать их боли.
А теперь то, что мы не планировали — это последствия второго порядка.
Никто не драйвит качество продукта. В этой проблеме есть 2 стороны:
- качество с точки зрения процессов;
- качество автотестов и пайплайна.
В выделенной команде QA мы драйвили качество. Мы были последними, кто видит продукт перед пользователями и понимали, как они его видят. Мы обсуждали изменения и улучшения на командном ретро, приходили с предложениями к командам разработки, чтобы вместе решить, стоит ли их вводить. Следили за автотестами и занимались их стабильностью.
После того как мы разошлись по командам, это всё куда-то исчезло. В команде разработки мы часть команды, часть корабля: полностью погрузились в её работу, глаз «замылился» и вот это вот всё общее качество продукта стало чем-то далеким.
Все идеи были направлены только на улучшение состояния команды — мы делали всё, чтобы выпустить качественную фичу, а не качественный продукт. В результате перестали появляться принципиально сильные решения, которые смогут поднять качество продукта на новый уровень.
Пропала компетенция написания автотестов — автотесты стали загибаться и чаще падать без изменения кода. К моменту роспуска команды ручные тестировщики только начинали постигать азы автоматизации. Получилось так, что экспертизы не было ни у тестировщиков, ни у разработчиков. К тому же крупицы экспертизы растерялись, когда люди, которые писали эти тесты, перешли в разработку, управление продуктом, а кто-то уволился.
Мы достоверно не знали какие у нас есть автотесты, что они покрывают, не знали как они развиваются, эволюционируют, добавляются-удаляются — всё было отдано на откуп разработчикам. В итоге, когда нужно было найти какую-то информацию в автотестах, это был тот еще квест, в котором без разработчика не разберешься.
Лишняя работа для разработчиков. Тяжело быть разработчиком. Если раньше они привыкли писать продуктовый код, который «магическим» образом проверяется и уходит на продакшн, то теперь им нужно самим писать тесты, править и стабилизировать. Мы на PBR определяем, какие сценарии должны быть покрыты тестами, а уровень автотестов разработчики выбирают сами.
Разработчики прошли несколько стадий принятия смерти пайплайна.
Отрицание. Все релизы Dodo IS катят разработчики. Они организуют процесс, комуницируют с командой нагрузочного тестирования, смотрят логи и мониторинг во время релиза. Разработчики, которые катили релиз, сталкиваясь с красным тестом, не пытались разобраться в его причине, а просто перезапускали пайплайн, пока он не становился зеленым 5–7–10 раз. Всё потому, что не было доверия к автотестам.
Максимальное количество перезапусков, которые я нашел, — 44 раза!!! Мне кажется, от полного отказа от тестов нас спасло правило которое мы приняли на одном из ретро «Не релизим с красными тестами. Если тест красный — разберись в чём проблема. Если проблема в тестах — почини или заигнорь и сделай карточку на разблокировку теста, и добавь ее в бэклог».
Гнев: разработчики ругались на наши тесты, говорили что они говно нестабильные, плохо написаны, их нужно переделать, выкинуть и переписать (именно в такой последовательности).
Торга и депрессии не было, наступило сразу принятие: разработчики теперь могут сами писать E2E-тесты UI и API, стабилизируют и улучшают их.
Количество багов на проде стало увеличиваться. На продакшн стали просачиваться не критичные баги. На это есть несколько причин:
- Наши автотесты покрывают не весь функционал, а только критически важный. А ручного регрессионного тестирования больше нет.
- На все команды не хватило QA-инженеров. У команд не было компетенций в тестировании, поэтому они не уделяли тестированию должного внимания
В результате мы стали случайно находить баги на продакшн. Они не критичны, но сколько их вообще — не представляли.
Как мы решаем эти проблемы
Возможно, другая команда могла бы предугадать все неочевидные последствия, но мы не смогли. Приняли решение, через несколько месяцев увидели последствия, и стали их устранять.
Создали гильдию QA Ресторана или Community of practice, в которую вошли все QA Ресторана. Цель сообщества — драйвить качество всего продукта, распространять хорошие практики тестирования на все команды продукта. Это образование, которое совмещает в себе преимущества выделенной QA-команды и также мы получаем преимущества от нахождения QA в команде разработки.
Мы встречаемся раз в неделю: делимся результатами, открытиями и планируем совместную работу над качеством. Также выделяем несколько слотов в неделю для работы над задачами гильдии. Например, допиливаем нашего бота-помощника для релизменов.
Дежурство. Гильдия частично закрывает проблему отсутствия овнера качества и автотестов. Но у гильдии нет сильных компетенций в разработке и автоматизации, поэтому наш CTO принял волевое решение и организовал дежурство на пайплайне.
Теперь разработчики могут системно улучшать процесс пайплайна: стабилизировать, находить проблемы, которые задерживают релизы и устранять. Один разработчик из команды разработки на месяц становится владельцем пайплайна и системно улучшает его. Не релизит, а именно улучшает — делает процесс релиза и поддержки тестов легким и непринужденным. Сейчас, когда метрики продукта улучшились, мы избавились от этого дежурного, но в любой момент сможем вернуть. (Пока писал статью, мы вернули его, т.к. заметили начинающуюся деградацию стабильности)
Курсы. Проблему отсутствия компетенций закрываем курсами для ручных тестировщиков и парной работой с разработчиками с опытом в автоматизации.
Лишняя работа для разработчиков. Тут уже ничего не поделаешь, разработчики просто дошли до стадии принятия автотестов. Теперь они сами пишут E2E-тесты, если более низкоуровневыми нельзя покрыть фичу, и стабилизируют пайплайн. Как пишут в умных книжках, это хорошая практика, когда вся команда и разработчики и тестировщики могут писать тесты. Сказывается и наш поход в сторону отпила микросервисов от монолита. В монолите становится меньше тестов, и все больше в отдельных репозиториях, пайплайн становится стабильнее.
Исследуем продукт. Проблемы с багами на продакшн мы решаем тем, что начали исследовать продукт на предмет несоответствий ожидаемому поведению. Мы запланировали еженедельные сессии исследовательского тестирования. И носим баги в бэклог владельцу продукта.
Что бы мы сделали сейчас?
Неспособность учитывать последствия второго и третьего порядка стала причиной плохих решений. Она особенно опасна, когда первый и не лучший вариант закрепляет уже имеющуюся предвзятость. Но сейчас, имея весь полученный опыт, мы бы поступили по-другому.
Например, потерю компетенций, можно было бы решить тем, что за несколько месяцев до перехода людей с компетенцией в автоматизации попросить их расшарить компетенцию на всех QA-инженеров в продукте или разработчикам из команд. А лучше и всем сразу.
Проблему с лишней работой для разработчиков никак не компенсируешь, но можно было бы снизить боль от написания тестов тем, что не ставить перед фактом, а:
- показать ценность тестов в явном виде;
- научить разработчиков эти тесты писать, улучшать и поддерживать;
- сделать переход не таким быстрым (за неделю), а растянуть дольше.
Как научиться предугадывать последствия второго порядка
Когда мы расходились мы даже не подумали об этих проблемах. «Задним числом» кажется, ну как же так, подумать об этом — элементарно. Но «задним умом» мы все крепки — попробуй спрогнозировать будущее.
Последствия второго или третьего порядка для меня, могут быть последствиями первого порядка для более опытных людей, которые уже много раз принимали такие решения и видели результаты таких решений.
Слишком много неопределенности и переменных, влияющих на результаты.
Важно не предугадать последствия, а, как минимум, знать что они могут быть. Прежде чем принимать какое-либо решение важно подумать о том, какие последствия вероятны, почитать информацию о кейсах в других компаниях чтобы хотя бы иметь представление о масштабах возможных неочевидных последствий.
Тот, кто научится предугадывать последствия второго (и даже третьего) порядка любых решений сможет спасти или уничтожить человечество. Или заработать денег больше, чем у Скруджа МакДака — хотя бы на колебаниях цены акций.
Как я теперь буду пытаться предугадывать последствия
Я почитал статьи на эту тему и вывел для себя несколько правил, которые по мнению авторов, помогут предугадывать такие последствия. Попробую ими воспользоваться:
- Прежде чем принять решение — задавать себе вопрос «А что будет дальше?» и добавить к вопросу временные отрезки. Что будет через 10 минут, 10 месяцев или 10 лет?
- Тренировать свое в сторону таких последствий, размышляя над разными ситуациями. Например, какие могут быть последствия первого второго или даже третьего порядка, если весь мир пересядет на электромобили, или, например, введут базовый безусловный доход. В этом упражнении нет правильных ответов, но оно позволит мыслить шире.
- Помнить о том, что первая мысль в голове — это первый порядок. Всегда.
Если вы сталкивались с другими проблемами при смене организации команды тестирования или других команд, напишите в комментарии, будет интересно узнать, с какими проблемами вы сталкивались и как их решали.
P.S. Нам сейчас требуются 2 мобильных QA-инженера в продукт «Открытие стран» и в Дринкит. Мы ищем человека которому не все равно на качество тестируемого продукта и который развивается в автоматизацию. Задач и возможностей полно: можно расти и углубляться в автоматизацию, можно менять процессы и подходы в командах, а можно двигаться в сторону SRE-практик и стать mobile SRE инженером. Все зависит от ваших целей и предпочтений. Если вы хотите у нас работать, пишите в Телеграм: мне (@EvgenSkt) или нашему HR Саше (@alexpanev).
Если хотите узнать, как мы собеседуем и онбордим кандидатов, то оставим ссылки на статьи, где об этом писали: «Собеседование в Додо Пиццу» и «Онбординг разработчиков» (на слово «разработчик» можно не ориентироваться — процесс практически идентичен для всех). А больше узнать о нашей культуре QA, можно в статье «А не фигню ли я опять делаю? Как и зачем внедрять метрики качества».
Наш Телеграм-чат, если захотите обсудить статью и задать вопросы.
Автор: Евгений
