Читаю одного игромана с плойкой, ему очень зашло, вроде "чего ждёте?" писал.

Про death stranding говорят, что если лицезрение, как фокус гемплея, не доставляет, лучше не играть

Кто то взял jedi: fallen order?

Презенташка для моего доклада на COMAQA Minsk 2019 . За каждым пунктом говорящим какой инструмент "можно" сделать — это, собственно, было мной (или при моём участии) сделано.

Хотя включено не только лишь всё, но большинство.

почему у тебя в sikuli примере не видно пэйдж обджекта?) там так можно?

или там тупо примитивные сценарии с копипастой надо пилить?

(внутренний поручик) "Иди в OOP".  :)

ну я себе приобрел еще н прошлой неделе, думал тут кто-то тоже играет 🙂

Чего хочешь, того и пилишь. Часто были мелкие сценарии.  Обезьянье решение, о котором шла речь, вообще прекрасно обходится без PO.

ну я имею ввиду есть ли возможность пилить методы какие-то и вызывать их потом в тесте и все такое

нее, пока денег нет) но вот смотрю прохождение и думаю

(по ассоциации) известный в кругах Солнцев недавно кидал против PO и ряда других популярных штуковин:

https://www.youtube.com/watch?v=U6z2dK7MwmI

Ну вот по той же причине не беру.
Ну точнее как. Все ещё хуже, деньги есть, но есть, на что ещё потратить) и метаешься.
Критики от этого дарк соулс в далёкой далёкой галактике в восторге

ну я пока только начал смотреть 🙂 мне все таки пока есть во что играть - Death Stranding )

да он просто свои локаторы в методах пилит и как-бы суть-то все равн опэйдж обджект, только без элементов, а с дейтвиями над этими элементами

Посылочки...)
Я ещё скидки на аутер ворлдс  жду. Играл?

нее, но слышал и видел как играют )

По датировке, конечно, совершенно не новость, но какой феерический пи-пи-пи-пи-пи
(статья о том как в РФ госорганам запрещают использовать "не исключительное" ПО)

https://www.gazeta.ru/tech/2019/09/05_a_12629911.shtml

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

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

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

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

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

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

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

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

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


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


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

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

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