Есть какие-то наброски на эту тему? Я как раз пытаюсь настроить в контейнерах 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 - третье подмножество всех тестов. Ну и нелохо было бы привести аргументы, вашим утверждениям, про стоимость для бизнеса. А то они не выглядят убедительно. Может для какого-то отдельного бизнеса так и есть. Но бизнесов много и все они разные. Многие не терпят такого подхода, просто из-за регулятор.
Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями". Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.
Конечно могут понадобиться другие сервисы. Поэтому и существует пирамида тестирования. Есть множество готовых сетов. Но каждая компания адаптирует под себя исходя из размера проекта, его степени зрелости и фазы, степени зрелости самой компании. В общем случаем - создал Feature/User Story, создал сабтаски на разработку обновлениями кода, на обновление документации, на написание тестов на всех уровнях - Unit, Unit Integration, Subsystem, Subsystem Integration, System, System Integration, Acceptance. Тут уже количество уровней напрую зависит от Архитектуры и должно коррелироваться ей, может продукту и 1го уровня достаточно. В сабтасках создаются feature branches, во все тесты просачивается tag с именем feature или любой другой идентификатор на усмотрение команды. Теперь, магия. Запуск тестов на всех уровнях с данным тагом покрывает весь необходимый функционал. Если же это не происходит, значит либо проблема с Архитектурой и документацией, что она не позволила сделать правильное решение какие тесты должны быть добавлены и обновлены, либо кто-то в команде не понимает, что происходит. Опять же теперь есть инструменты с AI позволяющие помочь с данной идентификацией. На сколько им доверять - это уже вопрос отдельный. Цепочка которую вы выбрали вполне себе может существовать. Но как раз она является проблемой. Это взгляд на продукт снизу вверх, индуктивный. При рассмотрении продукта снизу вверх невозможно увидеть связей. Для этого нужно смотреть сверху вниз как пользователь. Пользователя интересует чтобы вызов действия приводил к ожидаемым последствиям, а не то все как именно оно реализовано. И именно рассмотрение сверху вниз через Архитектуру дает быстрое понимание задействованных модулей и интерфейсов. Но опять же при условии, что они нормально и актуально задокументированы.
Я бы не сказал, что это сложно. Но это требует работы. Которую, с одной стороны делать нужно, а с другой стороны делать не хотят. И платить за нее не хотят. Это требует грамотного построения процеса и адекватной поддержки документации. Если задачи сгруппированы по features/user stories, залинкованы друг с другом согласно Software Architecture. Feature/user story включает позадачи не только на разработку но и на написание/обновление тестов на всех уровнях, поддержку документации, составление тест-плана, и т.д. То никаких проблем собрал release notes, тесты посмотрел по tags, эквивалентным фичам, можно парсить заколовок feature branch и брать оттуда, если ведется конвенция заголовок. Я ведь надеюсь она ведется, хотя бы для интеграции Task Management c репозиторием. И получаешь тест-ран без проблем в несколько кликов или вообще автоматизировано. Если в документацию не вкладываться, на Архитектуру и прочую документацию не обращать внимания, на планирование и согласование тестов время не выделять. И по менеджменту проекта только делать вид, а не реально оперировать тикетами, вести релиз менеджмент. То да, сделать эффективное тестирование - нереально. Тестирование, всегда опирается на входные данные в виде документации(требования, архитектуру, описание интерфейсов), если в это не вкладываться - тестирование не имеет смысла. Потому что задача тестирования, оценить степень готовности продукта и риск его релиза в текущем состоянии. А без входных данных невозможно измерить объем работ и изменений. И любой результат тест репорта - будет просто сферическим числом в вакууме. По которому абсолютно ничего нельзя сказать и измерить.
Они непосредственно связаны. Независимо от того приемник и получатель - это люди или технические приспособления. Главное правило - передавать информацию имеет смысл тогда и только тогда, когда приемник готов ее получить. Следующее - это использование понятных как передатчик так и приемнику форматов сообщений. Для техники это выражается в использовании API, RFC, форматов пакетов и заголовках. Люди тут мало чем отличаются. Нужно использовать понятный язык т в это понятие входит не только различие, например, русский и китайский. Но и терминалогия, стиль языка, формат изложения мыслей, используемые инструменты и удобство их использование не только для отправителя, но и для получателя. Как вы верно заметили, дисциплина из менеджмента о построении внутренних коммуникаций, всего лишь адаптирует более общие и абстрактные правила из предмета теории информации, который одинаковом применим к любой сфере, специально для сферы коммуникации людей в компаниях. Также я убежден что построение любой системы необходимо вести сверху-вниз. От общего к частному соответственно. Следовательно и для коммуникаций я убежден. Что для начала нужно понять общие правила передачи информации, и исходя из этого, их грамотно адаптировать для людских коммуникаций. А все попытки уходить от письменности - это исключительно сдвиг в сторону удобства 1го, отправителя, который зачастую менеджер и считает себя более важным, а свое время более дорогим. В сторону перекладывания трудо-затрат на восприятие и поиск информации получателя, которых обычно много больше. И сумарные затраты каждым получатель времени на поиск информации в видео и чатах съедает непропорционально много времени, а значит и денег компании. Если которотко, в данной системе менеджмент или руководство или любой другой контент мейкер делает видимость собственной производительности за счет, по-сути, воровства ресурсов компании, путем создания пузыря, поедающего время потребителей информации. Исходя из этого я убежден, что видео может служить дополнительным средство информации в очень ограниченной сфере. А перевод к видео-контенту за счет уменьшения текстовой информации - путь неверный. Поиск по тексту всегда будет быстрее поиска по видео. Структурирование текста, также имеет намного более продвинутые средства.
Когда начальный фреймворк написан плохо, всегда проблемы. Тестовые сценарии всегда должны быть отделены, чтобы как раз можно было перенести на новый фреймворк с минимальными усилиями. Но часто об этом не думают. И пришли к этому благодаря оутсорс. Проект сделал, как быстрее. Все работает, а про дальнейшую поддержку уже никто не думает. Скорее всего это будет проблема других команд, которые придут скажут как все плохо и будут полностью переделывать.
Для этого придуманы таги. Ставишь нужные таги исходя из архитектуры и потом запускаешь сьюты по тагам. Тут конечно нужно думать, архитектуру читать. А еще ее должен кто-то написать. А silver bullet - не существует. Хочу не думать и чтобы все за меня получилось. Так не бывает. Кто-то верит, что AI все сможет. Если готовы так рискнуть, можете его попробовать сейчас достаточно инструментов устраивают AI для этих целей. Строится интеграция с системами Тест Менеджмента, и AI за вас соберет необходимые сьюты.
Есть какие-то наброски на эту тему?
Я как раз пытаюсь настроить в контейнерах 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 - третье подмножество всех тестов.
Ну и нелохо было бы привести аргументы, вашим утверждениям, про стоимость для бизнеса. А то они не выглядят убедительно. Может для какого-то отдельного бизнеса так и есть. Но бизнесов много и все они разные. Многие не терпят такого подхода, просто из-за регулятор.
Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями".
Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.
Конечно могут понадобиться другие сервисы.
Поэтому и существует пирамида тестирования.
Есть множество готовых сетов. Но каждая компания адаптирует под себя исходя из размера проекта, его степени зрелости и фазы, степени зрелости самой компании.
В общем случаем - создал Feature/User Story, создал сабтаски на разработку обновлениями кода, на обновление документации, на написание тестов на всех уровнях - Unit, Unit Integration, Subsystem, Subsystem Integration, System, System Integration, Acceptance. Тут уже количество уровней напрую зависит от Архитектуры и должно коррелироваться ей, может продукту и 1го уровня достаточно.
В сабтасках создаются feature branches, во все тесты просачивается tag с именем feature или любой другой идентификатор на усмотрение команды.
Теперь, магия. Запуск тестов на всех уровнях с данным тагом покрывает весь необходимый функционал.
Если же это не происходит, значит либо проблема с Архитектурой и документацией, что она не позволила сделать правильное решение какие тесты должны быть добавлены и обновлены, либо кто-то в команде не понимает, что происходит.
Опять же теперь есть инструменты с AI позволяющие помочь с данной идентификацией. На сколько им доверять - это уже вопрос отдельный.
Цепочка которую вы выбрали вполне себе может существовать. Но как раз она является проблемой. Это взгляд на продукт снизу вверх, индуктивный. При рассмотрении продукта снизу вверх невозможно увидеть связей. Для этого нужно смотреть сверху вниз как пользователь. Пользователя интересует чтобы вызов действия приводил к ожидаемым последствиям, а не то все как именно оно реализовано. И именно рассмотрение сверху вниз через Архитектуру дает быстрое понимание задействованных модулей и интерфейсов. Но опять же при условии, что они нормально и актуально задокументированы.
Я бы не сказал, что это сложно. Но это требует работы. Которую, с одной стороны делать нужно, а с другой стороны делать не хотят. И платить за нее не хотят.
Это требует грамотного построения процеса и адекватной поддержки документации. Если задачи сгруппированы по features/user stories, залинкованы друг с другом согласно Software Architecture. Feature/user story включает позадачи не только на разработку но и на написание/обновление тестов на всех уровнях, поддержку документации, составление тест-плана, и т.д. То никаких проблем собрал release notes, тесты посмотрел по tags, эквивалентным фичам, можно парсить заколовок feature branch и брать оттуда, если ведется конвенция заголовок. Я ведь надеюсь она ведется, хотя бы для интеграции Task Management c репозиторием. И получаешь тест-ран без проблем в несколько кликов или вообще автоматизировано.
Если в документацию не вкладываться, на Архитектуру и прочую документацию не обращать внимания, на планирование и согласование тестов время не выделять. И по менеджменту проекта только делать вид, а не реально оперировать тикетами, вести релиз менеджмент. То да, сделать эффективное тестирование - нереально.
Тестирование, всегда опирается на входные данные в виде документации(требования, архитектуру, описание интерфейсов), если в это не вкладываться - тестирование не имеет смысла. Потому что задача тестирования, оценить степень готовности продукта и риск его релиза в текущем состоянии. А без входных данных невозможно измерить объем работ и изменений. И любой результат тест репорта - будет просто сферическим числом в вакууме. По которому абсолютно ничего нельзя сказать и измерить.
Они непосредственно связаны. Независимо от того приемник и получатель - это люди или технические приспособления.
Главное правило - передавать информацию имеет смысл тогда и только тогда, когда приемник готов ее получить.
Следующее - это использование понятных как передатчик так и приемнику форматов сообщений. Для техники это выражается в использовании API, RFC, форматов пакетов и заголовках. Люди тут мало чем отличаются. Нужно использовать понятный язык т в это понятие входит не только различие, например, русский и китайский. Но и терминалогия, стиль языка, формат изложения мыслей, используемые инструменты и удобство их использование не только для отправителя, но и для получателя.
Как вы верно заметили, дисциплина из менеджмента о построении внутренних коммуникаций, всего лишь адаптирует более общие и абстрактные правила из предмета теории информации, который одинаковом применим к любой сфере, специально для сферы коммуникации людей в компаниях.
Также я убежден что построение любой системы необходимо вести сверху-вниз. От общего к частному соответственно. Следовательно и для коммуникаций я убежден. Что для начала нужно понять общие правила передачи информации, и исходя из этого, их грамотно адаптировать для людских коммуникаций.
А все попытки уходить от письменности - это исключительно сдвиг в сторону удобства 1го, отправителя, который зачастую менеджер и считает себя более важным, а свое время более дорогим. В сторону перекладывания трудо-затрат на восприятие и поиск информации получателя, которых обычно много больше. И сумарные затраты каждым получатель времени на поиск информации в видео и чатах съедает непропорционально много времени, а значит и денег компании.
Если которотко, в данной системе менеджмент или руководство или любой другой контент мейкер делает видимость собственной производительности за счет, по-сути, воровства ресурсов компании, путем создания пузыря, поедающего время потребителей информации.
Исходя из этого я убежден, что видео может служить дополнительным средство информации в очень ограниченной сфере. А перевод к видео-контенту за счет уменьшения текстовой информации - путь неверный.
Поиск по тексту всегда будет быстрее поиска по видео. Структурирование текста, также имеет намного более продвинутые средства.
Когда начальный фреймворк написан плохо, всегда проблемы. Тестовые сценарии всегда должны быть отделены, чтобы как раз можно было перенести на новый фреймворк с минимальными усилиями.
Но часто об этом не думают. И пришли к этому благодаря оутсорс. Проект сделал, как быстрее. Все работает, а про дальнейшую поддержку уже никто не думает. Скорее всего это будет проблема других команд, которые придут скажут как все плохо и будут полностью переделывать.
Для этого придуманы таги.
Ставишь нужные таги исходя из архитектуры и потом запускаешь сьюты по тагам. Тут конечно нужно думать, архитектуру читать. А еще ее должен кто-то написать. А silver bullet - не существует. Хочу не думать и чтобы все за меня получилось. Так не бывает. Кто-то верит, что AI все сможет. Если готовы так рискнуть, можете его попробовать сейчас достаточно инструментов устраивают AI для этих целей. Строится интеграция с системами Тест Менеджмента, и AI за вас соберет необходимые сьюты.