Джеймс Уиттакер - Как тестируют в Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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