что из говна и палок можно только шалаш построить, но жить в нем -сомнительное удовольствие

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

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

С процессами это работает ровно так же, нанимаешь синьора\лида, который знает, "как делать правильно".
В итоге получаешь набор типовых бест-практисес с его предыдущих мест работы, которые в лучшем случае наносят какую-то пользу проекту, в худшем - только добавляют геморроя.
(а если совсем повезет, то он прочитал книгу "Как тестируют в Гугл" и пойдет насаждать "правильные" процессы, потому что "а вот в гугле так!")

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

Если ты решаешь задачи бизнеса, то довольно быстро плохой дизайн кода (или процессов) начинает мешать эффективно решать эти задачи.
Начало мешать - взял нужный тебе кусок и поменял.
Если при этом ещё немножко включать голову и погружаться в бизнес-контекст - то узнаешь ты об этом до того, как оно выстрелит тебе в ногу.

Ну и небольшой постскриптум:
Большинство историй про "пришёл опытный товарищ, выкинул старое и начал писать заново" совсем не потому, что старое не работает.
Для этого есть три стандартные причины:
- Инженеры не хотят решать задачи бизнеса, а хотят писать красивенький код (на который всем насрать).
И по какой-то причине их сначала взяли на работу, а потом ещё и по рукам не дали при их порывах перфекционизма.
- Писать с нуля веселее и проще, чем копаться в легаси и заниматься рефакторингом.
- Комплекс боженьки и вот это "ну я-то точно знаю, как правильно".

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

Про переписывание и копание в легаси:

Из-за ограничений в ресурсах на переписывание и бессмысленности на настоящий момент тащили и тащим сторонний (вендорский) фреймворк для end-2-end тестирования, который представляет собой велосипед на квадратных колесах с костылями. Но в настоящее время он наносит больше пользы, чем вреда. Просто постепенно рефакторим кривой код, стараемся убирать костыли и не добавлять слишком много новых.

Писать свой с нуля? Можно, не вопрос. Только потратишь кучу времени и сил, а результат будет не очень хорошо предсказуем, к сожалению.

> ситуации когда выгоднее выкинуть и написать заново, чем перепиливать существующее - это исключения, которые можно по пальцам одной руки сосчитать

Сильно зависит от начального стека.
Если тесты писались на селениум иде или на постмане с пачкой башскриптов для управления тестовыми данными - где вы найдёте дураков, готовых ковыряться в этом? Если это какой-то кастомный кейворд дривен фреймворк и автор кейвордов был невменяемый, то его тоже есть смысл переписать, чтобы избавиться от ежеминутных вопросов в чяте “а какой степ делает такое-то действие?”
В обоих случаях уход автора из проекта означает полную утрату экспертизы. И оба стека как раз характерны для кейса, когда у недостаточно квалифицированного автотестера есть много полномочий и нет людей, с которыми можно проконсультироваться. Такие истории часто начинаются со слов “ну возьму для начала %codeless_framework_name%, не понимаю, почему его все хейтят 🤔”

>  где найдете

на рынке.

у нас был python 2.7, bash, Robot - я в этом ковырялся.
теперь python 3.8, bash, Robot, но суть не поменялась.

вопросы в чате ввиду специфики продукта постоянные, от вменяемости кейвордов зависят мало.

Такие истории случаются не тогда, когда нехватает экспертизы.
Они случаются тогда, когда перед тем, как начинать что-то делать, люди не отвечают (себе, команде, руководителю) на вопросы "Зачем?" и "Почему именно так?" и "А нам точно это нужно делать?".

И с таким же успехом может придти синьор, навернуть супер масштабируемый фреймворк автотестов на голанге, с бесшовным деплоем в кубернетис и возможностью запускаться в 850 потоков на шести разных фермах, генерацией тестовых данных на нейросетях, репортами в аллюр и отдельным сервисом для постинга багов в 18 возможных багтрекеров.
(Когда нужен набор смоук тестов, прогоняющихся в один поток, в одном единственном браузере)

Почему? Да потому что может.
Давно хотел с кубером поработать, голанг вообще тема.

И ковыряться в этом говне будет желающих не больше, чем в постмане с башскриптами.

