Разработчики в тестировании в Google создают, настраивают, поддерживают и развивают инфраструктуру для автоматического тестирования. Инженеры по тестированию играют другую роль — они ориентированы на «человеческую сторону»: как пользователи будут взаимодействовать с приложением и какие проблемы при этом могут возникнуть. Им, как и большинству технических специалистов в Google, нужно уметь программировать. Но все-таки для решения многих задач тестировщикам не нужно писать код.

Тестирование, обращенное к пользователю

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

В Google есть особое, ставшее уже частью культуры компании, почтение к программированию. Принято считать, что любой, кто входит в команду разработки, должен знать, как писать код. Поэтому тестировщики должны уметь программировать, если хотят работать наравне с разработчиками. Тестировщик в Google, с одной стороны, обладает техническими навыками, которые так уважают разработчики, а с другой — умеет фокусироваться на потребностях пользователей, что постоянно держит программистов в тонусе. Вот такое вот раздвоение личности!

На заметку

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

Должностные обязанности тестировщиков сложно описать однозначно. Они отслеживают все, что связано с качеством, на протяжении всего процесса разработки, по мере того как одиночные сборки постепенно складываются в один большой продукт. Поэтому многие из них вовлекаются в самую низкоуровневую работу, где требуется еще одна пара опытных глаз и инженерный опыт. Это вопрос рисков: тестировщики находят самые уязвимые места в продукте и делают то, что принесет максимум ценности конкретно в этом случае. Иными словами, тестировщик будет выполнять задачи разработчика в тестировании, если именно эта работа принесет сейчас наибольшую пользу. Если нужно провести, например, код-ревью, он сделает это. Если тестовая инфраструктура хромает — тестировщик займется ею. Один и тот же тестировщик может сегодня заниматься исследовательским тестированием, а завтра в тестовых целях сам будет использовать продукт как обычный пользователь.

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

Инженер по тестированию

Инженеры по тестированию появились в Google позже разработчиков и даже позже разработчиков в тестировании, поэтому эта роль до сих пор находится в процессе становления. Сегодняшние тестировщики определяют ориентиры, которыми будут руководствоваться следующие поколения. В этой части мы расскажем о новейших процессах, которые используют такие инженеры в Google.

Не все проекты требуют внимания инженеров по тестированию. Некоторые проекты находятся в начальной стадии и не имеют четкой задачи или описанных пользовательских сценариев. Таким проектам вряд ли будет уделяться особое (да и любое другое) внимание тестировщиков. Если есть большая вероятность закрытия проекта (например, он создавался для проверки гипотезы и не выдержал испытания), если в нем еще нет пользователей или четкого набора фич, то тестирование должны выполнять сами разработчики.

Даже если продукт точно будет выпущен, то работы для тестировщика на ранней стадии разработки не много, так как функциональность еще не устоялась, не определены основные фичи и границы проекта. Если разработчик в тестировании уже задействован, привлечение инженера по тестированию может стать лишней тратой сил и времени. К тому же в самом начале для планирования тестирования нужно намного меньше тестировщиков, чем для исследовательского тестирования на финальных циклах, когда разработка продукта близка к завершению и охота за пропущенными дефектами становится самой важной задачей.

На заметку

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

Хитрость с подключением тестировщиков к проекту в том, что нужно учитывать риски и степень выгоды от работы тестировщиков. Если потенциальный риск для будущего пользователя (или для всей компании) считается высоким, тогда тестировщиков нужно больше, но затраченные усилия должны быть соизмеримы с возможной выгодой от проекта. Если вы решили подключать тестировщиков, то обязательно соблюдайте правильные пропорции и делайте это в подходящий момент.

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

— Где у продукта слабые места?

— Есть ли проблемы с безопасностью, конфиденциальностью, производительностью, надежностью, пригодностью использования, совместимостью?

— Работают ли первичные пользовательские сценарии как следует? Подходят ли они для международной аудитории?

— Взаимодействует ли продукт с другими (аппаратными и программными) продуктами?

— Хорошо ли работают средства диагностики проблем?

На самом деле вопросов, на которые предстоит ответить тестировщикам, гораздо больше, и все они связаны с выявлением рисков при выпуске продукта. И сов­сем не обязательно тестировщики выполняют всю работу сами, их задача в том, чтобы работа была выполнена. Для этого они могут привлекать других людей там, где это нужно. Так или иначе, тестировщикам платят за то, чтобы они защищали пользователей и бизнес от плохого проектирования, запутанного интерфейса, багов, проблем с безопасностью, конфиденциальностью и т.д. В Google только эти специалисты тратят все свое рабочее время на то, чтобы искать слабые места в приложениях. Поэтому эта роль намного меньше формализована, чем, например, роль разработчика в тестировании. К тестировщикам обращаются за помощью на всех стадиях проекта: и на этапе идеи, и во время выпуска восьмой версии, и даже когда проект уже считается древним, «законсервированным». Часто один такой инженер работает над несколькими проектами одновременно, особенно если его умения сфокусированы на безопасности, защите конфиденциальности и нюансах интернационализации.

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

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

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

На заметку

Чтобы быть хорошим тестировщиком, нужно быть проницательным и способным к управлению, поэтому многие топ-менеджеры Google вышли именно из тестировщиков.

Любопытный момент: работа тестировщиков в Google настолько разнообразна, что формализовать процесс их участия почти невозможно. Тестировщик может присоединиться к команде разработки в любой момент, он должен быть способен оценить состояние проекта, кода, архитектуры, пользователей и оперативно решить, на чем следует сосредоточиться в первую очередь. Если проект только начинается, то надо заняться планированием тестирования. Если проект уже в разгаре, то надо оценить готовность проекта к выпуску или искать какие-то дефекты, которые еще можно поймать до выхода проекта в бета-тестирование. Если в руки тестировщика попадает продукт, который Google только что приобрел, как правило, проводится исследовательское тестирование с минимальным планированием (или вообще без него). Некоторые проекты не выпускались довольно долгое время, и с них нужно смахнуть пыль, подлатать систему безопасности или немного изменить пользовательский интерфейс — здесь нужен уже другой подход.

В Google нельзя равнять всех тестировщиков под одну гребенку. Мы часто называем таких ребят «те, кто приходит в середине проекта», а это значит, что тестировщик должен быть гибким, способным быстро интегрироваться в команду разработки и текущую ситуацию. Если уже поздно строить тест-план — к черту тест-план. Если проекту срочно нужны тесты — нужно распланировать самый минимум, чтобы можно было начать. Следует реагировать по ситуации. Не стоит зацикливаться на каких-то догмах в тестировании. Если пришел к середине проекта, то сделай эту середину золотой.

Вот общий список того, в чем тестировщик должен однозначно разбираться:

— планирование тестирования и анализ рисков;

— анализ спецификации, архитектуры, кода и существующих тестов;

— исследовательское тестирование;

— пользовательские сценарии;

— разработка тест-кейсов;

— выполнение тест-кейсов;

— организация краудсорс-тестирования;

— метрики использования;

— работа с обратной связью от пользователей.

Лучше всех эти задачи решают тестировщики с сильными лидерскими качествами и хорошими навыками общения.

Планирование тестирования

 

A — значит Attribute

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

Мы ранжируем данные о продукте с помощью ACC-анализа (Attribute, Component, Capability), то есть раскладываем всю имеющуюся у нас информацию по трем полкам: атрибуты, компоненты, возможности. И, следуя принятому порядку, начинаем с определения атрибутов.

Итак, атрибуты — это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его. Возьмем Chrome и опишем его как «быстрый», «безопасный», «стабильный» и «стильный»: вот определения продукта, на которые мы повесим ярлык «атрибуты» и положим на соответствующую полку.

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

На заметку

Атрибуты — это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его.

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

Вот несколько советов для формирования перечня атрибутов.

— Проще. Вы не должны тратить на составление списка больше часа или двух.

— Точнее. Убедитесь, что вы пользуетесь документами или данными, которые ваша команда считает правдивыми.

— Быстрее. Не бойтесь, если вы что-то упустите на этом этапе. Если информация важная, она всплывает в ходе работы, если же нет — беспокоиться не о чем.

— Короче. Не больше дюжины атрибутов — это хороший результат. Мы свели список атрибутов Chrome OS к двенадцати пунктам, но, оглядываясь назад, можем сказать, что восемь или девять было бы в самый раз.

Рис. 3.1. Анализ рисков Chrome OS

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

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

Возьмем, к примеру, Google Sites — бесплатное приложение по созданию сайтов для открытых или закрытых сообществ. Как и у многих других пользовательских приложений, список практически всех нужных нам атрибутов уже написан внутри самого продукта. И верно: большинство приложений, имеющих что-то вроде страницы «С чего начать работу» или какие-нибудь рекламные тексты, уже определили атрибуты за вас. А если нет, то простой разговор со специалистом по продажам, просмотр коммерческих видео или презентаций даст вам необходимую информацию.

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

Рис. 3.2. Добро пожаловать на Google Sites

Рис. 3.3. Атрибуты Google Sites, записанные в GTA

На заметку

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

В Google мы можем фиксировать список атрибутов по-разному: можем использовать текстовые документы, электронные таблицы или специальную программу Google Test Analytics (GTA), созданную нашими предприимчивыми инженерами. Совершенно не важно, что именно вы будете использовать, главное, чтобы атрибуты были записаны.

 

C — значит Component

Вы уже составили список атрибутов? Добро пожаловать в мир компонентов! Компоненты — это «существительные» нашего продукта. Это наши кирпичи, из которых построена вся система. Компоненты — это, к примеру, корзина и система оформления заказов в интернет-магазине, это возможность редактирования и печати в текстовом процессоре. Иными словами, компоненты — это ключевые части кода, которые делают программу тем, чем она является. Собственно, это и есть те вещи, которые тестировщикам поручено тестировать!

На заметку

Компоненты — наши кирпичи, из которых построена вся система, это ключевые части кода, которые делают программу тем, чем она является.

Обычно за компонентами далеко ходить не надо, часто они уже определены в документе архитектуры системы. Компоненты в крупных системах — это большие прямоугольники на архитектурных диаграммах, а их названия часто появляются в тегах в багтрекинговой системе или явно указываются в проектной документации. В системах поменьше компонентами являются классы и объекты в коде. В любом случае можно подойти к разработчику и спросить, с какими компонентами он работает. Вам останется только зафиксировать список, и дело вместе с компонентами в шляпе.

Как и в случае с атрибутами, уровень детализации имеет значение. Слишком много подробностей — информация станет перегруженной, а отдача снизится. Слишком мало подробностей — станет непонятно, зачем вы вообще делали эту работу. Список должен быть небольшим. Получилось десять пунктов? Отлично! Двадцать? Многовато, если только ваша система не очень большая. Второстепенные подробности можно и пропустить, так как они или являются частью другого компонента, или не так уж и важны для конечного пользователя.

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

Главное, не пытайтесь охватить все за один раз. Смысл ACC-анализа в том, чтобы подготовиться к работе быстро, а затем в ходе итераций отточить результат. Если вы пропустили важный атрибут, то вы наткнетесь на него, составляя список компонентов. Когда вы дойдете до описания возможностей продукта, забытые компоненты и атрибуты обязательно всплывут.

Рис. 3.4. Компоненты Google Sites, записанные в GTA

 

C — значит Capability

Следующий этап ACC-анализа состоит в описании возможностей продукта, «глаголов» всей системы, действий, которые она выполняет по запросу пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые совершает приложение. По сути, пользователь выбрал этот продукт именно из-за возможностей: ему нужно что-то сделать, и ваше приложение может это сделать.

На заметку

Возможности — это действия системы, которые она выполняет под руководством пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые выполняет приложение по запросу пользователя.

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

Возможности лежат на пересечении атрибутов и компонентов. То есть компоненты выполняют какую-то функцию для того, чтобы соответствовать атрибуту продукта, а результатом станет предоставление пользователю возможности. Давайте вернемся к Chrome для наглядности: Chrome быстро отображает страницы, он безопасно воспроизводит Flash-файлы. Если ваш продукт делает что-то, что не является пересечением компонента и атрибута, то, скорее всего, это что-то не имеет значения и даже есть смысл спросить, зачем это вообще нужно. Возможность, которая не работает на ключевую цель продукта, может дать потенциальные точки сбоев, поэтому лучше всего сбросить этот балласт.

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

Вот пример нескольких возможностей интернет-магазина:

— Добавить/удалить товар из корзины. Это возможность компонента «Корзина», когда он пересекается с атрибутом интерфейса «интуитивный».

— Получить данные кредитных карт и верифицировать. Это возможность компонента «Корзина», когда он пересекается с атрибутами «удобный» и «интегрированный» (речь об интеграции с платежной системой).

— Обработать финансовые операции с помощью HTTPS. Это возможность компонента «Корзина», когда он пересекается с атрибутом «безопасный».

— Рекомендовать клиенту товары, основываясь на просмотренных им продуктах. Это возможность компонента «Поиск», когда он пересекается с атрибутом «удобный».

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

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

— Отложить товар. Это возможность компонента «Корзина», когда он пересекается с атрибутом «удобный».

— Искать товар по ключевым словам, артикулу или категории. Это возможность компонента «Поиск», когда он пересекается с атрибутами «удобный» и «точный». В общем случае мы рассматриваем каждую категорию поиска как отдельную возможность.

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

Возможности обычно отображают представление пользователя о том, что система может делать. То есть если краткость правит бал в составлении списка атрибутов и компонентов, то список возможностей может быть очень большим, ведь они описывают все, что может делать система. Чем сложнее функциональность приложения, тем длиннее будет список ее возможностей.

У систем, над которыми мы работаем в Google, список возможностей доходит до ста и более пунктов (например, у Chrome OS их больше трех сотен), у более простых приложений могут быть десятки возможностей. Конечно, есть продукты с небольшим количеством возможностей, тогда их могут протестировать разработчики и первые пользователи. Поэтому если вы тестируете приложение, у которого меньше двадцати возможностей, задайтесь вопросом: а ваша работа здесь действительно нужна?

Самый важный аспект возможностей продукта — это то, что мы можем их протестировать. Не зря мы пишем возможности глаголами — ведь это активный признак субъекта. Глагол требует действий с нашей стороны — мы должны написать тест-кейсы, которые проверят, насколько точно реализована каждая возможность в системе и найдет ли пользователь свое взаимодействие с такой системой полезным. Позднее мы подробно обсудим, как возможности превращаются в элегантные тест-кейсы.

На заметку

Самый важный аспект возможностей продукта — это то, что мы можем их протестировать.

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

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

Вернемся к примеру с Google Sites: обратите внимание на рис. 3.5, где в столбцах представлены атрибуты, а в строках — компоненты. Так мы связываем атрибуты с компонентами. Как вы видите, далеко не каждый компонент работает со всеми атрибутами, поэтому появляются пустые ячейки. В Chrome только некоторые компоненты связываются с атрибутами «быстрый» и «безопасный». Пустая ячейка на пересечении «атрибут–компонент» означает, что тестировать эту пару не нужно.

Рис. 3.5. Связь компонентов и атрибутов в GTA

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

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

— сделать документ доступным для сотрудников;

— дать возможность сотрудникам редактировать документ;

— показывать положение сотрудника на странице.

Итак, эти возможности проясняют моменты, которые нужно протестировать для пары «Просмотр страницы» и «доступный». Мы можем написать тест-кейс для каждой из них или протестировать комбинацию возможностей, объединив их в более крупный сценарий использования или тестовый сценарий.

Умение описать хорошие возможности требует определенного навыка. Вот несколько самых важных свойств возможностей, знание которых поможет при работе:

— Возможность должна быть представлена как действие и описывать выполнение пользователем одной задачи в тестируемом приложении.

— Возможность должна предоставлять тестировщику достаточно информации, чтобы он понял, какие переменные надо учитывать при написании тест-кейса. Например, дана возможность — «Обработать финансовые операции с помощью HTTPS». В данном случае тестировщик должен понимать, какие финансовые операции может выполнить система, какой механизм будет проверять осуществление операции через HTTPS. Да, работа немалая! Если вы думаете, что какие-то финансовые операции могут быть упущены, скажем, новым тестировщиком, то продублируйте эту возможность для разных типов операций. Опять же, если команда тестирования собаку съела на HTTPS, то общей формулировки будет вполне достаточно. Не усложняйте себе задачу и позволяйте возможностям оставаться общими, оставьте тест-кейсам и исследовательским тестировщикам самим определить нужный уровень детализации.

— Возможность должна стыковаться с другими возможностями. Сценарии использования или пользовательские сценарии должно быть можно представить как серию возможностей. Если это сделать нельзя, то в вашей системе какие-то возможности отсутствуют или представлены слишком общими понятиями.

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

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

