Ну я работал с 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).
Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc. Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций. Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич. У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами. Жил я себе, заработал на автомобиль в кредит. Выплатил за год. Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции. Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются. Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету. Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет. Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты. Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь. Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто. Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях. То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему. Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется. Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги. А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию. Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак. Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт. Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу. Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
Люто-бешено плюсую. Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
Ну я работал с 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).
Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc.
Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций.
Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич.
У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами.
Жил я себе, заработал на автомобиль в кредит. Выплатил за год.
Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции.
Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются.
Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету.
Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет.
Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты.
Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь.
Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто.
Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях.
То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему.
Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется.
Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги.
А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию.
Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак.
Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт.
Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу.
Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Учить AI - это конечно полезно. Но:
Галлюцинации, никто не отменял.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
За день сделаешь?
Сделаю.
А за 2?
Можно и за 2.
А за неделю?
Нет, за неделю не могу. Тут помощник нужен. (с)
Люто-бешено плюсую.
Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
А как же Gattling?