Как тестируют в Google
Шрифт:
Потом мы представили первую демоверсию руководителю разработки Chrome. Идея настолько захватила его, что он включил результаты Bots в повседневную работу по тестированию Chrome. Это признание сыграло важную для меня роль и придало мне уверенности, чтобы продолжать работу. А еще я понял, что если Chrome может использовать нашу систему, чтобы обнаруживать сложные проблемы, значит то же самое может делать любое веб-приложение.
Сразу же после этого мы провели презентации во многих командах Google. Каждый, кому мы показывали Bots, хотел использовать эту систему. Мы убеждались в реальности нашей мечты об использовании этой технологии во всех веб-приложениях. Поработав над ней еще несколько месяцев, я
После презентации мою команду часто спрашивали: «Смогу ли я отказаться от ручного тестирования?» Наш ответ — твердое «нет». Тестировщики теперь могут выполнять работу, для которой их нанимали: исследовательское тестирование, анализ рисков и интересов пользователя.
Успех в 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-адреса и добавляется информация об отладке самой страницы.
Допустим, тестировщик ввел поисковый запрос «офисы Google» на maps.google.com и получил нерелевантный результат: Белый дом. Тогда тестировщик жмет в меню BITE кнопку «Сообщить о баге» и выделяет курсором часть страницы, где, по его мнению, находится баг: четвертый результат поиска в нашем случае (рис. 3.36). Он может выделить любые элементы управления, изображения, сектора карты, отдельные слова, ссылки или значки.
Рис. 3.36. BITE выделяет нерелевантный результат поиска — Белый дом, выделен в колонке слева
Если кликнуть по выделенному фрагменту страницы, откроется форма регистрации бага (рис. 3.37), и не нужно метаться с одной вкладки на другую. Тестировщик быстро вводит название бага и нажимает кнопку «Здесь баг!», чтобы быстро добавить ошибку. Инженеры обычно не добавляют много данных, поэтому BITE добавляет их автоматически, и это здорово упрощает сортировку и отладку багов. Ну или от тестировщика нужно совсем немного усилий, но все равно он не сильно отвлекается от самого тестирования.