Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 10 (всего у книги 26 страниц)

Планирование тестирования

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

Тестировщики же работают с документами и артефактами, которые имеют определенный срок годности: на ранних стадиях они пишут тест-планы, позднее создают и выполняют тест-кейсы, формируют баг-репорты. Еще позже тестировщики составят отчеты о покрытии кода тестами и соберут отзывы у пользователей. Когда проект выпущен, разве кого-то интересует, как было проведено тестирование? Если продукт полюбился пользователю, то хорошее тестирование – это уже данность. Если проект потерпел неудачу, люди могут высказать свое мнение о тестировании, но вряд ли кто-то захочет подробностей.

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

Среди всех тестовых документов у тест-плана самая маленькая продолжительность жизни. [35]35
  Конечно, в случаях когда заказчик участвует в обсуждении тестовых планов или существует некое правительственное распоряжение на этот счет, гибкость, о которой мы пишем, пропадает. Есть некоторые тестовые планы, которые нужно писать и регулярно обновлять!


[Закрыть]На ранней стадии руководитель проекта часто настаивает на создании тест-плана (в приложении А приведен тест-план для ранней версии Chrome OS). Считается, что написание тест-плана – это отдельная задача со своим сроком и важностью. Но когда такой план создан, становится трудно уговорить того же руководителя проекта регулярно просматривать и обновлять его. Тест-план превращается в любимого плюшевого мишку, которого мы, как в детстве, таскаем с собой, не играя, но обязательно разревемся, если у нас его отберут.

Тест-план рождается первым, первым же он должен и умереть – отпустите его. На ранней стадии проекта тест-план еще отражает общую идею проекта, но без постоянного ухода и грамотного кормления тест-план быстро чахнет: появляется новый код, фичи изменяются и добавляются, решения, которые хорошо смотрелись на бумаге, переосмысливаются по ходу работы и получения отзывов от пользователей.

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

На заметку

Тест-план рождается первым, и первым же он должен умереть.

Этот пункт – краеугольный камень всей идеи планирования тестирования. Насколько тест-план действительно управляет тестированием на протяжении всей разработки? Обращаются ли к нему тестировщики, распределяя фичи между собой? Настаивают ли разработчики на своевременном обновлении тест-плана? Правда ли, что руководители разработки открывают тест-план на своих компьютерах так же часто, как и свои списки дел? Как часто тест-менеджер ссылается на содержимое тест-плана во время встреч, посвященных статусам и прогрессу? Если план действительно важен, то все это должно происходить каждый день.

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

Но это идеальный вариант, почти сказочная ситуация, которой мало кому удавалось достичь – будь то в 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 быстрый, безопасный и т.д.

На заметку

Атрибуты – это «прилагательные» нашей системы. Это качества и характеристики, которые продвигают наш продукт и отличают его на рынке. Это те причины, по которым пользователи выбирают именно его.

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

Вот несколько советов для формирования перечня атрибутов.

– Проще.Вы не должны тратить на составление списка больше часа или двух.

– Точнее.Убедитесь, что вы пользуетесь документами или данными, которые ваша команда считает правдивыми.

– Быстрее.Не бойтесь, если вы что-то упустите на этом этапе. Если информация важная, она всплывает в ходе работы, если же нет – беспокоиться не о чем.

– Короче.Не больше дюжины атрибутов – это хороший результат. Мы свели список атрибутов Chrome OS к двенадцати пунктам, но, оглядываясь назад, можем сказать, что восемь или девять было бы в самый раз.

Рис. 3.1. Анализ рисков Chrome OS

Обратите внимание, что некоторые рисунки в этой главе просто иллюстрируют написанное, не стоит в них всматриваться.

Атрибуты нужны, чтобы определить, как продукт работает на ключевую цель своего создания. Тестировщики используют их, чтобы убедиться, что их тестирование тоже работает на эту цель.

Возьмем, к примеру, Google Sites – бесплатное приложение по созданию сайтов для открытых или закрытых сообществ. Как и у многих других пользовательских приложений, список практически всех нужных нам атрибутов уже написан внутри самого продукта. И верно: большинство приложений, имеющих что-то вроде страницы «С чего начать работу» или какие-нибудь рекламные тексты, уже определили атрибуты за вас. А если нет, то простой разговор со специалистом по продажам, просмотр коммерческих видео или презентаций даст вам необходимую информацию.

Важно понимать, что атрибуты лежат на поверхности. Если вам тяжело быстро перечислить их, то вы недостаточно знаете свой продукт, чтобы хорошо его тестировать. Знайте и любите свой продукт, и тогда составление списка атрибутов станет минутным делом. Ну ладно, ладно, любить не обязательно, но и не запрещено законом.

Рис. 3.2. Добро пожаловать на Google Sites

