Как тестируют в Google?
На прошлой неделе, специалист по тестированию компании «Ардекс», выступил с докладом на тему: «Как тестирует в Google?», основываясь на материале книги «How Google Tests Software» 2014г.
Книга «How Google Tests Software» (Как тестируют в Google) рассказывает, как тестировщики в Google пришли к пониманию, что нужно меняться, как строили новые процессы, каких результатов достигли и как видят дальнейшее развитие тестирования.
Подход Google к тестированию на первый взгляд парадоксален: во всей компании меньше выделенных тестировщиков, чем у многих конкурентов в одной команде разработки. В Google вся ответственность за качество лежит на тех, кто пишет код. Каждый, кто пишет код в Google, — уже немного тестировщик, а качество — это проблема всего коллектива. Каждый инженер является и тестировщиком. С одной стороны, качество и не создается тестированием, с другой — без тестирования сделать качественный продукт невозможно. Нужно перестать рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку. Тестирование не отдельная практика, это часть самого процесса разработки. Одним только тестированием качества не добиться. Рецепт получения высокого качества: смешивать разработку и тестирование, пока они не станут единой субстанцией.
Тестировщиков в классическом понимании в Google мало. В Google считают, что лучше всего протестирует свой код тот, кто его написал, т.е. разработчик. Разработчики больше всех заинтересованы в коде без багов. Вот почему Google обходится таким небольшим числом тестировщиков — за качество отвечают разработчики. В итоге качество достигается предотвращением, а не выявлением багов. Качество — часть разработки, а не тестирования. В Google тестирование определяет, насколько хорошо они предотвращают ошибки. Подход Google к созданию продуктов подразумевает слияние разработки и тестирования.
Google выделили три основных роли команды:
- Разработчик (Software Engineer, SWE) - пишет код функциональности приложений, создает проектную документацию, определяет структуры данных и общую архитектуру, большую часть времени пишет код и проводит код-ревью. Разработчик пишет много тестового кода, например во время юнит-тестирования, отвечает за качество всего кода, к которому он прикасается: пишет, исправляет или вносит изменения.
- Разработчик в тестировании (Software Engineer in Test, SET) - фокусируется на тестируемости кода и создании инфраструктуры тестирования, анализирует архитектуру, уделяет особое внимание качеству кода и рискам проекта, выполняет рефакторинг, чтобы сделать код тестируемым, пишет фреймворки юнит-тестирования и средства автоматизации.
- Инженер по тестированию (Test Engineer, TE) - на первом месте находятся пользователи и только на втором — разработчики. Инженеры по тестированию ориентированы на «человеческую сторону»: как пользователи будут взаимодействовать с приложением и какие проблемы при этом могут возникнуть.
В Google вместо того чтобы разделять тестирование на модульное, интеграционное и системное, делят все тесты на малые, средние и большие, исходя из их охвата, а не размера.
- Малые тесты - проверяют работу каждой единицы кода независимо от ее окружения: отдельные классы или небольшие группы связанных функций. У малых тестов не должно быть внешних зависимостей и они чаще всего автоматизируются. Выполняются быстро, за несколько секунд и меньше.
- Средние тесты - проверяют взаимодействие между двумя или более модулями приложения. Такие тесты обычно автоматизируются и запускаются реже. Фокусируются на том, чтобы проверить взаимодействие между функциями, которые вызывают друг друга или контактируют напрямую.
- Большие тесты - покрывают не меньше трех функций. Это реальные пользовательские сценарии, которые используют реальные источники данных, а их выполнение может занять несколько часов и даже больше.
Google определяет, в каком объеме проводить тестирование и что именно тестировать, по-разному для каждого конкретного продукта.
Следует сделать вывод, что Google предпочитает выпускать часто и стремится как можно раньше передать продукт пользователям, чтобы быстрее получить обратную связь и внести необходимые изменения.