— Каждая возможность должна быть связана хотя бы с одним тест-кейсом. Если она была записана, значит достаточно важна для того, чтобы ее протестировать.

— Многие возможности требуют более одного тест-кейса. Каждый раз, когда во входной информации есть отклонения, последовательности ввода, системные переменные, тест-кейсов нужно делать несколько. Атаки, описанные в книге «How to Break Software», и туры в «Exploratory Software Testing» здорово описывают принципы выбора тестовых примеров и подход к выбору данных, которые легко превращают возможность в тест-кейс, вылавливающий баг.

— Не все возможности равны. Есть те, которые важнее других. На следующем шаге процесса возможности связываются с рисками и определяют степень их важности.

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

Пример: определение атрибутов, компонентов и возможностей Google+

ACC-анализ можно быстро выполнить в текстовом документе, таблице или даже на салфетке! Ниже следует сокращенный вариант ACC-процесса для Google+.

Атрибуты Google+ (список сформирован на основе наблюдения за дискуссией руководства Google).

— Социальный: позволяет пользователю обмениваться информацией и мыслями.

— Выразительный: пользователи используют возможности продукта для самовыражения.

— Простой: пользователь легко понимает, как сделать то, что он хочет.

— Релевантный: показывает только ту информацию, которая интересует пользователя.

— Расширяемый: интегрируется с другими ресурсами Google, сторонними сайтами и приложениями.

— Конфиденциальный: данные пользователя не будут открытыми.

Компоненты Google+ (получены из архитектурной документации).

— Профиль: информация и настройки текущего пользователя.

— Люди: профили людей, с которыми связан пользователь.

— Лента: ранжированная лента сообщений, комментариев, оповещений, фотографий и т.д.

— Круги: группы контактов («друзья», «коллеги» и т.д.).

— Оповещения: обозначения упоминания пользователя в сообщении.

— Интересы, или «+1»: обозначения материалов, которые понравились пользователю.

— Записи: сообщения о записях пользователей и их кругов.

— Комментарии: комментарии к сообщениям, фотографиям, видеороликам и т.д.

— Фотографии: фотографии, загруженные пользователями и их друзьями.

Возможности Google+.

Профиль:

— Социальный: обмениваться профилями и предпочтениями с друзьями и контактами.

— Выразительный: создавать онлайн-версию самих себя.

— Выразительный: взаимодействовать с Google+ по-своему.

— Простой: легко вводить, обновлять и распространять информацию.

— Расширяемый: передавать данные профилей приложениям с соответствующими правами доступа.

— Конфиденциальный: сохранять свои данные конфиденциальными.

— Конфиденциальный: передавать данные только одобренным пользователям и приложениям.

Люди:

— Социальный: связываться с друзьями, коллегами и членами своих семей.

— Выразительный: легко различать профили других пользователей.

— Простой: удобно управлять контактами пользователя.

— Релевантный: фильтровать свои контакты по своим критериям.

— Расширяемый: передавать контактную информацию службам и приложениям, имеющим необходимые разрешения.

— Конфиденциальный: предоставлять данные о контактах пользователя только сторонам с соответствующими разрешениями.

Лента:

— Социальный: информировать пользователей об обновлениях их социальных сетей.

— Релевантный: фильтровать те обновления, которые интересуют пользователя.

— Расширяемый: передавать обновления ленты службам и приложениям.

Круги:

— Социальный: группировать контакты на основании социального контекста.

— Выразительный: создавать новые круги на основе контекста пользователя.

— Простой: удобно добавлять, обновлять и удалять контакты из кругов.

— Простой: удобно создавать и изменять круги.

— Расширяемый: передавать данные о кругах службам и приложениям.

Оповещения:

— Простой: показывать оповещения кратко.

— Расширяемый: отправлять оповещения другим службам и приложениям.

Видеочат:

— Социальный: приглашать свои круги в видеочат.

— Социальный: открыть свой видеочат публике.

— Социальный: оповещать других пользователей в своих лентах о видеочатах.

— Простой: создавать видеочат и принимать в нем участие в несколько кликов.

— Простой: отключить в один клик видео- и аудиоданные.

— Простой: приглашать дополнительных пользователей в существующий видеочат.

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

— Расширяемый: общаться в текстовом чате во время видеочата.

— Расширяемый: включать видеоролики с YouTube в видеочат.

— Расширяемый: настраивать устройства в Настройках.

— Расширяемый: участвовать в видеочатах без веб-камеры, используя аудиоканал.

— Конфиденциальный: ограничивать доступ в видеочат только для приглашенных гостей.

— Конфиденциальный: оповещать только приглашенных гостей о видеочате.

Записи:

— Выразительный: выражать свои мысли.

— Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Комментарии:

— Выразительный: выражать свое мнение с помощью комментариев.

— Расширяемый: передавать данные комментариев для использования другими службами и приложениями.

— Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Фотографии:

— Социальный: делиться фотографиями с контактами и друзьями.

— Простой: легко загружать новые фотографии.

— Простой: легко импортировать фотографии из других источников.

— Расширяемый: интегрироваться с другими фотослужбами.

— Конфиденциальный: ограничивать доступ к фотографиям только для выбранной аудитории.

На рис. 3.6 приведены результаты ACC-анализа в форме электронной таблицы.

Рис. 3.6. Электронная таблица ACC для Google+

А на рис. 3.7 эти же данные представлены в другой форме.

Рис. 3.7. Таблица ACC для Google+

Риск

 

Анализ рисков

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

— О каких событиях нам следует беспокоиться?

— Насколько такие события вероятны?

— Каким может быть от них ущерб для нашей компании?

— Каким может быть от них ущерб для будущих пользователей?

— Есть ли в программе защита от возникновения нежелательных событий?

— Какова вероятность того, что такая защита не сработает?

— Во сколько нам обойдется такой сбой защиты?

— Насколько сложно будет восстановиться после такого сбоя?

— Нежелательное событие может случиться вновь или эта проблема может быть одноразовой?

Нет резона использовать математический расчет при анализе рисков просто потому, что количество вероятных переменных настолько велико, что на их точный расчет уйдет больше сил, чем на саму минимизацию рисков. В Google мы сводим все риски к двум факторам: частота сбоев и степень воздействия. Для каждой возможности в разрабатываемом продукте тестировщики присваивают этим двум факторам простые значения. Именно простые, а не идеально точные. Нам ведь нужно просто определить, какие возможности следует тестировать и в каком порядке. Для этого достаточно понять, какая возможность несет в себе больший риск, а какая меньший. В этом нам здорово помогает GTA (рис. 3.8).

GTA использует четыре оценки частоты появления сбоев:

— Очень редко: трудно представить ситуацию, при которой возникнет проблема, но если такое случится, то ее решение будет простым.

Пример: страница загрузки браузера Google Chrome. В основном содержимое этой страницы статично, автоматика там срабатывает только при определении клиентской ОС. Если произойдет сбой в базовом коде HTML или в сценарии на странице, то его быстро обнаружит мониторинг кода.

— Редко: есть случаи, когда может произойти сбой. Однако из-за невысокой сложности процесса или редкого использования такое случается нечасто.

Пример: кнопка «Вперед» в Chrome. Эта кнопка используется, но гораздо реже, чем ее напарница кнопка «Назад». Так сложилось, что ее работа редко приводит к сбоям, а если такое все-таки случится, то проблема будет быстро перехвачена еще на этапе тестирования раннего выпуска нашими первыми пользователями.

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

Пример: Возможности Chrome Sync. Chrome синхронизирует закладки, темы, заполнение форм, историю просмотра страниц и другие данные пользователя между компьютерами. Есть много типов данных и платформ ОС, поэтому слияние изменений — задача непростая. Если произойдет сбой синхронизации данных, пользователь, вероятнее всего, это заметит. Синхронизация выполняется только в том случае, когда происходят изменения в синхронизируемых данных — например, пользователь добавил новую закладку.

Рис. 3.8. Оценка риска по частоте и воздействию в GTA для Google+

— Часто: если в возможности, которая входит в часто используемую фичу, регулярно происходят сбои.

Пример: отображение веб-страниц. Основная задача браузера — отобразить HTML, CSS и код JavaScript любого происхождения и качества. Даже если исходный загружаемый код будет технически неправильным, пользователь решит, что проблема в браузере. Риск сильно возрастает, если мы рассматриваем сайт с высоким уровнем трафика. Проблемы отображения не всегда могут быть обнаружены пользователем: визуально элемент может съехать, но тем не менее остается рабочим. Или он может исчезнуть совсем, но тогда как пользователь узнает, что он вообще был?

Итак, тестировщик выбирает одно из этих значений для каждой возможности. Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант. Здесь нужно серьезно подумать.

Для оценки воздействия мы используем такой же упрощенный метод, с таким же количеством вариантов (снова возьмем браузер Chrome для примера).

Воздействие может быть:

— Минимальным: сбой, который пользователь может не заметить.

Пример: есть такой дополнительный сервис Chrome Labs. Его функциональность необязательна для работы, и сбой при загрузке страницы chrome://labs затронет лишь нескольких пользователей. Эта страница содержит дополнительные, экспериментальные фичи Chrome, о которых большинство людей даже не знают. Сами фичи снабжены пометкой «Используйте на свой страх и риск». Проще говоря, компания не несет ответственности за сбои, но зато и угроз для работы браузера нет.

— Небольшим: сбой, который может вызвать раздражение у пользователя. Если случается — механизмы повтора и восстановления легкодоступны.

Пример: нажмем на кнопку «Обновить». Если она не обновляет страницу, то можно заново ввести URL-адрес или открыть новую вкладку и попробовать ввести его там, а можно просто перезапустить браузер. Самые худшее в этой ситуации — раздражение пользователя.

— Существенным: сбой заблокирует выполнение пользовательских сценариев.

Пример: расширения Chrome. Если пользователь установил расширения в свой браузер, а в новой версии Chrome возник сбой при загрузке этих расширений, это провал.

— Максимальным: сбой нанесет удар по репутации продукта и заставит пользователей отказаться от работы с ним.

Пример: механизм автообновления Chrome. Если эта возможность отвалится, то браузер лишится важных обновлений безопасности или вовсе прекратит работать.

Иногда сбои приводят к разным последствиям у пользователя и компании. Допустим, перестал работать рекламный баннер. Проблема ли это для пользователя? Нет, он даже может не заметить. Проблема ли для Google? Да, конечно. Поэтому, анализируя риски, указывайте, кто пострадает.

Данные, которые присвоил рискам тестировщик, можно наложить на готовую таблицу «атрибут/компонент» для Google Sites. Таким образом мы получим тепловую карту рисков (рис. 3.9).

Рис. 3.9. Тепловая карта рисков для таблицы «атрибут/компонент» (ранняя версия Google+)

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

Такая диаграмма показывает возможности продукта, которые можно тестировать, вместе с присвоенными значениями рисков их сбоев. Трудно проставить эти значения объективно, тем более что у тестировщиков весьма специфическая точка зрения на продукт. Чтобы подстраховаться, мы опрашиваем и других заинтересованных в проекте лиц. Вот список тех людей, которые могут помочь с определением рисков, и несколько советов, как работать с их мнениями.

— Разработчики. Большинство разработчиков присвоят максимальное значение риска функции, которую писали они. Естественно, они хотят, чтобы их код был протестирован! Каждый кулик хвалит свое болото, но наш опыт подсказывает, что «кулик» часто переоценивает те функции, за которые он отвечает.

— Руководитель проекта. Удивительно, но руководители проектов тоже люди, и их оценка тоже может быть субъективной. Для них наиболее важными считаются те функции, которые позволят продукту выделиться на рынке и стать хитом.

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

— Директора и вице-президенты. Топ-менеджеров обычно интересуют те возможности продукта, которые качественно отличают его от главных конкурентов.

Итак, у всех мнений есть погрешность. Чтобы бороться с этим, мы опрашиваем всех заинтересованных в проекте людей по отдельности и просим оценить риски по описанным выше двум факторам. Их не так легко уговорить на эту работу, но мы, кажется, нашли успешную стратегию. Вместо того чтобы вдаваться в объяснения процесса и упрашивать участников нам помочь, мы просто делаем все сами и показываем им уже готовую тепловую карту. Как только они видят наше мнение, они мгновенно выплескивают свое. Разработчики активно принимают участие, если понимают, что мы используем карту для расстановки приоритетов в тестировании. Так же ведут себя и руководители проектов, и менеджеры по продажам. Все они заинтересованы в его качестве.

Есть в этом подходе определенная сила. Когда мы определяем риски самостоятельно, мы несомненно приходим к варианту, с которым другие участники проекта не будут согласны. Так и есть, подготавливая для них наш вариант анализа рисков, мы даем им почву для споров. В этом идея. Мы не спрашиваем их о каких-то абстрактных понятиях, мы даем им конкретные выводы, которые можно оспорить. Люди не всегда могут сказать, каким должен быть правильный ответ, но легко скажут, каким он быть не должен. Такой хитрый подход приносит нам много правдивых данных для вычисления рисков.

Когда риски будут согласованы, можно приступать к их последовательному снижению.

Снижение рисков

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

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

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

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

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

— Мы можем добавить средства контроля и сторожевой код для оперативного обнаружения сбоев.

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

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

В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.

Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования — это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC-анализ», и вот почему мы создали этот инструмент именно таким.

Тест-план за десять минут по рецепту Джеймса Уиттакера

Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.

Стоит ли такая работа усилий — это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы — они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли его создавать?

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

Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.

Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.

Когда у вас есть всего десять минут для решения задачи, каждая секунда становится значимой. В этом моя основная идея: ограничение во времени заставляет отсекать при планировании всю шелуху и концентрироваться только на важных моментах. Делайте только то, что абсолютно необходимо, оставьте подробности исполнителям тестов. Я хотел покончить с порочной практикой написания нежизнеспособных тест-планов, и это упражнение показалось мне верным.

Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.

Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т.д.), я дал им совсем немного времени на это.

Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям — да, абзацам текста — нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее — команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.

О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой при создании тест-кейсов и пользовательских историй.

Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.

Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!

Напоследок о рисках

Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.

Анализ рисков — это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.

GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.

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

1. Для самых рискованных возможностей и пар «атрибут/компонент», отмеченных красным, напишите набор пользовательских историй, сценариев использования или руководство по тестированию. В Google ответственность за наиболее рискованные возможности лежит на тестировщике. Он может координировать свою работу с коллегами, использовать разные инструменты, но личная ответственность все равно на нем.

2. Внимательно изучите все то, что делалось по тестированию разработчиками и разработчиками в тестировании до вас. Как результаты повлияли на риски, выявленные с помощью GTA? Хорошо ли это тестирование было организовано с точки зрения управления рисками? Стоит ли добавить новые тесты? Тестировщику может понадобиться дописать эти тесты самому или обратиться к разработчикам. В конечном счете важно, чтобы тесты были написаны, а не кто именно их напишет.

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

4. Будьте внимательнее к областям высокого риска — поинтересуйтесь механизмами восстановления и отката. Учтите возможное негативное влияние на пользователя, когда он столкнется с наихудшим сценарием. Обсудите такие ситуации с другими инженерами, проверьте реалистичность этих сценариев. К тестировщику, который часто кричит: «Волк!», вскоре перестанут прислушиваться. Громкие предупреждения о вероятных опасностях допустимы только в отношении сценариев с высоким риском, которые к тому же признаны реалистичными и уже были покрыты тестами.

5. Вовлекайте в работу как можно больше людей, заинтересованных в успешности проекта. Внутренних пользователей следует тормошить на тему обратной связи, иначе они будут просто использовать систему, игнорируя те или иные ошибки. Просите их проводить конкретные эксперименты, задавайте им вопросы типа «А как это работает на вашей машине?» или «Как бы вы использовали такую фичу?». Сотрудники Google много участвуют в тестировании, и их нужно активно направлять именно тестировать, а не просто пользоваться продуктами.

6. Если ни один из механизмов не работает, а подверженный риску компонент так и недотестирован, да еще и постоянно падает, постарайтесь добиться удаления элемента. Поздравляем! Вам выпал шанс объяснить руководству концепцию анализа рисков и подчеркнуть важность тестировщиков на проекте.

Пользовательские сценарии

Джейсон Арбон

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

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

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

Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.

Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.

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

Краудсорсинг

Джеймс Уиттакер

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

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

Еще одна ключевая ценность краудсорсинга (кроме множества конфигураций) — это более широкий взгляд на приложение. Вместо того чтобы один тестировщик имитировал действия тысячи пользователей, у нас есть тысяча пользователей, работающих как тестировщики. Есть ли лучший способ найти сценарии, приводящие приложение к сбою, чем сразу выдать эти сценарии пользователям и получить обратную связь? Разнообразие и масштаб — вот в чем ценность краудсорсинга.

Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.

