Ну я вижу тут просто культурный шок. Все страны очень разные. И я потратил очень много сил на изучение и выбор. Хотя в моем случае это во многом сила обстоятельств. В Канаде есть свои особенности в поиске работы. Если нет контракта от компании, я бы даже не совался. Да и с контрактом, могут быть нюансы. Одна из основных специфик - если ты не работал в Канаде, на канадскую компанию, неважно, что у тебя там в резюме, шансы стремятся к нулю. Если есть опыт хотя бы года 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 за вас соберет необходимые сьюты.
Мрак, конечно. Я только не понял проблему с файлами и количеством тестов. Разве тесты не по Танцам в сьюты собираются? Какая разница сколько там в файле? Ну а вообще умные ожидания - это как бы база. Но в современных реалиях лучше сразу использовать асинхронный подход. А вообще, никто не пытается решить ключевую проблему. Как вы выбираете какие именно тесты будут гоняться для комитета? Никто не хочет думать и просто выбирает все тесты, что есть. Но в этом нет ни смысла, ни логики. Из всего количества в 95% случаев нужно прогнать только тесты связанные с затронутым функционалом. А остальная масса - просто пожирает время. Не неся в себе никакой информации. И так очевидно, что изменения, например админки или бэкофиса, никак не могут повлиять на процессинг платежей или MFA. Но в подавляющем большинстве тесты все равно будут запущены и результаты получены. Только как какой в этом толк. Начинать всегда нужно с правильных механик, что и когда запускать. На коммит - достаточно проверить непосредственный модуль и смежные. А полный прогон на merge feature branch. Это, конечно, не отменяет важности проделанных изменений. Но подход не с той стороны. Большую часть проблемы можно было решить гораздо меньшими усилиями.
А можно подробнее про видеопоток? А то я очень опечалился когда MS выкинули поддержку проброса видеокарт в виртуалку. FX что-то там называлась. Вот KVM - умеет. Ну и вообще, ниша когда контейнеры низа что не вытеснят виртуалки - это другие ОС и архитектуры. Ну не могут контейнеры сделать Arm на AMD64 и наоборот. Да и QNX на виде в контейнере не взлетает, как и на Linux.
Я вот не понимаю, чем оно лучше. Ответ один: "Виртуальные машины - безопасней чем контейнеры." Поэтому VirtualBox или Hyper-V, можно устанавлтвать и использовать. А docker - нет. А раз докер установить нельзя - остается оркестрация вокруг виртуалок. Т.е. Vagrant и Terraform. А еще это вечно веселое правило. Нельзя ничего устанавливать не из корпоративного приложения, но если оно работает просто из бинарника, то можно создать папку со специальным именем и запускать бинари оттуда. Да и Microsoft Store забывают блокировать, так что из него все равно устанавливается. Вот такая безопасность. Всем неудобно, зато дыры на каждом шагу. Судя по всему, ьезопасник просто ничего не слышал про Vagrant boxes. Вот и не возражает. Ну и тут получил бы я на сервере виртуалку в которой можно кубер развернуть и крутил бы сервисы как хотел. Но нет, на серверах только виртуалки, через LXC. Ну идоступа естественно к админе никто не даст. Поэтому хочешь память увеличить, добавить места, поправить настройки сети. Создавай тикет на каждый чих, и жди пока у админа время будет это сделать и не факт, что как нужно с первого раза.
Я не ставлю никакого знака равенства. Мне нужна возможность легко и быстро разворачивать окружение, ломать его, убивать, и снова разворачивать. С помощью контейнеров, я могу 1 раз собрать нужные образы, написать конфигурации и запускать. А еще с контейнерами не нужно заморачиваться с восстановлением баз и прочих данных, которые могут затронуть тесты. У контейнеров если не настроить persistent volume, то измененные данные умрут вместе с контейнером, что мне и нужно. В первом приближении, мне хватит и docker-compose. Но я вполне не против kubernetes - он еще облегчит проблему получения ключей TLS каждым сервисом. Но в любом варианте для начала необходимо установить docker и иметь docker container registry. А это все запрещено безопасниками - потому что: "контейнеры - это небезопасно". А итоге нужно городить все тоже самое, только через vagrant, использовать центральный box registry. Потому что Gitlab - docker registry умеет, а vagrant box registry - не умеет. Потом виртуалки сохраняют все данные и нужно прикручивать решения по очистке данных, восстановлению баз и т.д. Terraform - не умеет из коробки работать с сертификатами и ключами - нужно еще Vault подключать. В итоге Kubernetes окружения подключаются к Gitlab за день максимум. А вот без установленного docker. Поясните мне как быстренько подключить и управлять окружениями из gitlab? Чтобы через pipeline ими управлять. И да приложение использует сервисы на разных нодах с проверкой TLS.
Лично мне по большому счету все равно. Я могу и писать запросы на получение физического сервера и каждый раз устанавливать все руками и тратить на это месяцы времени. Но бизнес требует быстрее. CI/CD без контейнеров - не работает.
Всегда можно найти что и как делать. На одной стране свет клином не сошелся. Есть Грузия, Армения, Кипр, ОАЭ. Можно делать бизнес там. Налоги будут всяко меньше.
Я могу развернуть окружение для тестирования на Kubernetes за пару часов. Поддержка его займет вообще минуты. Но, контейнеры ведь нельзя. Поэтому и Kubernetes - нельзя. Своего хранилища образов нет. Что остается? Сесть и переписать все на Vagrant и или Terraform. Виртуалки то по-прежнему можно. Ну и получается тянем боксы с открытого репозитория. Здравствуй безопасность. Теряем время на переделывание всего. Теряем время на запуск. Контейнеры стартуют минут за 3-5. Окружение на виртуалках стартует минут за 40. Самостоятельная настройка tls сертификатов для виртуалок - тоже требует настройки, Vault - тоже сам прикрути. Или забей на все. Используй один пароль на все и отключи https. Какой вариант имеет больше шансов? Ну и плюс если нужно изменить настройки или что-то проверить в kubernetes, то сам же пошел и проверил. Если завязан на виртуалки, то сделал тикет и сиди жди пока до него кто-нибудь дойдет. Ты ждешь, рабочее время тикает.
Ну я вижу тут просто культурный шок. Все страны очень разные. И я потратил очень много сил на изучение и выбор. Хотя в моем случае это во многом сила обстоятельств.
В Канаде есть свои особенности в поиске работы. Если нет контракта от компании, я бы даже не совался. Да и с контрактом, могут быть нюансы. Одна из основных специфик - если ты не работал в Канаде, на канадскую компанию, неважно, что у тебя там в резюме, шансы стремятся к нулю. Если есть опыт хотя бы года 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 за вас соберет необходимые сьюты.
Мрак, конечно.
Я только не понял проблему с файлами и количеством тестов. Разве тесты не по Танцам в сьюты собираются? Какая разница сколько там в файле?
Ну а вообще умные ожидания - это как бы база. Но в современных реалиях лучше сразу использовать асинхронный подход.
А вообще, никто не пытается решить ключевую проблему.
Как вы выбираете какие именно тесты будут гоняться для комитета?
Никто не хочет думать и просто выбирает все тесты, что есть. Но в этом нет ни смысла, ни логики. Из всего количества в 95% случаев нужно прогнать только тесты связанные с затронутым функционалом. А остальная масса - просто пожирает время. Не неся в себе никакой информации. И так очевидно, что изменения, например админки или бэкофиса, никак не могут повлиять на процессинг платежей или MFA. Но в подавляющем большинстве тесты все равно будут запущены и результаты получены. Только как какой в этом толк. Начинать всегда нужно с правильных механик, что и когда запускать. На коммит - достаточно проверить непосредственный модуль и смежные. А полный прогон на merge feature branch.
Это, конечно, не отменяет важности проделанных изменений. Но подход не с той стороны. Большую часть проблемы можно было решить гораздо меньшими усилиями.
А можно подробнее про видеопоток? А то я очень опечалился когда MS выкинули поддержку проброса видеокарт в виртуалку. FX что-то там называлась.
Вот KVM - умеет.
Ну и вообще, ниша когда контейнеры низа что не вытеснят виртуалки - это другие ОС и архитектуры. Ну не могут контейнеры сделать Arm на AMD64 и наоборот. Да и QNX на виде в контейнере не взлетает, как и на Linux.
Я вот не понимаю, чем оно лучше. Ответ один: "Виртуальные машины - безопасней чем контейнеры."
Поэтому VirtualBox или Hyper-V, можно устанавлтвать и использовать. А docker - нет. А раз докер установить нельзя - остается оркестрация вокруг виртуалок. Т.е. Vagrant и Terraform.
А еще это вечно веселое правило. Нельзя ничего устанавливать не из корпоративного приложения, но если оно работает просто из бинарника, то можно создать папку со специальным именем и запускать бинари оттуда.
Да и Microsoft Store забывают блокировать, так что из него все равно устанавливается.
Вот такая безопасность. Всем неудобно, зато дыры на каждом шагу.
Судя по всему, ьезопасник просто ничего не слышал про Vagrant boxes. Вот и не возражает.
Ну и тут получил бы я на сервере виртуалку в которой можно кубер развернуть и крутил бы сервисы как хотел. Но нет, на серверах только виртуалки, через LXC. Ну идоступа естественно к админе никто не даст.
Поэтому хочешь память увеличить, добавить места, поправить настройки сети. Создавай тикет на каждый чих, и жди пока у админа время будет это сделать и не факт, что как нужно с первого раза.
Я не ставлю никакого знака равенства.
Мне нужна возможность легко и быстро разворачивать окружение, ломать его, убивать, и снова разворачивать.
С помощью контейнеров, я могу 1 раз собрать нужные образы, написать конфигурации и запускать. А еще с контейнерами не нужно заморачиваться с восстановлением баз и прочих данных, которые могут затронуть тесты. У контейнеров если не настроить persistent volume, то измененные данные умрут вместе с контейнером, что мне и нужно.
В первом приближении, мне хватит и docker-compose. Но я вполне не против kubernetes - он еще облегчит проблему получения ключей TLS каждым сервисом. Но в любом варианте для начала необходимо установить docker и иметь docker container registry.
А это все запрещено безопасниками - потому что: "контейнеры - это небезопасно".
А итоге нужно городить все тоже самое, только через vagrant, использовать центральный box registry. Потому что Gitlab - docker registry умеет, а vagrant box registry - не умеет. Потом виртуалки сохраняют все данные и нужно прикручивать решения по очистке данных, восстановлению баз и т.д. Terraform - не умеет из коробки работать с сертификатами и ключами - нужно еще Vault подключать. В итоге Kubernetes окружения подключаются к Gitlab за день максимум. А вот без установленного docker. Поясните мне как быстренько подключить и управлять окружениями из gitlab? Чтобы через pipeline ими управлять. И да приложение использует сервисы на разных нодах с проверкой TLS.
Лично мне по большому счету все равно. Я могу и писать запросы на получение физического сервера и каждый раз устанавливать все руками и тратить на это месяцы времени. Но бизнес требует быстрее. CI/CD без контейнеров - не работает.
Всегда можно найти что и как делать. На одной стране свет клином не сошелся. Есть Грузия, Армения, Кипр, ОАЭ. Можно делать бизнес там. Налоги будут всяко меньше.
Я могу развернуть окружение для тестирования на Kubernetes за пару часов. Поддержка его займет вообще минуты. Но, контейнеры ведь нельзя. Поэтому и Kubernetes - нельзя. Своего хранилища образов нет. Что остается? Сесть и переписать все на Vagrant и или Terraform. Виртуалки то по-прежнему можно. Ну и получается тянем боксы с открытого репозитория. Здравствуй безопасность. Теряем время на переделывание всего. Теряем время на запуск. Контейнеры стартуют минут за 3-5. Окружение на виртуалках стартует минут за 40.
Самостоятельная настройка tls сертификатов для виртуалок - тоже требует настройки, Vault - тоже сам прикрути. Или забей на все. Используй один пароль на все и отключи https.
Какой вариант имеет больше шансов?
Ну и плюс если нужно изменить настройки или что-то проверить в kubernetes, то сам же пошел и проверил. Если завязан на виртуалки, то сделал тикет и сиди жди пока до него кто-нибудь дойдет. Ты ждешь, рабочее время тикает.