# Почему в Google нет отдела QA Canonical: https://www.kt-team.ru/blog/why-google-has-no-qa Source: https://www.kt-team.ru/blog/why-google-has-no-qa Canonical URL: https://www.kt-team.ru/blog/why-google-has-no-qa Original URI: /blog/why-google-has-no-qa ## SEO / GEO Metadata - Title: Почему в Google нет отдела QA: подходы к обеспечению качества в разработке - Description: Как Google строит процессы обеспечения качества без выделенного отдела QA: роль разработчиков, автоматизация тестирования и организационные практики - Canonical: https://www.kt-team.ru/blog/why-google-has-no-qa - Robots: not specified - Open Graph tags: 4 - Twitter tags: 4 - JSON-LD blocks: 2 ## Layout Blocks ### ИИ / AI AI решения инструменты кейсы карьера +7 (495) 204-14-33 Стать клиентом --- ### Прагматичный IT-сервис в стиле Google Прагматичный IT-сервис в стиле Google почему в запутанных средах использование тестировщиков идёт во вред продукту 15.2.2023 Принято считать, что серьезной IT-компании не обойтись без отдела тестирования. Сегодня мы разберёмся: так ли это? ‍ Тестирование в запутанной среде Почему такой расклад не идёт на пользу ни разработчику, ни тестировщику, ни продукту? Почему в Google нет тестировщиков To test or not to test? Когда тестировщики нужны ‍ Статья опубликована в журнале IT-world Время на прочтение: 6 мин. Принято считать, что серьезной IT-компании не обойтись без отдела тестирования. Воплощая принцип разделения труда, тестировщики более эффективно вылавливают баги, разгружают разработчиков, повышают качество продукта и его ценность. Мы привыкли к маркировке Q.A. Passed на разной электронике и ожидаем, что с IT-продуктами контроль будет работать так же. Но разработка — не конвейерное производство. Мировой опыт (и опыт IT-интегратора kt.team в том числе) говорит о том, что в запутанных средах критерии оценки определяются для каждой фичи — это явно выходит за пределы компетенции обычных тестировщиков. С их привлечением размывается ценность продукта, растёт его себестоимость и сроки разработки, внутри команды начинаются конфликты из-за неправильно разделенной ответственности. Разберу детально, почему так происходит. Тестирование в запутанной среде «Запутанные среды» — это понятие из фреймворка Кеневин, который делит все среды на четыре типа: простые, сложные, запутанные и хаотичные. В линейных (простых и сложных) средах тестировщикам достаточно строго следовать регламенту. Там всё понятно: достаточно сверить план и факт, «прозвонить детали» или воткнуть прибор в розетку. Результат тестирования однозначен, продукт либо соответствует регламенту, либо нет. Но в запутанной среде всё не так. В ней нет финального результата и фиксированного пути, по которому этот результат достигается. Нет стандарта приемлемого и отличного результатов — только вектор развития. Типичные для тестирования критерии оценки не совпадают с фундаментальными принципами Agile, которые наиболее эффективны в запутанной среде. В запутанной среде на первый план выходит реакция на изменения и обратную связь, а не регламент. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Впрочем, это слова. А как это выглядит в жизни? Однажды в IT-компании… ‍ Почему такой расклад не идёт на пользу ни разработчику, ни тестировщику, ни продукту? Они оба поставлены в условия, когда качество результата уходит на второй план и конфликты неизбежны. Вот факторы, которые их провоцируют. Неявная ответственность за продукт Плохо, если разработчики начинают думать, что их задача — поставлять код, а не ценность. В кейсе выше, с разработчиком Петей и тестировщиком Витей, Ю о ценности не думает ни один из них: разработчик думает про количество фич, а тестировщик — про количество багов. Интересы бизнеса остаются за пределами процесса. Неизбежная бюрократия Требования к результату меняются в каждом Agole-цикле и в каждой фиче. Чтобы избежать конфликтов, нужно написать критерии оценки к каждой фиче. А это приводит к чудовищному росту бюрократии и времени на разработку регламента. На продукт и у разработчика, и у тестировщика останется гораздо меньше времени. Постоянное переключение между задачами Проведите небольшой эксперимент, описанный в книге «Фокус». Сначала последовательно напишите «мама мыла раму», а потом попытайтесь писать эти слова параллельно: «м… м… р…», «ма. мы. ра.» и т. д. На какой вариант уйдёт больше времени и сил? В разработке то же самое. Когда Пете прилетели баги по задаче X («ма.»), он уже с головой погрузился в задачу Z («ра.»). Ему пришлось вспомнить свой код, дописать («мам.») его или оспорить исправления и опять вернуться в текущую задачу («рам.»). На одни переключения он потратит больше времени, чем на работу с задачей. Потеря связи с пользователем Когда разработчик не держит в голове вариант ошибки или трудности, с которыми может столкнуться пользователь, он не может их предусмотреть. Поэтому разработчик Петя, полностью переложивший на своего тестировщика мысли о том, как пользователь будет взаимодействовать Пока Витя пытается посмотреть на фичу глазами пользователя, Петя теряет связь с реальностью. Почему в Google нет тестировщиков Мировые лидеры 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-анализа под любые браузеры есть в легком доступе. Нужно настроить процессы тестирования в компании В этом случае компании нужен не рядовой «ловец багов», а менеджер, который думает о глобальных задачах и строит процессы тестирования, исходя из них. Он определяет зоны для тестирования, сертифицирует команды на качество, разрабатывает и внедряет стандарты тест-дизайна, настраивает процессы сбора и реакции на обратную связь от пользователей. Тестировщик необходим по требованиям безопасности или законодательства Есть узкие области разработки, которые строго регламентируются особенностями законодательства или особыми требованиями безопасности. Даже в банковском секторе к таким относится небольшая часть работ, которыми занимаются только технологичные мегакорпорации. Это компании, в которых много систем, работающих как единое целое на всех континентах и подчиняющихся единой правовой и прочей специфике. Тестировщики в таких компаниях проверяют как раз соответствие нормам и соблюдение единых стандартов. Поставка ценности не входит в их зону ответственности: их задача — регулярное чтение кода и выявление конкретной уязвимости. Обнаружив слабое место, они включают часть автоматизированного теста в код, который потом должен поддерживаться командой. Такие специалисты — ювелиры в своем деле. В работе им очень помогает наличие в компании сложившейся культура и эталона для оценки экспертизы разработчиков. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Оглавление Тестирование в запутанной среде Почему такой расклад не идёт на пользу ни разработчику, ни тестировщику, ни продукту? Почему в Google нет тестировщиков To test or not to test? Когда тестировщики нужны Другие статьи Смотреть все Как ИИ трансформирует бизнес-процессы — автоматизация, самообучение и ключевые технологии 2025 года 19/8/2025 Подробнее Зачем бизнесу WMS система и как она экономит деньги 30/9/2025 Подробнее Почему цифровая трансформация с ИИ, облаками и предиктивной аналитикой становится ключом к эффективности, скорости и росту бизнеса 6/8/2025 Подробнее Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта Ок Давайте обсудим ваш проект С вами свяжутся персональные менеджеры clients@kt.team Email: @kt_team_it Telegram: О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными → ![image](/assets/original/68a47ce64fa44e70b00b5afdcover29-d96dde9804.avif) ![image](/assets/original/68934c18a55e6c733b95493ccover04-750eef4146.avif) --- О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →