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

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

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

Менеджер проекта их обрабатывает и следит за «конвейером».

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

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

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

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

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

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

Привычка к тому, что кто-то «подтирает» ошибки, расхолаживает.

Не выловил проблемы сам? Ничего, придёт тестировщик и найдёт всё, что только можно найти.

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

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

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

Задача возвращается к разработчику. Но: он не сидел и не ждал, когда это произойдёт.

Он погрузился в совсем другие задачи.

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

После исправлений код опять возвращается на тестирование, и процесс повторяется снова «до победного». В итоге разработчик постоянно переключается туда-сюда между задачами и не может нормально погрузиться в решение проблем. Спрашивается, а как же многозадачность? А многозадачность убивает когнитивный навык глубокого погружения в проблему и приводит к неспособности фокусироваться.

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

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

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

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

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

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

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

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

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