Роль разработчика в тестировании (Software Engineer in Test, SET) тоже связана с разработкой, но фокусируется на тестируемости кода и создании инфраструктуры тестирования. Разработчик в тестировании анализирует архитектуру, уделяет особое внимание качеству кода и рискам проекта. Он выполняет рефакторинг, чтобы сделать код тестируемым, пишет фреймворки юнит-тестирования и средства автоматизации. Разработчик в тестировании работает с тем же кодом, что и разработчик, но больше заинтересован в улучшении качества и тестового покрытия, чем в добавлении новых фич или повышении производительности. Разработчик в тестировании тоже проводит почти 100 % своего времени за написанием кода, но делает это ради повышения качества, а не для реализации фич для пользователей.
На заметку
Разработчик в тестировании работает с тем же кодом, что и разработчик, но занимается скорее повышением качества и тестовым покрытием, чем добавлением новых фич или повышением производительности. Разработчик в тестировании пишет код, который помогает разработчику тестировать написанные им фичи.
Роль инженера по тестированию (Test Engineer, TE) связана с ролью разработчика в тестировании, но здесь на первом месте находятся пользователи и только на втором – разработчики. Некоторые инженеры по тестированию в Google пишут много кода для автотестов и управления сценариями использования и даже для имитации действий пользователя. Кроме того, именно они организуют работу по тестированию, которую выполняют другие инженеры, управляют выполнением тестов и интерпретируют их результаты тестов. Особенно важна их работа на поздних стадиях проекта, когда напряжение с приближением выпуска растет. Инженеры по тестированию – это эксперты продукта, консультанты по качеству и специалисты по анализу рисков. Одни пишут много кода, другие – мало[9].
На заметку
Инженеры по тестированию фокусируются на тестировании с точки зрения пользователя. Они занимаются общей организацией контроля качества, управляют выполнением тестов, интерпретируют их результаты и строят сквозную автоматизацию тестирования.
Итак, с точки зрения качества разработчики отвечают за фичи приложения и их качество отдельно от всего остального. Они ответственны за то, чтобы архитектура была устойчивой к ошибкам, приложение восстанавливалось после сбоев, отвечают за TDD, юнит-тесты и вместе с разработчиками в тестировании пишут код для тестирования фич.
Разработчики в тестировании отвечают за фичи тестирования. Они настраивают среду для изолированного выполнения кода с помощью имитации реального рабочего окружения. Для этого они создают такие компоненты, как заглушки (stubs), подставные объекты (mocks) и имитации (fakes), – мы рассмотрим их позже. Настроить очередь для управления отправкой кода в репозиторий – тоже их задача. Другими словами, разработчики в тестировании пишут код, который помогает разработчикам тестировать написанные ими фичи. Большую часть тестирования выполнит сам разработчик. Разработчики в тестировании в основном следят за тем, чтобы функциональность можно было легко протестировать, а разработчики не ленились писать тест-кейсы.
Получается, что разработчики в тестировании работают для разработчиков. Их конечная цель – качество кода и отдельных фич. Для этого они создают разработчикам удобную среду для тестирования кода. О пользователях думают тестировщики.
Если разработчики провели модульное и функциональное тестирование хорошо, то следующая задача – понять, насколько хорошо их исходный код вместе с данными будет работать на благо пользователей. Тестировщики проверяют добросовестность разработчиков дважды. Любые очевидные баги свидетельствуют о том, что тестирование раннего цикла было недостаточным или небрежным. Если таких багов мало, тестировщик переходит к своей основной задаче – убедиться в том, что продукт выполняет пользовательские сценарии, соответствует ожиданиям по производительности, что он надежен, правильно локализован и т. д. Тестировщики много тестируют сами и вдобавок обеспечивают координацию с другими инженерами, внешними тестировщиками-подрядчиками, тестировщиками из сообщества, внутренними пользователями, бета– и ранними внешними пользователями. Они сводят воедино все риски, которые могут сыграть из-за недочетов в базовой архитектуре, сложности функциональности и отказов в системе предотвращения сбоев. Как только тестировщики взялись за дело, их работе не видно конца.
Организационная структура
В большинстве компаний, где я работал, разработчики и тестировщики относились к одной команде разработки продукта. И разработчики, и тестировщики подчинялись одному и тому же руководителю проекта. Один продукт, одна команда – все участники говорят на одном языке.
К сожалению, я еще не видел, чтобы такой подход работал на практике. Обычно командой руководят менеджеры, вышедшие из среды программирования или управления, но не из среды тестировщиков. В предрелизном аврале они предпочтут выпустить функциональность полностью и закрыть как можно больше задач по «отделке» приложения, чем позаботиться об общем качестве. Внутри команды тестированию часто отводится второстепенная роль по отношению к разработке. Это отлично заметно по обилию глючных продуктов и преждевременных выпусков в нашей отрасли. Кто тут заказывал сервис-пак?
На заметку
Совместными командами обычно руководят менеджеры, вышедшие из среды программирования или управления, но не из среды тестировщиков. В предрелизном аврале они предпочитают выпустить функциональность полностью и закрыть как можно больше задач по «отделке», чем позаботиться об общем качестве. Внутри команды тестированию часто отводится второстепенная роль по отношению к разработке.
Давайте разберемся, кто кому подчиняется в Google. У нас есть своя иерархия, которая делится на направления, называемые Focus Area (FA). У нас есть направления Client (проекты Chrome, Google Toolbar и т. д.), Geo (проекты Maps, Google Earth и т. д.), Ads, Apps, Mobile и т. д. Все разработчики подчиняются директору или вице-президенту направления.
Правда, тестирование ломает эту схему. Тестирование находится в отдельном горизонтальном направлении, которое отвечает за продуктивность разработки. Направление продуктивности разработки существует параллельно с продуктовыми направлениями. Тестировщиков, по сути, предоставляют командам разработки продуктов во временное пользование. Они свободно поднимают вопросы безопасности и освещают области, где нет тестов или много багов. Так как мы не подчиняемся команде разработки продукта, нам нельзя ответить, что для нас есть дела поважнее. Мы сами устанавливаем свои приоритеты, и они всегда в рамках обеспечения надежности, безопасности и всего такого, пока мы не решим, что продукту нужно что-то другое. Если команда разработки захочет провести тестирование по упрощенной схеме, это необходимо согласовать заранее, а мы всегда можем сказать «нет».
С такой структурой работы мы можем сохранять небольшой штат тестировщиков. Команда разработки продукта не может снизить техническую планку тестировщиков или нанять их больше, чтобы свалить на них рутинную работу. Рутинная работа вокруг фичи входит в обязанности разработчика, ее нельзя переложить на какого-нибудь тестировщика-несчастливчика.
Тестировщиков на проекты назначают руководители направления продуктивности разработки. Они принимают стратегические решения, опираясь на приоритеты компании, сложность продукта и потребности конкретной команды проекта в сравнении с другими. Конечно, они могут ошибаться, и такое случается. Но в целом такая схема обеспечивает баланс ресурсов между фактическими, а не предполагаемыми потребностями.
На заметку
Тестировщиков на проект назначают руководители направления продуктивности разработки. Они принимают стратегические решения, опираясь на приоритеты компании, сложность продукта и потребности конкретной команды проекта в сравнении с другими. Такая схема сохраняет баланс ресурсов между фактическими, а не предполагаемыми потребностями. Централизованность подходов, идей и решений помогает всей компании использовать самые удачные из них.
