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

Давайте решим, каким мы хотим видеть тест-план:

— он всегда актуален;

— он объясняет назначение продукта и то, почему пользователи его полюбят;

— он описывает структуру проекта с названиями отдельных компонентов и фич;

— он описывает, что будет делать продукт и как именно он это будет делать.

С точки зрения тестирования мы должны беспокоиться об актуальности тест-плана и в то же время не превращать его поддержание в самоцель:

— создание плана должно быть быстрым и должно давать возможность оперативного изменения;

— план должен описывать то, что надо протестировать;

— план должен помогать оценивать тестирование и выявлять пробелы в покрытии.

В Google история планирования тестирования почти такая же, как и в других компаниях. Каждая команда сама определяла то, как будет выглядеть и функционировать тест-план, исходя из принятых и удобных для нее форматов работы. Например, некоторые писали тест-планы в Google Docs в виде текстовых документов или электронных таблиц с общим доступом для своей команды. Другие хранили планы прямо на странице своего продукта. Третьи добавляли его на внутренние страницы Google Sites и включали ссылки на них в инженерную документацию и внутренние вики-системы. Были и те, кто предпочитал классику и пользовался документами Microsoft Word, которые рассылались по почте участникам команд. У кого-то тест-планов не было вообще, а были лишь наборы тест-кейсов, которые, должно быть, и представляли такой план.

Рецензировать такие планы было сложно, очень трудно было определить авторов и рецензентов. Дата создания многих тест-планов ясно говорит, что про них давно забыли, как про просроченный джем в недрах холодильника. Когда-то они были важны, но то время давно прошло.

В Google то тут, то там возникали предложения о создании централизованной системы хранения тест-планов и шаблонов для их составления. Эта прекрасная идея, возможно, и прижилась бы в другом месте, но она явно противоречила самоуправляемой культуре Google, где концепция «большого правительства» вызывает только насмешки.

На помощь пришел АСС-анализ (Attribute Component Capability) — процесс, который сформировался из практик нескольких команд Google. Его инициаторами были авторы книги и несколько их коллег. АСС-анализ прошел фазу ранних последователей, прижился и сейчас даже экспортируется в другие компании. Его автоматизированная версия называется Google Test Analytics.

Основные принципы Attribute Component Capability:

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

— Оставьте продажи в покое.Тест-план — это не маркетинговый документ, поэтому разговоры о том, как прекрасен продукт и как он вписывается в свою рыночную нишу, здесь не нужны. Тестовые планы не для покупателей или аналитиков, они для инженеров.

— Не лейте воду.У тест-плана нет заранее определенного объема. Это не дипломная работа, где размер имеет значение. Больше — не означает лучше. Размер плана должен зависеть от объема тестирования, а не от склонности его автора к графомании.

— Если какой-то пункт не важен и не требует действий, не включайте его в план.Ни одно слово в тест-плане не должно вызывать у его читателя реакции «это для меня не важно».

— Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать. Если ему будет нужно — он продолжит чтение.

— Направляйте процесс мышления.Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования. Он ведет его от высокоуровневых концепций к низкоуровневым деталям, которые можно реализовать.

— Итогом должны стать тест-кейсы.К моменту завершения план должен не только показывать, как выполнять тестирование, но и сделать работу над тест-кейсами очевидной. Если ваш план не приводит к созданию тестов, вы потратили время зря.

На заметку

Если ваш план не приводит к созданию тестов, вы потратили время зря.

Последний пункт — самый важный: если тест-план не описывает, какие тесты мы должны написать, то он не соответствует главной задаче, ради которой мы его писали, — помочь в тестировании. Планирование тестирования должно привести нас в точку, где мы точно знаем, какие тесты нужно написать. Еще раз: вы можете считать планирование оконченным, когда точно знаете, какие тесты нужно написать.

АСС-анализ помогает в решении этой задачи планировщику, проводя его через три представления о продукте, соответствующих:

1. прилагательным и наречиям , описывающим цели и назначение продукта;

2. существительным , определяющим различные части и фичи продукта;

3. глаголам , которые расскажут, что продукт будет делать.

Следуя этому плану, мы сможем протестировать, что все работает правильно, а компоненты удовлетворяют цели и назначению приложения.

A — значит Attribute

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

Мы ранжируем данные о продукте с помощью ACC-анализа (Attribute, Component, Capability), то есть раскладываем всю имеющуюся у нас информацию по трем полкам: атрибуты, компоненты, возможности. И, следуя принятому порядку, начинаем с определения атрибутов.

Итак, атрибуты — это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его. Возьмем Chrome и опишем его как «быстрый», «безопасный», «стабильный» и «стильный»: вот определения продукта, на которые мы повесим ярлык «атрибуты» и положим на соответствующую полку.

Такая маркировка здорово упростит нам работу в будущем, когда мы будем связывать тест-кейсы с этими самыми атрибутами. Мы будем четко видеть, какой объем работы по тестированию нужен, чтобы продемонстрировать, насколько Chrome быстрый, безопасный и т.д.

На заметку