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

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

---

Рис. 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 года, пока два предприимчивых инженера, Тед Мао41 и Рави Гампала, не создали Buganizer.

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

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

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

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

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

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

На рис. 3.18 мы видим, что есть много багов с приоритетом P242, значительно меньше багов 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, независимо от того, работают ли они на этом проекте. Наша главная цель — сделать интернет лучше.