Стартапы бывают разные. Т если с человеком на берегу не обсудили эти моменты, то он вообще не обязан был на них закладываться. То что потом возникло несовпадение ожиданий - не так это ожидаемо, что непроговоренные вопросы - вылазят боком. Человеку не место в компании, ну так и компании не место в его жизни. Так бывает, как стартапы выживают 1 из сотни, так и людив них не всегда приживаются. Когда-то сотрудники промахтваются с выбором, а часто и не могут им. Объяснить на собеседовании чего ожидать, в надежде, что все видят стартап одинаково и без обсуждениях.
Каждой компании свои процессы. Я работал в старикан, где я был 5м инженером. Потом компания выросла до 50+ человек. И я могу 100% сказать, что невозможно работать с однимими процессами на 5 человек и на 20 человек. Там где 5 всегда можно собрать вместе и обсудить, 20 - не соберется почти никогда. Кто-то в отпуске, кто-то болеет у кого-то семейные проблемы, и т.д. да и руководитель уже не запомнит в голове так легко информацию от всех. Поэтому и существуют 5 уровней зрелости компаний от гаража до махрового Enterprise. И задача руководства стартера, планировать рост и решать все проблемы вовремя по мере роста. Не бежать впереди паровоза вводя политики и тренинги на 3 сотрудника, но и не тормозить пытаясь вести отчеты и планировать в экселях, когда на проекте уже 30 человек. И по прежнему зажимая ресурсы на DevOps и поддержку рабочих инструментов с лицензиями.
Существенная доля это сколько? Мне попадались, только что-то до 1,5% доли. И то с кучей условий, которые делают их получение скорее теоретическим. Кроме того, продукт продуктом. Но не меньшую роль играет установка процессов в самой компании. И тут начинаются все нюансы. Если разработчик вообще 1 он же СТО, он же архитектор. То нет смысла вкладываться даже в git сервер. Можно локальный поднять с бекапами. Если есть более-менее команда, хотя бы человек на 5 то тут уже нужен сервер, Task Manаger, писать вменяемый комментарии на коммиты. Если люди еще и в разных тайм-зонах с процентом пересечения не более 40%, то тут уже нужно культуру документации прививать, иначе они будут сидеть по пол-дня ожидая других, чтобы узнать что вчера такого случилось, что теперь перестало работать. Или сидеть разбирать логи теже пол дня, чтобы понять. Вместо того чтобы прочитать за 15 минут. В случае одной тайм зоны - еще можно позвонить. И вот эти все организационные заморочки и съедают львиную долю времени, вместо того чтобы работать над продуктом. Часто видел прыжки с одного Task Manager на другой без видимого профита, просто новому сотруднику так привычней, а других нужно всех переучивать. Или вообще на это забивают. Тогда нет нормальной коммуникации и все сотрудники в постоянном стресе. А потом удивляются, что они такие токсичные? Так их просто сделали такими, поставив в условия, где только так можно выжить не поехав кукухой. Дайте разработчикам и тестировщикам более-менее удобные и стабильные инструменты и понимание размера команды. Тогда они и не будут такими токсичными. Переделывать продукт и его архитектуру - это нормально для стартапа. А вот когда сама компания перестраивается по 20 раз на месяц - это уже диагноз нездоровой компании.
Долгосрочное планирование - нужно любой компании. Если ее прогнозируемый срок жизни больше года. Если, вы признаете что компания просуществует год то закроется если не будет продана, то какого отношения можно ожидать от сотрудников? Они в условиях, что чтобы ни случилось, через год искать новую компанию, а может и раньше. Ну и кроме того, они то работают за зарплату, а не за потенциальные 10%+ от продажи компании. Потому стартапы и платят выше рынка, потому что для сотрудников - это повышенные риски. Энтерпрайз компании могут просуществовать гораздо дольше, поэтому риск остаться без работы меньше. Ну а если план делать мануально - надо понимать, что тут нужно много низкоквалифицированных сотрудников с минимальной ставкой. А не начинать с 1-2 высококвалифицированных. План выглядеть будет примерно так: 1 год. Берем студентов пилим как попало, определяемся с нишей. Не тратится на тулы и бест практис. Репортер так же не окупиться ввиду низкой стоимости сотрудников. Получаем, PoC и строим дальнейший роадмап продукта. 2 год. Берем Архитектора и переделываем весь процесс, еще пол года уйдет на стафинг, потому что стартап, не все захотят пойти. Определяем тулы, строим CI/CD и репортер с мониторингом. Начинаем переписывать продукт. 3 год. Приводим в порядок продукт по процесам.
Очень даже просто. Вопрос приоритетов. Вот владелец стартапа - качество кода - да ну его. Нам на этапе стартапа важнее скорость. Сидит 1 CTO, и понимает, что в перспективе людей больше не будет. Если не построить всю обвязку с контейнерами и CI/CD, то ты просто повесишься. Потому что это ведёт к давай быстрей, и отсутствие нормальных инструментов и автоматизации загоняет тебя в порочный круг мануальной рутины из которого не вырваться. Мануальные тесты, мануальный репортинг, сбор метрик и т.д. бизнес не считает это за работу. Это некая магия которую можно сделать за секунды. А на практике ты просто зависает в море цифр и либо начинаешь клепать ошибки, либо тратишь на это все свое время. Ну попробуйте объяснить это бизнесу, я пытался раз 10. Ни разу не удалось. А все почему, когда людям говоришь про PMBoK, на тебя смотрят с широко открытыми глазами. Про тактику и стратегию, на тебя смотрят с широко открытыми глазами. Про долгосрочное планирование, на тебя смотрят ... Ну вы поняли. Люди приводят доводы, проблема в том, что даже чтобы их услышать, не говоря о том чтобы понять - нужно обладать хотя бы соизмеримыми знаниями с собеседником. Если между вами пропасть, вы не договоритесь, сколько бы вы на одном языке не разговаривали. Это как вы обсуждаете материаловедение и FEA, а собеседник не то что Теор Мех с Высшей Математикой не учил, так он ещё и школьный курс алгебры и геометрии прошёл мимо. Ну и как вам договориться?
Есть какие-то наброски на эту тему? Я как раз пытаюсь настроить в контейнерах nextcloud + keycloak через traefik. С аутентификацией через X509 сертификаты. Но застрял с настройкой user_oidc app. Никак не могу понять как ему можно поставить разные URI? 1 нужен для браузеров с аутентификацией, а другой для самого NextCloud у которого нет сертификата.
А если нужного решения нет в публичных репозиториях? Например, разработать что-то новое иди технологит пропртетарные и их днем с огнем не сыщешь в открытом доступе.
Ну если допускать, что история имеет место быть, то в целом это логично. Получаешь паспорт и дальше он тебе открывает возможность находиться и работать в других странах. Требования есть до получения паспорта на пребывание в стране. А гражданам с паспортом уже таких привязок нет. Так что можно ехать дальше по странам Британского содружества или где там безвиз у Канадцев.
Ну я вижу тут просто культурный шок. Все страны очень разные. И я потратил очень много сил на изучение и выбор. Хотя в моем случае это во многом сила обстоятельств. В Канаде есть свои особенности в поиске работы. Если нет контракта от компании, я бы даже не совался. Да и с контрактом, могут быть нюансы. Одна из основных специфик - если ты не работал в Канаде, на канадскую компанию, неважно, что у тебя там в резюме, шансы стремятся к нулю. Если есть опыт хотя бы года 3, то все меняется кардинально. Ситуация с полицией разная везде. Взвесив все за и против, я с семьёй, остался в Греции. Но тоже переезжал с помощью компании, хотя потом и уволили, из-за того что не смогли найти проект. Все IT сейчас можно поделить на 2 группы - это локальное, с разрешением на работу, а лучше с гражданством и языковыми навыками не ниже С2, и аутсорс. Весь американский аутсорс, плавно перетекает в Южную Америку. Один часовой пояс и политика штатов, держать все максимально под контролем. Европейский аутсорс - это Восточная Европа, Польша, Румыния, Болгария. Есть ещё Кавказ и средняя Азия, там хорошо по налогам и стоимости жизни, но тоже куча нюансов. В целом, приезжие нигде никому не нужны. Северную Европу я откинул из-за гендерной повестки. В Греции, в школах до сих пор молитву читают перед началом школьного дня. Что с гендерной повесткой не очень вяжется. Относительно безопасно, если не брать некоторые районы. Машину у меня здесь угнали, и похоже полиция не сильно собирается что-то делать. Были собеседования в Бельгию на нормальные суммы порядка 13 тысяч в месяц до налогов. Но там сразу срезают по отсутствию паспорта Евросоюза. Получил оффер пройдя собеседования на QA Manager, там оказалось 2500 Евро в месяц после налогов, или порядка 57000 в год до налогов. Что мне показалось откровенным издевательством, для страны, где чашка кофе стоит 5-7 Евро. Хотя да, соцпакет там хороший, даже машину и топливо оплачивают. Сейчас раздают электрички. Вот сейчас работаю в стартапе с распознаванием медицинских файлов с помощью Machine Learning. Хотя понимаю, что сейчас в Европе на зарплату, без своей недвижимости, нормально не выжить. И начинаю делать свои проекты. Будет желание, можем связаться.
Современные AI Assistents довольно хорошо справляются с созданием meeting notes. Которые легко конвертируются в страничку Confluence. Попробуйте посмотреть в данном направлении.
Сейчас у меня небольшой стартап. Прошлый проект был 100+ тестировщиков. Где я руководил командой из 25 человек. Это примерно два экстремума от 5 до 100+ человек. Остальные проекты были в основном от 15 до 40. Где я был на разных позициях, от SDET до Test Manager.
Правильно. Только осмыслив свой продукт можно принимать информированные решения как по изменению продукта, так и по изменению тестов. Эта же осведомленность позволяет выстраивать правильные сьюты и запускать нужные тесты при нужных изменениях. Есть вполне себе цепочки. Требования, код, тесты. Test Management системы с автоматизированными traceability matrix. Те же Requirement в Gitlab, если просто и по быстрому. Если GitLab не хватает, есть другие системы, TestRail, TestMo, etc. Хотя последние изменения, довольно многообещающие и должны довести в ближайшем будущем GitLab до приемлемого уровня. Если этого недостаточно, то есть системы для хранения документации. Всë есть, вопрос желания и готовности компании это использовать. Ну и опять же не стоит недооценивать Tags. У меня было несколько вполне успешных проектов, где мы использовали Tags для автоматизированного сбора тест сьютов. Успешные проекты, где сьюты собирались на системе TestRail, которая тригерила test runs. Были проекты с HP ALM и Siemens Polarion. Где все было завязано через требования. А любое изменение и тест на него был завязан на требование. Соответственно любой запуск тестов легко собирается по затронутой бизнес логике обозначеной в требованиях. Для проектов связанных с регулятор. Medical/Automotive/Air-Spacecraft. Там без этих систем в принципе не сделаешь. Другие проекты больше чем на 20-30 человек тоже вполне могли бы их использовать и это сильно бы им все упростило. Ведь решения готовые использовать проще, чем выдумывать новое свое. Бывают объективных причины, когда нужно что-то свое. Но ща 15 лет, я такого не встретил. Всегда на вопрос почему не использовать - ответ был мы про это просто не знали и уже сделали так, а переделывать не хочется. Так что лучше потратиться на исследование вначале. Чем потом платить временем, за изобретение своего велосипеда.
Нет, не достаточно. Все подобные системы заканчивают жизнь одинаково. 40 тысяч тестов, все зеленые. А баги все равно вылазят на продакшене. Понимание, какие тесты нужно гонять, а какие - нет это ключ к успешном проекту. Если нет такой цели, то нужно понимать, что проект проживет по инерции какое-то время, а потом загнется. А с подходом давайте гонять все - это тупик. Архитектуру перестраивают, требования меняются, бизнес логика меняется, а тесты остаются. В них уже смысла может год как нет, может они написаны неправильно и дают false positive. Они просто поедают время.и вместо того, чтобы привести их в порядок покупают больше ресурсов в облаках. Потом приходит менеджер и спрашивает: "Почему такой бюджет на облака? Давайте сокращать." И ведь действительно в большинстве случаев никак не оправдан. Большая часть тестов, просто пожирает ресурсы на CI, пожирает время тестировщиков, DevOps, разработчиков на разбор упавших тестов. Которые вообще никаким боком к последним изменениям не относятся. Просто гоняются прицепом, потому что разбираться не хочется какие действительно нужны, а какие - нет.
Регрес на то и регрес. Что запускает не все что можно, а то что нужно. Если команды не знают свой продукт и не понимают к чему приведут их изменения, то грош им цена.
Так вроде в этом и вопрос. Что нет смысла запускать полный тест-пьют на каждый пул-реквест. Для этого и есть слои тестирования. Ну пул-реквест - запускаются только необходимое подмножество. На мерж в фича-бренс другое подмножество. На мерж в main - третье подмножество всех тестов. Ну и нелохо было бы привести аргументы, вашим утверждениям, про стоимость для бизнеса. А то они не выглядят убедительно. Может для какого-то отдельного бизнеса так и есть. Но бизнесов много и все они разные. Многие не терпят такого подхода, просто из-за регулятор.
Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями". Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.
Стартапы бывают разные. Т если с человеком на берегу не обсудили эти моменты, то он вообще не обязан был на них закладываться. То что потом возникло несовпадение ожиданий - не так это ожидаемо, что непроговоренные вопросы - вылазят боком.
Человеку не место в компании, ну так и компании не место в его жизни.
Так бывает, как стартапы выживают 1 из сотни, так и людив них не всегда приживаются. Когда-то сотрудники промахтваются с выбором, а часто и не могут им. Объяснить на собеседовании чего ожидать, в надежде, что все видят стартап одинаково и без обсуждениях.
Каждой компании свои процессы.
Я работал в старикан, где я был 5м инженером. Потом компания выросла до 50+ человек.
И я могу 100% сказать, что невозможно работать с однимими процессами на 5 человек и на 20 человек. Там где 5 всегда можно собрать вместе и обсудить, 20 - не соберется почти никогда. Кто-то в отпуске, кто-то болеет у кого-то семейные проблемы, и т.д. да и руководитель уже не запомнит в голове так легко информацию от всех.
Поэтому и существуют 5 уровней зрелости компаний от гаража до махрового Enterprise. И задача руководства стартера, планировать рост и решать все проблемы вовремя по мере роста. Не бежать впереди паровоза вводя политики и тренинги на 3 сотрудника, но и не тормозить пытаясь вести отчеты и планировать в экселях, когда на проекте уже 30 человек. И по прежнему зажимая ресурсы на DevOps и поддержку рабочих инструментов с лицензиями.
Существенная доля это сколько?
Мне попадались, только что-то до 1,5% доли. И то с кучей условий, которые делают их получение скорее теоретическим.
Кроме того, продукт продуктом. Но не меньшую роль играет установка процессов в самой компании.
И тут начинаются все нюансы. Если разработчик вообще 1 он же СТО, он же архитектор. То нет смысла вкладываться даже в git сервер. Можно локальный поднять с бекапами. Если есть более-менее команда, хотя бы человек на 5 то тут уже нужен сервер, Task Manаger, писать вменяемый комментарии на коммиты. Если люди еще и в разных тайм-зонах с процентом пересечения не более 40%, то тут уже нужно культуру документации прививать, иначе они будут сидеть по пол-дня ожидая других, чтобы узнать что вчера такого случилось, что теперь перестало работать. Или сидеть разбирать логи теже пол дня, чтобы понять. Вместо того чтобы прочитать за 15 минут. В случае одной тайм зоны - еще можно позвонить.
И вот эти все организационные заморочки и съедают львиную долю времени, вместо того чтобы работать над продуктом. Часто видел прыжки с одного Task Manager на другой без видимого профита, просто новому сотруднику так привычней, а других нужно всех переучивать. Или вообще на это забивают. Тогда нет нормальной коммуникации и все сотрудники в постоянном стресе. А потом удивляются, что они такие токсичные? Так их просто сделали такими, поставив в условия, где только так можно выжить не поехав кукухой.
Дайте разработчикам и тестировщикам более-менее удобные и стабильные инструменты и понимание размера команды. Тогда они и не будут такими токсичными.
Переделывать продукт и его архитектуру - это нормально для стартапа. А вот когда сама компания перестраивается по 20 раз на месяц - это уже диагноз нездоровой компании.
Долгосрочное планирование - нужно любой компании. Если ее прогнозируемый срок жизни больше года. Если, вы признаете что компания просуществует год то закроется если не будет продана, то какого отношения можно ожидать от сотрудников? Они в условиях, что чтобы ни случилось, через год искать новую компанию, а может и раньше. Ну и кроме того, они то работают за зарплату, а не за потенциальные 10%+ от продажи компании. Потому стартапы и платят выше рынка, потому что для сотрудников - это повышенные риски. Энтерпрайз компании могут просуществовать гораздо дольше, поэтому риск остаться без работы меньше.
Ну а если план делать мануально - надо понимать, что тут нужно много низкоквалифицированных сотрудников с минимальной ставкой. А не начинать с 1-2 высококвалифицированных.
План выглядеть будет примерно так:
1 год. Берем студентов пилим как попало, определяемся с нишей. Не тратится на тулы и бест практис. Репортер так же не окупиться ввиду низкой стоимости сотрудников. Получаем, PoC и строим дальнейший роадмап продукта.
2 год. Берем Архитектора и переделываем весь процесс, еще пол года уйдет на стафинг, потому что стартап, не все захотят пойти. Определяем тулы, строим CI/CD и репортер с мониторингом. Начинаем переписывать продукт.
3 год. Приводим в порядок продукт по процесам.
Очень даже просто. Вопрос приоритетов. Вот владелец стартапа - качество кода - да ну его. Нам на этапе стартапа важнее скорость. Сидит 1 CTO, и понимает, что в перспективе людей больше не будет. Если не построить всю обвязку с контейнерами и CI/CD, то ты просто повесишься. Потому что это ведёт к давай быстрей, и отсутствие нормальных инструментов и автоматизации загоняет тебя в порочный круг мануальной рутины из которого не вырваться. Мануальные тесты, мануальный репортинг, сбор метрик и т.д. бизнес не считает это за работу. Это некая магия которую можно сделать за секунды. А на практике ты просто зависает в море цифр и либо начинаешь клепать ошибки, либо тратишь на это все свое время.
Ну попробуйте объяснить это бизнесу, я пытался раз 10. Ни разу не удалось.
А все почему, когда людям говоришь про PMBoK, на тебя смотрят с широко открытыми глазами. Про тактику и стратегию, на тебя смотрят с широко открытыми глазами. Про долгосрочное планирование, на тебя смотрят ... Ну вы поняли.
Люди приводят доводы, проблема в том, что даже чтобы их услышать, не говоря о том чтобы понять - нужно обладать хотя бы соизмеримыми знаниями с собеседником. Если между вами пропасть, вы не договоритесь, сколько бы вы на одном языке не разговаривали.
Это как вы обсуждаете материаловедение и FEA, а собеседник не то что Теор Мех с Высшей Математикой не учил, так он ещё и школьный курс алгебры и геометрии прошёл мимо. Ну и как вам договориться?
Есть какие-то наброски на эту тему?
Я как раз пытаюсь настроить в контейнерах nextcloud + keycloak через traefik. С аутентификацией через X509 сертификаты. Но застрял с настройкой user_oidc app. Никак не могу понять как ему можно поставить разные URI? 1 нужен для браузеров с аутентификацией, а другой для самого NextCloud у которого нет сертификата.
Что-то я не заметил такого. Web- приложения на Python/Java/JS - норм.
RobotFramework - жесть.
Autosar - тоже.
А если нужного решения нет в публичных репозиториях? Например, разработать что-то новое иди технологит пропртетарные и их днем с огнем не сыщешь в открытом доступе.
Для ответственности. Любой шлак сгенерированный нейросетью ложится ответственностью на того кто его закомитил.
Очень точная характеристика.
Ну если допускать, что история имеет место быть, то в целом это логично. Получаешь паспорт и дальше он тебе открывает возможность находиться и работать в других странах. Требования есть до получения паспорта на пребывание в стране. А гражданам с паспортом уже таких привязок нет. Так что можно ехать дальше по странам Британского содружества или где там безвиз у Канадцев.
Ну я вижу тут просто культурный шок. Все страны очень разные. И я потратил очень много сил на изучение и выбор. Хотя в моем случае это во многом сила обстоятельств.
В Канаде есть свои особенности в поиске работы. Если нет контракта от компании, я бы даже не совался. Да и с контрактом, могут быть нюансы. Одна из основных специфик - если ты не работал в Канаде, на канадскую компанию, неважно, что у тебя там в резюме, шансы стремятся к нулю. Если есть опыт хотя бы года 3, то все меняется кардинально.
Ситуация с полицией разная везде. Взвесив все за и против, я с семьёй, остался в Греции.
Но тоже переезжал с помощью компании, хотя потом и уволили, из-за того что не смогли найти проект. Все IT сейчас можно поделить на 2 группы - это локальное, с разрешением на работу, а лучше с гражданством и языковыми навыками не ниже С2, и аутсорс.
Весь американский аутсорс, плавно перетекает в Южную Америку. Один часовой пояс и политика штатов, держать все максимально под контролем. Европейский аутсорс - это Восточная Европа, Польша, Румыния, Болгария. Есть ещё Кавказ и средняя Азия, там хорошо по налогам и стоимости жизни, но тоже куча нюансов.
В целом, приезжие нигде никому не нужны.
Северную Европу я откинул из-за гендерной повестки. В Греции, в школах до сих пор молитву читают перед началом школьного дня. Что с гендерной повесткой не очень вяжется. Относительно безопасно, если не брать некоторые районы. Машину у меня здесь угнали, и похоже полиция не сильно собирается что-то делать.
Были собеседования в Бельгию на нормальные суммы порядка 13 тысяч в месяц до налогов. Но там сразу срезают по отсутствию паспорта Евросоюза. Получил оффер пройдя собеседования на QA Manager, там оказалось 2500 Евро в месяц после налогов, или порядка 57000 в год до налогов. Что мне показалось откровенным издевательством, для страны, где чашка кофе стоит 5-7 Евро. Хотя да, соцпакет там хороший, даже машину и топливо оплачивают. Сейчас раздают электрички.
Вот сейчас работаю в стартапе с распознаванием медицинских файлов с помощью Machine Learning.
Хотя понимаю, что сейчас в Европе на зарплату, без своей недвижимости, нормально не выжить. И начинаю делать свои проекты.
Будет желание, можем связаться.
Современные AI Assistents довольно хорошо справляются с созданием meeting notes. Которые легко конвертируются в страничку Confluence. Попробуйте посмотреть в данном направлении.
Сейчас у меня небольшой стартап. Прошлый проект был 100+ тестировщиков. Где я руководил командой из 25 человек.
Это примерно два экстремума от 5 до 100+ человек. Остальные проекты были в основном от 15 до 40. Где я был на разных позициях, от SDET до Test Manager.
Правильно. Только осмыслив свой продукт можно принимать информированные решения как по изменению продукта, так и по изменению тестов. Эта же осведомленность позволяет выстраивать правильные сьюты и запускать нужные тесты при нужных изменениях. Есть вполне себе цепочки. Требования, код, тесты. Test Management системы с автоматизированными traceability matrix. Те же Requirement в Gitlab, если просто и по быстрому. Если GitLab не хватает, есть другие системы, TestRail, TestMo, etc. Хотя последние изменения, довольно многообещающие и должны довести в ближайшем будущем GitLab до приемлемого уровня.
Если этого недостаточно, то есть системы для хранения документации. Всë есть, вопрос желания и готовности компании это использовать.
Ну и опять же не стоит недооценивать Tags.
У меня было несколько вполне успешных проектов, где мы использовали Tags для автоматизированного сбора тест сьютов.
Успешные проекты, где сьюты собирались на системе TestRail, которая тригерила test runs.
Были проекты с HP ALM и Siemens Polarion. Где все было завязано через требования. А любое изменение и тест на него был завязан на требование. Соответственно любой запуск тестов легко собирается по затронутой бизнес логике обозначеной в требованиях.
Для проектов связанных с регулятор. Medical/Automotive/Air-Spacecraft. Там без этих систем в принципе не сделаешь. Другие проекты больше чем на 20-30 человек тоже вполне могли бы их использовать и это сильно бы им все упростило. Ведь решения готовые использовать проще, чем выдумывать новое свое.
Бывают объективных причины, когда нужно что-то свое. Но ща 15 лет, я такого не встретил. Всегда на вопрос почему не использовать - ответ был мы про это просто не знали и уже сделали так, а переделывать не хочется.
Так что лучше потратиться на исследование вначале. Чем потом платить временем, за изобретение своего велосипеда.
Нет, не достаточно. Все подобные системы заканчивают жизнь одинаково. 40 тысяч тестов, все зеленые. А баги все равно вылазят на продакшене. Понимание, какие тесты нужно гонять, а какие - нет это ключ к успешном проекту. Если нет такой цели, то нужно понимать, что проект проживет по инерции какое-то время, а потом загнется. А с подходом давайте гонять все - это тупик.
Архитектуру перестраивают, требования меняются, бизнес логика меняется, а тесты остаются. В них уже смысла может год как нет, может они написаны неправильно и дают false positive. Они просто поедают время.и вместо того, чтобы привести их в порядок покупают больше ресурсов в облаках. Потом приходит менеджер и спрашивает: "Почему такой бюджет на облака? Давайте сокращать." И ведь действительно в большинстве случаев никак не оправдан. Большая часть тестов, просто пожирает ресурсы на CI, пожирает время тестировщиков, DevOps, разработчиков на разбор упавших тестов. Которые вообще никаким боком к последним изменениям не относятся. Просто гоняются прицепом, потому что разбираться не хочется какие действительно нужны, а какие - нет.
Ну значит еще сложнее.
Даже кафе у Фëклы придëтся закрыть или переименовать. Не думаю что все они зарегистрированы как товарные знаки.
Регрес на то и регрес. Что запускает не все что можно, а то что нужно. Если команды не знают свой продукт и не понимают к чему приведут их изменения, то грош им цена.
Так вроде в этом и вопрос. Что нет смысла запускать полный тест-пьют на каждый пул-реквест. Для этого и есть слои тестирования. Ну пул-реквест - запускаются только необходимое подмножество. На мерж в фича-бренс другое подмножество. На мерж в main - третье подмножество всех тестов.
Ну и нелохо было бы привести аргументы, вашим утверждениям, про стоимость для бизнеса. А то они не выглядят убедительно. Может для какого-то отдельного бизнеса так и есть. Но бизнесов много и все они разные. Многие не терпят такого подхода, просто из-за регулятор.
Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями".
Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.