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

Рис. 3.47. Test Analytics: связанные тесты

Рис. 3.48. Test Analytics: связанные баги

Легко не заметить одну очень важную функцию в GTA: тестировщики могут быстро превратить список возможностей в серию тестов. Команды очень просили добавить именно эту фичу. Смысл в том, что возможности — это простой список высокоуровневых тестов, который нужно прогнать перед выпуском программы. Для маленьких команд, которые фокусируются на исследовательском тестировании, например как команда Google Docs, этот список можно легко использовать вместо базы данных тестов.

В GTA используется матрица ACC-анализа, и это дает тестировщикам кардинально новый подход. Обычно тестовые серии или задания на разработку тестов назначаются по компонентам . ACC позволяет распределять тестировщиков по атрибутам . Наши эксперименты показали, что такой фокус работает лучше всего. Если за тестировщиком закрепить атрибут «быстрый» для всего набора тестов, то он может оценить, насколько быстро работают все интересующие компоненты продукта за одну серию тестов. Так можно выловить медленные компоненты, которые при независимом тестировании могли прикидываться достаточно быстрыми.

Что же со связями и зависимостями между рисками разных проектов? В GTA эта фича пока не реализована. Каждый проект делает свой ACC- анализ и оценивает риски только для своего проекта, без учета других проектов компании. Если кто-то хочет проанализировать риски нескольких продуктов сразу, ему нужно нормировать данные между проектами, чтобы смотреть на них в совокупности. Только то, что ваша маленькая команда работает над внутренним инструментом, не значит, что у вас не может быть максимальных значений рисков. Оставьте относительность тем, кто видит много проектов сразу. Когда оцениваете риск для своего проекта, оценивайте его так, как будто ваш проект — единственный в компании. В нем вполне могут быть часто срабатывающие риски с высокой степенью воздействия.

Сейчас проект GTA используется еще в нескольких компаниях, и мы хотим сделать GTA общедоступным продуктом с открытым кодом. Мы хотим, чтобы другие команды тестирования могли устанавливать у себя свои системы на движке Google App Engine или даже портировать код и разворачивать на других платформах.

GTA делает анализ рисков настолько простым и удобным, что люди действительно им пользуются. Джим Рирдон вырастил GTA с нуля и сейчас поддерживает его в опенсорсе (подробнее об этом мы рассказываем в приложении В). На момент написания книги несколько больших компаний, занимающихся облачным тестированием, хотят интегрировать эту технологию в свои рабочие процессы и инструменты. [60] Одной из таких облачных компании является Salesforce. Фил Валигора из SalesForce.com занимается интеграцией GTA во внутренний инструментарий. И еще около 200 внешних инженеров записались на использование GTA.

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

Почему нам это интересно? Работает простая схема: если тестирование бесплатно, маленькие компании и стартапы смогут позволить себе тестирование. Если тестирование бесплатно, интернет становится лучше, а это интересах пользователей и Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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