Рис. 3.3. Атрибуты Google Sites, записанные в GTA

На заметку

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

В Google мы можем фиксировать список атрибутов по-разному: можем использовать текстовые документы, электронные таблицы или специальную программу Google Test Analytics (GTA), созданную нашими предприимчивыми инженерами. Совершенно не важно, что именно вы будете использовать, главное, чтобы атрибуты были записаны.

C – значит Component

Вы уже составили список атрибутов? Добро пожаловать в мир компонентов! Компоненты – это «существительные» нашего продукта. Это наши кирпичи, из которых построена вся система. Компоненты – это, к примеру, корзина и система оформления заказов в интернет-магазине, это возможность редактирования и печати в текстовом процессоре. Иными словами, компоненты – это ключевые части кода, которые делают программу тем, чем она является. Собственно, это и есть те вещи, которые тестировщикам поручено тестировать!

На заметку

Компоненты – наши кирпичи, из которых построена вся система, это ключевые части кода, которые делают программу тем, чем она является.

Обычно за компонентами далеко ходить не надо, часто они уже определены в документе архитектуры системы. Компоненты в крупных системах – это большие прямоугольники на архитектурных диаграммах, а их названия часто появляются в тегах в багтрекинговой системе или явно указываются в проектной документации. В системах поменьше компонентами являются классы и объекты в коде. В любом случае можно подойти к разработчику и спросить, с какими компонентами он работает. Вам останется только зафиксировать список, и дело вместе с компонентами в шляпе.

Как и в случае с атрибутами, уровень детализации имеет значение. Слишком много подробностей – информация станет перегруженной, а отдача снизится. Слишком мало подробностей – станет непонятно, зачем вы вообще делали эту работу. Список должен быть небольшим. Получилось десять пунктов? Отлично! Двадцать? Многовато, если только ваша система не очень большая. Второстепенные подробности можно и пропустить, так как они или являются частью другого компонента, или не так уж и важны для конечного пользователя.

В самом деле, составить список атрибутов или компонентов – это дело нескольких минут. Если вам тяжело это сделать, то у вас однозначно слишком мало знаний о продукте и нужно потратить время на его изучение. Продвинутый пользователь проекта даже спросонья немедленно перечислит список атрибутов продукта, так же как любой участник проекта, обладающий доступом к исходному коду и документации, легко перечислит список компонентов. Для нас тестировщик – это опытный пользователь и подкованный участник проекта одновременно.

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

Рис. 3.4. Компоненты Google Sites, записанные в GTA

C – значит Capability

Следующий этап ACC-анализа состоит в описании возможностей продукта, «глаголов» всей системы, действий, которые она выполняет по запросу пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые совершает приложение. По сути, пользователь выбрал этот продукт именно из-за возможностей: ему нужно что-то сделать, и ваше приложение может это сделать.

На заметку

Возможности – это действия системы, которые она выполняет под руководством пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые выполняет приложение по запросу пользователя.

Возьмем, к примеру, Chrome. Он отображает веб-страницы, воспроизводит Flash-файлы, синхронизируется между клиентами и скачивает документы. Все это и многое другое составляет список возможностей браузера Chrome. Или возьмем интернет-магазин: он может найти товар и оформить заказ – это и есть его возможности. Проще говоря, если приложение может выполнить какую-то задачу, это мы и назовем его возможностью.

Возможности лежат на пересечении атрибутов и компонентов. То есть компонентывыполняют какую-то функцию для того, чтобы соответствовать атрибутупродукта, а результатом станет предоставление пользователю возможности. Давайте вернемся к Chrome для наглядности: Chrome быстроотображает страницы, он безопасновоспроизводит Flash-файлы. Если ваш продукт делает что-то, что не является пересечением компонента и атрибута, то, скорее всего, это что-то не имеет значения и даже есть смысл спросить, зачем это вообще нужно. Возможность, которая не работает на ключевую цель продукта, может дать потенциальные точки сбоев, поэтому лучше всего сбросить этот балласт.

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

Вот пример нескольких возможностей интернет-магазина:

– Добавить/удалить товар из корзины.Это возможность компонента «Корзина», когда он пересекается с атрибутом интерфейса «интуитивный».

– Получить данные кредитных карт и верифицировать.Это возможность компонента «Корзина», когда он пересекается с атрибутами «удобный» и «интегрированный» (речь об интеграции с платежной системой).

– Обработать финансовые операции с помощью HTTPS. Это возможность компонента «Корзина», когда он пересекается с атрибутом «безопасный».

– Рекомендовать клиенту товары, основываясь на просмотренных им продуктах.Это возможность компонента «Поиск», когда он пересекается с атрибутом «удобный».

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

