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

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

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