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

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

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