Всем, кому интересна тема автоматизированного тестирования UI, рекомендую почитать мою статью на Хабре: «Автоматизируем тесты UI с помощью Kotlin (Playwright + JUnit5)». В ней я изложил своё видение архитектуры и показал, как Kotlin отлично справляется с этой задачей. Вообще, по опыту я заметил, что архитектуре проекта или фреймворка для автоматизированного тестирования уделяется крайне мало внимания. В результате получается проект, напичканный хаотично разбросанными модулями и функциями, которые к тому же дублируются от теста к тесту. Зачастую это связано с тем, что автотесты не считаются критически важным функционалом, в отличие от основного продукта, и не всегда пишутся разработчиками. А в эпоху ИИ ситуация усугубляется в тысячу раз. В итоге такой проект становится практически невозможно поддерживать и расширять, поскольку нарушаются базовые принципы разработки. Именно поэтому я хочу ещё раз подчеркнуть, что вектор развития ручного тестировщика в автоматизаторы является одним из самых популярных заблуждений. Ручной тестировщик, безусловно, может научиться простым действиям по поддержке или созданию новых тестов по шаблону. Но чтобы это действительно получилось, необходима стройная архитектура, а создать её можно, только обладая фундаментальными знаниями в области разработки и имея практический опыт. Это не значит, что ручным тестировщикам запрещено интересоваться автотестами. Однако подавляющему большинству не стоит бросаться в это направление, просто поддаваясь модным трендам. Ведь в области обеспечения качества есть много других перспективных ниш.