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

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

Успех в Chrome привлек ресурсы в наш проект. Теперь у нас была пара инженеров, которые активно работали над Bots и помогали нам поднять продукт на следующий уровень. Тогда же нас попросили помочь команде поиска, которая находилась в процессе выпуска новой классной фичи Instant Pages. Мы потратили на Instant Pages еще несколько недель, — нужно было научить систему запускать Chrome в разных режимах. Мы написали специальную серию тестов Bots, и теперь разработчики могли спокойно выпускать свой продукт, ведь они знали, что те же тесты пройдут автоматически для любых изменений, которые они внесут в будущем.

Мой совет инженерам по тестированию: если вы во что-то верите — делайте это! Мой совет менеджерам: не перекрывайте инженерам кислород, разрешите им экспериментировать, и они сотворят настоящие чудеса для вашего бизнеса и пользователей.

Эксперимент BITE

Мы создали BITE (Browser Integrated Test Environment), тестовую среду, интегрированную в браузер, для того чтобы вынести как можно больше тестовых действий, инструментов и данных в браузер и облако и показывать их в контексте. Мы хотели уменьшить время, которое тестировщики тратят не на тестирование, отвлекаясь от него. Мы хотели сделать тестирование еще более эффективным.

Что общего у пилота истребителя и тестировщика? Они оба тратят много времени на переключение контекста и обработку большого количества данных. В браузере у тестировщика часто открыто сразу несколько вкладок: одна с багтрекинговой системой, другая с электронной почтой проектной рассылки, третья с системой управления тест-кейсами, четвертая с планом тестирования. Наш пилот-тестировщик постоянно лавирует между этими вкладками. Может показаться, что мы чересчур зацикливаемся на скорости и эффективности, но здесь действительно есть проблема: легко потерять ценный контекст. Плюс ко всему:

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

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

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

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

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

Переместимся в кабину пилота истребителя. Проблема информационной перегруженности пилота решается с помощью индикаторов на лобовом стекле. Они упорядочивают информацию и подают ее в нужном контексте, как раз в поле зрения пилота. Чем сложнее становился самолет, тем больше появлялось данных и тем быстрее приходилось реагировать пилоту. Развитие разработки продуктов в Google происходит по той же схеме — чем дальше, тем больше выпусков, больше данных и тем быстрее нужно принимать решения. Мы позаимствовали подход у авиации, когда разрабатывали BITE для регрессионного и ручного тестирования.

Мы реализовали BITE как расширение браузера, чтобы можно было проследить за действиями тестировщика (см. рис. 3.35) и исследовать внутреннюю структуру веб-приложения. К тому же расширение позволяло показывать одинаковый для всех пользовательский интерфейс на панели инструментов браузера и быстро просматривать данные поверх веб-страницы: выглядит, как индикаторы на лобовом стекле пилота-тестировщика.

Рис. 3.35. Всплывающее окно расширения BITE

Давайте посмотрим, как эти экспериментальные возможности будут работать с реальными веб-приложениями Google.

Регистрируем баги с BITE

Помните про правило одного клика, которое работает в Google Feedback? Тестировщик, обнаружив баг в веб-приложении, может одним точным ударом сообщить о баге, выделив часть страницы, где возникла проблема, и дописав от себя сообщение. BITE, по сути, позволяет сделать то же самое, но в описание бага автоматически включается самая полезная и самая занудная для ручного ввода информация: URL-адрес, проблемный элемент или фрагмент текста на странице и снимок экрана. Для некоторых веб-приложений, в которых BITE встроен глубже, автоматически извлекаются отладочные URL-адреса и добавляется информация об отладке самой страницы.