Прагматичный IT-сервис в стиле Google: почему в запутанных средах использование тестировщиков идёт во вред продукту

«Запутанные среды» — это понятие из фреймворка Кеневин, который делит все среды на четыре типа: простые, сложные, запутанные и хаотичные.

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

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

Однажды в IT-компании…

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

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

Требования к результату меняются в каждом Agole-цикле и в каждой фиче. Чтобы избежать конфликтов, нужно написать критерии оценки к каждой фиче. А это приводит к чудовищному росту бюрократии и времени на разработку регламента. На продукт и у разработчика, и у тестировщика останется гораздо меньше времени.

Проведите небольшой эксперимент, описанный в книге «Фокус». Сначала последовательно напишите «мама мыла раму», а потом попытайтесь писать эти слова параллельно: «м… м… р…», «ма. мы. ра.» и т. д. На какой вариант уйдёт больше времени и сил?

В разработке то же самое. Когда Пете прилетели баги по задаче X («ма.»), он уже с головой погрузился в задачу Z («ра.»). Ему пришлось вспомнить свой код, дописать («мам.») его или оспорить исправления и опять вернуться в текущую задачу («рам.»). На одни переключения он потратит больше времени, чем на работу с задачей.

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

Мировые лидеры IT-рынка не используют тестировщиков. На примере компаний MAANG: Meta* (запрещена в РФ), Apple, Amazon, Netflix, Google — мы видим отношение к идее конвейерного тестирования как к устаревшей концепции. Хедлайнеры не верят, что привлечение тестировщиков по умолчанию добавляет качественную ценность программному обеспечению. Например, в книге «Как Google тестирует программное обеспечение» авторы указывают, что Feature Developers имеют все необходимое для самостоятельной доставки качественной ценности, а так называемые Software Engineers in Test устарели. Google пишет о продуктовых IT-компаниях, но и в практике сервисных компаний, которые работают по Agile, действует та же логика.

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