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

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

Заказчик ставит высокоуровневые задачи на продукт или решение. 2.

Менеджер проекта их обрабатывает и следит за «конвейером». 3. Бизнес-аналитики и системные аналитики перерабатывают требования, пишут кучу документации. 4.

Тимлид определяет на базе разработанных требований, кто и что будет разрабатывать.

Тестировщики проверяют разработанное на предмет соответствия задачам и проектной документации.

Системные администраторы обеспечивают инфраструктуру.

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

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

Он не развивает компетенции по пониманию бизнес-результата, по обеспечению качества.

Он не чувствует ответственности за конечный результат.

Единственная задача разработчика — писать свои задачи.

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

Разработчик тут — вариация машинистки.

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

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

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

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

Для «прокликивания» и прогона по автотестам, по большому счёту, вникать в ситуацию и не надо.

Чистейшей воды monkey business, механическая работа.

Не зря фиктивная компания Primate Programming Inc., «предлагавшая» в своё время услуги тестировщиков-шимпанзе, у многих не вызвала сомнений. Впрочем, вернёмся к тестировщикам.

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

Просто потому что ни знать, ни думать о них они не будут.

Плоская команда, состоящая (у нас например) из SCRUM-мастера, проджект-менеджера и разработчиков, в которой все, кроме наставника (SCRUM-мастера), занимаются доставкой ценностей проекта.

Тестированием также занимается вся команда: разработчики пишут тесты на коды друг друга (кросс-тестирование).

Означает ли это, что разработчики занимаются низкоквалифицированным трудом?

Категорически нет. Во-первых, один разработчик не на словах на стендапе, а действительно просматривает, что сделано другими.

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

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

В Agile вопросы качества кода решаются не только кросс-тестированием, о котором мы говорили выше.

Есть множество практик, в том числе TDD, Agile-тестирование, роль SCRUM-мастера в процессе.

Обо всём этом мы расскажем в следующих статьях.

Генеральный директор kt.team «Строго говоря, разработчики у нас не кодеры, а инженеры.

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

Тестировщик в Agile-команде фактически не нужен, только наставник по качеству — QA-инженер. Тот, кто будет регулярно смотреть на проект и давать оценку прошедшим мероприятиям: наличие тестов, скорость работы, наличие инцидентов и их тип.

Он способен посмотреть на задачу новым взглядом, провести аудит. И не просто выявить проблемные места, а взять на себя функцию наставника и предложить решение. QA-инженер сотрудничает со всеми проектными командами.

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

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

Он хочет, чтобы мы обеспечили работающее решение его бизнес-задач. Качественное, гибкое, прозрачное и лучше — в самые короткие сроки. Agile всё это обеспечивает.

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

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