Мы обходимся без армии QA:
как отсутствие тестировщиков экономит время разработчиков и повышает их компетенцию

Внимательно просмотрев штат kt.team, ты не найдёшь у нас ни одного «кликера» или тестировщика по автотестам. Это вовсе не значит, что мы скрываем часть своих сотрудников или отдаём тестирование на аутсорс. Мы действительно отказались от тестировщиков, оставив в штате двоих QA-инженеров. В рамках SCRUM-подхода такая структура не просто имеет право на жизнь — она позволяет выдавать качественный результат.

Так было не всегда.

Как и большинство коллег, мы исповедовали конвейерный подход. Раньше у нас в продуктовой команде тоже были и проджекты, и разработчики, и тестировщики… В общем, все необходимые позиции, которые закрывали этапы разработки проекта.

Но примерно два года назад мы начали переходить на методологию Agile и, в частности, на SCRUM в управлении проектами. Стали постепенно вводить технику test-driven development (TDD). Сейчас мы уже можем подбить статистику и официально заявляем: качество кода от этого не пострадало.

Сложный проект — это всегда запутанный класс систем (об этом мы говорили в одной из предыдущих статей). Давай рассмотрим, как строится работа над ним на «конвейере» и по методологии Agile с точки зрения места разработчика.

Работа над сложным проектом при конвейерном подходе выглядит примерно так.

Дальше понятно. Разработчики пишут код. Тестировщики проверяют разработанное на предмет соответствия задачам и проектной документации. Системные администраторы обеспечивают инфраструктуру.

Многие разработчики и наследники «советской школы» считают этот процесс эталонным.

Кажется, проблем в этой системе быть не должно. Но на деле всё не так просто.

Разработчик не в курсе целей проекта, с позиции «конвейера» ему это «не нужно»: он всё равно не может повлиять на них. Он не развивает компетенции по пониманию бизнес-результата, по обеспечению качества. Он не чувствует ответственности за конечный результат.

Разработчик тут — вариация машинистки. Ему дают хорошо сформулированную и описанную задачу — он «переводит» её на свой язык программирования (PHP, Go, Python — неважно).

Причём неважно, идёт ли речь о джунах или о разработчиках высокой квалификации: на «конвейере» они могут выполнять только свою узкоспециализированную задачу и ничего больше.

В конвейерном подходе тестировщик всегда остаётся внешним человеком, который не погружается в проект или фичу полностью. Код попадает к нему в руки уже в готовом виде и чаще всего — с минимальными пояснениями: почему фича была реализована именно так и зачем такое решение в целом нужно.

Для «прокликивания» и прогона по автотестам, по большому счёту, вникать в ситуацию и не надо. Чистейшей воды monkey business, механическая работа. Не зря фиктивная компания Primate Programming Inc., «предлагавшая» в своё время услуги тестировщиков-шимпанзе, у многих не вызвала сомнений.

Впрочем, вернёмся к тестировщикам. Не вникая в ситуацию, они не смогут раскопать проблемы в нестандартных сценариях, достаточности или недостаточности какого-либо решения. Просто потому что ни знать, ни думать о них они не будут.

В Agile другой подход к задачам. Плоская команда, состоящая (у нас например) из SCRUM-мастера, проджект-менеджера и разработчиков, в которой все, кроме наставника (SCRUM-мастера), занимаются доставкой ценностей проекта. Тестированием также занимается вся команда: разработчики пишут тесты на коды друг друга (кросс-тестирование).

Означает ли это, что разработчики занимаются низкоквалифицированным трудом? Категорически нет. Во-первых, один разработчик не на словах на стендапе, а действительно просматривает, что сделано другими. Его задача — не столько найти изъян, сколько ознакомиться с результатом работы другого человека в проекте.

Люди, находящиеся в контексте всего проекта, принимают лучшие решения, больше осведомлены о бизнес-целях и результатах. Команда включена в проект полностью, принимает более осознанные решения, лучше понимает связь своей работы с результатом.

К тестировщикам, как правило, отношение двоякое. С одной стороны, их принято считать не-совсем-разработчиками, которым не хватило навыков и умений на карьеру полноценного инженера. С другой — именно их назначают крайними, если что-то идёт не так. Негласно, неофициально и не всегда — но такая тенденция есть.

И это самым фатальным образом сказывается как на динамике внутри команды, так и на профессиональных качествах каждого из разработчиков.

Отсюда следует ещё кое-что. Задумывался когда-нибудь, сколько времени разработчика «сжирает» взаимодействие с тестировщиком? Очень много, иногда — до трети!

Как это получается?

Готовый написанный разработчиком код тестируется не сразу: он ждёт, когда наступит его очередь в графике тестировщика (время). Тестировщик прогоняет код по тестам исходя из ТЗ и обнаруживает баги, недочёты, проблемы (ещё время).

Задача возвращается к разработчику. Но: он не сидел и не ждал, когда это произойдёт. Он погрузился в совсем другие задачи. Чтобы устранить недочёты, он должен выдёргивать себя из рабочего процесса, перенастраиваться, заново вникать в проблему. А это — время (снова!), силы и нервы.

После исправлений код опять возвращается на тестирование, и процесс повторяется снова «до победного».

В Agile вопросы качества кода решаются не только кросс-тестированием, о котором мы говорили выше. Есть множество практик, в том числе TDD, Agile-тестирование, роль SCRUM-мастера в процессе. Обо всём этом мы расскажем в следующих статьях.

С бизнесом мы работаем давно и плотно. И знаем одну простую вещь: заказчику неважно количество тестировщиков. И даже тест-кейсы сами по себе ему неважны. Он хочет, чтобы мы обеспечили работающее решение его бизнес-задач. Качественное, гибкое, прозрачное и лучше — в самые короткие сроки.

Agile всё это обеспечивает. Когда разработчик видит конечную цель и выдаёт осознанные решения, а не «перевод ТЗ на язык программирования», не тратит время на бесконечные итерации с тестированием через третьи руки, удаётся добиться поставленных целей гораздо быстрее.

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

Понравилась статья?

Подпишись на нашу рассылку — стань первым, кто узнает о наборе
на обучающие курсы, митапах и новых открытых вакансиях!