Больше половины части успеха любого проекта по процессу автоматизации тестирования основывается на использовании популярных паттернов, которые, как неоднократно было доказано на практике, помогают максимально поднять уровень надежности и работоспособности тестовых сценариев автоматизации тестирования.
Паттерн проектирования автоматизации тестирования ПО — это крайне легкое решение, ежедневно демонстрирующее свою эффективность на разноплановых проектах по разработке и тестированию веб ПО.
Такие шаблоны, по праву, считаются наиболее полезными практиками для проектов, которые выстроены на основе объектно-ориентированного программирования.Роль паттернов в процессе автоматизации тестирования
Необходимо принять как должное тот факт, что программное обеспечение, со временем, будет неизбежно меняться.
И если вы будете понимать, что такие изменения обязательно наступят, с самого начала будете использовать исключительно эффективные практики и паттерны тестирования ПО. С их помощью, все ваши автотесты будут простыми в эксплуатации и легкими в технической поддержке.
Далее будут описаны наиболее распространенные паттерны проектирования процесса автоматизированного тестирования, которые находятся на вооружении многих популярных команд. Они помогают создавать надежные тесты автоматизированной проверки и улучшать общую логику тестирования на проектах.
Page Object
Одна из самых популярных стратегий, которая применяется при автоматизации тестирования, направлена на моделирование поведения создаваемого программного обеспечения.
Для этой цели обычно используются простые page objects, способные моделировать те части ПО, которые переходят от процесса создания к тестам.
Пример Page Object
К примеру, проверяющий может создавать page objects для страницы входа в систему или домашней страницы. Подобный подход корректно отображает все важные правила единой ответственности.
В случае, когда что-то редактируется, например ID объекта, необходимо сменить одно место в программном коде, а все тесты на основе page object, автоматически получат данные изменения без выполнения лишних технических манипуляций со стороны проверяющего.
В возможности Page Objects также входит функции скрытия технических деталей HTML/CSS за методами с самыми простыми и доступными для понимания обозначениями.
Внимательное отношение к обозначению используемых методов имеет дополнительный неоспоримый плюс, так как помогает тестировщику разрабатывать приятно читаемый API, с которым легко разберется даже самый неопытный программист.
Данный паттерн дополнительно придерживается востребованной ныне практики создания ПО — Don’t Repeat yourself (Не повторяйте себя).
Тезисно, принцип Don’t Repeat yourself обозначает следующее: за каждую логическую часть ПО должен нести ответственность только одна часть программного кода и не более.
Возникающее дублирование кода существенным образом затрудняет процесс его технической поддержки: чем меньше кода создается, тем лучше, так как больше кода на поддержке говорит о том, что в фреймворк для тестов может попасть баг.
Даже один такой шаблон проектирования ПО может легко решить базовую проблему некоторых тестировщиков, но это не ключ ко всем решениям.Тем не менее, именно он позволяет сделать большой шаг по направлению к стабильности автоматизированных тестов.
Screenplay
Вышеописанный Page Objects — это замечательный шаг для начала создания поддерживаемых тестов, но если вести себя «неаккуратно», со временем, все автоматизированные проверки могут выйти из-под контроля.
Популярный паттерн Screenplay являет собой определенное применение принципов программного проектирования SOLID для внедрения целей автоматизированного приемочного тестирования. То есть, по факту, это то, что было итогом безжалостного рефакторинга Page Objects с выполнением принципов проектирования SOLID.
Данный паттерн «берет» page objects и «дробит» их на крохотные элементы.
Некоторые QA-инженеры судачат о том, что это привело к тому, что их тесты стали более «ремонтопригодными» и надежными для многократного применения на разных проектах.
Дополнительным преимуществом этого паттерна есть то, что он может систематизировать тестовые сценарии в более удобные для чтения блоки.Принято считать, что начало использования этого паттерна положено в 2017 году, когда Джон Смарт (создатель популярного фреймворка автоматизации тестирования — Serenity) предложил прибегнуть к использованию сценариев, в которых термины тестовых сценариев не взаимодействуют с системой.
Пример Screenplay
При глубоком анализе Screenplay может возникнуть ощущение, что его использование в разы сложнее чем Page Objects, но такой подход существенно экономит командам время и бюджет.
Presenter first
Presenter first — это, своего рода, вариация Model-View-Controller (MVC) для организации программного кода и создания ПО, которое придерживается цели полностью проверенного программного ПО с применением test-driven подхода к созданию (TDD).
Пример Presenter First
Чтобы понять особенность паттерна Presenter first, можно воспользоваться следующей моделью: если вы изобразите паттерн MVC в форме блоков и графических стрелок, то сможете увидеть, что представление, которое, по факту, является тестируемым графическим интерфейсом, имеет корректно определенные связи с моделью и непосредственно с контроллером.
При желании, QA-инженер или программист может самостоятельно настроить тестируемую модель и контроллер таким образом, чтобы система демонстрировала все типы странного поведения программного обеспечения, к примеру, выход системы из технического строя.Выводы
Все описанные выше паттерны относятся к шаблонам проектирования, но стоит помнить, что существует еще очень много других паттернов (до 86), которые могут решать проблемы, связанные не только с кодом программного обеспечения.
Если вы опытный автоматизатор, то данные паттерны вам пригодятся не только при создании первоначальных тестовых структур, а и в процессе многократного тестирования сложных программных архитектур.
Оставить комментарий