– Выводить информацию о наличии товара.Это возможность компонента «Поиск», когда он пересекается с атрибутами «удобный» и «точный».

– Отложить товар.Это возможность компонента «Корзина», когда он пересекается с атрибутом «удобный».

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

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

Возможности обычно отображают представление пользователя о том, что система может делать. То есть если краткость правит бал в составлении списка атрибутов и компонентов, то список возможностей может быть очень большим, ведь они описывают все, что может делать система. Чем сложнее функциональность приложения, тем длиннее будет список ее возможностей.

У систем, над которыми мы работаем в Google, список возможностей доходит до ста и более пунктов (например, у Chrome OS их больше трех сотен), у более простых приложений могут быть десятки возможностей. Конечно, есть продукты с небольшим количеством возможностей, тогда их могут протестировать разработчики и первые пользователи. Поэтому если вы тестируете приложение, у которого меньше двадцати возможностей, задайтесь вопросом: а ваша работа здесь действительно нужна?

Самый важный аспект возможностей продукта – это то, что мы можем их протестировать. Не зря мы пишем возможности глаголами – ведь это активный признак субъекта. Глагол требует действий с нашей стороны – мы должны написать тест-кейсы, которые проверят, насколько точно реализована каждая возможность в системе и найдет ли пользователь свое взаимодействие с такой системой полезным. Позднее мы подробно обсудим, как возможности превращаются в элегантные тест-кейсы.

На заметку

Самый важный аспект возможностей продукта – это то, что мы можем их протестировать.

Насколько общими должны быть возможности – предмет ожесточенных споров тестировщиков в Google. По определению, возможности не могут фиксироваться излишне детально, так как одна возможность может описывать любое количество сценариев пользователя. Например, в интернет-магазине, который мы приводили в пример, возможности не уточняют, какой предмет положили в корзину, и не описывают результат, который мы получим при конкретном поиске. Они только говорят нам о том, какие действия может выполнить пользователь. Такое обобщение делается намеренно, так как бессмысленно тратить время на тонны документации, если мы не собираемся это тестировать. Мы не можем протестировать все возможные варианты поиска и состояния корзины, поэтому напишем тест-кейсы только на основе тех вариантов, которые действительно будем тестировать.

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

Вернемся к примеру с Google Sites: обратите внимание на рис. 3.5, где в столбцах представлены атрибуты, а в строках – компоненты. Так мы связываем атрибуты с компонентами. Как вы видите, далеко не каждый компонент работает со всеми атрибутами, поэтому появляются пустые ячейки. В Chrome только некоторые компоненты связываются с атрибутами «быстрый» и «безопасный». Пустая ячейка на пересечении «атрибут–компонент» означает, что тестировать эту пару не нужно.

Рис. 3.5. Связь компонентов и атрибутов в GTA

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

Числовые значения в ячейках показывают количество возможностей, которые может предложить компонент для выполнения атрибута. Чем число выше, тем больше тестов связано с таким пересечением. Например, компонент «Просмотр страницы» взаимодействует с атрибутом «доступный» в трех возможностях:

– сделать документ доступным для сотрудников;

– дать возможность сотрудникам редактировать документ;

– показывать положение сотрудника на странице.

Итак, эти возможности проясняют моменты, которые нужно протестировать для пары «Просмотр страницы» и «доступный». Мы можем написать тест-кейс для каждой из них или протестировать комбинацию возможностей, объединив их в более крупный сценарий использования или тестовый сценарий.

Умение описать хорошие возможности требует определенного навыка. Вот несколько самых важных свойств возможностей, знание которых поможет при работе:

– Возможность должна быть представлена как действиеи описывать выполнение пользователем одной задачи в тестируемом приложении.

– Возможность должна предоставлять тестировщику достаточно информации, чтобы он понял, какие переменные надо учитывать при написании тест-кейса. Например, дана возможность – «Обработать финансовые операции с помощью HTTPS». В данном случае тестировщик должен понимать, какие финансовые операции может выполнить система, какой механизм будет проверять осуществление операции через HTTPS. Да, работа немалая! Если вы думаете, что какие-то финансовые операции могут быть упущены, скажем, новым тестировщиком, то продублируйте эту возможность для разных типов операций. Опять же, если команда тестирования собаку съела на HTTPS, то общей формулировки будет вполне достаточно. Не усложняйте себе задачу и позволяйте возможностям оставаться общими, оставьте тест-кейсам и исследовательским тестировщикам самим определить нужный уровень детализации. [36]36
  Позволить тестировщику детализировать возможность – здравая мысль: становится больше вариантов интерпретации функциональности и их преобразований в тестовые примеры, а это, в свою очередь, улучшает покрытие.


[Закрыть]

