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

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

Контекст:

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

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

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

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

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

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

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

Решение: Пишите тесты до создания кода. Они будут способствовать созданию правильного дизайна и мотивировать в процессе кодирования.

Контекст:

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

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

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

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

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

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