Прагматичный IT-сервис в стиле Google

почему в запутанных средах использование тестировщиков идёт во вред продукту

15.2.2023

Содержание

Принято считать, что серьезной IT-компании не обойтись без отдела тестирования. Сегодня мы разберёмся: так ли это?

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

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

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

To test or not to test?

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

Статья опубликована в журнале IT-world

Redirector

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

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

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

rus: Проблемы роста компании. Стадия стартапа

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

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

rus: Проблемы роста компании. Стадия стартапа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rus: Проблемы роста компании. Стадия стартапа

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

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

To test or not to test?

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

  • Парное программирование
  • Test driven development (тесты пишутся разработчиками до кода)
  • Непрерывная интеграция
  • Рефакторинг и другие.

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

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

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

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

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

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

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

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

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

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

К тому же, сейчас не 2010 год, нет никакой проблемы, если в какой-то версии редкого браузера поплывёт кнопка. Да и автоматизированные средства попиксельного DOM-анализа под любые браузеры есть в легком доступе.

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

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

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

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

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

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

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

Другие статьи

Смотреть все

Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce

Подробнее

Правда ли, что low-code нельзя применять в enterprise-решениях

Подробнее

Продуктовый подход в аутсорс-разработке. Закулисье работы в крупном IT-интеграторе. Часть 1

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок

Ваша заявка отправлена успешно

Отправить снова

Ready to help you with your project

You'll be contacted by your personal manager

Contacts