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

Логотип компании
Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?
Мировые лидеры ИТ-рынка не используют тестировщиков. Хедлайнеры не верят, что привлечение тестировщиков по умолчанию добавляет качественную ценность программному обеспечению.

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

Мы привыкли к маркировке Q.A. Passed на разной электронике и ожидаем, что с ИТ-продуктами контроль будет работать так же. Но разработка — не конвейерное производство. Мировой опыт (и опыт ИТ-интегратора kt.team) говорит о том, что в запутанных средах критерии оценки определяются для каждой фичи — это явно выходит за пределы компетенции обычных тестировщиков. С их привлечением размывается ценность продукта, растут его себестоимость и сроки разработки, внутри команды начинаются конфликты из-за неправильно разделенной ответственности. Разберем детально, почему так происходит.

Тестирование в запутанной среде

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

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 1

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

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

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 2

Впрочем, это слова. А как это выглядит в жизни?

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

1.

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 3

2.

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 4

3.

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 5

Почему такой расклад не идёт на пользу ни разработчику, ни тестировщику, ни продукту?

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

Неявная ответственность за продукт

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

Неизбежная бюрократия

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

Постоянное переключение между задачами

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

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

Потеря связи с пользователем

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

Почему в Google нет тестировщиков?

Прагматичный ИТ-сервис в стиле Google: почему в запутанных средах использование тестировщиков идет во вред продукту?. Рис. 6

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

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

To test or not to test?

Исходя из опыта компании kt.team, оптимальный вариант построения процесса — такой, когда разработчик:

  • изначально думает о ценности, а не о коде;

  • покрывает код тестами и

  • беспокоится о наиболее высокой скорости сбора обратной связи через логирование и дашборды.

Это проверенный практикой и работающий способ избежать масштабного отказа.

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

  • парное программирование;

  • test driven development (тесты пишутся разработчиками до кода);

  • непрерывная интеграция;

  • рефакторинг

и другие.

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

Когда тестировщики нужны?

Не буду утверждать, что тестировщики в запутанных средах не нужны вообще никогда. Есть ситуации, в которых без Q.A. в команде не обойтись.

Процесс тестирования специфичный

Например, при создании мобильного приложения. Есть множество платформ и вариантов устройств, на которых приложение должно корректно работать. Разработчик может протестировать его работоспособность на нескольких основных платформах и устройствах, но «прогонять» его по всем только силами разработчика не имеет смысла.

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

Не стоит спихивать на Q.A. тестирование под популярные браузеры: функциональные тесты справляются с такими задачами намного эффективнее. К тому же сейчас не 2010 год, нет никакой проблемы, если в какой-то версии редкого браузера поплывет кнопка. Да и автоматизированные средства попиксельного DOM-анализа под любые браузеры есть в легком доступе.

Нужно настроить процессы тестирования в компании

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

Тестировщик необходим по требованиям безопасности или законодательства

Есть узкие области разработки, которые строго регламентируются особенностями законодательства или особыми требованиями безопасности.

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

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

Такие специалисты — ювелиры в своем деле. В работе им очень помогает наличие в компании сложившейся культуры и эталона для оценки экспертизы разработчиков.

Опубликовано 12.10.2022

Похожие статьи