Как тестируют в Google
Шрифт:
Следующий этап ACC-анализа состоит в описании возможностей продукта, «глаголов» всей системы, действий, которые она выполняет по запросу пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые совершает приложение. По сути, пользователь выбрал этот продукт именно из-за возможностей: ему нужно что-то сделать, и ваше приложение может это сделать.
Возможности — это действия системы, которые она выполняет под руководством пользователя. Это реакция программы на ввод данных, ответы на запросы и все операции, которые выполняет приложение по запросу пользователя.
Возьмем, к примеру, Chrome. Он отображает
Возможности лежат на пересечении атрибутов и компонентов. То есть компоненты выполняют какую-то функцию для того, чтобы соответствовать атрибуту продукта, а результатом станет предоставление пользователю возможности. Давайте вернемся к Chrome для наглядности: Chrome быстро отображает страницы, он безопасно воспроизводит Flash-файлы. Если ваш продукт делает что-то, что не является пересечением компонента и атрибута, то, скорее всего, это что-то не имеет значения и даже есть смысл спросить, зачем это вообще нужно. Возможность, которая не работает на ключевую цель продукта, может дать потенциальные точки сбоев, поэтому лучше всего сбросить этот балласт.
Правда, есть вариант, что эта загадочная возможность все же имеет право на существование, просто вы этого не знаете, а значит — плохо изучили продукт. Тестировщику недопустимо не понимать суть происходящего — это вопрос профессиональной квалификации. Если хотя бы один из инженеров проекта лучше всех понимает, какие именно возможности продукт предоставляет пользователю, то этот инженер однозначно тестировщик.
Вот пример нескольких возможностей интернет-магазина:
— Добавить/удалить товар из корзины. Это возможность компонента «Корзина», когда он пересекается с атрибутом интерфейса «интуитивный».
— Получить данные кредитных карт и верифицировать. Это возможность компонента «Корзина», когда он пересекается с атрибутами «удобный» и «интегрированный» (речь об интеграции с платежной системой).
— Обработать финансовые операции с помощью HTTPS. Это возможность компонента «Корзина», когда он пересекается с атрибутом «безопасный».
— Рекомендовать клиенту товары, основываясь на просмотренных им продуктах. Это возможность компонента «Поиск», когда он пересекается с атрибутом «удобный».
— Высчитать стоимость доставки. Это возможность компонента «Интеграция с почтовой службой UPS», когда он пересекается с атрибутами «быстрый» и «безопасный».
— Выводить информацию о наличии товара. Это возможность компонента «Поиск», когда он пересекается с атрибутами «удобный» и «точный».
— Отложить товар. Это возможность компонента «Корзина», когда он пересекается с атрибутом «удобный».
— Искать товар по ключевым словам, артикулу или категории. Это возможность компонента «Поиск», когда он пересекается с атрибутами «удобный» и «точный». В общем случае мы рассматриваем каждую категорию поиска как отдельную возможность.
Разумеется, количество возможностей продукта может быть большим. Если вам кажется, что вы перечислили все, что вы можете протестировать, — ура, вы освоили ACC-анализ. Ведь основная задача этого процесса — кратко и быстро перечислить главные возможности системы, работоспособность которых надо
Возможности обычно отображают представление пользователя о том, что система может делать. То есть если краткость правит бал в составлении списка атрибутов и компонентов, то список возможностей может быть очень большим, ведь они описывают все, что может делать система. Чем сложнее функциональность приложения, тем длиннее будет список ее возможностей.
У систем, над которыми мы работаем в Google, список возможностей доходит до ста и более пунктов (например, у Chrome OS их больше трех сотен), у более простых приложений могут быть десятки возможностей. Конечно, есть продукты с небольшим количеством возможностей, тогда их могут протестировать разработчики и первые пользователи. Поэтому если вы тестируете приложение, у которого меньше двадцати возможностей, задайтесь вопросом: а ваша работа здесь действительно нужна?
Самый важный аспект возможностей продукта — это то, что мы можем их протестировать. Не зря мы пишем возможности глаголами — ведь это активный признак субъекта. Глагол требует действий с нашей стороны — мы должны написать тест-кейсы, которые проверят, насколько точно реализована каждая возможность в системе и найдет ли пользователь свое взаимодействие с такой системой полезным. Позднее мы подробно обсудим, как возможности превращаются в элегантные тест-кейсы.
Самый важный аспект возможностей продукта — это то, что мы можем их протестировать.
Насколько общими должны быть возможности — предмет ожесточенных споров тестировщиков в Google. По определению, возможности не могут фиксироваться излишне детально, так как одна возможность может описывать любое количество сценариев пользователя. Например, в интернет-магазине, который мы приводили в пример, возможности не уточняют, какой предмет положили в корзину, и не описывают результат, который мы получим при конкретном поиске. Они только говорят нам о том, какие действия может выполнить пользователь. Такое обобщение делается намеренно, так как бессмысленно тратить время на тонны документации, если мы не собираемся это тестировать. Мы не можем протестировать все возможные варианты поиска и состояния корзины, поэтому напишем тест-кейсы только на основе тех вариантов, которые действительно будем тестировать.
Возможности не должны быть аналогами тест-кейсов — точных значений и данных у них нет. Например, для возможности «пользователь может что-то купить» тест-кейс будет включать «что именно он покупает». Возможности предусматривают наличие тестов, направляют их в нужное русло, но сами таковыми не являются.
Вернемся к примеру с Google Sites: обратите внимание на рис. 3.5, где в столбцах представлены атрибуты, а в строках — компоненты. Так мы связываем атрибуты с компонентами. Как вы видите, далеко не каждый компонент работает со всеми атрибутами, поэтому появляются пустые ячейки. В Chrome только некоторые компоненты связываются с атрибутами «быстрый» и «безопасный». Пустая ячейка на пересечении «атрибут–компонент» означает, что тестировать эту пару не нужно.
Рис. 3.5. Связь компонентов и атрибутов в GTA
Каждая строка или столбец в таблице — это срез функциональности системы, объединенный общим признаком. Можно разделить таблицу по строкам или по столбцам — и перед вами готовые планы тестовых сессий. Тест-менеджер может раздать командам разные строки или провести целенаправленную атаку на баги в конкретном столбце. Такое деление отлично подходит для исследовательского тестирования: вручив тестировщикам разные столбцы и колонки, вы избавитесь от совпадений и обеспечите более высокое покрытие.