За прошедшие несколько лет инструмент автоматизации тестов для веб-приложений Selenium приобрел фантастическую популярность.
Владение этим инструментом стало одним из обязательных умений для тестировщика-автоматизатора, достаточно посмотреть динамику вакансий, чтобы убедиться в этом.
Если вы хотите считаться профессионалом в области автоматизации тестирования, строчка "я знаю Selenium" обязательно должна присутствовать в вашем резюме.
Простые тесты можно создавать при помощи рекордеров Selenium IDE или Selenium Builder. Но при увеличении объёма и сложности тестов этот подход теряет свою эффективность и привлекательность. Профессионалы пишут тесты на языках программирования.
Основным "официальным" языком программирования для Selenium является Java, потому что большая часть самого Selenium реализована на этом языке и все новые возможности сначала реализуются на Java, а потом переносятся в реализации на других языках – .Net (C#), Ruby, Python.
Этот курс предназначен для тех, кто хочет освоить программный интерфейс Selenium 2.0 и научиться разрабатывать автотесты для веб-приложений на языке программирования Java.
Если до этого Вы не занимались автоматизацией и не знакомы с Selenium, то лучше начать с курса Selenium 2.0: стартовый уровень.
Также существует аналогичные тренинги на языке Python и на C#.
После прохождения тренинга учащийся будет уметь разрабатывать автоматизированные тесты для веб-приложений на языке программирования Java с использованием инструмента Selenium 2.0, в частности:
владеть базовым набором команд Selenium 2.0, эмулирующих действия пользователя (ввод текста, клики мышью),
владеть расширенным набором команд Selenium 2.0, эмулирующих действия пользователя (клавиатурные сочетания, перетаскивание элементов мышью и другие),
владеть техниками поиска (идентификации) элементов в окне браузера,
уметь обеспечивать стабильность и скорость выполнения тестов за счёт правильного использования ожиданий,
уметь выполнять проверки фактических данных, полученных из браузера, на соответствие ожидаемым значениям,
владеть основными шаблонами проектирования тестов, в том числе шаблоном PageObject,
уметь выстраивать архитектуру тестов таким образом, чтобы тесты можно было легко модифицировать и добавлять новые (при небольшом количестве тестов),
уметь организовывать инфраструктуру для запуска тестов на сервере непрерывной интеграции.
Модель проектного треугольника очень быстро дала плоды на благодатной почве русской души, которая любит всё делать с размахом. Хотите больше фич? Надо увеличивать сроки! Хотите более качественный продукт? Давайте расширим команду!
Первое следствие такого подхода становится заметным сразу: мы всё реже выпускаем новые версии, а бюджет непрерывно растёт. Но постепенно становится заметным и менее ожидаемый результат: продукт качественнее не становится, а за единицу времени мы добавляем всё меньше новых фич.
Раздутая команда становится неуправляемой, расширяться дальше нет желания и возможностей. Как решать проблему?
В своём докладе я расскажу о четвёртом, редко учитываемом факторе, который влияет на успешность проектов - процессе разработки. За счёт оптимизации процессов мы почти всегда можем достигнуть улучшений в своей работе, не затрачивая дополнительных ресурсов.
Распространённые источники утечек ресурсов, времени и качества.
Способы анализа эффективности проектных процессов (ТОС, Lean).
Поиск узких горлышек (bottlenecks).
Расчёт ROI при внедрении внутрипроектных улучшений.
“Бесплатные” решения по повышению качества.
Человеческий фактор и борьба с консерватизмом при внедрении улучшений.
Доклад будет полезен руководителям проектов, руководителям продуктов, руководителям отделов разработки и руководителям отделов тестирования, а также всем сочувствующим.
Я периодически сталкиваюсь с мнением, что после выполнения тестов нужно "почистить за собой", то есть удалить все артефакты, которые были созданы в процессе тестирования. При этом сам я придерживаюсь противоположной точки зрения.
Особенно часто это мнение встречается в контексте автотестирования, но и при ручном тестировании вопрос тоже актуален.
Так удалять или не удалять? И если удалять, то когда -- после каждого теста или в самом конце?
На курсе про Селениум 2 учили шаблон PageObject. Я сейчас решила переделать наш старый "процедуральный" проект автомации под этот паттерн.
В новом проекте сразу возник вопрос:
1) могут ли Helpers вызывать функции друг друга? На курсе все примеры были с изолированными друг от друга хелперами, только класс самого теста имел доступ ко всем хелперам сразу (ну, и ApplicationManager).
2) если могут, то как красиво сделать это взаимодействие? Сохранить в DriverBasedHelper поле с ApplicationManager и через него "общаться"?