Главный недостаток тестирования сообществом в том, что им нужно время, чтобы разобраться с приложением и понять, с какой стороны лучше подойти к тестированию. Большая часть этого времени теряется впустую из-за количества людей, но мы придумали, как с этим справляться. Для Chrome, например, мы написали туры, и внешние тестировщики следовали им при исследовательском тестировании и при выполнении пользовательских сценариев (примеры есть в приложении Б «Туры тестов для Chrome»). Туры сразу направляли тестировщиков к нужным частям приложения и давали необходимые инструкции. Фокус в том, чтобы сделать разные наборы туров и распределить их между участниками. Так мы избежали варианта «принеси то, не знаю что» и получили именно то, о чем просили.

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

Итак, сила ACC-анализа в том, что мы получаем список возможностей продукта, который можно упорядочить по риску и закрепить за разными исполнителями. Тестировщики, работающие над одним проектом, могут получить разные наборы возможностей для проверки. Внутренние пользователи, «двадцатипроцентные» участники, тестировщики-подрядчики, тестировщики из сообщества, разработчики, разработчики в тестировании — все получат свои списки возможностей, и, к радости тестировщика, важные области будут покрыты с меньшим перекрытием, чем если бы мы просто раздали приложение для тестирования всем желающим.

Работа тестировщика, в отличие от работы разработчика в тестировании, с выпуском продукта не заканчивается.

Пишем тест-кейсы

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

Чаще всего тест-кейсы хранились в электронных таблицах и документах. Коман­ды, работающие по быстрым методологиям с короткими циклами выпуска, не очень заботятся о сохранении тест-кейсов. Как только выходит новая фича, скрипты начинают падать, и тесты приходится переписывать заново. Поэтому документа, который можно использовать, а потом с чистым сердцем удалить, — вполне достаточно. Формат такого документа не подойдет для конкретных тест-кейсов с действиями, но сгодится для описания контекста тестовой сессии. Такие тесты обычно менее регламентированы и, по сути, просто указывают, какие фичи нужно исследовать.

Конечно, есть команды, которые хранят тестовые процедуры и данные в довольно сложных таблицах. Некоторые даже копируют данные ACC-анализа в электронные таблицы, потому что они, видите ли, более гибкие, чем Google Test Analytics. Но такой подход требует дисциплины и целостности в команде, ведь работа одного тестировщика может ограничить работу другого. Большим командам с их текучкой нужен другой подход. Нужна структура, которая переживет любого участника команды.

Электронные таблицы все же удобнее документов, потому что в них имеются подходящие столбцы для процедур, данных и отметок о результатх. Их легко настроить под себя. Google Sites и другие разновидности онлайновых вики-систем часто используют, чтобы транслировать тестовую информацию другим заинтересованным людям. Их легко использовать совместно и редактировать.

С ростом Google у многих команд росли объемы тест-кейсов, ими нужно было лучше управлять. Некоторые документы с тест-кейсами выросли до таких размеров, что даже поиск в них стал невозможен. Нужен был новый подход. Наши тестировщики построили систему на основе нескольких коммерческих продуктов и доморощенных систем управления тест-кейсами, знакомых им по предыдущим местам работы. Систему назвали Test Scribe.

Test Scribe хранит тест-кейсы в жесткой структуре. Можно включить или исключить тест-кейс из конкретной тестовой сессии. Реализация была примитивной, и энтузиазм по поводу ее использования быстро угас. И хотя многие команды оставили что-то от нее и возились с этим несколько кварталов, мы ее все-таки похоронили. В 2010 году Джорданна Корд, старший разработчик в тестировании, написала новую программу. Это была система Google Test Case Manager (GTCM).

Рис. 3.10. Домашняя страница GTCM сосредоточена на поиске

GTCM создали, чтобы сделать процесс написания тестов проще, создать гибкий формат тегов, который можно адаптировать под любой проект, упростить поиск и повторное использование тестов. И ­— самое важное — интеграция GTCM с остальной инфраструктурой Google. Посмотрите на снимки экранов GTCM (рис. 3.10–3.14). На рис. 3.11 показана страница создания тест-кейса. Можно создавать произвольные разделы или метки, поэтому GTCM поддерживает любые схемы, от классических тестов до исследовательских туров, «огурцов» и описаний пользовательских историй. Некоторые тестовые команды даже хранят фрагменты кода и данные прямо в тест-кейсах GTCM. GTCM помогает в работе любым тестовым командам и учитывает их различающиеся представления тест-кейсов.

Рис. 3.11. Создание проекта в GTCM

Рис. 3.12. Создание теста в GTCM

Рис. 3.13. Просмотр тест-кейсов при поиске Chrome в GTCM

Рис. 3.14. Простой тест-кейс для диалогового окна About в Chrome

Метрики, полученные от GTCM, дают представление о том, что происходит с тест-кейсами в общем. Можно понаблюдать за графиками общего количества тестов и результатов тестов на рис. 3.15 и 3.16. Общее количество тестов приближается к асимптоте. Это потому, что Google закрывает старые проекты, ориентированные на ручное регрессионное тестирование, вместе с их тестами. Кроме того, GTCM в основном содержит ручные тесты, а многие команды заменяют ручные методы тестирования автоматизацией, краудсорсингом или исследовательским тестированием. Поэтому общее число тест-кейсов во внутренней базе TCM уменьшается, хотя покрытие при этом увеличивается. Количество проведенных тестов тоже увеличивается, так как в этой области доминируют несколько больших команд, для которых ручное тестирование обязательно (например, команда Android).

Рис. 3.15. Изменение количества тестов со временем в GTCM

Общее количество проведенных ручных тестов, как и следовало ожидать, увеличивается (рис. 3.16).

Рис. 3.16. Изменение количества результатов тестов со временем в GTCM

Посмотрим на график количества багов, показанный в GTCM (рис. 3.17). Он интересен, но еще не может показать всю картину. Google дает инженерам свободу действий. Одни команды отслеживают, какие баги были найдены какими тест-кейсами, а другие не считают эти данные полезными для своего проекта. Некоторые баги создаются в системе автоматически, не все они были найдены в ходе ручного выполнения тестов.

Рис. 3.17. Изменение общего количества багов, заведенных в ходе выполнения тестов GTCM, со временем

Основным требованием к GTCM с самого начала было наличие четкого и простого API. На самом деле и у системы TestScribe был API, но он базировался на SOAP, а схема аутентификации была настолько недружелюбной, что ею мало кто пользовался. Кроме того, с повышением внутреннего уровня безопасности тот режим аутентификации стал непригодным. Эти проблемы решились, когда у GTCM появился RESTful JSON API.

Команда разработки собирается скоро открыть GTCM для внешнего использования. Мы надеемся перевести эту базу данных тест-кейсов на модель открытого кода, чтобы поддерживать ее всем миром. Система GTCM проектировалась с расчетом на продолжение использования извне. Она построена на базе Google App Engine для обеспечения масштабируемости и для того, чтобы другие компании могли развернуть у себя свою копию системы. Внутренняя структура GTCM сделана так, чтобы отделить большую часть логики и пользовательских интерфейсов от Google App Engine, чтобы люди могли портировать систему. Следите за Google Testing Blog, если хотите узнать больше об этом процессе.

Интересные факты из жизни багов

Каждый тестировщик знает, что такое баги и баг-репорты. Поиск багов, сортировка багов, исправление багов, отлов регрессионных багов — основной костяк работы по контролю качества программных продуктов. Эта часть тестирования, пожалуй, больше всего распространена в Google, но и здесь есть несколько интересных особенностей. В этом разделе мы не будем говорить о «жучках», которые заносятся в систему, чтобы отслеживать работу ее элементов. Речь пойдет только о реальных ошибках в коде. Ежедневная работа команд разработки чаще всего связана именно с ними.

Итак, сначала был баг. Баги может найти и занести в багтрекинговую систему любой сотрудник Google. Менеджеры продуктов заводят баги еще на ранних версиях продукта, когда находят расхождения со спецификацией или со своим представлением о продукте. Разработчики заводят баги, когда понимают, что случайно поломали свой код или зацепили чужой, или когда сами используют продукты Google. Баги могут прийти с полей: в ходе работы краудсорс-тестировщиков или внешнего тестирования сторонними компаниями. Коммьюнити-менеджеры, которые следят за сообщениями в специальных группах, посвященных продуктам, тоже могут заводить баги. Во внутренних версиях некоторых приложений, например Google Maps, можно сообщить о баге одним кликом. Иногда баг регистрируется через API прямо из приложения.

Если процесс отслеживания багов и связанный с ним объем работы — это такая большая часть работы инженеров, понятное дело, хочется такой процесс автоматизировать. Первой попыткой подобной автоматизации в Google была система под названием BugsDB: простая база данных из нескольких таблиц и запросов, где можно было хранить и получать информацию и даже считать какую-то статистику. Системой BugDB пользовались до 2005 года, пока два предприимчивых инженера, Тед Мао и Рави Гампала, не создали Buganizer.

Вместе с Buganizer мы получили новую гибкую n-уровневую иерархию компонентов взамен простой иерархии «проект компонент версия», которая была в BugDB (да и во всех остальных коммерческих багтрекинговых системах того времени). Стало проще учитывать и отслеживать баги, появился новый жизненный цикл рассмотрения и сопровождения багов. Упростилось отслеживание групп багов — теперь мы могли создавать и управлять целыми списками, строить диаграммы и отчеты. Разработчики реализовали полнотекстовый поиск, историю изменений, настройки «по умолчанию» при создании бага. В целом использовать новую систему стало намного удобнее, пользовательский интерфейс стал интуитивно понятным. Плюс с добавлением аутентификации повысилась безопасность.

Немного подробнее о Buganizer

Самый старый баг, зарегистрированный в Google, создан 18 мая 2001 года в 15:33 и существует до сих пор. Он называется «Test Bug», а его описание выглядит как «First Bug!». Смешно, что этот баг до сих пор случайно всплывает, когда разработчики привязывают исправленные баги к своим коммитам.

Самый старый из активных поныне багов был зафиксирован в марте 2009 года. В нем предлагается исследовать проблемы производительности для снижения задержки отображения рекламы с учетом локации пользователя. В последнем комментарии к этому багу написано, что вопрос может быть исследован, но это потребует архитектурной работы, а вообще — метрики задержки вполне допустимы. Это было в 2009 году.

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

Рис. 3.18. Распределение багов в Buganizer по приоритетам

На рис. 3.18 мы видим, что есть много багов с приоритетом P2, значительно меньше багов P1 и совсем мало багов P0. Корреляция необязательно подтверждает причину-следствие, но вполне может быть признаком того, что инженерная методология, описанная в этой книге, действительно работает. Конечно, можно подумать, что люди просто не заводят баги с высокими приоритетами, но в реальной жизни это не так. А вот баги P3 и P4 часто не заносятся в систему, так как на них редко обращают внимание.

Средний возраст багов на рис. 3.19 тоже показывает вполне ожидаемую картинку. Заметили аномалию в области багов P0? Все просто: на практике баги P0 часто трудно исправить, поскольку это серьезные просчеты в проектировании и развертывании, сложные для отладки и решения. Срок жизни остальных багов зависит от их приоритета: чем меньше важность бага, тем дольше его могут исправлять.

Рис. 3.19. Средний возраст багов в Buganizer

Диаграмма зависимости количества багов от времени (рис. 3.20) показывает постоянный небольшой рост. Мы не знаем точно, почему это происходит. Наверное, у нас становится больше кода. С другой стороны, количество багов растет не так быстро, как количество разработчиков и тестировщиков. Может быть, наш код и становится лучше из-за контроля качества, а может быть, мы просто их не находим.

График исправления багов на рис. 3.21 показывает нам, что команды обычно справляются с ростом багов. Многие команды просто перестают добавлять новые фичи, когда скорость появления багов начинает превышать пропускную способность команды по их исправлению. Мы рекомендуем всем перенять эту практику, а не фокусироваться только на фичах и поставленных датах завершения. Чтобы держать число багов под контролем, сосредоточьтесь на маленьких фрагментах тестируемого кода, тестируйте инкрементально и отдавайте продукт внутренним пользователям как можно раньше.

Рис. 3.20. Зависимость количества багов от времени

Как только продукты Google становятся открытыми (к примеру, Chrome и Chrome OS), нам уже не удается вести единую базу данных багов. В этих проектах используются базы данных багов, доступные извне, — Bugzilla для проблем WebKit и Issue Tracker для проблем chromium.org. Мы в Google подталкиваем наших сотрудников заводить баги из любых продуктов Google, независимо от того, работают ли они на этом проекте. Наша главная цель — сделать интернет лучше.

Issue Tracker — основной репозиторий для всех багов Chrome и Chrome OS. Эта багтрекинговая система открыта публично: информацию об исправлении багов может получить любой желающий, даже пресса. Мы иногда скрываем баги безо­пасности до их исправления, чтобы не раззадоривать хакеров, но в остальном доступ к базе данных открыт. Внешние пользователи могут свободно заводить баги, и для нас это ценный источник информации. На рис. 3.22 и 3.23 показан процесс и результат поиска бага, связанного с логотипом Chrome в окне About.

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

Рис. 3.21. Зависимость количества исправленных багов от времени. График похож на график количества обнаруженных багов, и это хорошо!

Рис. 3.22. Поиск в Issue Tracker

Рис. 3.23. Открытый баг в Issue Tracker

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

— Назначен (Assigned to, Assignee)

[Не обязательно] LDAP-аккаунт сотрудника, который должен сделать следующий шаг в обработке этого запроса. Этот человек автоматически получит сообщение при создании проблемы и каждый раз, когда кто-то изменит значение любого поля. У каждого компонента есть ответственный по умолчанию.

— Поставить в копию (CC)

[Не обязательно] Любое количество (ноль или более) LDAP-аккаунтов сотрудников, которых нужно информировать о создании или изменении проблемы. Имена задают в формате LDAP или имен почтовых ящиков без @google, поэтому можно ввести только действующие аккаунты. Элементы списка разделяются запятыми. Не нужно включать имя из поля «Назначен» при регистрации проблемы, потому что этот человек и так получит письмо.

— Вложения (Attachments)

[Не обязательно] Документы, прикрепляемые при создании бага (ноль или более). Принимает любой тип файлов, их количество может быть любым, но размер всего приложения не должен превышать 100 Мбайт.

— Блокирует (Blocking)

[Не обязательно] ID багов, решению которых препятствует этот баг. Элементы списка разделяются запятыми. Обновление такого списка автоматически обновляет поле «Зависит от» перечисленных багов.

— Зависит от (Depends On)

[Не обязательно] ID багов, которые должны быть исправлены до исправления этого бага. Обновление списка приводит к автоматическому обновлению поля «Блокирует» перечисленных багов. Элементы этого списка тоже разделяются запятыми.

— Дата изменения (Changed)

[Только для чтения] Дата и время последнего ручного изменения любого из полей проблемы.

— Изменения (Changelists)

[Не обязательно] Ноль или более номеров коммитов кода, связанных с решением проблемы. Указываются только коммиты, которые уже залиты в репозиторий.

— Компонент (Component)

[Обязательно] Компонент, содержащий баг или запрос на реализацию функциональности. Здесь нужно указывать полный путь к компоненту, причем длина пути не ограничена.

Дополнительные компоненты могут создавать только руководители проекта или разработки.

— Дата создания (Created)

[Только для чтения] Дата создания бага.

— Обнаружен в (Found In)

[Не обязательно] Используется для контроля версий; в поле указывается номер версии продукта, в которой была обнаружена проблема (например, 1.1).

— Последнее изменение (Last modified)

[Только для чтения] Дата последней автоматической модификации любого поля проблемы.

— Заметки (Notes)

[Не обязательно] Подробное описание проблемы и комментарии по ходу ее решения. При регистрации проблемы нужно описать шаги для воспроизведения бага или путь к экрану, который требует изменений. Чем больше информации вы здесь укажете, тем меньше вероятность того, что разработчикам, которые будут решать эту проблему, придется связываться с вами. Редактировать предыдущие записи в поле «Заметки» нельзя, даже если это вы сами их добавили; поле «Заметки» поддерживает только добавление новых значений.

— Приоритет (Priority)

[Обязательно] Определяет важность бага, где P0 — самый серьезный баг. Приоритет показывает, насколько срочно нужно исправить баг и сколько ресурсов выделить для его исправления. Например, опечатка в слове «Google» на логотипе страницы поиска будет некритичной, так как функциональность страницы от нее не страдает, но высокоприоритетной. Такие опечатки — это очень плохо. Заполнение обоих полей позволит команде исправления багов разумно распределять свое время. Обратите внимание на описание поля «Критичность» для закрепления темы.

