Должны ли разработчики тестировать свой код

Почему команды всё чаще доверяют тестирование разработчикам и где в этом подходе скрываются риски для продукта.

В QA есть одна вечная тема, которая так или иначе периодически всплывает на каждом втором проекте. Кто должен тестировать продукт? Когда-то в начале развития отрасли все казалось проще простого – разработчик пишет код, а QA проверяет. Баги находятся, фиксятся, проект выходит в люди. Классическая схема и почти уютная. Такое аккуратное «перекидывание кода через забор»: девелопер дописал фичу, кинул в тестирование, пошёл писать следующую. Но индустрия давно ускорилась и релизы стали чаще, а CI крутится круглосуточно. И в какой-то момент кто-то вбросил: а почему разработчик не может проверить свой код сам? Упс. И понеслось…

На словах вброс-вопрос звучит вполне разумно. Более того, иногда ткая схема проверки реально работает. Я работала на проектах, где разрабы активно тестировали собственные фичи, и это давало отличный результат. При этом никто не отменял, что у медали вообще-то две стороны. И вот вторая сторона вам не понравится, потому что подход «разраб сам тестирует» не всегда правильный. Если говорить более точно, то он и не «неправильный», он – нуждающийся в балансе. Проскочить в подобном случае точку невозврата ну очень легко.

Когда разработчик тестирует свой код

...случается  довольно прозаичная, но крутая штука. Давайте начнём с хорошего и посмотрим на плюсы модели работы. Они же есть и иногда очень серьёзные.

• Моментальный фидбек. Это самый очевидный бонус. Разработчик только-только написал кусок логики. Контекст еще в голове и поэтому когда он запускает тесты или быстро прогоняет сценарии, то ловит баг без напряга и сразу. Никаких задержек, очередей задач QA или сборки на тестовом стенде. Прямо здесь и сейчас.

Любая команда, которая хотя бы немного работала с CI/CD, знает, чем раньше поймали дефект, тем дешевле его исправить. Когда я только пришла в тестирование, мне повезло работать с разработчиками, которые исправно писали юнит-тесты и проверяли основные сценарии. Тогда мне казалось, что они нас «объедают», потому что до команды QA (то есть до нас) баги доходили гораздо реже. И если доходили, то обычно уже как раз те, над которыми приходилось поломать голову, интересные, а не банальные null (NPE).

• Код становится чище. Это как забавный побочный эффект. Хотя я точно знаю нескольких специалистов, которые скажут, что нет такого и вообще как мы могли такое написать 🙂 И тем не менее…когда разработчик знает, что ему самому писать тесты, внезапно оказывается, что писать тестируемый код гораздо удобнее. Появляются нормальные интерфейсы, декомпозиция логики, понятные зависимости, меньше монолитных функций на сотни строк.

Если код невозможно протестировать, значит с архитектурой что-то пошло не так, и разработчик начинает это видеть первым. В хорошем смысле тесты дисциплинируют.

• Быстрее движутся небольшие проекты. Признаться, на маленьких продуктах или стартапах это вообще может быть спасением. Бывает (к сожалению или счастью) команда из трёх разработчиков и на них один QA (не дай богоскрипт!) на полставки. Релизы каждую неделю.

В такой ситуации базовое тестирование разработчиками дает возможность не тормозить поток задач. Девелоперы проверяют свои фичи, QA концентрируется на более сложных сценариях. Работает оно довольно неплохо. До определённого момента, конечно. Но это уже слегка другой разговор.

А потом начинаются слепые зоны

Я очень люблю разработчиков. Серьезно. Без них у нас не было бы работы. Но есть одна фундаментальная проблема. Суть ее в том, что мы (разработчик и тестировщик) смотрим на систему совершенно по-разному. И дело тут не в компетенции, а в мышлении.

Туннельное зрение

Разработчик проверяет, работает ли его логика. QA проверяет, как её можно сломать. Это две разные задачи. Когда девелопер тестирует свой код, он почти всегда идёт по happy path. По самому правильному сценарию использования. Ну какой пользователь так делает? Тестировщик играет роль пользователя и начинает задавать неприятные вопросы…

• а что если пользователь нажмёт кнопку пять раз подряд?
• а если запрос придёт дважды?
• а если поле будет пустым?
• а если данные сломанные?

