Чем данный формат обучения отличается от стандартных тренингов и семинаров?

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

Но на тренингах обычно не хватает времени для практики, и условия для практики слишком искусственные.

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

Шаблоны автоматизации (краткое описание)

Простой шаблон

1. Проблема: Как можно создать много тестов без написания большого количества программного кода?
2. Решение: Используйте обобщенную среду управления сценариями (фреймворк), расширяя ее под нужды вашего проекта.
3. Шаблон: Фреймворк

1. Проблема: Как можно разместить тестовые данные в таблицы, не прописывая их жестко в коде тестовых сценариев?
2. Решение: Напишите код, который позволит тестовым скриптам считывать тестовые параметры напрямую из таблиц.
3. Шаблон: Скрипты на основе данных (data-driven).

1. Проблема: Как специалисты без знания программирования могут сами создавать автоматизированные тесты?
2. Решение: Используйте таблицы где будут определены свойства окон, элементы на окнах, действий и данные для тестов.
3. Шаблон: Таблицы на основе пользовательского интерфейса.

1. Проблема: Как бизнес пользователи могут создавать тестовые сценарии без знания программирования?
2. Решение: Определите ключевые слова-действия, которые будут являться действиями пользователя с системой, с помощью которых можно будет создать нужный сценарий.
3. Шаблон: Ключевые слова-действия (action keywords).

1. Проблема: Как можно быть уверенным что разрабатываемый код работает правильно, при этом создавая регрессионные тесты для последующего рефакторинга кода?
2. Решение: Пишите тесты до создания кода. Они будут способствовать созданию правильного дизайна и мотивировать в процессе кодирования.
3. Шаблон: Программирование на основе тестов (test-first programming).

1. Проблема: Как можно разработать тесты без взаимодействия через графический интерфейс?
2. Решение: Используйте программные интерфейсы, которые позволяют получить прямой доступ к той функциональности, что надо протестировать.
3. Шаблон: API-тесты.

1. Проблема: Как можно протестировать графический интерфейс без непосредственного вызова элементов управления?
2. Решение: Разрабатывайте графический интерфейс пользователя как отдельный слой презентационного кода исходя из бизнес-логики. Используйте модульные- или API- тесты для тестирования бизнес-логики.
3. Шаблон: Ограниченное использование графического интерфейса.

1. Проблема: Как можно определить качество большого количества тестов?
2. Решение: Воспользуйтесь оракулом. Это программа, которая вычисляет правильный ожидаемый результат.
3. Шаблон: Использование оракула.

1. Проблема: Пользователи могут совершить действия в такой последовательности, которой вы даже не могли себе представить при дизайне тестов. Как же протестировать их все?
2. Решение: Спроектируйте автоматизированную обезьянку. Это модель состояния тестируемой системы на основе которой можно генерировать большое количество тестовых последовательностей.
3. Шаблон: Автоматизированная обезьянка

1. Проблема: Как можно найти ошибки, которые могут возникнуть только со временем? Из-за этого может возникнуть некорректные состояния системы или поломаться/создаться неправильные данные, но это будет выявлено спустя некоторого времени последующего тестирования системы.
2. Решение: Добавьте проверки (assert) и диагностики в код продукта. Проверки указывают на неправильное функционирование системы, т.е. когда это случается - это дефект. Диагностики указывают на промежуточные значения, которые подлежат последующему анализу чтобы определить это дефект или нет.
3. Шаблон: Проверки и Диагностики (Assertions and Diagnostics)

1. Проблема: Как можно разработать автоматизацию, когда не хватает времени?
2. Решение: Делайте то, что можете. Сфокусируйтесь на тех тестах, которые в данный момент наиболее полезны, smoke тесты, конфигурационные тесты. Тем временеи, изучите возможности инструмента автоматизации и его возможности.
3. Шаблон: Быстро и неаккуратно (Quick and Dirty)

Хотите создать в компании базу курсов для обучения тестированию ПО? Составить индивидуальный план занятий для каждого сотрудника? Узнать про области тестирования, с которыми пока не приходилось работать?

Мы предлагаем записи онлайн-семинаров, прочитанных в течении этого учебного года Алексеем Баранцевым: