Чтобы тест-план оставался жизнеспособным, требуется огромная бюрократическая работа, и она оправданна только в том случае, когда к этому документу регулярно обращаются заинтересованные в проекте люди.
На заметку
Тест-план рождается первым, и первым же он должен умереть.
Этот пункт — краеугольный камень всей идеи планирования тестирования. Насколько тест-план действительно управляет тестированием на протяжении всей разработки? Обращаются ли к нему тестировщики, распределяя фичи между собой? Настаивают ли разработчики на своевременном обновлении тест-плана? Правда ли, что руководители разработки открывают тест-план на своих компьютерах так же часто, как и свои списки дел? Как часто тест-менеджер ссылается на содержимое тест-плана во время встреч, посвященных статусам и прогрессу? Если план действительно важен, то все это должно происходить каждый день.
Тест-план должен играть центральную роль во время выполнения проекта. Это должен быть документ, который родился одновременно с проектом, живет и взрослеет вместе с ним, обновляется при каждом обновлении кода проекта и описывает продукт в его текущем виде, а не в том, каким он был на старте. Тест-план должен облегчить работу инженеру, примкнувшему к проекту на любой стадии.
Но это идеальный вариант, почти сказочная ситуация, которой мало кому удавалось достичь — будь то в Google или в других компаниях.
Давайте решим, каким мы хотим видеть тест-план:
— он всегда актуален;
— он объясняет назначение продукта и то, почему пользователи его полюбят;
— он описывает структуру проекта с названиями отдельных компонентов и фич;
— он описывает, что будет делать продукт и как именно он это будет делать.
С точки зрения тестирования мы должны беспокоиться об актуальности тест-плана и в то же время не превращать его поддержание в самоцель:
— создание плана должно быть быстрым и должно давать возможность оперативного изменения;
— план должен описывать то, что надо протестировать;
— план должен помогать оценивать тестирование и выявлять пробелы в покрытии.
В Google история планирования тестирования почти такая же, как и в других компаниях. Каждая команда сама определяла то, как будет выглядеть и функционировать тест-план, исходя из принятых и удобных для нее форматов работы. Например, некоторые писали тест-планы в Google Docs в виде текстовых документов или электронных таблиц с общим доступом для своей команды. Другие хранили планы прямо на странице своего продукта. Третьи добавляли его на внутренние страницы Google Sites и включали ссылки на них в инженерную документацию и внутренние вики-системы. Были и те, кто предпочитал классику и пользовался документами Microsoft Word, которые рассылались по почте участникам команд. У кого-то тест-планов не было вообще, а были лишь наборы тест-кейсов, которые, должно быть, и представляли такой план.
Рецензировать такие планы было сложно, очень трудно было определить авторов и рецензентов. Дата создания многих тест-планов ясно говорит, что про них давно забыли, как про просроченный джем в недрах холодильника. Когда-то они были важны, но то время давно прошло.
В Google то тут, то там возникали предложения о создании централизованной системы хранения тест-планов и шаблонов для их составления. Эта прекрасная идея, возможно, и прижилась бы в другом месте, но она явно противоречила самоуправляемой культуре Google, где концепция «большого правительства» вызывает только насмешки.
На помощь пришел АСС-анализ (Attribute Component Capability) — процесс, который сформировался из практик нескольких команд Google. Его инициаторами были авторы книги и несколько их коллег. АСС-анализ прошел фазу ранних последователей, прижился и сейчас даже экспортируется в другие компании. Его автоматизированная версия называется Google Test Analytics.
Основные принципы Attribute Component Capability:
— Избегайте повествования, пишите списки. Не все тестировщики хотят стать писателями, когда вырастут. Не все могут красиво описать текстом цели создания продукта или его потребности в тестировании. Прозу трудно читать, поэтому, пожалуйста, только факты!
— Оставьте продажи в покое. Тест-план — это не маркетинговый документ, поэтому разговоры о том, как прекрасен продукт и как он вписывается в свою рыночную нишу, здесь не нужны. Тестовые планы не для покупателей или аналитиков, они для инженеров.
— Не лейте воду. У тест-плана нет заранее определенного объема. Это не дипломная работа, где размер имеет значение. Больше — не означает лучше. Размер плана должен зависеть от объема тестирования, а не от склонности его автора к графомании.
— Если какой-то пункт не важен и не требует действий, не включайте его в план. Ни одно слово в тест-плане не должно вызывать у его читателя реакции «это для меня не важно».
— Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать. Если ему будет нужно — он продолжит чтение.
— Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования. Он ведет его от высокоуровневых концепций к низкоуровневым деталям, которые можно реализовать.
— Итогом должны стать тест-кейсы. К моменту завершения план должен не только показывать, как выполнять тестирование, но и сделать работу над тест-кейсами очевидной. Если ваш план не приводит к созданию тестов, вы потратили время зря.
На заметку
Если ваш план не приводит к созданию тестов, вы потратили время зря.
Последний пункт — самый важный: если тест-план не описывает, какие тесты мы должны написать, то он не соответствует главной задаче, ради которой мы его писали, — помочь в тестировании. Планирование тестирования должно привести нас в точку, где мы точно знаем, какие тесты нужно написать. Еще раз: вы можете считать планирование оконченным, когда точно знаете, какие тесты нужно написать.
АСС-анализ помогает в решении этой задачи планировщику, проводя его через три представления о продукте, соответствующих:
1. прилагательным и наречиям, описывающим цели и назначение продукта;
2. существительным, определяющим различные части и фичи продукта;
3. глаголам, которые расскажут, что продукт будет делать.
Следуя этому плану, мы сможем протестировать, что все работает правильно, а компоненты удовлетворяют цели и назначению приложения.
Мы начинаем планирование тестирования, или ACC-анализ, с выявления, почему этот продукт важен для пользователя и для бизнеса. Зачем мы создаем его? Какова его основная ценность? Почему он интересен пользователю? Помните, что разработчики и руководители продукта уже сделали свою работу: они выпускают продукт, который считают востребованным, поэтому нет необходимости объяснять, почему именно он нужен на рынке. Наша задача как тестировщиков — разложить все по полочкам и наклеить ярлыки. Это поможет нам учесть нужную информацию о продукте при тестировании.
Мы ранжируем данные о продукте с помощью ACC-анализа (Attribute, Component, Capability), то есть раскладываем всю имеющуюся у нас информацию по трем полкам: атрибуты, компоненты, возможности. И, следуя принятому порядку, начинаем с определения атрибутов.
Итак, атрибуты — это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его. Возьмем Chrome и опишем его как «быстрый», «безопасный», «стабильный» и «стильный»: вот определения продукта, на которые мы повесим ярлык «атрибуты» и положим на соответствующую полку.
Такая маркировка здорово упростит нам работу в будущем, когда мы будем связывать тест-кейсы с этими самыми атрибутами. Мы будем четко видеть, какой объем работы по тестированию нужен, чтобы продемонстрировать, насколько Chrome быстрый, безопасный и т.д.
На заметку
Атрибуты — это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его.
Менеджер продукта может помочь составить список атрибутов системы. Тестировщик составляет такой список, читая требования к продукту, изучая его концепцию, миссию или просто слушая, как специалист по продажам описывает продукт потенциальному покупателю. Мы обнаружили, что продавцы и евангелисты продукта — это превосходный источник атрибутов. Представьте рекламный текст на обратной стороне коробки или подумайте, как бы ваш продукт был представлен в интернет-магазине. Представили? Теперь у вас есть правильный ход мыслей, чтобы составить список атрибутов.
