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

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

Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.

Главный недостаток тестирования сообществом в том, что им нужно время, чтобы разобраться с приложением и понять, с какой стороны лучше подойти к тестированию. Большая часть этого времени теряется впустую из-за количества людей, но мы придумали, как с этим справляться. Для Chrome, например, мы написали туры, и внешние тестировщики следовали им при исследовательском тестировании и при выполнении пользовательских сценариев (примеры есть в приложении Б «Туры тестов для Chrome»). Туры сразу направляли тестировщиков к нужным частям приложения и давали необходимые инструкции. Фокус в том, чтобы сделать разные наборы туров и распределить их между участниками. Так мы избежали варианта «принеси то, не знаю что» и получили именно то, о чем просили.

Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов. [39] Программа «Платим за баги» для Chrome обсуждается по адресу: http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

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

Работа тестировщика, в отличие от работы разработчика в тестировании, с выпуском продукта не заканчивается.

Тестировщики в Google создают очень много тест-кейсов, которые определяют входные данные (от общих условий до конкретных значений) для тестирования приложения. Тест-кейсы могут строиться и на основе пользовательских историй, и прямым преобразованием возможностей продукта: работа с ними не зависит от их происхождения. В отличие от кода и автоматизации, которые управляются общей инфраструктурой, тест-кейсы до сих пор пишутся локально каждой командой. Недавно появился инструмент, который изменит ситуацию.

Чаще всего тест-кейсы хранились в электронных таблицах и документах. Коман­ды, работающие по быстрым методологиям с короткими циклами выпуска, не очень заботятся о сохранении тест-кейсов. Как только выходит новая фича, скрипты начинают падать, и тесты приходится переписывать заново. Поэтому документа, который можно использовать, а потом с чистым сердцем удалить, — вполне достаточно. Формат такого документа не подойдет для конкретных тест-кейсов с действиями, но сгодится для описания контекста тестовой сессии. Такие тесты обычно менее регламентированы и, по сути, просто указывают, какие фичи нужно исследовать.

Конечно, есть команды, которые хранят тестовые процедуры и данные в довольно сложных таблицах. Некоторые даже копируют данные ACC-анализа в электронные таблицы, потому что они, видите ли, более гибкие, чем Google Test Analytics. Но такой подход требует дисциплины и целостности в команде, ведь работа одного тестировщика может ограничить работу другого. Большим командам с их текучкой нужен другой подход. Нужна структура, которая переживет любого участника команды.

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

С ростом Google у многих команд росли объемы тест-кейсов, ими нужно было лучше управлять. Некоторые документы с тест-кейсами выросли до таких размеров, что даже поиск в них стал невозможен. Нужен был новый подход. Наши тестировщики построили систему на основе нескольких коммерческих продуктов и доморощенных систем управления тест-кейсами, знакомых им по предыдущим местам работы. Систему назвали Test Scribe.

Test Scribe хранит тест-кейсы в жесткой структуре. Можно включить или исключить тест-кейс из конкретной тестовой сессии. Реализация была примитивной, и энтузиазм по поводу ее использования быстро угас. И хотя многие команды оставили что-то от нее и возились с этим несколько кварталов, мы ее все-таки похоронили. В 2010 году Джорданна Корд, старший разработчик в тестировании, написала новую программу. Это была система Google Test Case Manager (GTCM).

Рис. 3.10. Домашняя страница GTCM сосредоточена на поиске

GTCM создали, чтобы сделать процесс написания тестов проще, создать гибкий формат тегов, который можно адаптировать под любой проект, упростить поиск и повторное использование тестов. И ­— самое важное — интеграция GTCM с остальной инфраструктурой Google. Посмотрите на снимки экранов GTCM (рис. 3.10–3.14). На рис. 3.11 показана страница создания тест-кейса. Можно создавать произвольные разделы или метки, поэтому GTCM поддерживает любые схемы, от классических тестов до исследовательских туров, «огурцов» [40] «Огурцами» называют поведенческие тест-кейсы. Подробнее — на http://cukes.info и описаний пользовательских историй. Некоторые тестовые команды даже хранят фрагменты кода и данные прямо в тест-кейсах GTCM. GTCM помогает в работе любым тестовым командам и учитывает их различающиеся представления тест-кейсов.