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

Технические аспекты

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

В основном, автоматизированный тест состоит из двух частей: тестовые данные и код, который управляет тестируемым приложением. Тестовые данные обычно поддерживаются в отдельной формате или даже в отдельном репозитории. Фактический код автоматизации может строиться через уже существующие фреймворки, такие как FitNesse или RobotFramework или же могут использоваться фреймворки, которые создаются непосредственно в компании для нужд проектов.

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

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

Контекст:

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

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

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

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

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

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

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

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

Контекст:
Участники:

• Автоматизаторы разрабатывают скрипты.
• Любой (в том числе, бизнес пользователь) может создать входные данные вписывая их в таблицы.

Продукт:

• Любой.

Цель:

• Любая функциональность, которая должна быть протестирована в различный вариациях различающаяся только входными данными или же параметрами

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

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

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

• Тесты выполняются по сценариям в соответствии с входными данными.

Оценка:

• Ожидаемые результаты практически всегда указываются вместе с входными данными.

Атрибуты качества:
Cопровождение и поддержка:

• Высокое.
• Сценарии тестирования могут быть адаптированы к изменениям интерфейса без внесения изменений в данные.

Проверка:

• Средняя/высокая.
• Данные для тестов можно легко проанализировать и проверить.
• Тестовые сценарии могут быть быть легко проверены на основных данных.

Целостность и зависимость: 

• Средняя.
• Читаемость и возможность проверки данных поможет в сохранание тестов в целостном состоянии.
• Однако, тестовые сценарии также должны быть проверенны, для уверенности, что они работают так, как это ожидается.
• Такая архитектура может быть сложной из-за количества опций и ветвлений в коде, а также может увеличить вероятность появления  ошибок в входных данных внесенными пользователями.

Возможность повторного использования:

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

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

Проблема: Как можно разработать автоматизацию, когда не хватает времени?

Решение: Делайте то, что можете. Сфокусируйтесь на тех тестах, которые в данный момент наиболее полезны, smoke тесты, конфигурационные тесты. Тем временем, изучите возможности инструментов автоматизации и их возможности.

Контекст:

• Сотрудники: Тестировщики/Программисты.
• Продукт: Любой.
• Цели: Автоматизировать те тесты, которые быстро окупят затраченное на них время.

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

• Создание тестов: Код пишется вручную, или используется Record&Playback, если возможно. Ознакомьтесь, какими интерфейсами можно воспользоваться.
• Выполнение тестов: Это цель.
• Оценка результатов тестов: Для выходных данных может потребоваться дополнительная «ручная» проверка .

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

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

Следующий шаг.
Используйте то, что изучили о наилучших путях, куда направить дальнейшие усилия.

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

Решение: Добавьте проверки (assert) и диагностики в код продукта. Проверки указывают на неправильное функционирование системы, т.е. когда это случается - это дефект. Диагностики указывают на промежуточные значения, которые подлежат последующему анализу чтобы определить это дефект или нет.

Контекст:

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

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

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

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

• Сопровождение и поддержка: Средняя/Высокая. Проверки и диагностки нужно изменять каждый раз, когда изменяется основной тестируемый код.
• Возможность пересмотра: Средняя. Расположенные в коде проверки и диагностки могут быть легко поняты другими разработчиками. Диагностики позволяют собрать информацию о покрытии.
• Надежность: целостность и достоверность: Средняя. Все зависит от того, насколько качественно в коде применены проверки и диагностики.
• Возможность повторного использования: Высокая. Любой тест будет автоматически пройдет через проверки.

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

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

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

Контекст:

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

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

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

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

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

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

Проблема: Как можно определить качество большого количества тестов?

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

Контекст:

• Участники: Любые.
• Продукт: Продукт не может быть первым в своем роде, так как никакого оракула еще не будет существовать.
• Цели: Тщательная проверка достоверности и надежности тестов.

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

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

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

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

Следующий шаг.
Скрипты на основе данных.

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

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

Контекст:

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

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

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

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

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

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