😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойНовостиПочему Google не нанимает тестировщиков

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

Автор

Дата

Категория

Прагматичный IT в стиле Google: почему использование QA-специалистов в сложных продуктах может стать для этого продукта губительным.

Примечание: это перевод статьи, опубликованной на Medium. Мнение автора этой статьи может не совпадать с мнением редакции testengineer.ru

Принято считать, что серьезная IT-компания не может обойтись без QA-отдела. Реализуя принцип разделения труда, команда QA помогает эффективнее разобраться с багами, разгрузить разработчиков, повысить качество и ценность продукта.

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

В этой статье мы попробуем разобраться, почему так происходит.

Тестирование в сложной среде

Сложная среда — это понятие из концепции Cynefin framework, в котором все среды разделены на четыре типа: понятные, сложные, комплексные и хаотичные.

типы сред в Cynefin framework

В линейных средах QA-специалистам просто необходимо строго следовать правилам. Все ясно: достаточно сравнить ожидаемый результат с полученным или проверить поведение на соответствие требованиями. Результат может быть только один: продукт либо соответствует требованиям, либо нет.

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

Главные ценности Agile

Ценности Agile

Однако это всего лишь слова. Разберем на конкретном примере

Давным-давно, в одной ИТ-компании…

Почему эта ситуация не идет на пользу ни разработчику, ни специалисту по контролю качества, ни продукту?

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

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

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

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

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

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

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

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

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

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

Почему у Google нет отдела контроля качества.

Мировые лидеры ИТ-рынка не нанимают QA-специалистов. В случае с компаниями MAANG: Meta, Apple, Amazon, Netflix, Google — идея непрерывного тестирования является устаревшей концепцией. Лидеры рынка не считают, что привлечение QA-специалистов по умолчанию добавляет ценность качеству программного обеспечения. Например, в книге «Как тестируют в Google» авторы отмечают, что разработчики имеют все необходимое для самостоятельной доставки качественного продукта. Google описывает свой продукт, используемый розничными продавцами продуктов питания, но та же логика применима к большинству сервисов, разработка которых ведестся по Agile.

На практике QA-специалисты в Agile не рассматриваются как отдельный класс инженеров. Для нелинейных задач фреймворк Cynefin рекомендует подстоянное предоставление ценности и постоянную обратную связь. Поэтому необходима общая ключевая фигура — разработчик, который будет отвечать как за предоставление ценности, так и за получение обратной связи. Как только он начинает делить ответственность с командой QA, он неизбежно теряет фокус.

Тестировать или не тестировать?

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

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

Как мы пришли к такому выводу? Мы протестировали различные схемы работы, с командой QA и без нее. На основе наших экспериментов, проведенных более года назад, мы исключили тестирование из нелинейных задач. Вместо этого мы активно используем техники экстремального программирования, такие как:

  • парное программирование
  • Test-Driven-Development (тесты пишутся разработчиками до написания кода)
  • непрерывная интеграция
  • непрерывный рефакторинг

и другие

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

Когда нужен QA-инженер

Я не буду утверждать, что QA-команда никогда не нужна в сложных средах. Есть ситуации, в которых команда не может обойтись без QA-инженера.

Специфический процесс тестирования

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

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

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

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

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

QA-инженер необходим по юридическим причинам или по соображениям безопасности

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать

Последние комментарии