Как тестируют в 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. Иначе нам пришлось бы несколько часов ждать завершения индексирования на новой установке. Мы сформировали небольшой автоматизированный пакет смоук-тестирования47, покрывающий самые важные функции продукта.

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

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

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

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