– Возможность должна стыковаться с другими возможностями. Сценарии использования или пользовательские сценарии должно быть можно представить как серию возможностей. Если это сделать нельзя, то в вашей системе какие-то возможности отсутствуют или представлены слишком общими понятиями.

Преобразование набора возможностей в пользовательские истории – это необязательный шаг, но он способен сделать всю систему тестирования более гибкой. В Google есть несколько команд, которые предпочитают более общие пользовательские истории частным тест-кейсам, когда работают с внешнимим подрядчиками или при организации исследовательского краудсорс-тестирования. Почему? Слишком конкретные тест-кейсы, выполняемые сторонним тестировщиком многократно, вызывают скуку, становятся рутиной, в то время как пользовательские истории дают больше свободы действий, делают процесс тестирования творческим и интересным, защищают от ошибок, которые можно сделать, занимаясь механическим процессом, уже набившим оскомину.

Что бы вы ни выбрали своей целью – создание тест-кейсов, пользовательских историй, а может, и того и другого, – используйте общие правила для трансформации возможностей в тест-кейсы. Имейте в виду, что это просто направляющие, а не абсолютные утверждения.

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

– Многие возможности требуют более одного тест-кейса. Каждый раз, когда во входной информации есть отклонения, последовательности ввода, системные переменные, тест-кейсов нужно делать несколько. Атаки, описанные в книге «How to Break Software», и туры в «Exploratory Software Testing» здорово описывают принципы выбора тестовых примеров и подход к выбору данных, которые легко превращают возможность в тест-кейс, вылавливающий баг.

– Не все возможности равны. Есть те, которые важнее других. На следующем шаге процесса возможности связываются с рисками и определяют степень их важности.

Завершив ACC-анализ, мы знаем все, что мы могли быпротестировать при неограниченном бюджете и времени. Но поскольку часто не хватает то одного, то другого, будет полезно выделить главное. В Google такая расстановка приоритетов называется анализом рисков, и это будет нашей следующей темой.

Пример: определение атрибутов, компонентов и возможностей Google+

ACC-анализ можно быстро выполнить в текстовом документе, таблице или даже на салфетке! Ниже следует сокращенный вариант ACC-процесса для Google+.

Атрибуты Google+(список сформирован на основе наблюдения за дискуссией руководства Google).

– Социальный: позволяет пользователю обмениваться информацией и мыслями.

– Выразительный: пользователи используют возможности продукта для самовыражения.

– Простой: пользователь легко понимает, как сделать то, что он хочет.

– Релевантный: показывает только ту информацию, которая интересует пользователя.

– Расширяемый: интегрируется с другими ресурсами Google, сторонними сайтами и приложениями.

– Конфиденциальный: данные пользователя не будут открытыми.

Компоненты Google+(получены из архитектурной документации).

– Профиль: информация и настройки текущего пользователя.

– Люди: профили людей, с которыми связан пользователь.

– Лента: ранжированная лента сообщений, комментариев, оповещений, фотографий и т.д.

– Круги: группы контактов («друзья», «коллеги» и т.д.).

– Оповещения: обозначения упоминания пользователя в сообщении.

– Интересы, или «+1»: обозначения материалов, которые понравились пользователю.

– Записи: сообщения о записях пользователей и их кругов.

– Комментарии: комментарии к сообщениям, фотографиям, видеороликам и т.д.

– Фотографии: фотографии, загруженные пользователями и их друзьями.

Возможности Google+.

Профиль:

– Социальный: обмениваться профилями и предпочтениями с друзьями и контактами.

– Выразительный: создавать онлайн-версию самих себя.

– Выразительный: взаимодействовать с Google+ по-своему.

– Простой: легко вводить, обновлять и распространять информацию.

– Расширяемый: передавать данные профилей приложениям с соответствующими правами доступа.

– Конфиденциальный: сохранять свои данные конфиденциальными.

– Конфиденциальный: передавать данные только одобренным пользователям и приложениям.

Люди:

– Социальный: связываться с друзьями, коллегами и членами своих семей.

– Выразительный: легко различать профили других пользователей.

– Простой: удобно управлять контактами пользователя.

– Релевантный: фильтровать свои контакты по своим критериям.

– Расширяемый: передавать контактную информацию службам и приложениям, имеющим необходимые разрешения.

– Конфиденциальный: предоставлять данные о контактах пользователя только сторонам с соответствующими разрешениями.

Лента:

– Социальный: информировать пользователей об обновлениях их социальных сетей.

– Релевантный: фильтровать те обновления, которые интересуют пользователя.

– Расширяемый: передавать обновления ленты службам и приложениям.

Круги:

– Социальный: группировать контакты на основании социального контекста.

– Выразительный: создавать новые круги на основе контекста пользователя.

– Простой: удобно добавлять, обновлять и удалять контакты из кругов.