Как тестируют в 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+ по-своему.

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

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

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

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

Люди:

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

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

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

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

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

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

Лента:

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

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

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

Круги:

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

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

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

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