C — значит Capability
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]
— Возможность должна стыковаться с другими возможностями. Сценарии использования или пользовательские сценарии должно быть можно представить как серию возможностей. Если это сделать нельзя, то в вашей системе какие-то возможности отсутствуют или представлены слишком общими понятиями.
Преобразование набора возможностей в пользовательские истории — это необязательный шаг, но он способен сделать всю систему тестирования более гибкой. В Google есть несколько команд, которые предпочитают более общие пользовательские истории частным тест-кейсам, когда работают с внешнимим подрядчиками или при организации исследовательского краудсорс-тестирования. Почему? Слишком конкретные тест-кейсы, выполняемые сторонним тестировщиком многократно, вызывают скуку, становятся рутиной, в то время как пользовательские истории дают больше свободы действий, делают процесс тестирования творческим и интересным, защищают от ошибок, которые можно сделать, занимаясь механическим процессом, уже набившим оскомину.
Что бы вы ни выбрали своей целью — создание тест-кейсов, пользовательских историй, а может, и того и другого, — используйте общие правила для трансформации возможностей в тест-кейсы. Имейте в виду, что это просто направляющие, а не абсолютные утверждения.
— Каждая возможность должна быть связана хотя бы с одним тест-кейсом. Если она была записана, значит достаточно важна для того, чтобы ее протестировать.
— Многие возможности требуют более одного тест-кейса. Каждый раз, когда во входной информации есть отклонения, последовательности ввода, системные переменные, тест-кейсов нужно делать несколько. Атаки, описанные в книге «How to Break Software», и туры в «Exploratory Software Testing» здорово описывают принципы выбора тестовых примеров и подход к выбору данных, которые легко превращают возможность в тест-кейс, вылавливающий баг.
— Не все возможности равны. Есть те, которые важнее других. На следующем шаге процесса возможности связываются с рисками и определяют степень их важности.
Завершив ACC-анализ, мы знаем все, что мы могли бы протестировать при неограниченном бюджете и времени. Но поскольку часто не хватает то одного, то другого, будет полезно выделить главное. В Google такая расстановка приоритетов называется анализом рисков, и это будет нашей следующей темой.
Пример: определение атрибутов, компонентов и возможностей Google+
ACC-анализ можно быстро выполнить в текстовом документе, таблице или даже на салфетке! Ниже следует сокращенный вариант ACC-процесса для Google+.
Атрибуты Google+ (список сформирован на основе наблюдения за дискуссией руководства Google).
— Социальный: позволяет пользователю обмениваться информацией и мыслями.
— Выразительный: пользователи используют возможности продукта для самовыражения.
— Простой: пользователь легко понимает, как сделать то, что он хочет.
— Релевантный: показывает только ту информацию, которая интересует пользователя.
— Расширяемый: интегрируется с другими ресурсами Google, сторонними сайтами и приложениями.
— Конфиденциальный: данные пользователя не будут открытыми.
Компоненты Google+ (получены из архитектурной документации).
— Профиль: информация и настройки текущего пользователя.
— Люди: профили людей, с которыми связан пользователь.
— Лента: ранжированная лента сообщений, комментариев, оповещений, фотографий и т.д.
— Круги: группы контактов («друзья», «коллеги» и т.д.).
— Оповещения: обозначения упоминания пользователя в сообщении.
— Интересы, или «+1»: обозначения материалов, которые понравились пользователю.
— Записи: сообщения о записях пользователей и их кругов.
— Комментарии: комментарии к сообщениям, фотографиям, видеороликам и т.д.
— Фотографии: фотографии, загруженные пользователями и их друзьями.
Возможности Google+.
Профиль:
— Социальный: обмениваться профилями и предпочтениями с друзьями и контактами.
— Выразительный: создавать онлайн-версию самих себя.
— Выразительный: взаимодействовать с Google+ по-своему.
— Простой: легко вводить, обновлять и распространять информацию.
— Расширяемый: передавать данные профилей приложениям с соответствующими правами доступа.
— Конфиденциальный: сохранять свои данные конфиденциальными.
— Конфиденциальный: передавать данные только одобренным пользователям и приложениям.
Люди:
— Социальный: связываться с друзьями, коллегами и членами своих семей.
— Выразительный: легко различать профили других пользователей.
— Простой: удобно управлять контактами пользователя.
— Релевантный: фильтровать свои контакты по своим критериям.
— Расширяемый: передавать контактную информацию службам и приложениям, имеющим необходимые разрешения.
— Конфиденциальный: предоставлять данные о контактах пользователя только сторонам с соответствующими разрешениями.
Лента:
— Социальный: информировать пользователей об обновлениях их социальных сетей.
— Релевантный: фильтровать те обновления, которые интересуют пользователя.
— Расширяемый: передавать обновления ленты службам и приложениям.
Круги:
— Социальный: группировать контакты на основании социального контекста.
— Выразительный: создавать новые круги на основе контекста пользователя.
— Простой: удобно добавлять, обновлять и удалять контакты из кругов.
— Простой: удобно создавать и изменять круги.
— Расширяемый: передавать данные о кругах службам и приложениям.
Оповещения:
— Простой: показывать оповещения кратко.
— Расширяемый: отправлять оповещения другим службам и приложениям.
Видеочат:
— Социальный: приглашать свои круги в видеочат.
— Социальный: открыть свой видеочат публике.
— Социальный: оповещать других пользователей в своих лентах о видеочатах.
— Простой: создавать видеочат и принимать в нем участие в несколько кликов.
— Простой: отключить в один клик видео- и аудиоданные.
— Простой: приглашать дополнительных пользователей в существующий видеочат.
— Выразительный: посмотреть, как видеочат будет выглядеть для других.
— Расширяемый: общаться в текстовом чате во время видеочата.
— Расширяемый: включать видеоролики с YouTube в видеочат.
— Расширяемый: настраивать устройства в Настройках.
— Расширяемый: участвовать в видеочатах без веб-камеры, используя аудиоканал.
— Конфиденциальный: ограничивать доступ в видеочат только для приглашенных гостей.
— Конфиденциальный: оповещать только приглашенных гостей о видеочате.
Записи:
— Выразительный: выражать свои мысли.
— Конфиденциальный: ограничивать сообщения выбранной аудиторией.
Комментарии:
— Выразительный: выражать свое мнение с помощью комментариев.
— Расширяемый: передавать данные комментариев для использования другими службами и приложениями.
— Конфиденциальный: ограничивать сообщения выбранной аудиторией.
Фотографии:
— Социальный: делиться фотографиями с контактами и друзьями.
— Простой: легко загружать новые фотографии.
— Простой: легко импортировать фотографии из других источников.
— Расширяемый: интегрироваться с другими фотослужбами.
— Конфиденциальный: ограничивать доступ к фотографиям только для выбранной аудитории.
На рис. 3.6 приведены результаты ACC-анализа в форме электронной таблицы.
Рис. 3.6. Электронная таблица ACC для Google+
А на рис. 3.7 эти же данные представлены в другой форме.
Рис. 3.7. Таблица ACC для Google+
Данный текст является ознакомительным фрагментом.