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

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

С аналогичной ситуацией столкнулись в компании Google: потребовался некий единый стандарт разработки тестовых наборов. Благодаря Д.А. Уиттакеру, Д. Каролло, Д. Арбону и ряду других авторов удалось выработать методику, которая позволяет быстро и качественно составлять тест-планы. Она получила название ACC-анализ, и на сегодня внедрена в ряде других компаний-разработчиков мирового значения.

ACC (Attribute, Component, Capability) – методика, разбивающая процедуру создания тест-планов на 3 элемента: атрибуты, компоненты, возможности. Такой подход позволяет достичь эффективности тест-планов за счет:

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

Для лучшего понимания элементов ACC-анализа можно провести аналогию:

1. Атрибуты являются "прилагательными" системы. Они отличают продукт фирмы от аналогов конкурентов и выделяют его на рынке.
2. Компоненты можно сравнить с кирпичами, "существительными", которые строят систему и делают приложение таким, каким оно является по сути.
3. Возможности представляются "глаголами", действиями, которые осуществляет приложение в руках пользователя. Это некие реакции на запросы потребителя: ввод данных, разнообразие операций.

Рассмотрим основные принципы ACC-методики.

1. Стремление к списковой структуре
Нет нужды в тщательном описании сути тестов красивыми словами. Нужен лишь список из главных элементов, подвергаемых тестированию.

2. Никакого маркетинга
Реклама, PR и другие маркетинговые инструменты пусть остаются маркетологам. Инженерам не нужно рассказывать о преимуществах и достоинствах приложения, им интересен функционал и способы его реализации.

3. Достаточность информации
Тест-план должен быть оправданным по объему. И не всегда 100 страниц означает преимущество над 10 страницами текста. Вывод: стремимся к написанию тест-плана адекватного размера без лишних (понятных) пояснений.

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

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

6. Тест-кейсы как итог
Конечная цель составления тест-плана – понимание того, какие тест-кейсы потребуется написать. В противном случае он бесполезен.

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

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

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

При составлении перечня важно не переусердствовать по количеству: следует стремиться к 10-12 атрибутам максимум. Если их больше – вы уходите в ненужные детали или стремитесь приписать своему товару все возможные качества.

Достаточно 1-2 часов для означенного мероприятия.

Данный этап тестировщикам более понятен, так как связан непосредственно с функциональными особенностями будущего продукта. Компоненты следует признать строительными блоками, из которых состоит вся система.

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

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

Требования к количеству тут идентичны: не нужно делать 20-30 пунктов, достаточно 7-12. Если возникают трудности, приводите небольшой перечень атрибутов и компонентов. Потом все это будет расширяться, модифицироваться, изменяться по ходу развития проекта.

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

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

В качестве демонстрации возможностей попробуйте перечислить те задачи, которые выполняет браузер. Итак, он умеет: открывать страницы, отображать графические и текстовые элементы, обрабатывать запросы, скачивать файлы и т.п. Все это является возможностями.

Их количество не ограничено, в отличие от других элементов ACC-анализа. В случае сложных сервисов может наблюдаться и 200 возможностей.

Применяемая в компании Google методика представлена 3-мя взаимосвязанными элементами, о которых было сказано выше.

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

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

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

В качестве примера приведем часть элементов интернет-магазина, определенных на основе ACC-анализа (в ячейках показаны возможности).

Здесь мы имеем 4 атрибута и 3 компонента. На пересечении получаем возможности. Часть возможностей может относиться к нескольким атрибутам / компонентам. Некоторые ячейки могут содержать больше одной возможности.

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