— Кем создан (Reported by, Reporter)

[Только для чтения] Имя пользователя или сотрудника Google, первым сообщившего о баге. По умолчанию в поле заносится аккаунт человека, который завел проблему, но оно может быть изменено позднее для чествования фактического первооткрывателя.

— Резолюция (Resolution)

[Не обязательно] Последняя операция, выполняемая проверяющим. Может принимать значения «Нереально» (Not feasible), «Работает как предполагалось» (Works as intended), «Не воспроизводится» (Not repeatable), «Информация устарела» (Obsolete), «Дубликат» (Duplicate) и «Исправлено» (Fixed).

— Критичность (Severity)

[Обязательно] Критичность определяет, как сильно баг мешает использованию продукта. S0 — самые критичные баги. Мы выставляем и приоритет, и критичность каждой проблеме, чтобы разработчики могли приоритизировать важность багов при исправлении. Помните наш пример с опечаткой в слове «Google»? Ошибка высокого приоритета, но некритичная. Значения критичности можно объяснить как:

— S0 = Система непригодна к использованию

— S1 = Высокая

— S2 = Средняя

— S3 = Низкая

— S4 = Не влияет на систему

— Статус (Status)

[Обязательно] Текущее состояние бага. Посмотрите на жизненный цикл бага на рис. 3.24, чтобы понять, как меняется значение этого поля. «Статус» бага может быть несколько видов.

— Новая (New): проблема была создана, но ответственный за ней еще не закреплен.

— Назначена (Assigned): назначен ответственный.

— Принята (Accepted): ответственный принял проблему.

— Будет исправлена позднее (Fix later): ответственный решил, что проблема будет исправлена позднее.

— Не будет исправлена (Will not fix): ответственный решил, что проблема по какой-то причине не будет исправлена.

— Исправлена (Fixed): проблема исправлена, но исправление не проверено.

— Назначен проверяющий (Verifier assigned): проблеме назначен проверяющий.

— Проверена (Verified): исправление проверено проверяющим.

— Описание (Summary)

[Обязательно] Общее описание проблемы. Оно должно быть как можно более понятным и однозначным; когда кто-нибудь просматривает список проблем, именно этот текст поможет решить, нужно ли дальше исследовать проблему.

— Исправить в (Targeted To)

[Не обязательно] Используется для контроля версий; поле заполняется номером версии продукта, в которой проблема будет исправлена (например, 1.2).

— Тип (Type)

[Обязательно] Типом проблемы может быть:

— Баг (Bug): из-за проблемы программа работает не так, как ожидалось.

— Запрос на реализацию функциональности (Feature request): нечто, что бы вы хотели добавить в программу.

— Проблема клиента (Customer issue): возникла в ходе обучения или общего обсуждения.

— Внутренняя чистка (Internal cleanup): требует сопровождения.

— Процесс (Process): автоматически отслеживается через API.

— Исправлен в (Verified In)

[Не обязательно] Используется для контроля версий; поле заполняется номером версии продукта, в которой исправление проблемы прошло проверку (например, 1.2).

— Проверяющий (Verifier)

[Обязательно до разрешения проблемы] Каждой проблеме назначается один человек, который имеет право отметить ее как решенную. Этот человек должен быть назначен до того, как проблема будет готова к решению. Проверяющий — единственный человек, который может установить статус «Проверена» и закрыть баг. Проверяющий и ответственный могут быть одним человеком. Посмотрим на жизненный цикл бага.

Чем отличается обработка багов в Google от такого же процесса в других компаниях?

— Мы открыты. База данных багов практически полностью открыта. Любой сотрудник Google может просмотреть любой баг любого проекта.

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

— Свобода выбора. В Google нет предписанных сверху схем работы с багами. Процесс приоритизации багов зависит от команды. Иногда это индивидуальная задача, иногда она решается между тестировщиками и разработчиками в неформальном разговоре. Приоритизация может быть частью еженедельной или ежедневной планерки. Нет формальных методов, электронных очередей или Большого Брата, контролирующего работу команд. Google оставляет команде право самой организовать работу с багами.

Рис. 3.24. Основной процесс устранения багов при работе с Buganizer

Проекты Google обычно находятся в одном из двух состояний: новый проект с быстрой разработкой, где поток проблем непрерывен, или проект с устоявшейся инфраструктурой и постепенными выпусками. В последнем случае объем юнит-тестирования и меры предотвращения багов сводят количество ошибок к минимуму.

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

