Уиттакер . - Как тестируют в Google

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

Пишем тест-кейсы

Тестировщики в 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 и описаний пользовательских историй. Некоторые тестовые команды даже хранят фрагменты кода и данные прямо в тест-кейсах GTCM. GTCM помогает в работе любым тестовым командам и учитывает их различающиеся представления тест-кейсов.

Рис. 3.11. Создание проекта в GTCM

Рис. 3.12. Создание теста в GTCM

Рис. 3.13. Просмотр тест-кейсов при поиске Chrome в GTCM