Сколько тестировщиков нужно, чтобы выловить все баги на проекте масштаба enterprise? Однозначного ответа никто не даёт. Одни источники считают нормальным соотношение «один тестировщик на 10 разработчиков», другие говорят, что «1:1 — в самый раз» (и то мало).
В рамках методологии Agile, которой придерживаемся мы в kt.team, тестировщиков как отдельной позиции не нужно вообще. Рассказываем, как мы живём и работаем без них и почему отсутствие тестировщика — это благо как для заказчика, так и для разработчика.
Куда они делись?
Внимательно просмотрев штат kt.team, ты не найдёшь у нас ни одного «кликера» или тестировщика по автотестам. Это вовсе не значит, что мы скрываем часть своих сотрудников или отдаём тестирование на аутсорс. Мы действительно отказались от тестировщиков, оставив в штате двоих QA-инженеров. В рамках SCRUM-подхода такая структура не просто имеет право на жизнь — она позволяет выдавать качественный результат.
Так было не всегда.
Как и большинство коллег, мы исповедовали конвейерный подход. Раньше у нас в продуктовой команде тоже были и проджекты, и разработчики, и тестировщики… В общем, все необходимые позиции, которые закрывали этапы разработки проекта.
Но примерно два года назад мы начали переходить на методологию Agile и, в частности, на SCRUM в управлении проектами. Стали постепенно вводить технику test-driven development (TDD). Сейчас мы уже можем подбить статистику и официально заявляем: качество кода от этого не пострадало.
Сложный проект — это всегда запутанный класс систем. Давай рассмотрим, как строится работа над ним на «конвейере» и по методологии Agile с точки зрения места разработчика.
Винтик на большом «конвейере»
Работа над сложным проектом при конвейерном подходе выглядит примерно так.
- Заказчик ставит высокоуровневые задачи на продукт или решение.
- Менеджер проекта их обрабатывает и следит за «конвейером».
- Бизнес-аналитики и системные аналитики перерабатывают требования, пишут кучу документации.
- Тимлид определяет на базе разработанных требований, кто и что будет разрабатывать.
Дальше понятно. Разработчики пишут код. Тестировщики проверяют разработанное на предмет соответствия задачам и проектной документации. Системные администраторы обеспечивают инфраструктуру.
Многие разработчики и наследники «советской школы» считают этот процесс эталонным.
Кажется, проблем в этой системе быть не должно. Но на деле всё не так просто.
Разработчик не в курсе целей проекта, с позиции «конвейера» ему это «не нужно»: он всё равно не может повлиять на них. Он не развивает компетенции по пониманию бизнес-результата, по обеспечению качества. Он не чувствует ответственности за конечный результат.
Единственная задача разработчика — писать свои задачи.
Как они связаны с конечным результатом, с целью проекта, как влияют на работу других разработчиков, почему работа строится именно так, он не понимает: это зона ответственности тимлида и проджекта. Всё, что нужно от разработчика, — «красота кода».
Разработчик тут — вариация машинистки. Ему дают хорошо сформулированную и описанную задачу — он «переводит» её на свой язык программирования (PHP, Go, Python — неважно).
Причём неважно, идёт ли речь о джунах или о разработчиках высокой квалификации: на «конвейере» они могут выполнять только свою узкоспециализированную задачу и ничего больше.
Бонус: место тестировщика на «конвейере»
В конвейерном подходе тестировщик всегда остаётся внешним человеком, который не погружается в проект или фичу полностью. Код попадает к нему в руки уже в готовом виде и чаще всего — с минимальными пояснениями: почему фича была реализована именно так и зачем такое решение в целом нужно.
Для «прокликивания» и прогона по автотестам, по большому счёту, вникать в ситуацию и не надо. Чистейшей воды monkey business, механическая работа. Не зря фиктивная компания Primate Programming Inc., «предлагавшая» в своё время услуги тестировщиков-шимпанзе, у многих не вызвала сомнений.
Впрочем, вернёмся к тестировщикам. Не вникая в ситуацию, они не смогут раскопать проблемы в нестандартных сценариях, достаточности или недостаточности какого-либо решения. Просто потому что ни знать, ни думать о них они не будут.
Agile: когда есть цель
В Agile другой подход к задачам. Плоская команда, состоящая (у нас например) из SCRUM-мастера, проджект-менеджера и разработчиков, в которой все, кроме наставника (SCRUM-мастера), занимаются доставкой ценностей проекта. Тестированием также занимается вся команда: разработчики пишут тесты на коды друг друга (кросс-тестирование).
Означает ли это, что разработчики занимаются низкоквалифицированным трудом? Категорически нет. Во-первых, один разработчик не на словах на стендапе, а действительно просматривает, что сделано другими. Его задача — не столько найти изъян, сколько ознакомиться с результатом работы другого человека в проекте.
Люди, находящиеся в контексте всего проекта, принимают лучшие решения, больше осведомлены о бизнес-целях и результатах. Команда включена в проект полностью, принимает более осознанные решения, лучше понимает связь своей работы с результатом.
Пара слов о потерянном времени
К тестировщикам, как правило, отношение двоякое. С одной стороны, их принято считать не-совсем-разработчиками, которым не хватило навыков и умений на карьеру полноценного инженера. С другой — именно их назначают крайними, если что-то идёт не так. Негласно, неофициально и не всегда — но такая тенденция есть.
И это самым фатальным образом сказывается как на динамике внутри команды, так и на профессиональных качествах каждого из разработчиков.
Привычка к тому, что кто-то «подтирает» ошибки, расхолаживает. Не выловил проблемы сам? Ничего, придёт тестировщик и найдёт всё, что только можно найти.
Отсюда следует ещё кое-что. Задумывался когда-нибудь, сколько времени разработчика «сжирает» взаимодействие с тестировщиком? Очень много, иногда — до трети!
Как это получается?
Готовый написанный разработчиком код тестируется не сразу: он ждёт, когда наступит его очередь в графике тестировщика (время). Тестировщик прогоняет код по тестам исходя из ТЗ и обнаруживает баги, недочёты, проблемы (ещё время).
Задача возвращается к разработчику. Но: он не сидел и не ждал, когда это произойдёт. Он погрузился в совсем другие задачи. Чтобы устранить недочёты, он должен выдёргивать себя из рабочего процесса, перенастраиваться, заново вникать в проблему. А это — время (снова!), силы и нервы.
После исправлений код опять возвращается на тестирование, и процесс повторяется снова «до победного».
В итоге разработчик постоянно переключается туда-сюда между задачами и не может нормально погрузиться в решение проблем.
Спрашивается, а как же многозадачность? А многозадачность убивает когнитивный навык глубокого погружения в проблему и приводит к неспособности фокусироваться.
Качество без тестировщиков — это не миф
В Agile вопросы качества кода решаются не только кросс-тестированием, о котором мы говорили выше. Есть множество практик, в том числе TDD, Agile-тестирование, роль SCRUM-мастера в процессе. Обо всём этом мы расскажем в следующих статьях.
Андрей , генеральный директор kt.team
«Строго говоря, разработчики у нас не кодеры, а инженеры. Их уровень таков, что они объективно могут проверить свою работу и работу коллег при кросс-тестировании. И даже те, кто приходит к нам из других парадигм, перестраиваются под нашу систему работы относительно быстро.
Тестировщик в Agile-команде фактически не нужен, только наставник по качеству — QA-инженер. Тот, кто будет регулярно смотреть на проект и давать оценку прошедшим мероприятиям: наличие тестов, скорость работы, наличие инцидентов и их тип. Он способен посмотреть на задачу новым взглядом, провести аудит. И не просто выявить проблемные места, а взять на себя функцию наставника и предложить решение.
QA-инженер сотрудничает со всеми проектными командами. Он знает, как каждая из них решает возникающие проблемы, и может распространить успешную практику на другие команды и проекты».
Вывод
С бизнесом мы работаем давно и плотно. И знаем одну простую вещь: заказчику неважно количество тестировщиков. И даже тест-кейсы сами по себе ему неважны. Он хочет, чтобы мы обеспечили работающее решение его бизнес-задач. Качественное, гибкое, прозрачное и лучше — в самые короткие сроки.
Agile всё это обеспечивает. Когда разработчик видит конечную цель и выдаёт осознанные решения, а не «перевод ТЗ на язык программирования», не тратит время на бесконечные итерации с тестированием через третьи руки, удаётся добиться поставленных целей гораздо быстрее.
И, что не менее важно, гораздо быстрее происходит личный и профессиональный рост самого разработчика. Потому что осознанное решение задач помогает не только развивать использование языков программирования и наращивать стек, но и приобретать навыки проектирования, управления, понимания бизнеса и лучше понимать другие части своего проекта.
