Мы с вами делаем хорошее дело - учимся и равиваем автоматизацию. Нет предела совершенству, и поэтому мы идем все дальше и дальше. На носу 5-я встреча автоматизаторов, которая пройдет, как и прошлая встреча, в G-Club компании GlobalLogic. Предыдущая встреча прошла действительно хорошо, атмосфера была дружественная, что особенно способствовало активному общению. Мягкие и удобные диваны и просторное помещение G-Club создают определенный домашний уют, поэтому следующую встречу снова проведем в G-Club.

Понятно, что в первую очередь, автоматизация – это непостредственное кодирование, написанние скриптов и т.д. Но для того, чтобы действительно достичь значительных результатов в автоматизации, ее необходимо хорошо спланировать и тем более спроектировать. Проектирование - дело нелегкое, и приходит с опытом, поэтому  очень ждем доклад на тему «Шаблоны автоматизации на практике и создание архитектуры автоматизации», где Коля Колесник, автор доклада, расскажет нам о различных подходах в проектировании автоматизации, которые он активно применял на практике. Конечно же, встреча одним докладом мы не ограничивается. Как планировалось ранее, встречи будут больше ориентированы на групповую работу. Потому ждем вас и ваших коллег на 5-й встрече автоматизаторов.

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

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

Контекст:

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

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

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

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

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

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

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

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

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

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

Продукт:

• Любой.

Цель:

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

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

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

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

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

Оценка:

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

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

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

Проверка:

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

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

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

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

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

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

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

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

Контекст:

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

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

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

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

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

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

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

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

Контекст:

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

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

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

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

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

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

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

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

Контекст:

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

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

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

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

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

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