Мы представляем, что бесплатное тестирование это:

— почти нулевые затраты;

— мгновенное получение результатов;

— минимум человеческих ресурсов;

— супергибкость. Мы не верим, что всем может подойти одно и то же.

Чтобы задача соответствовала времени и остальным проектам Google, мы решили начать с веб-тестирования, надеясь, что к моменту завершения работы весь мир все равно будет работать в облаке, а драйверы и COM останутся в прошлом. Мы знали, что если будем создавать бесплатный продукт, то при любом исходе получим что-то интересное.

Итак, у нас получилась модель, которая здорово сокращает затраты на тестирование и ловко обходит проблемы. В наших лабораториях уже созрели первые плоды такой модели (рис. 3.49). Схема работы такая.

1. Планирование с GTA. Основанное на анализе рисков, быстрое и автоматически обновляемое планирование тестирования.

2. Тестовое покрытие. Боты проверяют каждую новую версию сайта, индексируют его содержимое, ищут различия. Бот, конечно, не сможет отличить регресионный баг от новой фичи, но он заметит изменения и сообщит о них человеку.

3. Оценка багов. Обнаруженные различия автоматически передаются специалистам для оценки. Итак, регрессия или новая фича? Здесь поможет BITE, который показывает информацию о заведенных багах в контексте этой оценки.

4. Исследовательское тестирование. Непрерывное исследовательское тестирование силами краудсорс-тестировщиков и ранних последователей. Они помогут поймать баги, связанные с конфигурациями и такие, которые сможет заметить только человек.

5. Регистрация багов. Всего несколько кликов — и баг зарегистирирован, а в отчете можно найти снимки экрана, конкретное место появления и информацию для отладки.

6. Приоритизация и отладка. Разработчики и тест-менеджеры почти что в реальном времени получают сводную и очень подробную информацию о багах. Все необходимые данные уже есть, и даже можно в один клик посмотреть, как именно тестировщик нашел баг.

7. Развертывание новой версии и возвращение к шагу 1. Повторяем все заново.

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

Самая приятная часть работы с ботами — сокращение времени между выкатыванием версии продукта и поимкой багов. Итак, если боты и тестировщики из сообщества могут работать круглосуточно, значит разработчики могут оперативно получать данные о последствиях своих изменений в коде. Так как сборка и установка происходят непрерывно, то легко определить, какая именно горстка изменений привнесла баг. К тому же все изменения еще свежи в голове разработчика, и процесс отладки прост и понятен.

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

Рис. 3.49. Сквозной процесс бесплатного тестирования

Мы в Google за любые эксперименты, поэтому у нас и создается множество инноваций. Ну и куча неудачных экспериментов заодно. Даже если уже есть хорошее решение, мы не запрещаем инженерам пытаться придумать еще лучше. Собственно, переосмысливать, анализировать и улучшать — это их работа.

Когда Джеймс Уиттакер пришел в Google, первым делом он организовал внутреннюю встречу технических специалистов и рассказал, каким он видит будущее тестирования. В его понимании тестирование должно напоминать видеоигры: как и в шутерах от первого лица, на тестируемое приложение должна накладываться полная контекстная информация. Мало кто мог представить, что его доклад на конференции GTAC [61] задаст тон работе на несколько лет вперед. Конечно, на слайдах его идеи смотрелись хорошо, но построение общего решения для всех клиентских приложений казалось делом очень дорогим и сложным.

Я скептически относился к смелым идеям Джеймса, пока вдруг не осо­знал, что уже могу почти моментально реализовать их в браузере для веб-приложений с помощью API новых расширений Chrome. Идея захватила меня настолько, что всю следующую неделю я провел в работе над прототипом. Я даже приостановил свою текущую работу и провел выходные в Starbucks, неистово программируя. Сотрудники кофейни интересовались у меня, не ищу ли я работу в интернете, и мне оставалось только постучать по дереву.

Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine [62] и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов: