Книга: Как тестируют в Google
Google Test Analytics
Google Test Analytics
Несмотря на то что анализ рисков нужен разработке как воздух, этот процесс часто происходит как попало. Если данным вообще удается покинуть головы участников команды, то часто они просто фиксируются в таблицах. Что в этом плохого?
— У данных нет единой схемы, потому что каждая таблица создается под конкретную ситуацию. Данные нельзя связать между собой, а это очень неудобно, если вы следите за несколькими проектами.
— Простые, но важные вещи, например четырехбалльная шкала оценки и общая схема названий из ACC-анализа, порой теряются при попытках сократить количество полей в таблицах.
— Данные не хранятся централизованно, поэтому недоступны всегда и всем. Командам приходится запрашивать друг у друга информацию устно при каждой необходимости.
— Разработка скриптов, которые связали бы анализ рисков с метриками продукта, обычно обходится дорого, поэтому редко сочетается с таблицами.
Google Test Analytics (GTA) — наша попытка решить эти проблемы. В интерфейс GTA встроены методы ACC-анализа, это простое приложение упрощает ввод данных и работу с рисками. Все данные представлены по одной схеме — менеджеры и директора могут легко получить сводку рисков по всем своим проектам, чтобы перераспределить ресурсы в более опасные области.
Итак, GTA поддерживает модель анализа рисков ACC. Атрибуты и компоненты вводятся в простые формы и формируют таблицы (рис. 3.42 и 3.43), а интерфейс позволяет добавлять возможности в ячейки при планировании тестирования (рис. 3.44). Чтобы добавить риск, нужно просто выбрать частоту и степень воздействия из выпадающих списков для каждой возможности. Все эти значения сводятся в общую витрину рисков. Итоговый риск для каждой области (рис. 3.45) считается простым усреднением рисков по ней.[59]
Рис. 3.42. Test Analytics: ввод атрибутов для Google+
Рис. 3.43. Test Analytics: ввод компонентов для Google+
Рис. 3.44. Test Analytics: ввод возможностей в ячейке. Обратите внимание: вводится количество возможностей на пересечении, а не величина риска
Рис. 3.45. Test Analytics: карта рисков для Google+
Возможность связать расчет рисков с текущими данными проекта — это опциональная экспериментальная возможность GTA. Вы добавляете новые тесты, пишете новый код, находите новые дефекты, и оценка риска меняется. Как инженеры по тестированию, мы и так всегда держали все эти изменения в голове, эта фича просто позволяет опираться на фактические данные и делать это более системно. Тест-планы, даже основанные на рисках ACC, часто хороши в начале планирования тестирования. Но скоро они могут устареть и покрыться пылью. Хотя в GTA всегда можно внести любые изменения при получении любых новых данных, мы хотим автоматизировать и эту сторону планирования тестирования.
Пока GTA умеет связывать свои данные только с нашими внутренними базами, но мы работаем над избавлением от этой зависимости в будущем. Работая с возможностями в GTA, тестировщики могут ссылаться на секции или запросы в багтрекинговой системе, ветку кода или номер тест-кейса. В Google все используют одни и те же базы, поэтому это работает. Как только метрики багов, кода или тестов меняются, запускаются простые подсчеты и риски пересчитываются. Сейчас несколько команд разработки испытывают этот метод на себе.
Правила расчета, которые мы используем, постоянно меняются, поэтому мы их не будем здесь приводить. По сути, они показывают, как изменилось число багов, строк кода, прошедших и упавших тестов к завершению оценки рисков. Мы учитываем то, что у разных команд разные подходы, ведь некоторые заносят даже мельчайшие баги или по-другому измеряют свой код. Каждый компонент риска масштабируется в рамках условий проекта. Посмотрите примеры связей данных с рисками для Google Sites на рис. 3.46–3.48.
Рис. 3.46. Test Analytics: связь источников данных с риском
Рис. 3.47. Test Analytics: связанные тесты
Рис. 3.48. Test Analytics: связанные баги
Легко не заметить одну очень важную функцию в GTA: тестировщики могут быстро превратить список возможностей в серию тестов. Команды очень просили добавить именно эту фичу. Смысл в том, что возможности — это простой список высокоуровневых тестов, который нужно прогнать перед выпуском программы. Для маленьких команд, которые фокусируются на исследовательском тестировании, например как команда Google Docs, этот список можно легко использовать вместо базы данных тестов.
В GTA используется матрица ACC-анализа, и это дает тестировщикам кардинально новый подход. Обычно тестовые серии или задания на разработку тестов назначаются по компонентам. ACC позволяет распределять тестировщиков по атрибутам. Наши эксперименты показали, что такой фокус работает лучше всего. Если за тестировщиком закрепить атрибут «быстрый» для всего набора тестов, то он может оценить, насколько быстро работают все интересующие компоненты продукта за одну серию тестов. Так можно выловить медленные компоненты, которые при независимом тестировании могли прикидываться достаточно быстрыми.
Что же со связями и зависимостями между рисками разных проектов? В GTA эта фича пока не реализована. Каждый проект делает свой ACC- анализ и оценивает риски только для своего проекта, без учета других проектов компании. Если кто-то хочет проанализировать риски нескольких продуктов сразу, ему нужно нормировать данные между проектами, чтобы смотреть на них в совокупности. Только то, что ваша маленькая команда работает над внутренним инструментом, не значит, что у вас не может быть максимальных значений рисков. Оставьте относительность тем, кто видит много проектов сразу. Когда оцениваете риск для своего проекта, оценивайте его так, как будто ваш проект — единственный в компании. В нем вполне могут быть часто срабатывающие риски с высокой степенью воздействия.
Сейчас проект GTA используется еще в нескольких компаниях, и мы хотим сделать GTA общедоступным продуктом с открытым кодом. Мы хотим, чтобы другие команды тестирования могли устанавливать у себя свои системы на движке Google App Engine или даже портировать код и разворачивать на других платформах.
GTA делает анализ рисков настолько простым и удобным, что люди действительно им пользуются. Джим Рирдон вырастил GTA с нуля и сейчас поддерживает его в опенсорсе (подробнее об этом мы рассказываем в приложении В). На момент написания книги несколько больших компаний, занимающихся облачным тестированием, хотят интегрировать эту технологию в свои рабочие процессы и инструменты.[60] И еще около 200 внешних инженеров записались на использование GTA.
- Тестирование, обращенное к пользователю
- Инженер по тестированию
- Планирование тестирования
- Риск
- Снижение рисков
- Напоследок о рисках
- Пользовательские сценарии Джейсон Арбон
- Краудсорсинг Джеймс Уиттакер
- Пишем тест-кейсы
- Интересные факты из жизни багов
- Немного подробнее о Buganizer
- Жизненный путь бага Джеймс Уиттакер
- Как мы нанимаем инженеров по тестированию
- Как отличить тестировщика от разработчика в тестировании Джейсон Арбон
- Собеседование с инженерами по тестированию
- Управление тестированием в Google
- Управление «пиратским кораблем» для чайников Джеймс Арбон
- Тестирование в режиме сопровождения
- Пример режима сопровождения: Google Desktop Джейсон Арбон
- Эксперимент с Quality Bots
- Сингулярность: легенда о происхождении ботов Джейсон Арбон
- Bots: детство, отрочество и масштабирование на весь интернет Теджас Шах
- Эксперимент BITE
- Google Test Analytics
- Бесплатное тестирование
- Инновации и эксперименты в тестировании Джеймс Арбон
- Внешние тестировщики
- Интервью с инженером по тестированию Google Docs Линдси Уэбстер
- Интервью с инженером по тестированию YouTube Эппл Чоу
- Google Test Analytics — теперь с открытым кодом
- rc.test-iptables.txt
- CPC или CPM: показатель оптимизации № 11 – CPC как инновация компании Google
- Example rc.test-iptables script
- 6.2. Заработок на контекстной рекламе Google AdSense
- Testing the Project
- Testing Wdm2 Power Capabilities
- Test Driver Code
- Глава 1. Первое знакомство с организацией тестирования в Google
- Тестовые данные (Test Data)
- Testing Samba with the testparm Command
- Поиск в Гугле (Google)