Читаем Как тестируют в Google полностью

Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.

Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.

Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования.[38] Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.

<p>Краудсорсинг</p><p><emphasis>Джеймс Уиттакер</emphasis></p>

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

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

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

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

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

Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов.[39]

Перейти на страницу:

Похожие книги