Книга: Как тестируют в Google
Пишем тест-кейсы
Пишем тест-кейсы
Тестировщики в Google создают очень много тест-кейсов, которые определяют входные данные (от общих условий до конкретных значений) для тестирования приложения. Тест-кейсы могут строиться и на основе пользовательских историй, и прямым преобразованием возможностей продукта: работа с ними не зависит от их происхождения. В отличие от кода и автоматизации, которые управляются общей инфраструктурой, тест-кейсы до сих пор пишутся локально каждой командой. Недавно появился инструмент, который изменит ситуацию.
Чаще всего тест-кейсы хранились в электронных таблицах и документах. Команды, работающие по быстрым методологиям с короткими циклами выпуска, не очень заботятся о сохранении тест-кейсов. Как только выходит новая фича, скрипты начинают падать, и тесты приходится переписывать заново. Поэтому документа, который можно использовать, а потом с чистым сердцем удалить, — вполне достаточно. Формат такого документа не подойдет для конкретных тест-кейсов с действиями, но сгодится для описания контекста тестовой сессии. Такие тесты обычно менее регламентированы и, по сути, просто указывают, какие фичи нужно исследовать.
Конечно, есть команды, которые хранят тестовые процедуры и данные в довольно сложных таблицах. Некоторые даже копируют данные ACC-анализа в электронные таблицы, потому что они, видите ли, более гибкие, чем Google Test Analytics. Но такой подход требует дисциплины и целостности в команде, ведь работа одного тестировщика может ограничить работу другого. Большим командам с их текучкой нужен другой подход. Нужна структура, которая переживет любого участника команды.
Электронные таблицы все же удобнее документов, потому что в них имеются подходящие столбцы для процедур, данных и отметок о результатх. Их легко настроить под себя. Google Sites и другие разновидности онлайновых вики-систем часто используют, чтобы транслировать тестовую информацию другим заинтересованным людям. Их легко использовать совместно и редактировать.
С ростом Google у многих команд росли объемы тест-кейсов, ими нужно было лучше управлять. Некоторые документы с тест-кейсами выросли до таких размеров, что даже поиск в них стал невозможен. Нужен был новый подход. Наши тестировщики построили систему на основе нескольких коммерческих продуктов и доморощенных систем управления тест-кейсами, знакомых им по предыдущим местам работы. Систему назвали Test Scribe.
Test Scribe хранит тест-кейсы в жесткой структуре. Можно включить или исключить тест-кейс из конкретной тестовой сессии. Реализация была примитивной, и энтузиазм по поводу ее использования быстро угас. И хотя многие команды оставили что-то от нее и возились с этим несколько кварталов, мы ее все-таки похоронили. В 2010 году Джорданна Корд, старший разработчик в тестировании, написала новую программу. Это была система Google Test Case Manager (GTCM).
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_025.jpg)
Рис. 3.10. Домашняя страница GTCM сосредоточена на поиске
GTCM создали, чтобы сделать процесс написания тестов проще, создать гибкий формат тегов, который можно адаптировать под любой проект, упростить поиск и повторное использование тестов. И — самое важное — интеграция GTCM с остальной инфраструктурой Google. Посмотрите на снимки экранов GTCM (рис. 3.10–3.14). На рис. 3.11 показана страница создания тест-кейса. Можно создавать произвольные разделы или метки, поэтому GTCM поддерживает любые схемы, от классических тестов до исследовательских туров, «огурцов»[40] и описаний пользовательских историй. Некоторые тестовые команды даже хранят фрагменты кода и данные прямо в тест-кейсах GTCM. GTCM помогает в работе любым тестовым командам и учитывает их различающиеся представления тест-кейсов.
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_026.jpg)
Рис. 3.11. Создание проекта в GTCM
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_027.jpg)
Рис. 3.12. Создание теста в GTCM
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_028.jpg)
Рис. 3.13. Просмотр тест-кейсов при поиске Chrome в GTCM
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_029.jpg)
Рис. 3.14. Простой тест-кейс для диалогового окна About в Chrome
Метрики, полученные от GTCM, дают представление о том, что происходит с тест-кейсами в общем. Можно понаблюдать за графиками общего количества тестов и результатов тестов на рис. 3.15 и 3.16. Общее количество тестов приближается к асимптоте. Это потому, что Google закрывает старые проекты, ориентированные на ручное регрессионное тестирование, вместе с их тестами. Кроме того, GTCM в основном содержит ручные тесты, а многие команды заменяют ручные методы тестирования автоматизацией, краудсорсингом или исследовательским тестированием. Поэтому общее число тест-кейсов во внутренней базе TCM уменьшается, хотя покрытие при этом увеличивается. Количество проведенных тестов тоже увеличивается, так как в этой области доминируют несколько больших команд, для которых ручное тестирование обязательно (например, команда Android).
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_030.jpg)
Рис. 3.15. Изменение количества тестов со временем в GTCM
Общее количество проведенных ручных тестов, как и следовало ожидать, увеличивается (рис. 3.16).
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_031.jpg)
Рис. 3.16. Изменение количества результатов тестов со временем в GTCM
Посмотрим на график количества багов, показанный в GTCM (рис. 3.17). Он интересен, но еще не может показать всю картину. Google дает инженерам свободу действий. Одни команды отслеживают, какие баги были найдены какими тест-кейсами, а другие не считают эти данные полезными для своего проекта. Некоторые баги создаются в системе автоматически, не все они были найдены в ходе ручного выполнения тестов.
![Пишем тест-кейсы](https://img-lib.wm-help.net/2502678000/i_032.jpg)
Рис. 3.17. Изменение общего количества багов, заведенных в ходе выполнения тестов GTCM, со временем
Основным требованием к GTCM с самого начала было наличие четкого и простого API. На самом деле и у системы TestScribe был API, но он базировался на SOAP, а схема аутентификации была настолько недружелюбной, что ею мало кто пользовался. Кроме того, с повышением внутреннего уровня безопасности тот режим аутентификации стал непригодным. Эти проблемы решились, когда у GTCM появился RESTful JSON API.
Команда разработки собирается скоро открыть GTCM для внешнего использования. Мы надеемся перевести эту базу данных тест-кейсов на модель открытого кода, чтобы поддерживать ее всем миром. Система GTCM проектировалась с расчетом на продолжение использования извне. Она построена на базе Google App Engine для обеспечения масштабируемости и для того, чтобы другие компании могли развернуть у себя свою копию системы. Внутренняя структура GTCM сделана так, чтобы отделить большую часть логики и пользовательских интерфейсов от Google App Engine, чтобы люди могли портировать систему. Следите за Google Testing Blog, если хотите узнать больше об этом процессе.
- Тестирование, обращенное к пользователю
- Инженер по тестированию
- Планирование тестирования
- Риск
- Снижение рисков
- Напоследок о рисках
- Пользовательские сценарии Джейсон Арбон
- Краудсорсинг Джеймс Уиттакер
- Пишем тест-кейсы
- Интересные факты из жизни багов
- Немного подробнее о Buganizer
- Жизненный путь бага Джеймс Уиттакер
- Как мы нанимаем инженеров по тестированию
- Как отличить тестировщика от разработчика в тестировании Джейсон Арбон
- Собеседование с инженерами по тестированию
- Управление тестированием в Google
- Управление «пиратским кораблем» для чайников Джеймс Арбон
- Тестирование в режиме сопровождения
- Пример режима сопровождения: Google Desktop Джейсон Арбон
- Эксперимент с Quality Bots
- Сингулярность: легенда о происхождении ботов Джейсон Арбон
- Bots: детство, отрочество и масштабирование на весь интернет Теджас Шах
- Эксперимент BITE
- Google Test Analytics
- Бесплатное тестирование
- Инновации и эксперименты в тестировании Джеймс Арбон
- Внешние тестировщики
- Интервью с инженером по тестированию Google Docs Линдси Уэбстер
- Интервью с инженером по тестированию YouTube Эппл Чоу
- Глава 3. Кто такой инженер по тестированию
- Глава 18. Пишем и считаем
- Тестирование Web-сервиса XML с помощью WebDev.WebServer.exe
- Кто такой тест-менеджер
- Пишем продающее письмо
- Разработка через тестирование и разработка с тестами
- Директор по тестированию
- 2. Операции декартового произведения и естественного соединения
- 6. Операция естественного соединения.
- Часть III. Шаблоны разработки через тестирование
- Приложение 1 Тестирование ПК при включении
- Программы для тестирования привода