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

На середине очередного проекта мне предложили взяться за колоссальную задачу тестирования 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. Иначе нам пришлось бы несколько часов ждать завершения индексирования на новой установке. Мы сформировали небольшой автоматизированный пакет смоук-тестирования, [47] Смоук-тестирование — это минимальный набор тестов, который проводят, чтобы убедиться, что базовые функции программы работают корректно. Если система не проходит смоук-тестирование, то дальнейшие тесты не имеют смысла. Термин родился в ходе проверки радиоэлектронных устройств — если после пробного включения детали аппарата перегреваются, «идет дым», то все устройство нужно отправлять на доработку. — Примеч. перев. покрывающий самые важные функции продукта.

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

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