редакции Выбор
Полгода без тестировщика
Тестировщики нужны, чтобы не было багов. Тестировщик спасает софт от погружения в пучину безумия, без него не построить качественный продукт. Без тестировщика команда обречена постоянно тушить пожары на проде, софт будет глючным. Один человек спасает команде много времени и нервов, а компании экономит кучу денег.
Ведь так?

Кто мы такие? Мы — команда в крупной финтех-компании, отвечаем за небольшую часть сервисов, на которых работают продукты с миллиардным оборотом. Из фронтенда у нас только админка, остальные фронты живут в других командах и вызывают наши сервисы через REST API или асинхронно. Я — не очень опытный тимлид команды.
Как мы жили, от чего страдали
Давайте сначала расскажу, чего нам спокойно не сиделось и зачем мы вообще затеяли наш эксперимент.
Как мы релизили
До начала эксперимента мы релизили софт так, как в 2010-е было мейнстримом в средних и крупных компаниях. Опишу в двух словах для понимания.
- Релиз планируем заранее, составляем список задач на релиз, и по мере выполнения задач тестировщик проверяет их на тестовом стенде.
- Когда сделали все задачи, входящие в релиз, делаем код фриз — например, в виде релизной ветки. В неё перестаёт попадать код по более новым задачам.
- Чтобы выкатить релиз, тестировщик делает регресс, фиксятся найденные баги.
- После выкатки тестировщик делает смоук тесты, а остальные сидят наготове, чтобы фиксить проблемы, возникающие после релиза.
Релиз у нас был каждые 1-2 месяца.
Что с этим было не так
В каждый релиз входит много изменений, поэтому релиз надо тщательно проверить. А после релиза часто находятся баги, которые надо пофиксить и... выпустить ещё один релиз с фиксами.
Выпуск релиза — это танцы с бубнами на несколько дней, в которых участвует вся команда. Кто-то второпях доделывает последние задачи релиза, кто-то спешно фиксит баги по сделанным задачам, тестировщик оперативно всё это успевает проверять и после этого уходит делать регресс всей системы.
Релизиться часто не хочется — много накладных расходов. Поэтому заказчик задачи частенько ждёт несколько недель релиза, вместо того, чтобы пользоваться фичой, которая уже готова.
Код может висеть месяцами, не добираясь до прода. Висят как не очень востребованные фичи, так и некритичные фиксы. Например, один раз я разбирал проблему на проде и увидел, что в логах не хватает информации, чтобы понять, что происходит. Добавил логов, залил. Через месяц делаю разбор похожей проблемы — а нужных логов до сих пор нет.
Часто релизы задерживаются. Сначала определяют дату релиза, но по мере её приближения релиз несколько раз сдвигается — на день, потом ещё на 2, потом ещё...
Просто кто-то не успел сделать свою задачу в срок, заболел или взял отгул на пару дней. А кто-то никак не может перекинуть свою задачу через тестирование, потому что она постоянно возвращается с новыми и новыми багами. Если в релиз вошла задача, где есть изменения сразу по нескольким сервисам, то тут вообще пиши пропало. Чаще всего изменения по таким задачам не обратно совместимы — новая версия одного сервиса не будет работать со старой версией другого. Поэтому требуется релизить несколько сервисов одновременно. Чаще всего для этого сервисы гасят, обновляют и синхронно стартуют на обновлённой версии. То есть появляется даунтайм, и это нифига не круто. Если перед релизом такой задачи во время регресса в одном (или не одном) из сервисов нашли баг, то блокируются релизы всех этих сервисов. Если мы находим баг в одном из сервисов уже после релиза, то откатить мы можем либо все сервисы сразу, либо никого. Часто остаётся только героически фиксить проблему за минимально возможный срок, оставаясь после работы. И каждую минуту, пока баг не исправлен, растёт ущерб пользователям и компании, а давление на команду ощущается прямо физически. Команда, понятно дело, стрессует, и это негативно влияет на мораль и производительность как на ближайшие дни, так и в долгосрок. Говорят, в гугле большинство команд работают без тестировщиков. Сервисы проверяются автоматическими тестами, а если баг проскакивает на прод, то его просто исправляют и дописывают тесты. Релизы делают чуть ли не на каждую задачу, и выпуск релиза не требует участия человека, всё делается в пайплайне. Получается, если у вас нет тестировщика, то вы не обязательно отсталая компания с ужасным качеством и плохими процессами. Может быть наоборот — вы передовая компания с самыми современными подходами :) Мы подумали: «А чем мы хуже гугла?» И решили тоже так попробовать. Мы сделали так: У вас, наверное, сразу возникли возражения и вопросы, примерно такие: У нас у самих возникали все эти мысли. Нам как раз было интересно проверить, оправданы ли эти опасения на самом деле, или это всё шаблоны и обычный страх неизвестного. В противовес у нас были и положительные гипотезы: В общем, мы были готовы к разному эффекту. Мы договорились об изменениях и попробовали. Что у нас получилось на самом деле? Давайте сначала послушаем, как это пережили в команде и какие у ребят впечатления. Я задал команде 4 вопроса: В среднем получается: Мы не увидели просадки в качестве. Метрики показывают, что количество багов на проде осталось таким же, а число багов, найденных на тестовых средах, неожиданно сократилось в 2 раза. Скорее всего багов тестирования стало меньше, потому что разработчики стали, во-первых, находить большую часть багов во время разработки задачи, а во-вторых, потому что разработчики не всегда заводят баги, когда замечают проблему самостоятельно на тестовом стенде до релиза в прод. Тем не менее, качество работы прода нас устроило, по нашей оценке оно не снизилось. За полгода у нас было 2 блокер-инцидента, но они произошли бы даже при наличии тестировщика, их причина была в изменении конфигурации инфраструктуры в облаке. Что касается скорости разработки, то она понизилась, по моим оценкам процентов на 20. Это если мерять по времени нахождения тикета в статусах «разработка» и «ревью». Но здесь надо учитывать ещё и другие затраты времени, которые раньше случались уже после окончания разработки: тестировщик теперь не приходит к разработчикам с вопросами и багами дни и недели спустя после того, как задача залита в мастер. Цикл обратной связи теперь короче за счёт хорошего покрытия тестами, плюс разработчик хорошо покрывает ими и свою текущую задачу, что сразу подсвечивает большинство проблем и позволяет их исправить ещё до того, как код уйдёт дальше. В целом такой подход к тестированию мне показался более технологичным и интересным, и в нём определённо есть полезное зерно. Но не все эффекты, которые мы пронаблюдали, были классными. Хотелось бы скорректировать нашу работу по итогу — оставить всё, что нам понравилось, и постараться убрать то, что мешает. Обсудили и пришли примерно к таким вещам: Что оставляем: Что хотим поменять: Так мы поняли, что нам в команде всё-таки нужен тестировщик. Просто ручным регрессом он заниматься практически не должен, не больше пары-тройки дней в месяц. А в чём он реально был бы полезен, так это в исследовательском тестировании, чтобы помочь выявить те проблемы, которые не так очевидны. И очень мог бы помочь прокачать автотесты, чтобы у них росло покрытие, но они оставались при этом быстрыми и гибкими. Возможно уже на следующей неделе к нам выйдет тестировщик, которого мы и позвали в команду помочь с этими вещами. Через какое-то время после начала эксперимента мне нужно было усилить команду разработчиками. Нет, не из-за того, что половина разработчиков уволились после таких изменений :) Вакансии были предусмотрены ещё до начала эксперимента, никто не увольнялся :) Так вот, я оказался в интересной ситуации. На собесах кандидаты спрашивают: «Расскажите про состав команды, про процессы». А я отвечаю: «Кстати да, мы живём без тестировщика, но это не плохо, это мы сами от него отказались, и вообще это не баг а фича, и мы не отсталые, а наоборот такие прогрессивные». Мне самому казалось, что потенциальных разработчиков будет отпугивать отсутствие тестировщика, а идея, что можно жить и без него, ассоциируется скорее с отсталыми конторами, где говнокод, авралы, нет кофе-машины в офисе и всё остальное :) Мне казалось, что слишком мало разработчиков на текущий момент пробовали жить так, как живём мы, и я сомневался, воспримут ли они это с позитивом. Тем не менее, я закрыл все вакансии классными спецами. И решил спросить их о том, какое впечатление на собеседовании производила наша схема работы: В целом получается, что привлекательность вакансии может быть даже выросла. Влияние на онбординг противоречивое, нужно больше точек данных :) Тут конечно стоит учитывать ошибку выжившего — те, кто «не купил» идею, что работать как мы — это круто, наверное просто не пошёл на наши позиции. Суммируя наш опыт, вам стоит пробовать перейти на автоматический регресс, если: И да, совсем прощаться с тестировщиком не обязательно, это, наоборот, хорошая возможность вытащить его из бесконечного регресса и дать возможность прокачать скилы в автоматизации. Автор: Дмитрий Литвин, Максилект P. S. Многие вещи я упомянул в статье только вскользь, иначе она была бы ещё в 3 раза больше. Если интересно о чём-то узнать подробнее, спрашивайте в коментах. Отвечу на что смогу, или сделаю мини-статью, если тема большая. Мне интересно делиться опытом и сравнивать его с вашим, так можно узнать много интересного. P. P. S. Привет всем из команды и компании, кому история из статьи уже знакома :) Я специально не стал указывать, о какой компании речь, ибо пишу не чтобы попиарить компанию, а просто от себя, чтобы поделиться практикой и обсудить впечатления от такого подхода. Велкам в комменты!
Релизы задач, затрагивающих несколько сервисов сразу
А давайте как в гугле
Ну вы ребята крейзи
Результаты
Мнение команды
Мнение лида (моё)
Кстати, насчёт найма
Итоги