Как тестируют в Google

Я уже давно прочитал эту книгу, но всё не было времени выложить своё мнение о книге. Сама книга 2012-го года, то есть уже не самая свежая. Не факт, что тестирование происходит также и сейчас, но мне понравилось много моментов. 

Книгу явно понимают по разному. Я начал читать книгу после того, как мне её посоветовали со словами - посмотри, в Google нет ручного тестирования, там всё автоматическое.

Только когда я прочитал её, то там чётко написано, что в компании есть как инженеры, так и тестировщики. Одни авторматизируют тестирование, другие могут тестировать и вручную, чтобы убедиться, что реализовано именно так, как хотят пользователи. Они проверяют удобство использования продуктов.

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

Я выделил из книги два определения:

Разработчик в тестировании - это программист, который разрабатывает инструменты и помогает с автоматизацией

-Инженер по тестированию - может тестировать руками как конечный пользователь

Мне очень понравилось следующее высказывание:

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

Интересно, как работает Google - feature разработка или trunk? Просто если это это Trunk, то они должны заливать свои изменения в мастер как можно чаще. Вроде есть рекомендация, чтобы изменения попадали в мастер каждый день, чтобы не было конфликтов. Если так, то писать код и хорошо тестировать каждый день сложно.

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

Чтобы это правило работало, нужно работать по Feature. Если они так работают, то от меня плюсик. Я большой фанат этого подхода и тоже считаю, что нужно пускать в мастер только хорошо протестированный код. Никакого кода, который ещё находится в разработке туда попадать не должно.

Вот это выглядит немного как бардак:

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

Другие хранили планы прямо на странице своего продукта. Третьи добавляли его на внутренние страницы Google Sites и включали ссылки на них в инженерную документацию и внутренние вики-системы. Были и те, кто предпочитал классику и пользовался документами Microsoft Word, которые рассылались по почте участникам команд. У кого-то тест-планов не было вообще, а были лишь наборы тест-кейсов, которые, должно быть, и представляли такой план.

С одной стороны - это плюс, что каждый выбирает то, что работает хорошо именно для его команды, но с другой стороны это выглядит немного как бардак.

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

После презентации мою команду часто спрашивали: «Смогу ли я отказаться от ручного тестирования?» Наш ответ — твердое «нет». Тестировщики теперь могут выполнять работу, для которой их нанимали: исследовательское тестирование, анализ рисков и интересов пользователя.

Я уже как-то записывал видео о моём отношении к тестировщикам. Я считаю, что они нужны. Но именно их сокращают каждый кризис в первых рядах. Сейчас некоторые компании избавляются от тестировщиков для оптимизации расходов.

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

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым