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