Если код по солиду написан, а не как бог пошлёт, то почему бы и нет😀

Да потому что куча бесполезного кода написанного по солиду - это все ещё куча бесполезного кода.

Но в нём хотя бы поковыряться не страшно, в отличие от спагетти.

> куча бесполезного кода
Вы как-то меряете отношение количества строк кода к привнесенному business value или это просто по ощущениям?

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

> Вы как-то меряете отношение количества строк кода к привнесенному business value или это просто по ощущениям?

Скорее количество ресурсов, потраченных на создание и поддержку к привнесенному business value (и измеримым критериям успешности задачи).

С количеством строк кода оно, в целом, не особенно коррелирует.
А вот с количеством абстракций и функциональной логики - коррелирует.

> На мой взгляд - оверинжениринг ничем не лучше спагетти кода
Если полезного кода всего на сотню строк, то да. Если там тысячи строк, то даже в автотестах без солида всё будет очень плохо.

> Скорее количество ресурсов, потраченных на создание и поддержку к привнесенному business value
Вопрос немного в другом - это глобальная практика в аррайвале или твоя частная инициатива?

> люди не отвечают (себе, команде, руководителю) на вопросы "Зачем?" и "Почему именно так?" и "А нам точно это нужно делать?"
Иногда автотестерам просто хочется написать какую-нибудь yoba-фичу на моднейшем стеке, просто по фану. Ну и интервьюеры подливают масла в огонь, спрашивая “какое ваше самое крутое достижение?”. Если вы не даёте им такую возможность, а у них есть амбиции и скилл, то они уйдут 🤷‍♂️

Как вам? давно используете? плюсы минусы?

Никита- фаундер этой системы )))
Хорошая тулза, для описанных вами задач подходит :)
Есть бесплатная версия, пользуемся ей на некоторых проектах. Быстрый отклик поддержки, всегда приятно пообщаться. Помогают с проблемами. Вот про поддержку тест рейла такого не могу сказать. Система большая, баги висят в беклоге долго, хотя они реально раздражают кучу пользователей.

Хорошая шутка :) Это _Founder_ Qase

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

И с одной стороны, автотесты можно отлично писать на чистой функциональщине, не используя классы примерно совсем.
С другой стороны, когда добавление простого функционального теста превращается в жонглирование тридатью абстракциями, DTO и интерфесами - ни радости, ни перформанса такой солид не добавляет.

2) Я уже не работаю в аррайвале.
Но вообще, определять критерии успешностей фичей до того, как начинать что-то делать, и потом сверять с результатами - довольно глобальная практика, много где используется. :)


3) Тут всё не так однозначно, на самом деле.
Я писал уже по этому поводу пост.
Моё мнение по этому поводу - предельно простое.
Давать людям возможность делать что-то "по фану", экспериментировать с инструментами и прочее - хорошая и нужная практика.
С одним большим но.
Все заинтересованные лица должны понимать, что Вася пилит задачу на новом стэке, потому что фан.
Потому что фан Васи не должен мешать работать другим людям и не должен потом выливаться в геморрой для бизнеса.

Поэтому придти и сказать "Блин, у меня есть пара идей, как напилить кастомную репортилку для наших тестов, вот идея, вот что это даст" - хороший подход.
Предложить это как один из вариантов решения задачи (с аргументами) - хороший подход.  
Если к тебе приходят и говорят "Нам нужны репорты для тестов", а ты просто берешь и садишься писать кастомные репорты, потому что тебе фан - ты нехороший человек.

В первом случае я готов всячески помогать и придумать интересные задачи, что бы человеку было интересно.
Во втором случае я готов всячески помогать, что бы человек реализовывал свои амбиции (игнорируя интересы окружающих) где-нибудь ещё.

Простите, не панял на счёт шутки. ) Ищу ПО, которые будет заменять нынешнюю гугл таблицу.. в то же время, возможность синхронизации с ClickUP
https://qase.io/
https://help.qase.io/hc/en-us/articles/360006541018-Gettings-Started

У нас регресс до сих пор в гугл таблице.😁

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

Спасибо большое за положительный отзыв)