Джеймс Уиттакер - Как тестируют в Google

• Название: Как тестируют в Google
• Автор: Джеймс Уиттакер
• Издательство: Издательский дом "Питер"
• Жанр: Программирование
• Год: 2014
• ISBN: 978-5-496-00893-8

В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием. Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.

---

В то же время интерны Джейсона работали над демоверсией крутейшего проекта Bots. Я присматривал за ходом дела, но когда они продемонстрировали результаты, мои представления о том, как следует проверять сайты, изменились навсегда. Увидев демоверсию ботов, созданную Еленой, с первыми данными, я был покорен. Я понял, что передо мной возможность фундаментального изменения подхода к веб-тестированию. Мои скриптовые тесты, конечно, были важны, но они масштабировались только линейно, и их нужно было сопровождать. А проект Bots содержал в себе что-то более универсальное. Я сразу влюбился в эту технологию. Практиканты ушли, и все знали, что их код был только демонстрацией. Чтобы сделать его частью базовой инфраструктуры и решением, пригодным для веба, нужно было еще много работать.

Первые несколько месяцев я работал над Bots один. Я хотел избежать лишних вопросов и скептицизма. Но я верил, что есть тот, кто справится с задачей.

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

Потом мы представили первую демоверсию руководителю разработки Chrome. Идея настолько захватила его, что он включил результаты Bots в повседневную работу по тестированию Chrome. Это признание сыграло важную для меня роль и придало мне уверенности, чтобы продолжать работу. А еще я понял, что если Chrome может использовать нашу систему, чтобы обнаруживать сложные проблемы, значит то же самое может делать любое веб-приложение.

Сразу же после этого мы провели презентации во многих командах Google. Каждый, кому мы показывали Bots, хотел использовать эту систему. Мы убеждались в реальности нашей мечты об использовании этой технологии во всех веб-приложениях. Поработав над ней еще несколько месяцев, я смог построить графики и трендов и результатов для канареечной сборки Chrome. Теперь Bots не только работала как система раннего оповещения, но и обнаруживала реальные баги на ранней стадии цикла. Система предоставляла куда более точные данные о сбоях, так что разработчики могли принимать решения на основе точных фактов. Мой любимый баг нашла первая боевая версия Bots, сравнив две сборки в один день. Bots обнаружила баг через несколько часов после того, как разработчик из Apple изменил атрибут WebKit. Фича была покрыта юнит-тестами, но только технология 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 добавляет их автоматически, и это здорово упрощает сортировку и отладку багов. Ну или от тестировщика нужно совсем немного усилий, но все равно он не сильно отвлекается от самого тестирования.