оставил вчера вечером, решения так и не подъехало

Всем привет
У кого-нибудь еще есть проблемы с импортом .p12 сертификатов в Charles 4.5.4 (macOS Mojave)?

Отличный доклад!
Совершенно замечательный.

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

Андрей достаточно подробно описал настоящие, скрытые, проблемы процессов и некоторые методы их решения.

С другой стороны, некоторые он обошёл стороной, когда, к примеру, не поделился опытом или рекомендациями, как внедрить бдд правильно, раз это хорошая идея, а только порекомендовал не внедрять его неправильно и "для галочки". Хотя это конечно тоже экономит ресурсы, вместо затрат их впустую на бурную деятельность.

По поводу паттерна Page Object и его реализации согласен, но в том числе возникает вопрос, а нужен ли он как концепция, именно в отношении страницы, а не, скажем, целиком веб-приложения.
Видел реализации этого паттерна, в которых совершенно одинаковая кнопка "далее" и её аналоги типа "войти" для каждой страницы сайта в объекте этой страницы описывались заново. Само название слегка подталкивает людей к таким решениям, тоже по сути создавая проблему процесса.

Есть иной вариант работы со страницей, и в нём BDD подход полезен - список локаторов объявляется единый для всего сайта/веб-приложения, поддерживается в одном месте и доступен всем тестам. Таким образом получаем заявленную простоту поддержки "меняем локатор один раз" и уменьшаем дублирование при этом.
Ограничение - осмысленное, понятное участникам процесса название элементов, чтобы тесты были не write and forget, а читабельные, причём не только автором. Построение такого процесса тестирования  ощутимо затратно, и не всегда оправдано, например, если проект предстоит небольшой.

Дальше в рамках хорошо работающего  bdd подхода накапливается набор операций, если говорить термином из доклада, "поведений", которые можно выполнить где угодно и реализация которых не зависит от местонахождения. Не требуется инициализация объектов страниц, если мы не работает с объектами, мы просто в сценарии знаем где мы находимся, читая описание сценария и выполняем действия, которые хотим. В таком случае, тесты накапливают информацию о продукте, а не скрывают её.

Но подход требует реального взаимодействия команды из разных ролей, а не сидящих порознь отделов разработки/аналитики/тестирования/бизнеса, о чём как раз говорил Андрей.

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


По других поводу технических моментов Андрей очень хорошо рассказал, имел удовольствие пользоваться селенидом, среди java инструментов он показался мне наилучшим вариантом для работы без бойлерплейта.


Но у меня всегда есть вопрос: зачем на проекте автотестов выбирать java?
Это же "энтерпрайзный" язык, полный этого самого бойлерплейта на все случаи жизни, для тестовых сценариев, которые по самой своей сути должны быть  конечны и детерминированы.

Банальный python или любой другой более "легковесный" язык, на мой взгляд, для этих целей подходит куда лучше.

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

Значит те кто пришёл послушать, получили информацию, как меньше в такие ловушки попасть, ведь если поискать какое-нибудь "java testng", в половине статей будет "начните с написания пейджобджекта, все пацаны так делают", а разработчику-то какая разница, раз пацаны делают, так и я сделаю

Некоторые проблемы можно решить технически, некоторые нет