Разработчик в тестировании работает с тем же кодом, что и разработчик, но занимается скорее повышением качества и тестовым покрытием, чем добавлением новых фич или повышением производительности. Разработчик в тестировании пишет код, который помогает разработчику тестировать написанные им фичи.
Роль инженера по тестированию (Test Engineer, TE) связана с ролью разработчика в тестировании, но здесь на первом месте находятся пользователи и только на втором — разработчики. Некоторые инженеры по тестированию в Google пишут много кода для автотестов и управления сценариями использования и даже для имитации действий пользователя. Кроме того, именно они организуют работу по тестированию, которую выполняют другие инженеры, управляют выполнением тестов и интерпретируют их результаты тестов. Особенно важна их работа на поздних стадиях проекта, когда напряжение с приближением выпуска растет. Инженеры по тестированию — это эксперты продукта, консультанты по качеству и специалисты по анализу рисков. Одни пишут много кода, другие — мало.[9]
Инженеры по тестированию фокусируются на тестировании с точки зрения пользователя. Они занимаются общей организацией контроля качества, управляют выполнением тестов, интерпретируют их результаты и строят сквозную автоматизацию тестирования.
Итак, с точки зрения качества разработчики отвечают за фичи приложения и их качество отдельно от всего остального. Они ответственны за то, чтобы архитектура была устойчивой к ошибкам, приложение восстанавливалось после сбоев, отвечают за TDD, юнит-тесты и вместе с разработчиками в тестировании пишут код для тестирования фич.
Разработчики в тестировании отвечают за фичи тестирования. Они настраивают среду для изолированного выполнения кода с помощью имитации реального рабочего окружения. Для этого они создают такие компоненты, как заглушки (stubs), подставные объекты (mocks) и имитации (fakes), — мы рассмотрим их позже. Настроить очередь для управления отправкой кода в репозиторий — тоже их задача. Другими словами, разработчики в тестировании пишут код, который помогает разработчикам тестировать написанные ими фичи. Большую часть тестирования выполнит сам разработчик. Разработчики в тестировании в основном следят за тем, чтобы функциональность можно было легко протестировать, а разработчики не ленились писать тест-кейсы.
Получается, что разработчики в тестировании работают для разработчиков. Их конечная цель — качество кода и отдельных фич. Для этого они создают разработчикам удобную среду для тестирования кода. О пользователях думают тестировщики.
Если разработчики провели модульное и функциональное тестирование хорошо, то следующая задача — понять, насколько хорошо их исходный код вместе с данными будет работать на благо пользователей. Тестировщики проверяют добросовестность разработчиков дважды. Любые очевидные баги свидетельствуют о том, что тестирование раннего цикла было недостаточным или небрежным. Если таких багов мало, тестировщик переходит к своей основной задаче — убедиться в том, что продукт выполняет пользовательские сценарии, соответствует ожиданиям по производительности, что он надежен, правильно локализован и т.д. Тестировщики много тестируют сами и вдобавок обеспечивают координацию с другими инженерами, внешними тестировщиками-подрядчиками, тестировщиками из сообщества, внутренними пользователями, бета- и ранними внешними пользователями. Они сводят воедино все риски, которые могут сыграть из-за недочетов в базовой архитектуре, сложности функциональности и отказов в системе предотвращения сбоев. Как только тестировщики взялись за дело, их работе не видно конца.