Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д. В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров. Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15". Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5. Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы. В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7. Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7. До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7. Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64. Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке. Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело? Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать? И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять. Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен? Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с) Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc. Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик. Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное. Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает. Мышление тестировщика: один раз не сработало - значит не работает. И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна. Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности. Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет. Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве. Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов. Если речь касается Энтерпрайза - всё просто. Открываем нужный ISO и читаем. Там всё прописано с полной инструкцией как провести приоритезацию модулей/юнитов, какой уровень документации какому модулю необходим. Но для это сначала нужна архитектура, где будет расписано, где какой модуль, сколько уровней интеграции, есть ли зависимость на hardware, third party, etc. Нет архитектуры, нет требований, нет описания интерфейсов, так и говорить не о чем. Предел возможностей на таком проекте - это юнит тестирование.
Где вы увидели, что увольнять нужно всех? Только тех, кто не владеет базовыми навыками коммуникации, саботирует работу всей команды и является не компетентным. И то после 1-2-3 предупреждений на усмотрение бизнеса.
Мне вот довелось поработать как в стартапах на 5 человек, так и в медицинском энтерпрайзе по роботизированной хирургии, где одних SDET было 120 человек. А еще сверху отдельный департамент QA, который следил за работой как разработчиков, так и тестировщиков, чтобы всё было по ISO 13485 и ISO 62304. Так что всё бывает. Просто невозможно сделать медицинскую установку, автомобиль или самолёт по тем же процессным подходам, архитектурным паттернам и уровню документации как очередной веб- магазин или онлайн-казино. Банально не пройдёте сертификацию и не сможете ничего продать. Ну в крайнем случае выйдет как у Боинга, всех обмануть пока 2 самолёта не упадёт, а теперь бизнес активно загибается. Так что не торопитесь утверждать, что так не бывает, если конкретно у вас небыло такого опыта. Если у вас нет актуальной документации - значит у вас нет тестирования, а то что есть - это полная профанация. Потому как тестирование, это сверка документации с реальным поведением продукта. Нет документации - не с чем сравнивать, продукт живёт своей жизнью и о качестве даже бесполезно поднимать разговор. Таким продуктам не нужны ни Архитекторы, ни Тестировщики. Только вот реакция пользователей потом вполне ожидаема и предсказуема.
Вот читаю я все эти ситуации и мне кажется, что тут что-то пошло не туда в мире IT. Я вообще не понимаю, что значит Инженер не понимает зачем нужен Архитектор и саботирует его задачи? Обычно за такое делают выговор, а если не понятно увольняют. Тут ровно 2 проблемы: Это не задача Архитектора - доказывать Инженерам, что он нужен. Если он есть на проекте, значит бизнес принял такое решение, а значит и мотивы есть и есть чем объяснить это команде. Если инженер не знает зачем нужен архитектор, значит он банально не компетентен. Наглядно ему это объяснить можно поставив одну из архитекторских задач по обоснованию и выбору БД, масштабируемости продукта или задач по оптимизации производительности. И потом просто показав как нужно решать такие задачи, а еще и не просто решать, но и обосновывать чем данный выбор лучше альтернатив.
Потому что это всё выглядит как непонятная возня вокруг девелоперов, чтобы они не дай Бог не обиделись. Разработка продукта - это не игрушки в первую очередь, хотя да этот аспект привносит хайп, веселье и улучшает атмосферу в коллективе. Но это не перво цель. Исходная причина - это зарабатывание денег компанией, для этого нужно всем работать в команде, уважать друг друга, и стараться решать задачи максимально приблеженно к срокам и заданию. Это не ПЭТ-проект, не обучение отдельного инженера и не развлечение. Это - Работа. Поэтому задачи - это цели компании. Не согласен с задачей - спрашивай, обсуждай, пытайся разобраться. А не сиди себе тихонько в уголку и саботируй всю работу. Это проблема не только архитекторов. Я как QA Engineer тоже с таким постоянно сталкиваюсь, что почему-то разработчики считают, что им нужно доказывать и учить, зачем нужно писать юнит-тесты, использовать статические инструменты анализа, документировать интерфейсы и думать что именно в них должно быть и как, и т.д. Самый эпик который мне приходилось слышать от Principal Software Develooment Engineer: "Почему это наш код, должен соответствовать задокументированной Архитектуре?" Я даже не нашёлся, что ответить. Но через два месяца всё было отрефакторено согласно архитектуре. Выводы: Software Develipment Engineer, работает над очень маленьким кусочком продукта, он даже представить себе не может, на сколько вся система сложна в целом и сколько усилий требуется на её согласованную, эффективную и бесперебойную работу. В силу ограниченности этого, он физически не может принимать верные архитектурные решения, просто из-за отсутствия информации для видения полноты картины. Это нормально, Архитекторы работают вширь продукта, разработчики же сосредоточены на работе вглубь отдельных частей. Они могут разбираться в моделях за которые ответственны гораздо лучше архитектора, но они никогда не будут лучше понимать поведение продукта в целом. Если это происходит, значит у человека просто не верный титул в подписи почты. Результат работы Архитектора - архитектурные документы в различных их реализациях. Результат работы Инженера - это Дизайн документы отдельных модулей, их реализация в коде и юнит тесты на данный код в соответствии с дизайн документом. Ну и естественно должно быть traceability между modules, units, software items в архитектуре с дизайн документами раскрывающими данный сущности.
Оставляя деньги в руках богатых, ты растлеваешь богатых и они у них заканчиваются. Давая деньги просто так бедным, ты растлеваешь бедных. Поэтому они там навсегда и останутся, так никогда и не став богатыми.
Не всегда у тебя будет выделенный девопс на проекте. А иногда у меня были такие девопсы, что это превращались в боль. Приходилось им писать пошаговую инструкцию, что нужно сделать. Доступов команде не давали из-за безопасности, а девопсы с доступами просто не владели нужным стеком, владели другим. Но проект стартануть нужно было быстро, а размер проекта порядка 200 человек. Проще самому было сделать, но всё упиралось в доступы.
Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.
Собеседование - нужно проводить под позицию. Конечно интервьюверу. проще написать список стандартных вопросов и идти по ним. Но толку от таких собеседований мало. Я стараюсь учитывать все аспекты. Что реально нужно будет делать, состав команды, какие области нужно будет закрыть, бизнес домен и т.д. Можно получить факап по любой из этих причин. Например, сильный алгортмист, но на проекте это не нужно, от слова совсем. И девопсов выделенных нет, а он ни в кубернетс не умеет, ни с облаками не работал и терраформ не знает. Да и банально не может поставить пайплайн с юнит-тестами, сборкой и развёртыванием. Ну и наоборот бывает, человек всё умеет, а ему никто прав не даст, все построено и девопсов целая команда, а от него нужно только код хороший писать с глубоким погружением в архитектуру. Или всё классно, но человек только приложения делал, а тут embedded а он даже даташит со схемой прочитать не может. Или моё любимое, медицинский домен. Можно иметь кучу знаний и всё уметь, но запороть проект недооценив важность процессов. И закомитив, что-то до подписания всех необходимых бумаг.
Я остановился на среде Mate и Linux Mint. Долго сидел на KDE, но после того как упёрся в его баг с тайлингом по хоткеям на цифровой клавиатуре. Оставил все попытки. 10 лет никто не хочет это починить. А я уже не могу без перекидывания окон на пол экрана или на другой монитор. Gnome давно не понравился. Из коробки многое не работает, нужно допиливать постоянно из консоли или фиксить. Когда покупал последний компьютер под Линукс, остановил выбор на AMD и Radeon. Помнил долгие муки с драйверами лет 15 назад под ATI. И был приятно удивлён увидеть видео теперь прямо в ядре. Для игр придётся по-прежнему многое таскать для починки звука и видео, особенно для старых игр без поддержки FullHD. Если не хочется, есть всем известный трекер. Там игры вместе с собранным и настроенным под конкретную игру wine идут.
Так-то оно так. Но если двигаться в этом направлении. То практически всё сегодня многопоточно. Потому что процессоры многоядерные и зачастую мультитредовые. Тогда можно поставить гипервизор, развернуть N операционных систем, поднять в них любую среду и написать приложение которое будет в этом всём работать. Ну или просто какой-нибудь Kubernetes развернуть. Только всё это будет сделано вовсе вовсе не средствами языка программирования. И некоторые операции станут сильно дорогими в плане времени.
Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать. В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день. Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python. Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений. Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек. Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять. Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.
Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске? Сколько проектов по тестированию требуют глубоких знаний базовых методов языка? Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт. В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений. Некоторые фреймворки вообще ломают логику базового языка. Например, работа с Selenium в Python, всё равно превращает код в JAVA образный. Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI. Почему Azure в минимальной подписки не имеет смысла. И т.д.
Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д.
В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров.
Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15".
Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5.
Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы.
В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7.
Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7.
До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7.
Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64.
Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке.
Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело?
Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать?
И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять.
Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен?
Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с)
Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc.
Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик.
Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное.
Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает.
Мышление тестировщика: один раз не сработало - значит не работает.
И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна.
Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности.
Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет.
Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?
А кто втирал- то?
Я как-раз обратное предлагал. В весьма доходчивой форме.
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве.
Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов.
Если речь касается Энтерпрайза - всё просто. Открываем нужный ISO и читаем. Там всё прописано с полной инструкцией как провести приоритезацию модулей/юнитов, какой уровень документации какому модулю необходим. Но для это сначала нужна архитектура, где будет расписано, где какой модуль, сколько уровней интеграции, есть ли зависимость на hardware, third party, etc.
Нет архитектуры, нет требований, нет описания интерфейсов, так и говорить не о чем. Предел возможностей на таком проекте - это юнит тестирование.
Где вы увидели, что увольнять нужно всех? Только тех, кто не владеет базовыми навыками коммуникации, саботирует работу всей команды и является не компетентным. И то после 1-2-3 предупреждений на усмотрение бизнеса.
Мне вот довелось поработать как в стартапах на 5 человек, так и в медицинском энтерпрайзе по роботизированной хирургии, где одних SDET было 120 человек. А еще сверху отдельный департамент QA, который следил за работой как разработчиков, так и тестировщиков, чтобы всё было по ISO 13485 и ISO 62304. Так что всё бывает.
Просто невозможно сделать медицинскую установку, автомобиль или самолёт по тем же процессным подходам, архитектурным паттернам и уровню документации как очередной веб- магазин или онлайн-казино.
Банально не пройдёте сертификацию и не сможете ничего продать. Ну в крайнем случае выйдет как у Боинга, всех обмануть пока 2 самолёта не упадёт, а теперь бизнес активно загибается.
Так что не торопитесь утверждать, что так не бывает, если конкретно у вас небыло такого опыта.
Если у вас нет актуальной документации - значит у вас нет тестирования, а то что есть - это полная профанация. Потому как тестирование, это сверка документации с реальным поведением продукта. Нет документации - не с чем сравнивать, продукт живёт своей жизнью и о качестве даже бесполезно поднимать разговор. Таким продуктам не нужны ни Архитекторы, ни Тестировщики. Только вот реакция пользователей потом вполне ожидаема и предсказуема.
Вот читаю я все эти ситуации и мне кажется, что тут что-то пошло не туда в мире IT. Я вообще не понимаю, что значит Инженер не понимает зачем нужен Архитектор и саботирует его задачи? Обычно за такое делают выговор, а если не понятно увольняют.
Тут ровно 2 проблемы:
Это не задача Архитектора - доказывать Инженерам, что он нужен. Если он есть на проекте, значит бизнес принял такое решение, а значит и мотивы есть и есть чем объяснить это команде.
Если инженер не знает зачем нужен архитектор, значит он банально не компетентен. Наглядно ему это объяснить можно поставив одну из архитекторских задач по обоснованию и выбору БД, масштабируемости продукта или задач по оптимизации производительности. И потом просто показав как нужно решать такие задачи, а еще и не просто решать, но и обосновывать чем данный выбор лучше альтернатив.
Потому что это всё выглядит как непонятная возня вокруг девелоперов, чтобы они не дай Бог не обиделись. Разработка продукта - это не игрушки в первую очередь, хотя да этот аспект привносит хайп, веселье и улучшает атмосферу в коллективе. Но это не перво цель. Исходная причина - это зарабатывание денег компанией, для этого нужно всем работать в команде, уважать друг друга, и стараться решать задачи максимально приблеженно к срокам и заданию.
Это не ПЭТ-проект, не обучение отдельного инженера и не развлечение. Это - Работа. Поэтому задачи - это цели компании. Не согласен с задачей - спрашивай, обсуждай, пытайся разобраться. А не сиди себе тихонько в уголку и саботируй всю работу.
Это проблема не только архитекторов. Я как QA Engineer тоже с таким постоянно сталкиваюсь, что почему-то разработчики считают, что им нужно доказывать и учить, зачем нужно писать юнит-тесты, использовать статические инструменты анализа, документировать интерфейсы и думать что именно в них должно быть и как, и т.д.
Самый эпик который мне приходилось слышать от Principal Software Develooment Engineer:
"Почему это наш код, должен соответствовать задокументированной Архитектуре?"
Я даже не нашёлся, что ответить. Но через два месяца всё было отрефакторено согласно архитектуре.
Выводы:
Software Develipment Engineer, работает над очень маленьким кусочком продукта, он даже представить себе не может, на сколько вся система сложна в целом и сколько усилий требуется на её согласованную, эффективную и бесперебойную работу. В силу ограниченности этого, он физически не может принимать верные архитектурные решения, просто из-за отсутствия информации для видения полноты картины.
Это нормально, Архитекторы работают вширь продукта, разработчики же сосредоточены на работе вглубь отдельных частей. Они могут разбираться в моделях за которые ответственны гораздо лучше архитектора, но они никогда не будут лучше понимать поведение продукта в целом. Если это происходит, значит у человека просто не верный титул в подписи почты.
Результат работы Архитектора - архитектурные документы в различных их реализациях. Результат работы Инженера - это Дизайн документы отдельных модулей, их реализация в коде и юнит тесты на данный код в соответствии с дизайн документом.
Ну и естественно должно быть traceability между modules, units, software items в архитектуре с дизайн документами раскрывающими данный сущности.
Оставляя деньги в руках богатых, ты растлеваешь богатых и они у них заканчиваются. Давая деньги просто так бедным, ты растлеваешь бедных. Поэтому они там навсегда и останутся, так никогда и не став богатыми.
Не всегда у тебя будет выделенный девопс на проекте. А иногда у меня были такие девопсы, что это превращались в боль. Приходилось им писать пошаговую инструкцию, что нужно сделать. Доступов команде не давали из-за безопасности, а девопсы с доступами просто не владели нужным стеком, владели другим. Но проект стартануть нужно было быстро, а размер проекта порядка 200 человек.
Проще самому было сделать, но всё упиралось в доступы.
Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.
Собеседование - нужно проводить под позицию. Конечно интервьюверу. проще написать список стандартных вопросов и идти по ним.
Но толку от таких собеседований мало.
Я стараюсь учитывать все аспекты. Что реально нужно будет делать, состав команды, какие области нужно будет закрыть, бизнес домен и т.д.
Можно получить факап по любой из этих причин. Например, сильный алгортмист, но на проекте это не нужно, от слова совсем. И девопсов выделенных нет, а он ни в кубернетс не умеет, ни с облаками не работал и терраформ не знает. Да и банально не может поставить пайплайн с юнит-тестами, сборкой и развёртыванием.
Ну и наоборот бывает, человек всё умеет, а ему никто прав не даст, все построено и девопсов целая команда, а от него нужно только код хороший писать с глубоким погружением в архитектуру.
Или всё классно, но человек только приложения делал, а тут embedded а он даже даташит со схемой прочитать не может.
Или моё любимое, медицинский домен. Можно иметь кучу знаний и всё уметь, но запороть проект недооценив важность процессов. И закомитив, что-то до подписания всех необходимых бумаг.
Просто не берите принтеры Canon. С остальными проблем не помню.
Я остановился на среде Mate и Linux Mint.
Долго сидел на KDE, но после того как упёрся в его баг с тайлингом по хоткеям на цифровой клавиатуре. Оставил все попытки. 10 лет никто не хочет это починить. А я уже не могу без перекидывания окон на пол экрана или на другой монитор.
Gnome давно не понравился. Из коробки многое не работает, нужно допиливать постоянно из консоли или фиксить.
Когда покупал последний компьютер под Линукс, остановил выбор на AMD и Radeon. Помнил долгие муки с драйверами лет 15 назад под ATI. И был приятно удивлён увидеть видео теперь прямо в ядре.
Для игр придётся по-прежнему многое таскать для починки звука и видео, особенно для старых игр без поддержки FullHD. Если не хочется, есть всем известный трекер. Там игры вместе с собранным и настроенным под конкретную игру wine идут.
Так-то оно так. Но если двигаться в этом направлении. То практически всё сегодня многопоточно. Потому что процессоры многоядерные и зачастую мультитредовые. Тогда можно поставить гипервизор, развернуть N операционных систем, поднять в них любую среду и написать приложение которое будет в этом всём работать. Ну или просто какой-нибудь Kubernetes развернуть. Только всё это будет сделано вовсе вовсе не средствами языка программирования. И некоторые операции станут сильно дорогими в плане времени.
Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать.
В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день.
Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python.
Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений.
Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек.
Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять.
Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.
Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске?
Сколько проектов по тестированию требуют глубоких знаний базовых методов языка?
Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт.
В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений.
Некоторые фреймворки вообще ломают логику базового языка.
Например, работа с Selenium в Python, всё равно превращает код в JAVA образный.
Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI.
Почему Azure в минимальной подписки не имеет смысла. И т.д.