Проблема: Как можно протестировать графический интерфейс без непосредственного вызова элементов управления?

Решение: Разрабатывайте графический интерфейс пользователя как отдельный слой презентационного кода исходя из бизнес-логики. Используйте модульные- или API- тесты для тестирования бизнес-логики.

Контекст:

• Участники: Разработчики помогают тестировщикам разработать архитектуру автоматизации
• Продукт: Продукт имеет в наличии некоторый графический интерфейс или же другие формы отображения информации. Фреймворк автоматизации уже существует для модульного и API тестирования.
• Цели: Расширить автоматические тесты для покрытия графического интерфейса

Стратегия тестирования:

• Создание тестов: Тесты создаются как программистами, так и тестировщиками
• Выполнение тестов: Тесты запускаются через модульный или API фреймворк
• Оценка: Ожидаемые результаты описываются вручную в тестах. Заметка, фактические значения, которые отображаются на экране не проверяются, а проверяется значения которые посланы на спроектированный графический интерфейс

Атрибуты качества:

• Сопровождение и поддержка: Высокая. Цель отделения фактического графического интерфейса заключается в том, чтобы сделать тесты более устойчивыми к изменениям графического дизайна. Хотя некоторые технические проблемы могут помешать этой цели.
• Проверка: Средняя. GUI тесты написаны на том же языке программирования, что и модульные или API тесты. Соответственно, большинство людей из команды смогут проверять код автоматизации.
• Целостность и зависимость: Средняя. Фактически графический интерфейс не тестируется автоматически, потому все равно нужно будет выделить ресурсы на ручное тестирование.
• Возможность повторного использования: Средняя. Все что можно переиспользовать в этой технике - это модульные или API тесты

Следующий шаг:
Нет.

Проблема: Как можно разработать тесты без взаимодействия через графический интерфейс?

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

Контекст:

• Участники: Программисты/тестировщики.
• Продукт: API тестируемого продукта должен быть предоставлен.
• Цели: Поиск эффективного пути создания мощных автоматизированных тестов.

Стратегия тестирования:

• Создание тестов: Тесты пишутся на стандартном языке программированния, который позволяет использовать API-функции.
• Выполнение тестов: Понадобятся специальная среда для выполнения тестов.
• Оценка результатов тестов: Обычно, ожидаемые результаты определяются в момент создания тестов.

Атрибуты качества:

• Сопровождение и поддержка: Высокая. API-функции более стабильны нежели пользовательский интерфейс.
• Проверка: Средняя. Тесты пишутся на том же языке программирования и в той же среде, что и модульные/API-тесты, а это означает, что многие сотрудники смогут разобраться в коде.
• Целостность и зависимость: Средняя. Заметьте, что тестирование реального графического интерфейса пользователя невозможно полностью автоматизировать. Какие-то тесты все равно придется провести вручную.
• Возможность повторного использования: Низкая. 

Следующий шаг:
Можно воспользоваться другими техниками и расширить API тестами, например до использования ключевых слов-действий. Разработчики API тестов могут воспользоваться программированием на основании тестов. Как только API тесты созданы, то можно подумать надо использованием и добавлением проверок и диагностик. Если пользовательский интерфейс строится поверх API, то вы можете использовать технику "Ограниченного использования графического интерфейса"

Проблема: Как бизнес пользователи могут создавать тестовые сценарии без знания программирования?

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

Контекст:

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

Стратегия тестирования:

• Создание тестов: Тесты создаются в виде таблиц. Тесты высокого уровня могут быть спроектированы до того, как продукт будет доступен для тестирования.
• Выполнение тестов: механизм обработки ключевых слов выполняет тесты автоматически.
• Оценка: Обычно ожидаемые результаты определены как точки проверки в сценариях теста.

Атрибуты качества:

• Сопровождение и поддержка: Высокая. Тесты определяются на высоком уровне абстракции. Только библиотеки функционала навигации и прочих задач должны изменятся при внесении изменений в пользовательский интерфейс.
• Проверка: Высокая. Тесты легко проанализировать менеджерам и тем, кто не имеет отношения к программированию.
• Целостность и зависимость: Средняя. Механизм обработки ключевых слов и библиотеки функций являются ключевыми элементами. Если они работают хорошо, то возможность пересмотра способствует и надежности автоматизации.
• Возможность повторного использования: Низкая.

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

Проблема: Как специалисты без знания программирования могут сами создавать автоматизированные тесты?

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

Контекст:

• Участники: Эксперты предметной области с поддержкой специалистов автоматизаторв, которые реализуют данную архитектуру.
• Продукт: Пользовательский интерфейс уже определен ранее и находится в рабочем состоянии.
• Цели: тестирование продукта с точки зрения бизнес пользователя

Стратегия тестирования:
Создание тестов:

• Специалисты предметной области пошагово планируют тесты, оформляя их в таблицы.
• Тесты могут быть записаны и финализированны как только пользовательский интерфейс будет известен. (другими словами, как только все готово для проведения тестоварония).

Выполнение тестов:

• Интерпретатор и «диспетчер» выполняют тесты.

Оценка:

• Ожидаемые результаты определяет автор теста.

Атрибуты качества:

• Cопровождение и поддержка: Низкая. Табличный формат тестов позволяет автоматизировать поддержку и сопровождение некоторых видов изменений интерфейса пользователя.
• Проверка: Высокая.Тесты легко проанализировать и тестировщикам, и программистам, и менеджерам.
• Целостность и зависимость: Обработка ошибок и логгирование изолируются в выполняющую систему, которая может быть оптимизирована для улучшения надежности.
• Возможность повторного использования: Формат представление действий и данных может заменить потребность использование дополнительных инструментов работы с графическим интерфейсом..

Следующий шаг:
«Ключевые слова-действия» строятся на этом подходе.