Т.е. вопрос все таки в лени. Один человек не может сделать работу 1 раз по настройке, своего хранилища образов и сделать несколько нужных базовых образов. Чтобы 100-1000-10000 других разработчиков и тестировщиков тратили в разы больше своего времени, а значит и денег компании? Я прекрасно понимаю стоимость проблем с безопасностью. Но я так же понимаю стоимость проблем, когда безопасность мешает компании нормально зарабатывать деньги. Это выливается исключительно в то, что все равно находятся пути обхода проблем? Конструкторы отказываются от оборудования компании и рабоют на своëм. Запретили права на установку приложений. Но, установка приложений из Windows Store - почему-то продолжает работать. Докеры можно, но только в отдельной виртуалке. Я подозреваю, что если бы поднял свой DHCP или DNS server, то спокойно положил бы сеть, как не раз видел в таких компаниях. Потому что spoofing настраивать было так же лень как и дркер.
Еще раз, речь про разворачивание тестового окружения для разработки и тестирования. Никакого продакшн, никаких данных, никаких ссылок с корпоративными сервисами. Чем контейнер докера опасней коробки для Vagrant? Есть разница между безопасностью и параноей. Т.е. докер - нельзя потому что влом настраивать. А Vault - тоже влом поднимать, шлите пароли как хотите. Эта "мнимая" безопасность стоит каждый одному только небольшому офису в 100 сотрудников - около часа в день их оплачиваемый рабочего времени. Средняя стоимость часа работы сотрудника для компании - 50 Евро. Т.е. это 5000 Евро в день компания выкидывает на что? Чтобы админ лишний раз не напрягся? Не дороговат ли обходиться такой админ?
ИМХО, никто не глянул что статья про США. И работа ушла не столько из-за ИИ. Сколько из-за программистов в других регионах, где можно платить меньше. Вместо одного за 100 000 в год в штатах, можно взять 2х по 50 в условной Грузии. Как по мне - это более веский фактор. Ранее была языковая проблема. Теперь программист в любой точке мира довольно сносно говорит на английском. Так что идеи Трампа все вернуть в Америку - прекрасны только на бумаге.
У меня была куча обратных проблем. Доступы делают по 4 месяца. В целом мне норм, деньги платят, доступы ждёшь, но менеджеры нервничают. Доступ на тестовый сервер на AWS, только из внутренней сети, никакого порта наружу. Пришлось городить ssh туннели. ХЗ, кому от этого было лучше. Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера. Из полезного пришлось выучить Vagrant и Terraform. Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере. Ну и пришлось требовать больше оперативной памяти.
Был у меня один такой менеджер. Доступы выдавались у заказчика по 4 месяца. Каждый созвон требовал шарить креды. Я ему каждый раз говорил, давай письмо на мейл с указом, тогда пошарю. Естественно никакого письма не было.
Ну вроде как понятно, абсолютно рабочий бот - это сродни вечному двигателю. Торговля - это всегда риск. А теория вероятностей меня научила считать риски. И тут они не в твою пользу как и в казино. Хотя бы потому, что тебя могут лишить доступа в любой момент, без объяснения причин. А ещё и впаять срок, выдумать за что, всегда сумеют.
А почему не использовать fiber-lock вместо сварки. Да он даёт более высокое затухание, но заметно дешевле. Если их не ставить 100 штук на один кабель, то проблем не будет.
Думаю тут нужно разбирать конкретный кейс. Обычно, faker приносит пользу разработчикам для юнит-тестов. Тестировщики же, как правило, и так отлично понимают какие в рамках теста корнер-кейсы и что нужно подать на вход теста. Применяют всяке техники, например Pair Wise Testing, Border Values Analysis, Equivalence Classes, etc. Я тут больще за всякие утилиты вроде PICT для помощи с Pair Wise. Потому как если просто отдать на откуп faker, то колличество тестов начинает расти неадекватной прогрессией. И на действительно нужные тестовые данные, будет приходиться 100 за компанию. А ведь каждый набор данных - это лишний тест ран, т.е. время. Регулярная практика на больших проектах вычищать бесполезные тесты, которые накидали на всякий случай. Иногда, проще вообще выкинуть такие фреймворки, чем разбирать что там такого насочиняли и почему тест-ран занимает 2-3 дня.
Для меня AI - это прежде всего экономия собственной памяти. Достаточно помнить названия паттернов или алгоритмов и кейсы для их применения, а сам алгоритм или паттерн отлично накидает сам AI. Ну и хорошо помогает для начального ликбеза по незнакомому функционалу. Глубоко - потом все равно лучше посмотреть документацию. Но для быстрого старта - очень даже.
Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых. Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
Тоже так скитаюсь, только в тестировании. Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку. Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
Позволю с вами не согласиться. Есть важные особенности. Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык. Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами. Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает. Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д. А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может. И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции. Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта. Вы считаете, что человек ничем в жизни не занимался кроме Python последние лет 5-10. Желательно все это время он ходил по собеседованиям или сам кого-то собеседовал подобным образом. У меня на текущий момент подобная проблема, я давно не помню эту базовую мишуру из справочника, потому что могу посмотреть ее в справочнике. Я уже молчу про Copilot. Но за 13 лет, мне довелось поработать с C/C++, Python, RobotFramework, Java, JS, Golang. Да, я не знаю ни один из них так же хорошо как джун который только на 1 язык и готовился. И довелось мне работать с этими языками, потому что в тот или иной момент так нужно было проекту/компании. Но, при этом я могу развернуть сам kubernetes/terraform, могу развернуть проект на стэке Azure, Atlassian, GitLab с пайплайнам, тестированием, quality gates, pre-commit хуками, настройками код стилей для IDE и чтобы вот это все автоматически побежало, и деплоилось без ручных манипуляций. Когда нужно было поднять проект на JS, а договаривались изначально на Java, просто пошел за месяц освоился с фреймворком, параллельно его поднял и настроил всю обвязку. Вот интересно, мне узнать. Приходит к вам проект, например. Есть у вас супер Python инженер. Какой язык и стэк он подберёт исходя из потребностей проекта? А скажем проект нацелен на Automotive или Embedded? Или другой проект для High Frequency Trading? Я же надеюсь Senior Engineer не пойдет просить DevOps или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
Ну я работал с Medtronic. Проект на более 100 человек Manual testers, Automarted Testers, SDET, Test Leads, Test Managers, DevOps. Всё было, и этот проект был чисто по тестированию, потому как по стандарту требуется максимальная независимость на уровне сторонней компании от разработки. Т.е. нельзя доверять результатам тестирования самой компании разработчика, потому что продукт из Safety Critical области. И в крайнем случае может привести к смерти людей. Работал Thomson Reuters, когда они еще были таковыми и с Refinitiv/LSEG. Там были платформы из fintech $ risk&legal доменов. Аналогично, никто не экономил. Все команды и роли были, включая Business Analytics. Так что всё вполне есть, только не у всех. Также работал и в стартапах, где приходилось делать всё. В общем основной посыл, что время и ресурсы потраченные компанией на "свой велоосипед" для определений ролей - это во-первых зря потраченные ресурсы. А во-вторых, я еще не видел, чтобы кто-то это сделал лучше или хотя бы на уровне как у ISTQB. Вместо того чтобы тратить на это время, можно просто почитать ISTQB и уже решать какие роли совмещать в конкретных людях. А на практике, выдумывают что-то своё и 99,5% случаев много чего упускают, получают фейл и начиают исправлять, опять что-то упуская. И так по спирали. Пока не приёдут к решению максимально близкому к давно описанному.
Ну статья про AI, написанная AI. С чем могу согласиться, что это действительно сильно помогает разобраться с возможностями незнакомых инструментов, запустив набросанные примеры. Я получал от разработчиков документацию, написанную AI без вычитки, хотелось их пристрелить. Плюс, всё очень сильно зависит от инструмента и доступной по нему открытой информации. Т.е. все проприетарное - без шансов. Пробовал, Java тесты и Python тесты - работает сносно. Пробовал RobotFramework и тут попандос. Сыпет примерами 3-4 мажорных версий назад. Ну и его примеры хороши для PoC. А нужна сразу продуманная архитектура с учётом особенностей твоего проекта. Чего никто тебе тут не скажет. Ну и выйдет что ты с помощью AI быстро накидаешь костыльное решение, которое очень скоро будет практически невозможно поддерживать. Т.е. для буяк-буяк ив продакшн - это ОК. Если ты планируешь с этим жить какое-то время. То ничего хорошего так просто не выходит. Нужен, человек с опытом, который разберёт все проблемы и разложит по проектам и пайплайнам. Ну и саму архитектуру и модули сделает как-надо, без мешанины.
Если релиз менеджер не делает свою работу, а получает деньги просто так. Это вообще не означает, что эту работу должен начать делать кто-то другой бесплатно. Просто нужно уволить такого релиз-менеджера. Просто он должен был выработать метрики и настроить их автоматический сбор. Получить тест репорт от QA с разбивкой дефектов по кластерам и если это укладывается в рамки оговоренные в тест-плане. Например, 0% - critical/major defects, <10% - minor defects, <25% - cosmetic defect. Цифры указаны для примера и должны быть установлены для конкретного проекта. Сверил репорт с реферальными значениями, прошел по чек-листу, что остальные компоненты тоже не пропущены. Например, пользовательская документация, собран пакет, обновлены ссылки, версии, копирайта и т.д. и закрыл релиз. Тут не требуется глубоких знаний. Или эти все операции - тоже QA выполняет?
Я вот работал в компании, где проще было самому исправить баги и сделать Pull Request. Чем описывать 100500 одинаковых дефектов в каждом модуле. Ведь разработчики код писали копи-пастой и один дефект с перечислением модулей их не устраивал, подавай на каждый модуль отдельный. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт. А потом понимаешь, что твоя оплата вообще не соответствует уровню обязанностей. Почему менеджеры получают много? Потому что они несут на себе ответственность за успех продукта/проекта. Уровень ответственности прямо пропорционален уровню оплаты. Почему так много фейлов на практике компаний? Потому что, менеджеры либо некомпетентны, либо на отморозе сбрасывают ответственность на QA. QA не бывает в состоянии принять верные решения, просто потому что не обладает всей информацией особенно про зависимости с другими модулями, проектами, подрядчиками и т.д. Его просто никто никогда не позовет на митинги, где торгуются компании, без этой информации про стоимость и сроки - невозможно сделать правильного решения про релиз. Ты можешь сделать все как можно лучше, всех пригнать в обозначенные сроки, а потом узнать что в этом нет смысла, потому что модуль подрядчика будет через пол-года. Так с ним договорились. Эта информация уровня минимум QA Manager, но ведь в вашей компании вообще нет такой роли, раз поднимается подобный вопрос. Release Manager выделенного может и не быть, если проектов не так много. Но эта роль должна быть на Project Manager или Product Owner в крайнем случае. Да что там, QA даже priority багам не должны выставлять, только severity. Но я встречал единицы представителей бизнеса, которые бы нормально делали свою работу и отвечали за приоритеты и риски и занимались риск менеджментом. Я думаю, хоть раз слышали про Triage дефектов? Почему слово-то такое? Да потому что тут своя триада - бизнес, разработка, тестирование. И этот процесс означает совместный анализ дефектов. А как на практике? Ты QA - вот или сам и триаж. А потом получаются компании уровня Боинг, у которых что-нибудь отваливается в полёте. И я не понял, какое отношение команда имеет к MTTR? Это вообще понятие из категории надёжности продукта. Время за которое продукт восстанавливает работоспособность в случае непредвиденной ошибки. Т.е. сколько времени пользователь не сможет воспользоваться продуктом после наступления ошибки. Я бы рекомендовал ознакомиться хоть немного с ISTQB. Эти идеи массово витают в стартапах, банально в силу неграмотности. Но не работают на практике, для любого продукта с хоть сколь-нибудь существующей фазой его поддержки(Maintenance Phase).
Т.е. вопрос все таки в лени. Один человек не может сделать работу 1 раз по настройке, своего хранилища образов и сделать несколько нужных базовых образов. Чтобы 100-1000-10000 других разработчиков и тестировщиков тратили в разы больше своего времени, а значит и денег компании?
Я прекрасно понимаю стоимость проблем с безопасностью. Но я так же понимаю стоимость проблем, когда безопасность мешает компании нормально зарабатывать деньги.
Это выливается исключительно в то, что все равно находятся пути обхода проблем?
Конструкторы отказываются от оборудования компании и рабоют на своëм. Запретили права на установку приложений. Но, установка приложений из Windows Store - почему-то продолжает работать.
Докеры можно, но только в отдельной виртуалке. Я подозреваю, что если бы поднял свой DHCP или DNS server, то спокойно положил бы сеть, как не раз видел в таких компаниях. Потому что spoofing настраивать было так же лень как и дркер.
Еще раз, речь про разворачивание тестового окружения для разработки и тестирования. Никакого продакшн, никаких данных, никаких ссылок с корпоративными сервисами.
Чем контейнер докера опасней коробки для Vagrant?
Есть разница между безопасностью и параноей.
Т.е. докер - нельзя потому что влом настраивать. А Vault - тоже влом поднимать, шлите пароли как хотите.
Эта "мнимая" безопасность стоит каждый одному только небольшому офису в 100 сотрудников - около часа в день их оплачиваемый рабочего времени. Средняя стоимость часа работы сотрудника для компании - 50 Евро. Т.е. это 5000 Евро в день компания выкидывает на что? Чтобы админ лишний раз не напрягся? Не дороговат ли обходиться такой админ?
ИМХО, никто не глянул что статья про США. И работа ушла не столько из-за ИИ. Сколько из-за программистов в других регионах, где можно платить меньше. Вместо одного за 100 000 в год в штатах, можно взять 2х по 50 в условной Грузии. Как по мне - это более веский фактор. Ранее была языковая проблема. Теперь программист в любой точке мира довольно сносно говорит на английском. Так что идеи Трампа все вернуть в Америку - прекрасны только на бумаге.
Слишком много Oracle выёживался с лицензиями.
У меня была куча обратных проблем. Доступы делают по 4 месяца. В целом мне норм, деньги платят, доступы ждёшь, но менеджеры нервничают.
Доступ на тестовый сервер на AWS, только из внутренней сети, никакого порта наружу. Пришлось городить ssh туннели. ХЗ, кому от этого было лучше.
Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера. Из полезного пришлось выучить Vagrant и Terraform. Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере. Ну и пришлось требовать больше оперативной памяти.
Был у меня один такой менеджер. Доступы выдавались у заказчика по 4 месяца. Каждый созвон требовал шарить креды. Я ему каждый раз говорил, давай письмо на мейл с указом, тогда пошарю. Естественно никакого письма не было.
Ну вроде как понятно, абсолютно рабочий бот - это сродни вечному двигателю.
Торговля - это всегда риск. А теория вероятностей меня научила считать риски. И тут они не в твою пользу как и в казино. Хотя бы потому, что тебя могут лишить доступа в любой момент, без объяснения причин. А ещё и впаять срок, выдумать за что, всегда сумеют.
А почему не использовать fiber-lock вместо сварки. Да он даёт более высокое затухание, но заметно дешевле. Если их не ставить 100 штук на один кабель, то проблем не будет.
Думаю тут нужно разбирать конкретный кейс.
Обычно, faker приносит пользу разработчикам для юнит-тестов.
Тестировщики же, как правило, и так отлично понимают какие в рамках теста корнер-кейсы и что нужно подать на вход теста. Применяют всяке техники, например Pair Wise Testing, Border Values Analysis, Equivalence Classes, etc. Я тут больще за всякие утилиты вроде PICT для помощи с Pair Wise.
Потому как если просто отдать на откуп faker, то колличество тестов начинает расти неадекватной прогрессией. И на действительно нужные тестовые данные, будет приходиться 100 за компанию. А ведь каждый набор данных - это лишний тест ран, т.е. время. Регулярная практика на больших проектах вычищать бесполезные тесты, которые накидали на всякий случай. Иногда, проще вообще выкинуть такие фреймворки, чем разбирать что там такого насочиняли и почему тест-ран занимает 2-3 дня.
Для меня AI - это прежде всего экономия собственной памяти. Достаточно помнить названия паттернов или алгоритмов и кейсы для их применения, а сам алгоритм или паттерн отлично накидает сам AI. Ну и хорошо помогает для начального ликбеза по незнакомому функционалу. Глубоко - потом все равно лучше посмотреть документацию. Но для быстрого старта - очень даже.
Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых.
Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
Тоже так скитаюсь, только в тестировании.
Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку.
Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
Всё идёт по плану... (с)
Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
Позволю с вами не согласиться. Есть важные особенности.
Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык.
Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами.
Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает.
Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д.
А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может.
И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции.
Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта.
Вы считаете, что человек ничем в жизни не занимался кроме Python последние лет 5-10. Желательно все это время он ходил по собеседованиям или сам кого-то собеседовал подобным образом.
У меня на текущий момент подобная проблема, я давно не помню эту базовую мишуру из справочника, потому что могу посмотреть ее в справочнике. Я уже молчу про Copilot.
Но за 13 лет, мне довелось поработать с C/C++, Python, RobotFramework, Java, JS, Golang. Да, я не знаю ни один из них так же хорошо как джун который только на 1 язык и готовился.
И довелось мне работать с этими языками, потому что в тот или иной момент так нужно было проекту/компании.
Но, при этом я могу развернуть сам kubernetes/terraform, могу развернуть проект на стэке Azure, Atlassian, GitLab с пайплайнам, тестированием, quality gates, pre-commit хуками, настройками код стилей для IDE и чтобы вот это все автоматически побежало, и деплоилось без ручных манипуляций.
Когда нужно было поднять проект на JS, а договаривались изначально на Java, просто пошел за месяц освоился с фреймворком, параллельно его поднял и настроил всю обвязку.
Вот интересно, мне узнать. Приходит к вам проект, например. Есть у вас супер Python инженер.
Какой язык и стэк он подберёт исходя из потребностей проекта?
А скажем проект нацелен на Automotive или Embedded? Или другой проект для High Frequency Trading?
Я же надеюсь Senior Engineer не пойдет просить DevOps или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
Ну я работал с Medtronic. Проект на более 100 человек Manual testers, Automarted Testers, SDET, Test Leads, Test Managers, DevOps. Всё было, и этот проект был чисто по тестированию, потому как по стандарту требуется максимальная независимость на уровне сторонней компании от разработки. Т.е. нельзя доверять результатам тестирования самой компании разработчика, потому что продукт из Safety Critical области. И в крайнем случае может привести к смерти людей.
Работал Thomson Reuters, когда они еще были таковыми и с Refinitiv/LSEG. Там были платформы из fintech $ risk&legal доменов. Аналогично, никто не экономил. Все команды и роли были, включая Business Analytics. Так что всё вполне есть, только не у всех. Также работал и в стартапах, где приходилось делать всё.
В общем основной посыл, что время и ресурсы потраченные компанией на "свой велоосипед" для определений ролей - это во-первых зря потраченные ресурсы. А во-вторых, я еще не видел, чтобы кто-то это сделал лучше или хотя бы на уровне как у ISTQB.
Вместо того чтобы тратить на это время, можно просто почитать ISTQB и уже решать какие роли совмещать в конкретных людях. А на практике, выдумывают что-то своё и 99,5% случаев много чего упускают, получают фейл и начиают исправлять, опять что-то упуская. И так по спирали. Пока не приёдут к решению максимально близкому к давно описанному.
Ну статья про AI, написанная AI.
С чем могу согласиться, что это действительно сильно помогает разобраться с возможностями незнакомых инструментов, запустив набросанные примеры.
Я получал от разработчиков документацию, написанную AI без вычитки, хотелось их пристрелить.
Плюс, всё очень сильно зависит от инструмента и доступной по нему открытой информации. Т.е. все проприетарное - без шансов. Пробовал, Java тесты и Python тесты - работает сносно. Пробовал RobotFramework и тут попандос. Сыпет примерами 3-4 мажорных версий назад.
Ну и его примеры хороши для PoC. А нужна сразу продуманная архитектура с учётом особенностей твоего проекта. Чего никто тебе тут не скажет. Ну и выйдет что ты с помощью AI быстро накидаешь костыльное решение, которое очень скоро будет практически невозможно поддерживать.
Т.е. для буяк-буяк ив продакшн - это ОК. Если ты планируешь с этим жить какое-то время. То ничего хорошего так просто не выходит. Нужен, человек с опытом, который разберёт все проблемы и разложит по проектам и пайплайнам. Ну и саму архитектуру и модули сделает как-надо, без мешанины.
Если релиз менеджер не делает свою работу, а получает деньги просто так. Это вообще не означает, что эту работу должен начать делать кто-то другой бесплатно. Просто нужно уволить такого релиз-менеджера.
Просто он должен был выработать метрики и настроить их автоматический сбор. Получить тест репорт от QA с разбивкой дефектов по кластерам и если это укладывается в рамки оговоренные в тест-плане. Например, 0% - critical/major defects, <10% - minor defects, <25% - cosmetic defect. Цифры указаны для примера и должны быть установлены для конкретного проекта. Сверил репорт с реферальными значениями, прошел по чек-листу, что остальные компоненты тоже не пропущены. Например, пользовательская документация, собран пакет, обновлены ссылки, версии, копирайта и т.д. и закрыл релиз. Тут не требуется глубоких знаний.
Или эти все операции - тоже QA выполняет?
Я вот работал в компании, где проще было самому исправить баги и сделать Pull Request. Чем описывать 100500 одинаковых дефектов в каждом модуле. Ведь разработчики код писали копи-пастой и один дефект с перечислением модулей их не устраивал, подавай на каждый модуль отдельный. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт. А потом понимаешь, что твоя оплата вообще не соответствует уровню обязанностей.
Почему менеджеры получают много? Потому что они несут на себе ответственность за успех продукта/проекта. Уровень ответственности прямо пропорционален уровню оплаты.
Почему так много фейлов на практике компаний? Потому что, менеджеры либо некомпетентны, либо на отморозе сбрасывают ответственность на QA.
QA не бывает в состоянии принять верные решения, просто потому что не обладает всей информацией особенно про зависимости с другими модулями, проектами, подрядчиками и т.д.
Его просто никто никогда не позовет на митинги, где торгуются компании, без этой информации про стоимость и сроки - невозможно сделать правильного решения про релиз. Ты можешь сделать все как можно лучше, всех пригнать в обозначенные сроки, а потом узнать что в этом нет смысла, потому что модуль подрядчика будет через пол-года. Так с ним договорились.
Эта информация уровня минимум QA Manager, но ведь в вашей компании вообще нет такой роли, раз поднимается подобный вопрос. Release Manager выделенного может и не быть, если проектов не так много. Но эта роль должна быть на Project Manager или Product Owner в крайнем случае.
Да что там, QA даже priority багам не должны выставлять, только severity. Но я встречал единицы представителей бизнеса, которые бы нормально делали свою работу и отвечали за приоритеты и риски и занимались риск менеджментом.
Я думаю, хоть раз слышали про Triage дефектов?
Почему слово-то такое? Да потому что тут своя триада - бизнес, разработка, тестирование. И этот процесс означает совместный анализ дефектов. А как на практике? Ты QA - вот или сам и триаж. А потом получаются компании уровня Боинг, у которых что-нибудь отваливается в полёте.
И я не понял, какое отношение команда имеет к MTTR? Это вообще понятие из категории надёжности продукта. Время за которое продукт восстанавливает работоспособность в случае непредвиденной ошибки. Т.е. сколько времени пользователь не сможет воспользоваться продуктом после наступления ошибки.
Я бы рекомендовал ознакомиться хоть немного с ISTQB. Эти идеи массово витают в стартапах, банально в силу неграмотности. Но не работают на практике, для любого продукта с хоть сколь-нибудь существующей фазой его поддержки(Maintenance Phase).