Команда Google Feedback (http://www.google.com/tools/feedback/intl/en/index.html) запустила новый подход к регистрации багов в масштабе всего Google. С помощью Google Feedback конечные пользователи сообщают о багах в некоторых сервисах Google. Идея в том, что внешние пользователи не знают, какие баги уже были заведены или исправлены, но мы хотим быстро и легко получать обратную связь от них. Соответственно тестировщики и разработчики Google сделали так, чтобы сообщение о багах осуществлялось по простому принципу «навести и кликнуть». Инженеры команды очень постарались, чтобы пользователи при отправке сообщений о багах в Google могли скрыть те части страницы, где видна их конфиденциальная информация (пример на рис. 3.25).

Команда Google Feedback здорово потрудилась над тем, чтобы наши базы данных не затопило бушующим потоком багов. Количество дубликатов могло бы просто застопорить процесс приоритизации. Они внедрили кластерные алгоритмы, чтобы автоматически группировать дубликаты и определять самые частые проблемы. За неделю после выпуска новой версии могли поступить десятки тысяч сообщений, которые в итоге сводились всего к десятку основных проблем. Это сэкономило уйму времени, и Google смог услышать своих пользователей без индивидуальной обработки каждого сообщения. Команда сейчас тестирует работу этой системы на нескольких продуктах, но собирается расширить ее на все ресурсы Google.

Рис. 3.25. Google Feedback с фильтрацией конфиденциальной информации

Жизненный путь бага

Джеймс Уиттакер

Баги напоминают детей, излишне опекаемых родителями. Они получают много внимания. Они рождаются в тиши IDE на машине разработчика, но как только они выходят в большой мир, их жизнь наполняют фанфары.

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

Как и родитель, который звонит другу или родственнику, чтобы обсудить тревожный кашель, тестировщик должен пригласить коллегу и продемонстрировать ему больного. Поинтересоваться его мнением, поделиться своим мнением о баге — его критичности, приоритете и побочных эффектах. Ясность часто рождается в подобных обсуждениях. Родитель избавляется от ненужного вызова неотложки, а тестировщик обнаруживает, что баг, который он относил к категории P0, на самом деле тривиален и панику можно отставить.

А теперь пора заняться составлением баг-репорта. Как родитель, который тянется за градусником, тестировщик расчехляет свои инструменты. Родитель хочет точно диагностировать болезнь. Мать хочет убедить доктора в серьезности болезни ее ребенка. Тестировщик тоже хочет повлиять на критичность, но что еще важнее — он хочет, чтобы баг легко было исправить. Снимки экрана, записи нажатий клавиш, данные трассировки стека, дампы DOM — все это пригодится для документирования бага. Чем больше информации будет у разработчика, тем легче будет найти причину и тем выше вероятность ее исправления.

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

Этот тест становится частью регрессионного пакета приложения. Его стремятся автоматизировать, чтобы проще было ловить регрессионные баги. Или, как минимум, создают ручной тест-кейс и заносят в систему управления тестами. Так формируется иммунитет системы к будущим заражениям — подобно тому, как ребенок получает иммунитет к тому виду бактерий, от которого он когда-то заболел.

Как мы нанимаем инженеров по тестированию

Мы в Google серьезно подходим к найму людей. У большинства наших инженеров высшее образование в области компьютерных технологий. В очень немногих учебных заведениях учат тестированию, поэтому до сих пор есть проблемы с наймом хороших тестировщиков. Сложно найти нужное сочетание навыков программирования и тестирования.

Найти специалиста на роль инженера по тестированию особенно тяжело, потому что лучшие из них не просто технари. Тестировщики в Google разрушают привычное представление об инженерах, на котором основан процесс найма разработчиков и разработчиков в тестировании. Откровенно говоря, мы не всегда все делали правильно и приносим извинения всем тестировщикам, которые пострадали от наших опытов совершенствования процесса собеседования. Инженеры по тестированию — редкие птицы. Они технически подкованы, заботятся об интересах пользователя, понимают продукт на всех уровнях от системной архитектуры до внешнего представления. Они неунывающие и общительные, и, что самое важное, изобретательные и умеют работать в условиях неопределенности. Только чудом можно объяснить, как Google (да и любая другая компания) умудряется поймать таких редких особей.

Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование.

Мы опробовали несколько стилей собеседования для инженеров по тестированию.

— Сначала мы собеседовали их так же, как разработчиков в тестировании. Если мы находили умного и изобретательного кандидата, который недостаточно хорошо для нас умел программировать, мы рассматривали его на роль тестировщика. Такой подход привел к проблемам, возникала неформальная иерархия в команде. Что еще хуже, таким способом мы бы никогда не добрались до кандидатов, которые ориентированы больше на пользовательские аспекты — насколько удобно использовать продукт или как он решает задачи пользователей. Таких ребят нельзя было пропускать.

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

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

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

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

Приложения становились все более сложными, пользовательские интерфейсы становились сложнее, чем google.com, поэтому армия тестировщиков в Google росла. Пользователей становилось больше, и наши продукты стали занимать важное место в их жизни. Поэтому роль тестировщиков стала более значительной в культуре Google.

Как отличить тестировщика от разработчика в тестировании

Джейсон Арбон

Роли разработчика в тестировании и инженера по тестированию взаимо­связаны, но между ними есть фундаментальные различия. Я был на обеих позициях и управлял обеими ролями. Взгляните на списки, которые я привожу ниже, и выберите, какое описание больше подходит вам, — может, вам стоит сменить профессию.

Вам больше подходит роль разработчика в тестировании, если вы:

— Можете взять спецификацию и запрограммировать надежное и эффективное решение с чистого листа.

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

— Вы думаете, что конечный пользователь — это тот, кто вызывает функцию API.

— Вас раздражает плохо написанная документация API, но вы иногда забываете, зачем этот API вообще нужен.

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

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

— Вы предпочитаете командную строку графическому интерфейсу и редко прикасаетесь к мыши.

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

— Вы никогда не замечали и не меняли обои своего рабочего стола.

— Вы переживаете, когда видите предупреждения компилятора.

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

— Успех для вас — это построить прекрасный низкоуровневый фреймворк юнит-тестирования, который используют все и который запускается на тестовом сервере миллионы раз в день.

— Когда вас спрашивают, готов ли продукт к выпуску, вы можете просто ответить: «Все тесты прошли».

Вам больше подходит роль инженера по тестированию, если вы:

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

— Вы лучше почитаете Slashdot или News.com, чем будете весь день читать чужой код.

— Если вы читаете недописанную спецификацию, вы сами заполняете все пропуски в документе.

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

— Вам становится плохо при виде пользовательских интерфейсов некоторых веб-сайтов. Вы не понимаете, как с ними вообще кто-то работает.

— Визуализация данных вызывает у вас радостное возбуждение.

— Вы ловите себя на желании пообщаться с людьми из реального мира.

— Вы не понимаете, почему вам нужно ввести «i», чтобы набрать текст в одном известном текстовом редакторе.

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

— Когда вас спрашивают, готов ли продукт к выпуску, вы можете сказать: «Я думаю, да».

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

Обе роли очень важны, чтобы создать великолепный продукт.

Собеседование с инженерами по тестированию

Ура, мы обнаружили необходимую комбинацию навыков и немедленно зовем кандидата на интервью. Нас часто спрашивают, как мы собеседуем инженеров по тестированию, причем это самый частый вопрос, который нам задают буквально везде. Полный список вопросов мы приводить не будем, но покажем несколько примеров, чтобы проиллюстрировать наш подход. Учтите, что после публикации эти вопросы уже неактуальны!

Для начала мы проверяем способности кандидата к тестированию. Наша цель — определить, выходит ли кандидат за рамки обычной сообразительности и изобретательности и есть ли у него природный дар к тестированию. Мы ищем врожденную любознательность к устройству систем, к комбинациям переменных и конфигураций, которые можно и интересно было бы протестировать. Нам нужен человек, который поймет, как система должна работать, и сможет это объяснить простыми словами. И еще у него должен быть сильный характер.

Мы даем тестовую задачу, зависящую от многих входных факторов и условий среды, а потом просим кандидата перечислить самые интересные из них. Например, мы просим кандидата протестировать веб-страницу (рис. 3.26) с одним полем ввода и кнопкой, при нажатии которой подсчитывается количество букв «A» в текстовой строке. Вопрос: составьте список входных строк, которые вы хотите протестировать.

Рис. 3.26. Простой пользовательский интерфейс для тестового вопроса

Некоторые кандидаты бросаются с места в карьер и начинают строчить тест-кейсы. (Звучит тревожная музыка.) Скорее всего, они недостаточно подумали над задачей. Мы воспринимаем стремление к количеству, а не к качеству, как знак опасности. Мы пришли к этому с опытом. О кандидате можно многое узнать еще до того, как он справится с задачей, просто посмотрев на то, как он ее решает.

Лучший кандидат — тот, который начинает задавать уточняющие вопросы: прописные или строчные буквы? А только ли английские? А текст стирается после вычисления ответа? Как насчет повторного нажатия кнопок? И так далее.

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

— «banana»: 3 (реально существующее слово)

— «A» и «a»: 1 (простой допустимый случай с положительным результатом).

— «»: 0 (простой допустимый случай с нулевым результатом).

— null: 0 (простой ошибочный случай).

— «AA» и «aa»: 2 (случай, в котором количество символов > 1, а строка состоит из одних «A»).

— «b»: 0 (простой непустой допустимый случай с негативным результатом).

— «aba»: 2 (искомый символ в начале и конце строки для выявления багов смещения на 1 в цикле).

— «bab»: 1 (искомый символ в середине строки).

— пробелы/табуляции/и т.д.: N (символы-пропуски чередуются с N символов «A»).

— длинная строка без «A»: 0

— длинная строка с «A»: N, где N равно количеству «A».

— X\nX в строке: N, где N равно количеству «A» (символы форматирования).

— {java/C/HTML/JavaScript}: N, где N равно количеству «A» (символы исполняемого кода, бага или случайная интерпретация кода).

Если кандидат пропускает какие-то из перечисленных тестов, снова звучит тревожная музыка.

Лучшие кандидаты не ограничиваются конкретным выбором входных данных задачи и переходят на более глубокие уровни тестирования. Они могут:

— Исследовать оформление, цветовую палитру и контрастность: соответствуют ли они оформлению других взаимосвязанных приложений? Доступны ли они для пользователей с дефектами зрения и т.д.?

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

— Поинтересоваться возможностью запуска нескольких экземпляров этого приложения на одном сервере. Нет ли опасности пересечения данных разных пользователей?

— Спросить, сохраняются ли данные? В них могут быть адреса или другая личная информация.

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

— Спросить, достаточно ли быстро это работает? А как будет работать под нагрузкой?

— Уточнить, как пользователь будет попадать на эту страницу и легко ли ее найти?

— Ввести код HTML и JavaScript. Не сломает ли это отображение страницы?

— Спросить, должны учитываться символы «A» только верхнего или только нижнего регистра либо обоих?

— Попробовать копировать и вставлять строки.

А некоторые кандидаты идут еще дальше, их не удержать рамками поставленной задачи. Вот они — опытные и ценные инженерные кадры. Они могут:

— Понять, что если данные передаются серверу в HTTP GET-запросе с URL-кодированием, строка может быть обрезана в процессе передачи по интернету. Поэтому нет никакой гарантии, что поддерживается любая длина URL-адресов.

— Предложить параметризацию приложения. Почему мы считаем только «A»?

— Подумать о возможности подсчета «A» из других языков (например, со знаками ангстрема или умляута).

— Подумать о возможности интернационализации этого приложения.

— Подумать о написании скриптов или вручную составить выборку строк определенной длины (допустим, степеней двойки), чтобы найти предел длины строки и убедиться в том, что значения внутри пределов обрабатываются правильно.

— Учесть возможную реализацию и ее код. Возможно, в реализации используются счетчик для перебора символов строки и переменная-накопитель для хранения количества обнаруженных символов «A». Тогда интересно было бы менять как общее количество «A», так и длину строки в районе граничных значений.

— Задать вопросы: «Могут ли метод HTTP POST и параметры подвергнуться хакерской атаке? Нет ли здесь проблем с безопасностью?»

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

Обратив внимание на длины строк, которые кандидат использует в своих тестах, можно понять, как он будет работать. Если он ограничивается понятием «длинная строка», а такое бывает часто, снова включается тревожная музыка. Продвинутые кандидаты обычно просят спецификацию строки, а затем прикидывают граничные тесты для нужных значений. Например, если максимальная длина строки 1000 символов, они попробуют 999, 1000 и 1001. Лучшие кандидаты возьмут еще и значение 2^32, и несколько промежуточных хитрых значений, например степени 2 и 10. Кандидаты должны понимать, какие значения важны для системы, а не просто брать случайные числа. Для этого им нужно хорошо разбираться в основных алгоритмах, языке, оборудовании и среде выполнения программ, потому что именно здесь водится большинство багов. Они попробуют варианты длины строки с учетом возможной реализации и подумают о возможности смещения счетчиков и указателей на единицу. Самые лучшие кандидаты понимают, что система может запоминать состояние и что в тестах нужно учесть значения, введенные раньше. Попробовать ввести одну и ту же строку несколько раз или проверить нулевую длину сразу после тысячи символов — важные сценарии, которые хорошо бы учесть.

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

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

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

Управление тестированием в Google

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

Управлять тестировщиками в Google — задача, очень сильно отличающаяся от управления обычным отделом тестирования. Причин тому несколько: у нас намного меньше тестировщиков, мы берем на работу только очень компетентных специалистов, ценим и поддерживаем разнообразие и самостоятельность в работе. В нашем понимании управление тестированием — это больше про «вдохновлять», чем про «руководить». Это больше про стратегию, чем про ежедневное руководство к действию. Наш подход делает управление тестированием более сложным и даже непредсказуемым, если сравнивать с нашими прошлыми местами работы. Чтобы управлять тестированием в Google, нужно уметь быть лидером и смотреть далеко вперед, уметь общаться и договариваться, быть подкованным технически, уметь проводить собеседования и разбираться в людях, нанимать людей и потом регулярно оценивать их работу.

Обычно в Google чрезмерная формализация управления вызывает напряженность. Перед директорами по тестированию, менеджерами и руководством Google стоит сложная задача — дать инженерам столько свободы, чтобы не ограничить их работу лишними условностями, но и не позволять им расслабляться и плевать в потолок. Google не жалеет ресурсов на крупномасштабные, стратегические решения. Наши менеджеры помогают избежать разработки дубликатов тестовых фреймворков и чрезмерных вложений в малые тесты, при этом они помогают собирать команды для масштабных проектов. Без такого присмотра внутренние проекты тестирования часто не выживают, если остаются всего лишь проектом одного инженера или не выходят за рамки «двадцатипроцентного» времени.

Управление «пиратским кораблем» для чайников

Джеймс Арбон

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

Я думаю, что это примерно так же, как управляет капитан своим пиратским кораблем. Дело в том, что капитан не может держать всю команду в узде с помощью грубой силы или страха, так как подчиненных много и все они вооружены до зубов отточенными техническими талантами и другими предложениями работы. Он не может управлять только одним золотом — пираты часто получают больше, чем им нужно для существования. Что действительно вдохновляет пиратов — это их образ жизни и волнение, испытываемое при виде очередной добычи. Всегда есть реальная угроза бунта, ведь структура Google очень динамична. Инженеров даже поощряют часто менять команды. Если корабль не нашел достаточно сокровищ или на нем невесело плыть, наши пираты-инженеры сходят с него в ближайшем порту и не возвращаются, когда приходит время поднимать паруса.

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

В Google есть несколько типов руководителей и менеджеров.

— Ведущий инженер (Tech Lead). Эти ребята появляются в больших командах, где много разработчиков в тестировании и тестировщиков работают над большим проектом с общими техническими проблемами и инфраструктурой. Они встречаются в командах, которые занимаются инфраструктурами, не зависящими от продукта. Обычно ведущие инженеры не управляют людьми. К ним инженеры обращаются с техническими проблемами или вопросами по тестированию. Часто это неформальная роль, которая выделилась естественным образом в процессе работы. Ведущий инженер всегда сосредоточен только на одном проекте.

— Технический менеджер (TLM, Tech Lead Manager). Это удивительное создание рождается, когда человек, к которому обращаются по техническим вопросам, еще и официально руководит командой инженеров проекта. Технические менеджеры очень уважаемы и влиятельны. Обычно они тоже работают только над одним важным проектом.

— Тест-менеджер (Test Engineering Manager). Те, кто координирует инженерную работу нескольких команд, называются тест-менеджерами. Почти все они выросли из рядовых сотрудников. Можно сказать, что эта роль в Google — аналог принятой в индустрии роли тест-менеджера, но с более широким полем действий, типичным для директоров в других компаниях. В их полномочиях выделять и забирать ресурсы тестирования на проектах. Обычно у них в подчинении от 12 до 35 человек. Тест-менеджеры распределяют людей между командами, регулируют совместное использование инструментов и процессов и рулят процессом поиска, собеседований и найма людей.

— Директор по тестированию (Test Director). У нас несколько таких директоров. Они немного координируют работу нескольких тест-менеджеров, а по большей части работают над общей перспективой тестирования, стратегическим управлением и иногда — преобразованиями в технической инфраструктуре и методологиях тестирования. Все-таки основное направление их работы — следить, как влияет качество тестирования на бизнес: анализ затрат, анализ эффективности и т.д. Их работа развернута наружу — показывать результаты другим. У директоров по тестированию обычно от 40 до 70 подчиненных. Каждый из них закреплен за отдельным направлением: Client, Apps, Ads и т.д.

— Старший директор по тестированию (Senior Test Director). Такой человек у нас один — Патрик Коупленд. Он отвечает перед высшим руководством компании за единообразие должностных инструкций, найм, внешние взаимодействия и общую стратегию тестирования в Google. Это его работа — распространять передовые практики, создавать и продвигать новые начинания, например инфраструктуру глобальной сборки или тестирования. Статический анализ и задачи по тестированию, которые касаются всех продуктов Google, пользовательские проблемы и база тестового кода — все это лежит в ответственности старшего директора по тестированию.

Большинство тех, кто работает в тестировании в Google, особенно директора и даже сам Патрик Коупленд, участвуют в поиске и наборе людей. Есть несколько подводных камней, на которые мы натыкаемся во время собеседований. Например, большинство кандидатов отлично знают компанию, ее основные технологии и то, что это отличное место для работы. Инженеры очень осторожны на собеседовании: они опасаются показать свое волнение и не пройти отбор. Хорошие кандидаты и так работают в хороших условиях, и их беспокоит сильная конкуренция внутри Google. Часто можно развеять все опасения, если интервьюер представится и расскажет немного о себе. Инженеры в Google, безусловно, профессиональные и воодушевленные. И все же большая часть того, что заставляет их работу выглядеть такой интересной и даже героической, ­— это просто грамотное использование коллективного разума сообщества инженеров-единомышленников и технических мощностей Google.

У нас есть и процесс внутреннего подбора людей. Инженеров поощряют менять проекты, поэтому движение между командами есть всегда. Если команде нужны люди, ей нужно рассказывать всем о том, почему у них круто работать. Большинство внутренних перемещений — результат личного общения, когда инженеры обсуждают интересные проекты, технические проблемы и общую атмосферу в команде. Иногда проводятся полуформальные встречи, на которых команды, желающие привлечь инженеров, показывают, над чем они работают. Но по большей части внутренний набор людей в команды — процесс очень естественный и гармоничный. Люди просто могут перейти туда, где они хотят работать и где, как им кажется, их работа принесет наибольшую пользу.

Давайте отметим основные аспекты работы руководителей тестирования.

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

— Переговоры. Невозможно постоянно заниматься только тестированием. Руководители разработки постоянно требуют ресурсов и внимания тестирования, поэтому тест-менеджеры должны уметь вежливо и обоснованно отказывать.

— Внешние коммуникации. Менеджерам доводится работать с внешними исполнителями, нанятыми для временной работы в проекте или для тестирования продуктов извне. В зоне их ответственности организация мероприятий для обсуждения и обмена новыми инженерными практиками в области тестирования с широкой публикой. Живой пример тому — конференция GTAC.

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

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

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

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

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

Управлять тестированием — значит находить компромиссы и прислушиваться к каждому человеку. Управлять в Google — значит направлять и опекать своих людей, а не командовать ими. Возвращаясь к аналогии с пиратами: хороший руководитель обеспечивает семь футов под килем и попутный ветер.

Тестирование в режиме сопровождения

Google известен своими ранними и частыми выпусками, а еще — стремлением понять, что проект провальный, как можно быстрее. Поэтому мы можем срочно перебросить ресурсы на проект с наибольшими рисками. Что это значит для тестировщика? Фичи, над которыми он работает, а иногда и целые проекты могут потерять приоритет или полностью свернуться. Как с технической, так и с эмоциональной стороны инженер должен быть готов к этому. Да, возможно, вам придется бросить все, когда вы только что расставили все по полочкам, и начать сначала. Это не самые приятные моменты, и изменения могут обернуться высокими рисками и затратами, если действовать неосторожно.

Пример режима сопровождения: Google Desktop

Джейсон Арбон

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

Когда мы с двумя коллегами-тестировщиками влились в работу над проектом, у Google Desktop уже было около 2500 тест-кейсов в старой базе данных Test Case Manager, а несколько старательных подрядчиков в хайдарабадском офисе прогоняли эти тест-кейсы для каждого выпуска. Циклы прохождения тестов часто занимали по неделе и больше. Раньше уже были попытки автоматизировать тестирование продукта через пользовательский интерфейс, но они не удались из-за сложности проекта и их затратности. Управлять веб-страницами и пользовательским интерфейсом окна рабочего стола через C++ было непросто, постоянно возникали проблемы с задержками.

Моими коллегами-тестировщиками были Теджас Шах и Майк Мид. Тогда в Google ресурсы клиентского тестирования были ограничены. Так как большинство продуктов уже работало в веб или быстро туда переходило, мы решили взять фреймворк тестирования на Python, который разработали для Google Talk Labs Edition. Он управлял продуктом через веб-модель DOM. В этом простом фреймворке были реализованы основные средства — например, класс тест-кейсов, производный от PyUnit. Многие тестировщики и разработчики знали Python, так что у нас была стратегия выхода на всякий случай. А если бы что-то сломалось, многие другие инженеры могли помочь. Кроме того, Python прекрасно подходит для итеративной разработки маленьких фрагментов кода без компиляции. В Google он устанавливается на рабочие станции инженеров по умолчанию, так что весь тестовый пакет мог быть развернут одной командной строкой.

Мы с ребятами решили применить весь диапазон возможностей Python API для управления продуктом. Мы использовали ctype для управления COM API на стороне клиента для поиска, мы моделировали ответы сервера для тестового внедрения локальных результатов в результаты google.com (нетривиальная задача!), работали с множеством библиотечных функций, чтобы имитировать пользователя и воссоздать его путь в приложении. Мы даже построили систему виртуальных машин для автоматизации тестов, которым нужны индексы Google Desktop. Иначе нам пришлось бы несколько часов ждать завершения индексирования на новой установке. Мы сформировали небольшой автоматизированный пакет смоук-тестирования, покрывающий самые важные функции продукта.

Потом мы принялись изучать старые тест-кейсы. Многие из них было сложно даже понять. Например, там были ссылки на код из прототипов или уже удаленных функций ранних версий или же они сильно зависели от контекста и состояния машин. К сожалению, большая часть документации жила только в головах разработчиков из Хайдарабада. Если бы нам вдруг понадобилось быстро проверить сборку с фиксами безопасности, у нас бы ничего не вышло. Это обошлось бы слишком дорого. Поэтому мы решились на смелый шаг — проанализировали все 2500 тестов, выявили самые важные и актуальные из них, а потом удалили все, оставив примерно 150 тестов. Да, количество тест-кейсов удалось здорово сократить. Поработав вплотную с подрядчиками, мы довели до ума оставшиеся ручные тест-кейсы — последовательность действий стала настолько ясной и подробной, что ее мог выполнить любой, кто пользовался Google Desktop хотя бы несколько минут. Мы не хотели остаться единственными людьми, которые могли выполнить регрессионную серию.

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

Примерно тогда же начался проект Chrome, и это направление считали будущим для сервисов Google на клиентских машинах. Мы уже были готовы пожинать плоды наших трудов по автоматизации с полнофункциональным тестовым API, занесли руку над построением генерируемых тестов для длительного выполнения, но тут пришло распоряжение быстро перебросить ресурсы на браузер Chrome.

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

Но у нас оставался еще один капризный баг: в некоторых версиях Google Desktop у некоторых пользователей поглощалось свободное пространство на диске. Решение проблемы откладывалось, потому что мы не могли воспроизвести его. Мы попросили своего коммьюнити-менеджера собрать больше информации от пользователей, но никто не смог четко определить проблему. Мы переживали, что со временем этот баг мог затронуть большее количество пользователей, а без полноценной команды на проекте он не будет решен вообще. Поэтому перед уходом мы бросили все силы на исследование этой проблемы. Дошло до того, что автора исходного кода индексирования выдернули на проект из другого места, полагая, что он знает, где нужно искать. И он знал. Разработчик заметил, что Desktop продолжает повторно индексировать задачи, если у пользователя установлен Outlook. Дело в том, что код индексирования при каждом сканировании принимал старую задачу за новую и медленно, но верно пожирал жесткий диск. А предпочитал этот гурман только диски тех пользователей, которые пользовались планировщиком задач Outlook. Так как максимальный размер индекса 2 Гбайта, он заполнялся очень медленно, и пользователи замечали только то, что их новые документы не проиндексировались. Мы выпустили последнюю версию Desktop с исправлением этого бага, чтобы нам не пришлось возвращаться к этой проблеме через полгода на проекте с урезанной командой.

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

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

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

При исключении ручных тестов мы руководствуемся следующими правилами:

— Мы ищем тесты, которые всегда проходят, или тесты с низким приоритетом. Это наши первые кандидаты на выбывание!

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

— Освободившееся время мы используем для автоматизации, анализа высокоприоритетных тестов или исследовательского тестирования.

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

Несколько советов, которые лучше бы учесть перед переходом в режим сопровождения.

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

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

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

— Убедитесь в том, что у вас есть схема эскалации при возникновении проблемы. Оставьте и себе место в этой схеме.

— Всегда будьте готовы оказать помощь проектам, над которыми вы когда-то работали. Это полезно для продукта, команды и для пользователей.

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

Эксперимент с Quality Bots

Как изменится тестирование, если мы забудем о наших методах и инструментах, а возьмем на вооружение инфраструктуру поисковых движков? Почему бы и нет, ведь там есть бесплатное процессорное время, свободное пространство и дорогая система вычисления, работающая над алгоритмами! Давайте поговорим о ботах, а конкретнее — о Quality Bots.

Завершив множество проектов по тестированию в Google и поговорив со многими командами, мы осознали, что блестящие умы наших инженеров часто растрачиваются на ручное построение и выполнение регрессионных тестов. Поддерживать автоматизированные тестовые сценарии и вручную проводить регрессионное тестирование — дорогое удовольствие. К тому же медленное. Добавляет масла в огонь то, что мы проверяем ожидаемое поведение, — а как же неожиданное?

Регрессионные тесты обычно проходят без ошибок в более чем 95% случаев. Скорее всего, так происходит потому, что практика разработки в Google заточена на качество. Но, что важно, эта рутинная работа притупляет способности инженеров, которых мы нанимали вообще-то за любознательность и изобретательность. Мы хотим освободить наших ребят для более сложного, исследовательского тестирования, для которого, собственно, мы их и брали в команду.

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

1. Обход. Боты работают в вебе прямо сейчас. Тысячи виртуальных машин, вооруженные скриптами WebDriver, открывают в основных браузерах популярные URL-адреса. Перепрыгивая от одного URL-адреса к другому, словно обезьянки с лианы на лиану, они анализируют структуру веб-страниц, на которые приземляются. Они строят карту, которая показывает, какие элементы HTML отображаются, где и как.

2. Индексирование. Боты передают сырые данные серверам индексирования, где информация упорядочивается по типу браузера и времени обхода. Формируется статистика о различиях между обходами, например количество обойденных страниц.

3. Ранжирование. Когда инженер хочет посмотреть результаты для конкретной страницы по разным обходам или результаты всех страниц для одного браузера, система ранжирования вычисляет оценку качества. Проще говоря, система оценивает сходство страниц в процентах: 100% означает, что страницы идентичны. Соответственно, чем меньше процент сходства, тем больше различий.

4. Результаты. На информационной панели можно посмотреть сводку результатов (рис. 3.27). Подробные результаты строятся в виде простой таблицы оценок для каждой страницы с указанием сходства в процентах (рис. 3.28 и 3.29). Для каждого результата инженер может копнуть глубже и получить информацию о визуальных различиях. Они показаны с помощью наложения результатов разных проходов с указанием XPath-путей элементов и их позиций (рис. 3.30). Инструмент показывает средние минимальные и максимальные исторические показатели этого URL-адреса и другую подобную информацию.

Рис. 3.27. Сводка информации для разных сборок Chrome

Рис. 3.28. Типичная таблица с подробной информацией от ботов

Рис. 3.29. Таблица информации от ботов, отсортированная для выявления наибольших различий

Рис. 3.30. Анализ визуальных различий для идентичных страниц

Первый же официальный запуск проекта нашел различие между двумя канареечными сборками Chrome. Боты провели проверку автоматически. Тестировщик оценил результаты и заметил, что этот URL-адрес потерял несколько процентов сходства. Тестировщик быстро сообщил о проблеме, ссылаясь на подробную картинку (рис. 3.31) с выделенной частью страницы с различиями. Раз боты могли протестировать все версии Chrome, инженер мог быстро справляться с новыми регрессионными багами. Каждая сборка содержала всего несколько изменений, и заливку с проблемным кодом оперативно изолировали. Оказалось, что коммит в репозиторий WebKit (ошибка 56859: reduce float iteration in logicalLeft/RightOffsetForLine) вызвал регрессионный баг, из-за которого средний элемент div на этой странице стал отображаться ниже границы страницы. Тестировшик завел баг 77261: Макет страницы ezinearticles.com неправильно отображается в Chrome 12.0.712.0.

Рис. 3.31. Первый баг, обнаруженный при первом запуске ботов

Как мы прогнозировали (и надеялись), данные от ботов оказались очень похожи на данные, получаемые от их одушевленных аналогов, и во многом даже лучше. Большинство веб-страниц оказывались идентичными в разных версиях браузеров, и даже если находилось различие, инженер быстро просматривал его и понимал, есть ли что-то серьезное.

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

Если оставить версию браузера неизменной, а менять при этом только данные одного сайта, мы получим средство для тестирования сайтов, а не только браузера. Такую же штуку можно провернуть с анализом одного URL-адреса по всем браузерам и всем сериям тестов. То есть у веб-разработчика появилась возможность просмотреть все изменения, происходящие с его сайтом: он создает новую сборку, дает ботам ее обойти и получает таблицу результатов, где показаны все изменения. Быстро, безо всякого ручного тестирования, веб-разработчик определяет, какие изменения из обнаруженных не заслуживают внимания, а какие похожи на регрессионный баг и достойны занесения в багтрекинговую систему, причем сразу с информацией о браузерах, версии приложения и конкретных элементах HTML, где он водится.

А как насчет веб-сайтов, управляемых данными? Возьмем, например, сайты YouTube и CNN — их контент огромен и изменяется со временем. Не запутаются ли боты? Они справятся, если будут предупреждены о нормальных колебаниях данных этого сайта. Например, если в нескольких последовательных сериях изменился только текст статьи и картинки, то боты посчитают изменения уместными для данного сайта. Если показатели выйдут за рамки (допустим, при нарушении IFRAME или при переходе сайта на другой макет), боты могут подать сигнал тревоги и сообщить об этом веб-разработчику, чтобы он определил, нормально ли новое состояние или пора заводить соответствующий баг. Пример небольшого шума можно увидеть на рис. 3.32: на сайте CNET есть реклама, которая во время проверки

Рис. 3.32. Анализ визуальных различий для страниц с шумовыми различиями

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

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

Как мы получаем данные от сообщества? Гениальное — просто: мы построили инфраструктуру, которая транслирует необработанные данные ботов на обычную страницу голосования для тестировщиков. Разумеется, мы сравнивали работу краудсорсеров со стандартными методами ручного рецензирования. Схема была следующая: боты пометили только шесть URL-адресов как требующие дополнительной проверки. Помеченные URL-адреса получили тестировщики из сообщества. Имея в арсенале данные ботов и инструменты визуализации различий, краудсорсеры определяли, ошибка ли это, в среднем за 18 секунд. А проверка всех 150 URL-адресов на регрессию ручными методами заняла около трех дней. Тестировщики из сообщества успешно определили все шесть различий как несущественные. Результаты работы краудсорсеров и ручной затратной формы проверки совпали! А зачем платить больше?

Звучит здорово! Правда, этот метод подходит только для статических версий веб-страниц. А как насчет интерактивных элементов — раскрывающихся меню, тестовых полей и кнопок? Мы ведем работу по решению этой проблемы, можно сказать, мы открыли киностудию: боты автоматически взаимодействуют с интересующими нас частями веб-страницы и снимают на каждом шаге кадр DOM. Затем «фильмы» каждой серии сравниваются покадрово с помощью той же технологии анализа различий.

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

Базовый код проекта Bots работает в инфраструктурах Skytap и Amazon EC2. Код сервиса распространяется по модели открытого кода (подробнее в блоге тестирования Google и приложении В). Теджас Шах был техническим руководителем Bots с первых дней существования проекта; позднее к нему присоединились Эриэл Томас, Джо Михаил и Ричард Бустаманте. Присоединяйтесь и вы к этим ребятам, чтобы двигать эксперимент дальше!

Как оценить качество всего интернета

Чтобы измерить, насколько хорошо поисковая система справляется с запросами, для теста мы берем случайную репрезентативную выборку поисковых запросов. По результатам можно судить, как система будет работать со всеми запросами, — мы просто экстраполируем данные. А если мы используем Bots на репрезентативной выборке URL-адресов, мы можем судить о качестве интернета в целом.

Сингулярность:

[54]

легенда о происхождении ботов

Джейсон Арбон

Давным-давно, в далеком-далеком офисе Google родилась… первая версия Chrome. Уже по первым поступившим данным было понятно, что Chrome отображает веб-страницы иначе, чем Firefox. В начале мы оценивали эти различия, только отслеживая объем поступающих сообщений о багах и подсчитывая количество жалоб на проблемы совместимости от пользователей, которые удаляли браузер после пробного использования.

Мне было интересно, есть ли более многоразовый, автоматизированный и объективный метод оценки того, насколько хорошо мы работаем в этой области. Были ребята до меня, которые пытались организовать автоматическое сравнение снимков веб-страниц между браузерами, а кто-то даже пытался использовать продвинутые методы распознавания изображений и границ. Правда, эти методы часто не работали, потому что между страницами всегда много различий, вспомните хотя бы о разных картинках в рекламе, меняющемся контенте и т.д. В базовых тестах макетов WebKit вычислялся хэш-код всего макета страницы (см. рис. 3.33). Поэтому когда обнаруживалась проблема, инженеры не имели понятия о том, что именно в приложении не работает, у них был только снимок ошибки. Многочисленные ложноположительные срабатывания только прибавляли работы инженерам, вместо того чтобы уменьшать ее.

Рис. 3.33. В ранних средствах тестирования макетов WebKit использовались хэши всего макета страницы. Теперь мы можем тестировать целые страницы и обнаруживать сбои на уровне элементов, а не на уровне страницы

Мысли постоянно возвращали меня к ранней простой реализации ChromeBot, которая обходила миллионы URL-адресов в запущенных копиях браузера Chrome на тысячах виртуальных машин. Она искала всевозможные сбои, используя для этого свободное процессорное время в центрах обработки данных. Это был ценный инструмент, который находил баги на ранней стадии, а функциональное тестирование взаимодействия с браузером добавлялось позже. К сожалению, технология утратила свою новизну и использовалась только для выявления редких сбоев. А что, если построить более серьезную версию этого инструмента, которая будет нырять во всю страницу целиком, а не только ходить по берегу? И назвать ее, например, Bots.

Я подумал об использовании другого подхода: работы в DOM. Около недели ушло на подготовку эксперимента, в котором загружалось много веб-страниц одна за другой, а потом в них внедрялся код JavaScript, который извлекал карту внутренней структуры веб-страницы.

Многие умные люди скептически отнеслись к этому решению. Они считали, что моя идея была обречена на неудачу, потому что:

— реклама постоянно изменяется;

— контент на таких сайтах, как CNN.com, постоянно меняется;

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

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

— работа потребует огромных объемов данных.

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

Чтобы запустить эксперимент, мне нужны были контрольные данные, с которыми я мог бы сравнивать полученные. Лучшим источником информации были тестировщики проекта Chrome, ведь они каждый день вручную открывали около 500 популярных сайтов в Chrome, пытаясь найти различия с Firefox. Я поговорил с подрядчиками, которые прогоняли вручную все эти сайты и сравнивали результаты с Firefox. Они рассказали, что сначала проблемы находились почти в половине популярных сайтов, но ситуация постепенно улучшалась, и сейчас расхождения встречаются редко — менее чем в 5% сайтов.

Я взял WebDriver (Selenium следующего поколения) и провел эксперимент. WebDriver лучше поддерживал Chrome, и его API куда более понятный. В первый прогон я собрал данные в разных версиях Chrome, от ранних до текущей, чтобы увидеть, найдет ли автоматизация такой же тренд. Тесты просто загружали те же веб-сайты, проверяли каждый пиксель, определяли, какой элемент HTML (не RGB-значение!) был видим в этой точке, а потом отправляли данные на сервер. Выполнение на моем компьютере занимало около 12 часов, поэтому я запустил программу на ночь.

Полученные данные выглядели хорошо, поэтому я заменил Firefox на Chrome и снова запустил те же тесты на ночь. Конечно, мог появиться шум от изменения контента сайтов, но моя задача была только узнать, как выглядят данные, а потом выполнить обе серии параллельно. Когда я пришел утром в офис, я обнаружил, что мой компьютер выдернут из розетки. Мои соседи странно посматривали в мою сторону и сказали, что мне нужно поговорить со специалистами по безопасности. Я мог только догадываться, что они себе надумали. Оказалось, что во время обхода мой компьютер подхватил вирус с неизвестной сигнатурой, который и разбушевался ночью. Меня спросили, хочу ли я снять данные со своего компьютера, прежде чем диск будет уничтожен. К счастью, все мои данные хранились в облаке, и я отпустил свой компьютер с миром. После этого я стал запускать такие тесты только с внешних виртуальных машин.

За двое суток машины независимо выдали данные, которые были ужасно похожи на те, что мы получили примерно за год ручной тестовой работы (см. рис. 3.34). Подозрительно похожи.

Рис. 3.34. Первые данные, демонстрирующие сходство между метриками количества, вычисленными людьми и ботами

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

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

Bots: детство, отрочество и масштабирование на весь интернет

Теджас Шах

Я — технический руководитель проекта Bots, я хочу масштабировать технологии Bots на весь интернет и открыть их миру. Проект Bots вырос из ранних экспериментов в полноценную технологию, которую используют многие команды в Google.

В конце 2010 года я работал над средой автоматизации для Chrome, известной как SiteCompact. Она использовала тесты JavaScript, чтобы автоматически находить функциональные баги в Chrome при просмотре популярных сайтов. Она проверяла как поиск на google.com, так и отображение статей на CNN почти для всех сборок Chrome. Система работала на «отлично», выявляла регрессионные баги и дополняла автоматизированные функциональные проверки поведения сайтов.

В то же время интерны Джейсона работали над демоверсией крутейшего проекта 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 добавляет их автоматически, и это здорово упрощает сортировку и отладку багов. Ну или от тестировщика нужно совсем немного усилий, но все равно он не сильно отвлекается от самого тестирования.

1. Снимок экрана создается автоматически и прикладывается к отчету о баге.

2. В отчет вкладывается код HTML выделенного элемента.

3. Все действия, совершенные с перехода на maps.google.com, записываются в фоновом режиме и преобразуются в код JavaScript. Если разработчик захочет понаблюдать, как воспроизводится этот баг в его браузере, ему достаточно открыть ссылку на код, которая будет автоматически приложена к отчету (обратите внимание на рис. 3.38).

4. Отладочные URL-адреса конкретной карты тоже будут автоматически прикреплены к отчету. Часто в обычных адресах недостаточно информации для полного воспроизведения.

5. Все данные о браузере и ОС тоже прикладываются.

Рис. 3.37. BITE: встроенная форма сообщения о баге

Информация о баге заносится в багтрекинговую систему с полной информацией для приоритизации, и скорости регистрации багов позавидует любой пилот истребителя.

Рис. 3.38. BITE: код JavaScript, записанный в ходе тестирования

 

Просмотр багов в BITE

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

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

Рис. 3.39. BITE: панель с перечнем багов, относящихся к maps.google.com

Рис. 3.40. BITE: панель багов на домашней странице YouTube

Число рядом со значком BITE в браузере указывает, сколько багов связано с текущей веб-страницей. Это очень просто делается для багов, которые завели через BITE. У нас есть все данные про них, вплоть до части страницы, где он проявился. А с багами, заведенными традиционным способом, например непосредственно в Issue Tracker или в нашей внутренней системе Buganizer, мы поступаем по-другому. У нас есть бот, который ищет URL-адреса в их описаниях и сравнивает степень их соответствия с URL-адресом текущей страницы. Сначала показываются точные совпадения, потом совпадения путей, а потом совпадения с доменом текущего URL-адреса. Схема простая, но очень надежная.

Рисунок 3.39 показывает, как выглядит страница карты с наложенной панелью багов BITE. Один клик на номер бага откроет полную страницу отчета в Buganizer или Issue Tracker. На рис. 3.40 показана панель багов на странице YouTube.

 

Слияние BITE с RPF

Джеймс Арбон

В первые дни тестирования Chrome OS мы обнаружили, что главное качество платформы — безопасность — сильно осложняет тестирование. Тестируемость часто конфликтует с безопасностью, а ведь в Chrome OS очень большой упор сделан именно на безопасность.

В ранних сборках еще была частичная поддержка виртуальных Java-машин (JVM) с ограниченной сетевой функциональностью и поддержкой других базовых библиотек. Так как основные сценарии пользователя основаны на просмотре веб-страниц, мы решили написать несколько тестов с использованием Selenium, чтобы проверить базовую функциональность браузера, и надеялись, что получится просто портировать все уже готовые тесты Selenium для регрессионного тестирования.

Простейшие тесты заработали, но радоваться было рано: мы столкнулись с отсутствием полноценной поддержки Chrome в Selenium и WebDriver. Вернувшись к работе после праздников, мы обнаружили, что из базовой ОС Linux исключили поддержку Java, чтобы повысить уровень безопасности Chrome OS. Конечно, это осложнило выполнение тестов на Java, но мы решили проблему, построив специальную сборку Chrome OS с встроенной поддержкой Java. Это, конечно, было обходное решение, и мы не были им довольны на все сто.

В Google часто говорят, что «дефицит приносит ясность». Это работает в мире тестирования, как нигде больше. Это сработало и для нас в тот момент. Хорошенько оценив ситуацию, мы поняли, что решение было так себе. По сути, мы не тестировали реальный продукт в том виде, в котором им будет пользоваться наш клиент. Мы строили образы Chrome OS, которые содержали Java, артефакты тестирования (jar-файлы), и отключали некоторые средства безопасности. Посмотрите на фотографию нашей лаборатории автоматизации тестирования ранних версий Chrome OS (рис. 3.41).

Рис. 3.41. Лаборатория тестирования ранних версий Chrome OS

Вскоре нужное решение пришло. Мы вспомнили про проект нашего коллеги По Ху по автоматизации тестирования веб-страниц с использованием JavaScript через расширения Chrome. Это могло сработать. Он назывался Puppet, и это был внутренний API, похожий на WebDriver и работающий только на JavaScript. Правда, из-за межсайтовых ограничений он должен был развертываться вместе с тестируемым веб-приложением. Мы рискнули поместить сценарий Puppet в расширение Chrome, чтобы оно работало для любых сайтов. И — о чудо! — установив только это расширение и сохранив тесты в облаке, мы смогли выполнять браузерные тесты в Chrome OS даже на компьютере Chromebook, только что купленном в магазине. Реализация этой идеи заняла бы у нас больше времени, чем у нас было до выпуска Chrome версии 1, и мы подвинули этот проект в список инструментов, которые нужно разработать к следующей версии.

Кстати, исходная версия BITE называлась Web Test Framework, или WTF, и нам сошло это с рук. Официально считалось, что сокращение происходит от названия, а не наоборот. А вот метод RPF изначально назывался Flux Capacitor, так как она позволяла двигаться назад в будущее.

Google Test Analytics

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

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

— Простые, но важные вещи, например четырехбалльная шкала оценки и общая схема названий из ACC-анализа, порой теряются при попытках сократить количество полей в таблицах.

— Данные не хранятся централизованно, поэтому недоступны всегда и всем. Командам приходится запрашивать друг у друга информацию устно при каждой необходимости.

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

Google Test Analytics (GTA) — наша попытка решить эти проблемы. В интерфейс GTA встроены методы ACC-анализа, это простое приложение упрощает ввод данных и работу с рисками. Все данные представлены по одной схеме — менеджеры и директора могут легко получить сводку рисков по всем своим проектам, чтобы перераспределить ресурсы в более опасные области.

Итак, GTA поддерживает модель анализа рисков ACC. Атрибуты и компоненты вводятся в простые формы и формируют таблицы (рис. 3.42 и 3.43), а интерфейс позволяет добавлять возможности в ячейки при планировании тестирования (рис. 3.44). Чтобы добавить риск, нужно просто выбрать частоту и степень воздействия из выпадающих списков для каждой возможности. Все эти значения сводятся в общую витрину рисков. Итоговый риск для каждой области (рис. 3.45) считается простым усреднением рисков по ней.

Рис. 3.42. Test Analytics: ввод атрибутов для Google+

Рис. 3.43. Test Analytics: ввод компонентов для Google+

Рис. 3.44. Test Analytics: ввод возможностей в ячейке. Обратите внимание: вводится количество возможностей на пересечении, а не величина риска

Рис. 3.45. Test Analytics: карта рисков для Google+

Возможность связать расчет рисков с текущими данными проекта — это опциональная экспериментальная возможность GTA. Вы добавляете новые тесты, пишете новый код, находите новые дефекты, и оценка риска меняется. Как инженеры по тестированию, мы и так всегда держали все эти изменения в голове, эта фича просто позволяет опираться на фактические данные и делать это более системно. Тест-планы, даже основанные на рисках ACC, часто хороши в начале планирования тестирования. Но скоро они могут устареть и покрыться пылью. Хотя в GTA всегда можно внести любые изменения при получении любых новых данных, мы хотим автоматизировать и эту сторону планирования тестирования.

Пока GTA умеет связывать свои данные только с нашими внутренними базами, но мы работаем над избавлением от этой зависимости в будущем. Работая с возможностями в GTA, тестировщики могут ссылаться на секции или запросы в багтрекинговой системе, ветку кода или номер тест-кейса. В Google все используют одни и те же базы, поэтому это работает. Как только метрики багов, кода или тестов меняются, запускаются простые подсчеты и риски пересчитываются. Сейчас несколько команд разработки испытывают этот метод на себе.

Правила расчета, которые мы используем, постоянно меняются, поэтому мы их не будем здесь приводить. По сути, они показывают, как изменилось число багов, строк кода, прошедших и упавших тестов к завершению оценки рисков. Мы учитываем то, что у разных команд разные подходы, ведь некоторые заносят даже мельчайшие баги или по-другому измеряют свой код. Каждый компонент риска масштабируется в рамках условий проекта. Посмотрите примеры связей данных с рисками для Google Sites на рис. 3.46–3.48.

Рис. 3.46. Test Analytics: связь источников данных с риском

Рис. 3.47. Test Analytics: связанные тесты

Рис. 3.48. Test Analytics: связанные баги

Легко не заметить одну очень важную функцию в GTA: тестировщики могут быстро превратить список возможностей в серию тестов. Команды очень просили добавить именно эту фичу. Смысл в том, что возможности — это простой список высокоуровневых тестов, который нужно прогнать перед выпуском программы. Для маленьких команд, которые фокусируются на исследовательском тестировании, например как команда Google Docs, этот список можно легко использовать вместо базы данных тестов.

В GTA используется матрица ACC-анализа, и это дает тестировщикам кардинально новый подход. Обычно тестовые серии или задания на разработку тестов назначаются по компонентам. ACC позволяет распределять тестировщиков по атрибутам. Наши эксперименты показали, что такой фокус работает лучше всего. Если за тестировщиком закрепить атрибут «быстрый» для всего набора тестов, то он может оценить, насколько быстро работают все интересующие компоненты продукта за одну серию тестов. Так можно выловить медленные компоненты, которые при независимом тестировании могли прикидываться достаточно быстрыми.

Что же со связями и зависимостями между рисками разных проектов? В GTA эта фича пока не реализована. Каждый проект делает свой ACC- анализ и оценивает риски только для своего проекта, без учета других проектов компании. Если кто-то хочет проанализировать риски нескольких продуктов сразу, ему нужно нормировать данные между проектами, чтобы смотреть на них в совокупности. Только то, что ваша маленькая команда работает над внутренним инструментом, не значит, что у вас не может быть максимальных значений рисков. Оставьте относительность тем, кто видит много проектов сразу. Когда оцениваете риск для своего проекта, оценивайте его так, как будто ваш проект — единственный в компании. В нем вполне могут быть часто срабатывающие риски с высокой степенью воздействия.

Сейчас проект GTA используется еще в нескольких компаниях, и мы хотим сделать GTA общедоступным продуктом с открытым кодом. Мы хотим, чтобы другие команды тестирования могли устанавливать у себя свои системы на движке Google App Engine или даже портировать код и разворачивать на других платформах.

GTA делает анализ рисков настолько простым и удобным, что люди действительно им пользуются. Джим Рирдон вырастил GTA с нуля и сейчас поддерживает его в опенсорсе (подробнее об этом мы рассказываем в приложении В). На момент написания книги несколько больших компаний, занимающихся облачным тестированием, хотят интегрировать эту технологию в свои рабочие процессы и инструменты. И еще около 200 внешних инженеров записались на использование GTA.

Бесплатное тестирование

Google сокращает время отклика, борясь буквально за каждую миллисекунду, и старается сделать свои системы суперэффективными. И конечно, нам нравится делать свои продукты бесплатными. Наши тестировщики делают то же самое со своими инструментами и процессами. Google просит нас мыслить масштабно, так давайте рискнем и снизим стоимость тестирования почти до нуля!

Почему нам это интересно? Работает простая схема: если тестирование бесплатно, маленькие компании и стартапы смогут позволить себе тестирование. Если тестирование бесплатно, интернет становится лучше, а это интересах пользователей и Google.

Мы представляем, что бесплатное тестирование это:

— почти нулевые затраты;

— мгновенное получение результатов;

— минимум человеческих ресурсов;

— супергибкость. Мы не верим, что всем может подойти одно и то же.

Чтобы задача соответствовала времени и остальным проектам Google, мы решили начать с веб-тестирования, надеясь, что к моменту завершения работы весь мир все равно будет работать в облаке, а драйверы и COM останутся в прошлом. Мы знали, что если будем создавать бесплатный продукт, то при любом исходе получим что-то интересное.

Итак, у нас получилась модель, которая здорово сокращает затраты на тестирование и ловко обходит проблемы. В наших лабораториях уже созрели первые плоды такой модели (рис. 3.49). Схема работы такая.

1. Планирование с GTA. Основанное на анализе рисков, быстрое и автоматически обновляемое планирование тестирования.

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

3. Оценка багов. Обнаруженные различия автоматически передаются специалистам для оценки. Итак, регрессия или новая фича? Здесь поможет BITE, который показывает информацию о заведенных багах в контексте этой оценки.

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

5. Регистрация багов. Всего несколько кликов — и баг зарегистирирован, а в отчете можно найти снимки экрана, конкретное место появления и информацию для отладки.

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

7. Развертывание новой версии и возвращение к шагу 1. Повторяем все заново.

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

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

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

Рис. 3.49. Сквозной процесс бесплатного тестирования

Инновации и эксперименты в тестировании

Джеймс Арбон

Мы в Google за любые эксперименты, поэтому у нас и создается множество инноваций. Ну и куча неудачных экспериментов заодно. Даже если уже есть хорошее решение, мы не запрещаем инженерам пытаться придумать еще лучше. Собственно, переосмысливать, анализировать и улучшать — это их работа.

Когда Джеймс Уиттакер пришел в Google, первым делом он организовал внутреннюю встречу технических специалистов и рассказал, каким он видит будущее тестирования. В его понимании тестирование должно напоминать видеоигры: как и в шутерах от первого лица, на тестируемое приложение должна накладываться полная контекстная информация. Мало кто мог представить, что его доклад на конференции GTAC задаст тон работе на несколько лет вперед. Конечно, на слайдах его идеи смотрелись хорошо, но построение общего решения для всех клиентских приложений казалось делом очень дорогим и сложным.

Я скептически относился к смелым идеям Джеймса, пока вдруг не осо­знал, что уже могу почти моментально реализовать их в браузере для веб-приложений с помощью API новых расширений Chrome. Идея захватила меня настолько, что всю следующую неделю я провел в работе над прототипом. Я даже приостановил свою текущую работу и провел выходные в Starbucks, неистово программируя. Сотрудники кофейни интересовались у меня, не ищу ли я работу в интернете, и мне оставалось только постучать по дереву.

Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов:

— наложение информации о багах на страницу и даже на ее конкретные элементы;

— наложение тест-кейсов на тестируемую страницу с одной кнопкой для результата теста (рис. 3.50);

— тепловую карту, на которой было видно, чем раньше занимались другие тестировщики и какие значения использовали (рис. 3.51).

Рис. 3.50. Пользовательский интерфейс тестовых примеров

Рис. 3.51. Тепловая карта тестового покрытия

Технология заработала на google.com, и я начал пробовать ее на нескольких других сайтах, чтобы убедиться в ее работоспособности. Я назначил короткую неформальную встречу с Джеймсом, чтобы показать результаты своей работы и узнать, что он о них думает. Мы исписали всю доску тем, что потом стало планом для экспериментов, описанных в этой книге. Я отправил Пату Коупленду и Джеймсу письма, в которых сообщил, что теперь буду заниматься этой работой и отчитываться перед Джеймсом. Никаких вопросов не было — изменения были согласованы по почте.

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

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

Внешние тестировщики

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

Хорошим примером такой работы служит Chrome OS. Мы с самого начала поняли, что сетевые подключения Wi-Fi и 3G — очень рискованная область, потому что она зависит от производителя устройства. Облачное устройство без связи с интернетом теряет свой смысл как продукт. Более того, все обновления безопасности и версий программных продуктов тоже происходят по Сети, и если возникают проблемы с передачей данных по 3G, наша работа обесценивается. Это не та вещь, которую можно оставить на откуп неспециалистам, пусть и с благими намерениями.

Когда мы только начинали работать с устройствами, своих специалистов с нужным тестовым оборудованием у нас еще не было. Впрочем, даже если бы оно было, правильно его использовать все равно никто не умел. Поэтому тестирование проводили внешние специалисты, которые вручную переключались между 20 современными роутерами Wi-Fi. За пару недель эти ребята сообщили нам о многочисленных проблемах при переключении роутеров и о снижении скорости передачи, если квартира пользователя находится в зоне действия нескольких роутеров. Конечно, были и другие проблемы, обнаруженные тестированием, но не такие важные. Мы получили графики, которые свидетельствовали о серьезном падении скорости передачи (примерно как на рис. 3.52 и 3.53).

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

Рис. 3.52. Ожидаемый график зависимости скорости передачи от диапазона

Рис. 3.53. График зависимости скорости передачи от диапазона в ранних прототипах Chrome OS

Кстати, даже инженеры начального уровня в Google могут привлечь к работе внешних специалистов. Такая способность быстро решать задачи помогает нам быстро выпускать версии наших продуктов. Сейчас у нас есть все необходимое для того, чтобы выполнить работу самим, продолжая то, что начали внешние ребята. Но все же именно то, что мы смогли быстро подключить их экспертизу, стало основной причиной стабильно работающего сетевого соединения в боевых условиях к моменту запуска Chrome OS.

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

Интервью с инженером по тестированию Google Docs Линдси Уэбстер

Линдси Уэбстер — инженер по тестированию проекта Google Docs в нью-йоркском офисе Google. В компании ее знают как инженера-практика, способного привести в порядок процедуру тестирования в любой команде разработчиков. Ее подход к работе и умение влиять на команду и качество продукта сделали ее символом инженеров по тестированию в Google.

Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.

— Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?

Линдси: Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.

Как только все документы просмотрены, я начинаю изучать состояние проекта, а конкретно — его состояние качества. Я смотрю на количество багов, как они сгруппированы. Смотрю на типы открытых багов: какие из них открыты дольше всего, какие созданы недавно — и пытаюсь определить соотношение числа найденных и исправленных багов.

— Число багов на разработчика или на всю команду?

Линдси: На всех! Если честно, чтобы достигнуть максимальных результатов, команду надо знать как свои пять пальцев.

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

Я исследую любые автоматизированные тесты. Есть ли они вообще? Проходят ли они до сих пор? Я изучаю код этих тестов, чтобы понять, как они проходят сквозь приложение, насколько они полны, хороши ли предположения и условия прохождения или их еще надо доработать. Бывает, что автоматизация покрывает лишь простые тесты. А иногда наборы тестов покрывают сложные пользовательские сценарии, и это хороший знак.

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

Спрашивая про ожидания от тестировании, я очень много узнаю о том, что команда разработки не тестирует.

— Нам даже думать тяжело о такой работе. Хорошо, что у нас есть такие тестировщики! Итак, ты расправились с документами и командой, но что-то же осталось на десерт? Само приложение?

Линдси: Точно! Как только я получаю необходимые данные, наступает пора заняться делом. Обычно я разбиваю приложение на функциональные куски. Нестрашно, если между ними будет небольшое перекрытие. Моя главная задача — создать не слишком подробную, но и не слишком общую картину, чтобы я могла перечислить все компоненты и фичи.

Когда я разделила приложение на функциональные части, я могу их приоритизировать по очередности тестирования. Какие части приложения я могу назвать самыми рискованными?

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

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

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

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

— Какое место занимает пользователь в твоей работе как тестировщика?

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

— Как разработчики оценивают твою работу? Если они недооценивают тестирование, как ты себя ведешь?

Линдси: Разработчики часто недооценивают мой вклад, пока не поработают со мной пару месяцев. Закончив описанный мной этап работы, я встречаюсь с командой и знакомлю их со своим процессом тестирования. Только в личном общении можно донести до разработчиков, что я отношусь к их приложению очень серьезно. Я получаю хорошие отзывы о своей работе, а они убеждаются, что попали в надежные руки.

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

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

— Расскажи немного о своем тестировании Google Sites. Как ты подошла к проекту? Какие документы ты создавала и в каком формате? Как подала свои выводы и результаты разработчикам?

Линдси: Тестирование Sites стало настоящим испытанием. Продуктом пользовалось огромное количество людей, продукт был куплен, а не разработан в Google, и к тому же существовал в Google намного дольше остальных.

Я начала работу как пользователь, осваивала продукт самостоятельно, создавая свои сайты. Заодно я связалась с людьми, которые много им пользовались. Например, ассоциация домовладения дома, где я живу, несколько месяцев назад перевела сайт сообщества на Google Sites, и я поинтересовалась, как произошел этот переезд. Документация по этому проекту вовремя не обновлялась, поэтому мне пришлось разбить продукт на блоки и задокументировать все компоненты и подкомпоненты.

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

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

Я сделала общий сайт (конечно, на базе Google Sites!), где собрала всю документацию для тестирования: пользовательские истории, информацию о среде и команде тестирования, данные по выпускам и т.д. Чтобы быстро планировать тестирование для новой сборки, я использовала простую электронную таблицу со списком всех компонентов и субкомпонентов, упорядоченных по приоритету тестирования.

Закончив работу по реорганизации тестирования, я провела встречу с разработчиками, чтобы дать им полное представление о процессе тестирования. Презентация здорово помогла команде понять масштаб и подводные камни тестирования, а я почувствовала, что моя работа оценена по достоинству.

— А можешь рассказать о самом интересном баге, который ты находила, и как это произошло?

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

— Как ты оцениваешь результат своей работы?

Линдси: Важный критерий оценки для меня — количество багов, дошедших до пользователя. Я люблю, когда это число можно округлить до нуля. Еще я серьезно отношусь к тому, что болтают о моих проектах на форумах. Если пользователи ругают продукт за обилие багов или неудобный интерфейс (не сводите глаз с форума пользователей!), я воспринимаю это как сигнал к тому, что мне нужно активнее участвовать в проекте. Проект, кстати, может тащить на себе груз старых багов, которые так и не были исправлены. Поэтому, оценивая свою работу в проекте, я еще учитываю, сколько старых багов продолжает портить жизнь пользователям сегодня. Я стараюсь выводить такие дефекты на первый план, обосновывая повышение приоритета солидным возрастом бага.

— Как ты понимаешь, когда тестирование пора завершать?

Линдси: Трудно сказать. Когда тестируешь новые версии, то дата выпуска и есть финишная черта проекта. А если появляется новая версия браузера или устройства, на которых открывается наше приложение, даже если оно сейчас активно не разрабатывается, то это всегда серьезная причина продолжить тестирование. О’кей, если вы уверены, что если какие-то баги и остались, то они находятся в компонентах, фичах, браузерах, устройствах, которыми пользуются очень редко, а значит, не сильно помешают пользователям, то вы можете приостановить тестирование. Руководствуйтесь приоритетами фич и окружений, которые вы поддерживаете.

— А как исправляются баги?

Линдси: Важная часть моей работы — подталкивать разработчиков исправлять баги. Я постоянно пытаюсь оторвать разработчиков от работы над новыми фичами и отправить их исправлять баги. Чем больше жалоб на баг от пользователей мне удается собрать, тем легче мне убедить разработчика, что нужно уничтожить дефект, вместо того чтобы прикручивать новую функцию. У корпоративных продуктов в Google, таких как Sites, есть специальные службы поддержки клиентов. Я обязательно работаю с ними, чтобы быть в курсе, на что чаще всего жалуются клиенты.

— Если бы ты могла взмахнуть волшебной палочкой и изменить один аспект твоей работы, что бы это было?

Линдси: Если я скажу «все», то мое желание не исполнится? Хорошо, если бы могла, я бы создала простые, примитивные тест-кейсы или пользовательские сценарии, которые бы не надо было документировать, потому что они чудесным образом стали бы известны каждому тестировщику. Скажем, операции создание-чтение-обновление-удаление используются везде, поэтому каждый раз описывать их для каждой новой фичи утомительно. Я думаю, переход на высокоуровневые пользовательские истории вместо формализованных тест-кейсов частично решил проблему, но я бы все равно предпочла полностью избавиться от нее.

— Как твоя работа влияет на решение о выпуске продукта?

Линдси: Я решаю, может ли фича пройти в сборку для релиза, помня об интересах пользователя. К счастью, мои команды обычно соглашаются. Я не блокирую выпуск продукта, если для этого нет веских причин. Для меня важно сохранять доверие команды, чтобы люди знали: если я настаиваю, что нужно блокировать, значит, все совсем плохо.

— Что тебе больше всего нравится или не нравится в твоей работе?

Линдси: Мои навыки дают мне профессиональную гибкость, и мне это нравится. Я — технический специалист, но моя работа — думать о пользователе. Назовите проект, в котором не нужны такие люди! Я могу быть полезной в проекте любого типа. При запуске продукта или новой фичи команды часто нервничают, а мое присутствие и работа приносят им спокойствие и уверенность. Я чувствую, что приношу пользу и позитив.

— Чем тестирование в Google отличается от других компаний?

Линдси: Независимостью. Я свободна в выборе проектов, над которыми хочу работать как в основное время, так и в «двадцатипроцентное», — это такая концепция в Google, позволяющая нам проводить один день в неделю, или 20% общего времени, работая над любым проектом. Это расширяет мой кругозор и поддерживает мой энтузиазм, когда кажется, что работа превратилась в сплошной «День сурка».

— Как разработчики в тестировании относятся к твоей работе?

Линдси: Разработчики в тестировании часто не считают важной работу с репозиторием багов и тестирование каждой версии, пока сами не увидят, как это влияет на продукт. Даже если они думают, что автоматизация покрывает все тестовые сценарии (да, как же!), кто-то должен заниматься исследовательским тестированием для разработки новых тест-кейсов. А еще этот кто-то должен отслеживать все баги, найденные автотестами, сравнивать их с более старыми и менее серьезными багами и отзывами от пользователей. Так как я поднимаю эти вопросы, то разработчики в тестировании обычно понимают ценность изменений, которые я приношу в проект. Если и есть такие, кто не очень уважительно относится к моей работе, это те, с кем мы еще не поработали. После совместной работы отношение разработчиков всегда быстро меняется.

— Как организовано твое взаимодействие с разработчиками в тестировании?

Линдси: Я определяю стратегию тестирования для всех, включая разработчиков в тестировании. Если разработчики в тестировании не знают, с чего начать программирование тестов или инструментов, я показываю им документ с приоритетами, где написано, что нужно тестировать в первую очередь, и подкрепляю информацией о багах. Еще я могу дать им обратную связь, показать на реальных данных, насколько их решение действительно предотвращает баги. Так что мое взаимодействие в основном построено на организации и обратной связи, которую я привношу в работу разработчиков в тестировании.

Интервью с инженером по тестированию YouTube Эппл Чоу

Эппл Чоу — инженер по тестированию Google Offers. До этого проекта она руководила тестированием YouTube в офисе Google в Сан-Франциско. Эппл любит сложные задачи и всегда стремится применить к ним новейшие инструменты и методы тестирования.

Недавно мы побеседовали с Эппл и попросили ее рассказать о тестировании YouTube.

— Эппл, что привело тебя в Google? Такое имя наверняка наводило на мысли о работе в другой компании?

Эппл: Ха! Адрес [email protected] выглядит очень аппетитно! Но я выбрала Google из-за разнообразия продуктов и возможности поработать с исключительными специалистами. Мне нравится менять проекты и работать на разных флангах, поэтому я решила, что Google — подходящее для меня место. Я могу влиять на работу миллионов пользователей в самых разных областях. Каждый день ставит новые задачи, и мне никогда не бывает скучно. Конечно, бесплатный массаж — тоже плюс.

— Расскажи о процессе собеседования на роли тестировщика и разработчика в тестировании.

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

— Ты работала во многих технологических компаниях. Что оказалось самым неожиданным в организации тестирования в Google?

Эппл: Здесь многое устроено иначе. Может, я не очень объективна, потому что люблю Google, но я бы сказала, что наши тестировщики и разработчики в тестировании более подкованы технически, чем специалисты других компаний. Везде, где я работала, у нас были отдельные команды для автоматизированного и ручного тестирования. Понятно, что разработчики в тестировании в Google сами пишут код, это их работа. Но найти здесь инженера по тестированию, который не умеет программировать, сложно. Такие навыки помогают нам быть более ценными на ранних стадиях, когда до сквозного тестирования еще далеко и надо заниматься юнит-тестированием. Я думаю, что наши технические навыки объясняют наши успехи.

Еще одно отличие Google в тестировании — огромный объем автоматизации. Большинство автотестов уже проходят к тому моменту, когда на проект приходят инженеры по тестированию. Благодаря этому тестировщики получают в работу код очень высокого качества.

Третье отличие — инструменты, которыми мы пользуемся, созданы внутри компании. Мы почти не работаем с коммерческими программами. В нашей культуре очень высоко ценится разработка собственных инструментов, и многие тратят свое «двадцатипроцентное» время на такие проекты. Наши изобретения помогают нам с легкостью преодолевать рутинные и утомительные части тестирования и фокусировать усилия людей на сложных задачах, где действительно нужно участие человека.

Есть еще один важный момент: культура «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования, и в этом мы можем легко положиться на разработчиков. Мы все в Google играем на стороне качества продукта, и любой инженер может протестировать любой код с любого компьютера. Поэтому вся работа идет быстро.

— Отличия понятны, а чем тестирование в Google схоже с тестированием в других компаниях?

Эппл: Функциональность приложения, которую трудно автоматизировать, создает нам столько же проблем с тестированием, сколько и любой другой компании. Когда мы в спешке доделываем новые фичи для очередного выпуска, мы тестируем код не так тщательно, как хотелось бы. Идеальных компаний и совершенных продуктов не бывает.

— За какие функциональные области ты отвечала, работая инженером по тестированию для YouTube?

Эппл: Я работала с разными командами и участвовала в выпуске многих новых фич YouTube. Предмет моей особой гордости — запуск новой страницы просмотра роликов, которую мы полностью переработали. Это одна из самых часто просматриваемых страниц в интернете! Другой запоминающийся проект — наше партнерство с Vevo, новым порталом музыкального контента, для которого YouTube обеспечивает видеохостинг и стриминг. Этот проект — совместное творение Sony Music Entertainment и Universal Music Group. В день запуска на нем уже было 14 000 видеороликов. За три месяца после запуска видеоролики Vevo на YouTube собрали больше 14 миллионов просмотров. Еще я координировала работу по тестированию переписанной версии видеопроигрывателя YouTube на базе Flash, когда мы переходили с ActionScript 2 на ActionScript 3, и запуск новых страниц Channel и Branded Partner.

— Каково это — рулить тестированием в Google?

Эппл: Это значит координировать работу не только в своей команде и проекте, но и не забывать присматривать за всеми продуктами, на которые может повлиять наша работа. Например, в проекте Vevo мы постоянно держали в голове проигрыватель YouTube, брендированный компонент просмотра, иерархию каналов, распределение трафика и т.д. Нужно уметь видеть лес за деревьями.

— Как ты адаптировала исследовательское тестирование для YouTube?

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

— Как тестировщики YouTube восприняли идею исследовательского тестирования?

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

— Ты упомянула о турах. Джеймс подтолкнул тебя применить практики из его книги?

Эппл: Когда Джеймс пришел в Google, книга только вышла. Он провел пару семинаров и несколько раз встречался с нами. Но он работает в Сиэтле, а мы в Калифорнии, поэтому мы общаемся не так часто. Мы просто взяли туры из книги и попробовали их. Одни сработали, другие — нет, но мы быстро разобрались, какие лучше подходят для нашего продукта.

— Какие именно работали? Можешь назвать?

Эппл: «Денежный тур» с фокусом на фичи, связанные с деньгами (для YouTube это Ads и другие части, завязанные на партнеров), конечно, играл важную роль в каждом выпуске. «Тур по достопримечательностям» с фокусом на важнейшие функции системы. «Тур по неблагополучному району» с фокусом на области, в которых раньше находили баги, и области, к которым относились последние баг-репорты. Эти три оказались самыми эффективными в выявлении багов. Невероятно полезным оказалось рассмотреть заведенные друг другом баги и обсудить, как мы их искали. Концепция туров помогла нам выстроить стратегию исследовательского тестирования. Мы постоянно подшучивали над «антисоциальным туром» (ввод наименее вероятных данных при каждом удобном случае), «туром навязчивого невроза» (повторение одного действия) и «ленивым туром» (ввод минимума входных данных и выбор значений по умолчанию везде, где только можно). Туры не только помогли нам направлять наше тестирование, но и сплотили команду.

— Насколько мы знаем, вы много тестируете YouTube с помощью Selenium. Что тебе нравится и не нравится в автоматизации с использованием Selenium?

Эппл: Нравится простота API, то, что можно писать код тестов на любимом языке программирования, будь то Python, Java или Ruby, возможность прямого вызова кода JavaScript из приложения — потрясающая, суперполезная функция.

Не нравится то, что технология так и осталась браузерным тестированием. Она медленно работает, нужно встраивать точки входа в API, а тесты работают далеко от тестируемого кода. Selenium помогает при автоматизации сценариев, которые человеку особенно трудно проверять, например при вызовах к рекламной подсистеме. У нас есть тесты, которые запускают видеоролики и перехватывают вызовы Ad с помощью Banana Proxy (внутренняя программа проверки безопасности веб-приложений, которая логирует запросы и ответы HTTP). В двух словах: мы перехватываем запросы из браузера и направляем их на Banana Proxy, который их логирует и передает в Selenium. Так мы можем убедиться в том, что исходящие запросы содержат правильные URL-параметры, а содержимое входящих ответов соответствует ожиданиям. Тесты пользовательского интерфейса работают медленно, менее надежны и дороже в сопровождении. Мы пришли к выводу, что следует оставить несколько больших высокоуровневых смоук-тестов для проверки сквозных интеграционных сценариев, а остальные тесты должны быть как можно меньшего размера.

— Большая часть контента и пользовательский интерфейс YouTube работают на Flash. Как вы это тестируете? У вас есть волшебные приемы, позволяющие делать это через Selenium?

Эппл: Никакой магии, к сожалению. Если не считать огромное количество проделанной работы волшебством. Наши JavaScript API торчат наружу, и мы можем использовать Selenium для их тестирования. Еще есть программа определения различий pdiff, которая помогает в тестировании отображения превью, определения границ экрана и прочего. Мы делаем серьезную промежуточную обработку потока HTTP для прослушивания трафика, чтобы больше знать об изменениях на странице. Фреймворки As3Unit и FlexUnit помогают нам проверять различные состояния приложения и сравнивать графические изображения. Я бы хотела назвать это магией, но чтобы все это стало реальным, написано очень много кода.

— Какой самый серьезный баг нашла и не пустила к пользователям твоя команда?

Эппл: Самые серьезные баги обычно не так интересны. Был забавный баг в CSS, из-за которого браузер IE вылетал. До этого мы еще никогда не видели, чтобы баги CSS приводили к аварийному завершению браузера.

Нам запомнился один коварный баг, который поймали во время запуска новой страницы просмотра в 2010 году. Когда пользователь в IE7 выводил курсор за пределы области воспроизведения, проигрыватель через какое-то время зависал. Это интересный случай, потому что пользователи столкнулись бы с этим, только если бы долго смотрели один видеоролик и двигали курсором. Тогда все постепенно начинало тормозить, пока проигрыватель не зависал окончательно. Оказалось, что проблемы возникали из-за обработчиков событий и ресурсов, которые не освобождались, многократно выполняя одни и те же вычисления. Если пользователь смотрел короткие ролики или сидел спокойно и не двигал мышкой, баг не проявлялся.

— Расскажи о самом успешным и самом неуспешном моментах тестирования YouTube.

Эппл: Самым успешным был инструмент для получения и проверки проблемных URL-адресов. Эти простые тесты очень сильно помогли нам быстро отлавливать критические баги. Мы добавили фичу, которая упрощала отладку тем, что выдавала данные трассировки стека. Разработчикам стало проще выявлять причины проблем и исправлять их. Этот инструмент стал нашим первым флангом защиты при развертывании и сэкономил тестировщикам очень много времени. После небольшой доработки мы настроили его для самых популярных URL-адресов из наших логов и для добавочного списка URL-адресов, отобранных вручную. Это принесло много пользы.

Пожалуй, наименее успешным аспектом было то, что мы полагались на ручное тестирование во время наших еженедельных авралов. Учитывая то, что времени для тестирование мало, код замораживается и выкатывается на бой в тот же день, многие изменения в пользовательском интерфейсе очень трудно автоматизировать, ручное тестирование все еще играет важную роль в нашем процессе выпуска. Это серьезная проблема, и я хотела бы найти для нее достойное решение.

— Сайт YouTube управляется данными, а большая часть контента определяется алгоритмами. Как вы следите за тем, чтобы правильные видеоролики отображались вовремя и в нужном месте? Твоя команда проверяет качество видеоматериала? Если проверяет, то как вы это делаете?

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

У нас есть юнит-тесты для проверки качества видео. После моего прихода наша команда написала инструмент AS3 Player Helper для углубленного тестирования этого аспекта. Приложение распространяется с открытым кодом. Оно построено на тестах FlexUnit, которые используют встроенный проигрыватель YouTube, воспроизводят им тестовые видеоролики и выдают информацию о состоянии проигрывателя и свойствах ролика. В тестовые ролики зашиты большие штрихкоды, они помечают кадры и отрезки времени. Их легко распознать даже после сжатия и потери качества. Еще один прием, чтобы оценить состояние видео, — это делать снимки видеокадров и анализировать их. Мы проверяем правильность пропорций и кадрирования, ищем деформации, искажения цвета, пустые кадры, белые экраны, проблемы синхронизации и т.д. Так эти проблемы оказываются в наших баг-репортах.

— Какой совет ты бы дала другим тестировщикам веб, приложений на базе Flash и веб-служб, управляемых данными?

Эппл: Работая с тестовыми фреймворками или тест-кейсами, делайте их простыми. Изменяйте архитектуру итеративно вместе с развитием проекта. Не пытайтесь сразу решить все проблемы. Смело выбрасывайте то, что вам не подходит. Если тесты или инструменты слишком сложны в сопровождении, выбросьте их и постройте более гибкие. Следите за тем, сколько вы тратите на сопровождение и диагностику тестов. Соблюдайте правило 70-20-10: 70% малых юнит-тестов, которые проверяют один класс или функцию, 20% средних тестов, которые проверяют интеграцию одного или нескольких модулей приложений, и 10% больших тестов (тех, что обычно называют системными или сквозными), работающих на верхнем уровне и проверяющих работу приложения в целом.

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

— Скажи честно, тестирование для YouTube — шикарная работа? Целый день смотреть видеоролики с котиками…

Эппл: Да, мы любим повеселиться, не буду врать. У нас как-то была первоапрельская шутка, когда мы выводили все заголовки видеороликов перевернутыми. Я просматриваю много интересного контента, и это моя работа! И даже после всего этого я все еще смеюсь над видеороликами с котиками!