Разработчик редко думает в этой плоскости, потому что его мозг занят другой задачей. Ни в коем случае не потому что не может. Просто он строит систему, а тестировщик пытается её разрушить. Наши роли именно поэтому разделились исторически.

Контекстные переключения

Есть ещё одна проблема, которую редко обсуждают, это переключение контекста. Создатель кода пишет код. Это состояние созидания. Нужно держать в голове архитектуру, зависимости, бизнес-логику. А наша работа, то есть тестирование, требует противоположного мышления. Нужно искать уязвимости, странные сценарии, крайние случаи, ломать в общем… Можете себе представить одного человека, который постоянно прыгает между этими режимами? Там, где разработчики обязаны написать фичу, покрыть её тестами, прогнать тестирование, пройти регрессию, в итоге упадет скорость разработки. Ну и глубина тестирования останется под вопросом.

Иллюзия безопасности

Вот уж точно самый опасный эффект. Вдруг кому-то из руководства приходит гениальная мысль (фея Динь-Динь наколдовала, видимо): разработчики пишут тесты, значит отдельный QA не нужен. Доводят эту мысль до подчиненных, те красиво оформляют на бумаге план работ и назначают исполнителей. Ну а что? Все красиво. Есть юнит-тесты, есть CI, билды зелёные. А дальше продукт выходит в прод и оказывается (ну надо же!), что никто не проверял пользовательские сценарии, не проводил исследовательское тестирование, не смотрел на систему глазами реального пользователя.

Юнит-тесты проверили анкерные гайки на фюзеляже. Но никто не проверил, летит ли самолёт.

Когда автоматизация начинает тормозить разработку

Отдельная история, которую я наблюдала на нескольких проектах, где руководство слишком близко к сердцу восприняло популярную мантру «автоматизируйте всё, что автоматизируется». Красоту звучания оставлю оценить любителям, но сразу скажу, что в реальности автоматизация иногда все-таки начинает работать против команды. Только сначала это кому-то кажется идеальной стратегией: юнит-тесты, интеграционные проверки, UI-тесты, длинные пайплайны CI. А потом тестов становится столько, что они начинают мешать разработке. CI собирается по полчаса, часть тестов падает без причины. Разработчики тратят время не на код (они его любят больше, признаем честно), а на перезапуск пайплайнов и поиск, какой из кейсов снова «флакнул» (а это они не очень любят).

И вот хваленая автоматизация "почему-то" перестаёт быть ускорителем процесса и превращается в ещё один источник технического долга. Это отдельная большая тема, достойная целой статьи. Поэтому мы обязательно еще разберем, почему тестовая автоматизация иногда начинает тормозить разработку и как команды в итоге чинят свои CI-пайплайны. Ну и конечно, соберем важные сигналы, которые помогут вам понять, что процесс пошёл не туда.

Где же проходит граница

За годы работы на разных проектах я пришла к довольно простому выводу. Лучше всего работает разделение ответственности. Это сложно, но можно.

Не война ролей. А именно баланс.

Зона разработчика. Он отлично справляется с юнит-тестами, проверкой бизнес-логики, базовыми интеграциями, поддержкой зелёного билда в CI. Это его территория, его владения. И когда команда это все делает, качество системы реально растёт.

Зона QA. Есть вещи, которые почти всегда требуют отдельного взгляда. Тестировщик занимается тем, что разработчик просто не видит: сложные пользовательские сценарии, негативные кейсы, исследовательское тестирование, UX-проблемы, интеграции между системами, нестандартные сценарии поведения. QA смотрит на продукт без привязки к тому, как он был реализован. И в этом огромная ценность.

В итоге

Разработчик, который вообще не тестирует свой код, сегодня выглядит странно. Но разработчик, который полностью заменяет QA, почти всегда приводит проект к проблемам. Лучший результат можно получить, если обе роли работают вместе. Разработчик следит, чтобы его участок системы был надёжным, а QA проверяет, как ведёт себя продукт целиком. И иногда именно на этой границе происходит самый настоящий прорыв — и для специалистов, и для проекта, и для бизнеса.

Когда код становится чище, баги ловятся раньше, а продукт выходит в прод без сюрпризов. Ну или почти без них. В IT идеала все равно не бывает, но стремиться к нему нужно, согласны?