Кукумбер это просто спооб связать описание на естественном языке и кода. При чем здесь натыкивание?

Не нужен вам JS :)
Я перешел с Java+Selenide на JS+WebdriverIO. Уже почти полгода на JS и все еще, если бы была возможность, вернулся бы на Selenide
Он нативно понятен, стабилен, с джавой решены почти все проблемы, которые вы только можете натворить
Cucumber для новичка и не только — лишняя абстракция и дополнительный стопор на старте, можно и без него обойтись, написать тестов 10-15, освоиться, если поймете, что очень нужны эти when-then — прикрутите

ну я сам писал на Пайтоне 2 года, последние 1.5 на JS, есть с чем сравнивать, появился Playwright который расширяет возможности тестирования

Постарайтесь определиться что вы хотите протестировать- процесс создание заявки, или каждую из страниц процесса в изоляции?

Если первое, то очевидно, что у вас один тест - "тест процесса создания заявки". Вы можете разбить его на сколько угодно методов для лучшей читаемости кода, но тест должен быть один. Один passed или failed.

Можно еще в голове такой анализ провести - могу ли я распараллелить части теста, чтобы они запускались на разных компах. Чтобы страница 1 заявки на одном компе, и параллельно страница 3 на другом. А потом страница 2 на третьем. Если так не работает -  то у вас однозначно один тест.

Один юзер на заявку не прокатит. Заявку менеджер для пользователя создает.

зачем инженеру связывать описание на псевдо-естественном языке и коде? А вот мануальщику, которого привлекли к автоматизации - возможность создавать тесты используя простые и понятные лексические конструкции как раз и пригодится.

аа, ну в вашем случае 4 юзера значит

Я вот писал на Java, С# и плюсах, и остальное языками не считаю )))
Это все вкусовщина.
Важно для каких задач что использовать

Мануальщику нужен огурец?
Он с ума сводит тех, кто уже некоторое время автотесты пишет)
Для меня кукумбер это влажная мечта об аналитиках, которые будут читать автотесты и указывать на неточности
В реальности еще не встречал БА, которые лезли бы смотреть тесты

Вы сами его использовали в работе?
Никогда мануальщик без программирования с кукумбером не сделает.

Я думал об этом. Но в классах  описания страниц вроде как  Assert вызывать плохой практикой считается. А нам нужно еще паралельно с созданием заявки тестровать всякие поля .

Вот прям жирный плюс!

если современный веб с реактом и так далее то JS только), если условный энтепрайз то понятно что и джава пойдет, но уже видно что тренд идет в сторону JS и вакансий там с каждым годом все больше

В целом про один ассерт, это конечно ерунда. Зато в классическом тесте ААА, arrange, act, assert - у юнит и
большинства интеграционных тестов должен быть один единственный "act". А у e2e как раз вполне нормально иметь в одном тесте многочисленные act/assert, act/assert.

Вы путает пресное с зеленым.
Я не говорю что JS не нужная фигня.
Человек занимается тестированием, нафига ему JS?

никому не нужен обычно. Построить процесс, чтобы BDD давало свои плоды (работа над тесткейсами аналитиков, заказчиков и даже разрабов) - чертовски сложно, он очень хрупок, и в большинстве случаев ресурсы, потраченные на его внедрение - особо не окупятся

Я не знаю что такое классы описания страниц, но возможно вам стоит пересмотреть свои взгляды на то, что является плохой практикой, а что нет :-)

Нужно тестировать поля? Тестируйте, кто ж вам запретит.

Page object селениум же

Класс = название страницы , всяческие доп методы, например найди в таблице нужное значение и кликни по нему

В page object ассерты не типичны, но бывают кейсы где это разумно.

Но никто же не заставляет делать ассерты в ПО. Вызывайте методы ПО для нахождения объектов и ассертите в тесте.