German Jet

Во первых задумайтесь, нужна ли вам эта помойка
Чтобы сломить (пусть даже и немного) политику "экономим на всем кроме гелика гендира" нужно время и терпение:
Первое: разводим бюрократию, фиксируем все проблемы пользователей, замены компов, количество походов к пользователям в неделю на человека, особо отмечаем проблемы с безопасностью - сколько времени потребовалось чтобы вычистить комп менеджера Васи от вирусни которую он нахватал, какие риски могут возникнуть если менеджер Петя откроет письмо от "дяди Мнглуи" из Южной Африки.
Сколько простаивал складской комп пока вы удаляли с компа кладовщика Иннокентия порнографию.
Сколько литров чая было выпито за общением с бухгалтером Таней, пока показывали как печатать на новом принтере и т.п.
Это, по сути - работа начальника IT отдела, но одновременно - деньги бизнеса, потому что именно бизнес платит вам вашу зарплату (за которую вы почему то держитесь)

Второе: самообразование. Я бы не советовал вам,в отличие от других отвечающих, на говнокомпах(сервер же не купят) поднимать такие ключевые для инфраструктуры вещи как контроллер домена (будь он на линуксе или windows) или вообще любой центральный сервер - однако их подъем, настройка и, впоследствие, починка прибавят вам как опыта так и ценности в профессиональном плане и дадут шансы покинуть этот дом боли впоследствие.

Как быстрые решения:
- ставьте агент удаленного управления на каждую машину - поможет меньше между ними бегать
- стандартизируйте ПО и способы его установки (пусть это будуть хоть cmd скрипты, пофиг - лишь бы вы не сидели и не ждали очередного окошка визарда с кнопкой "NEXT" пока он там что-то затупил
- в общем и целом придумывайте как минимизировать всю беготню чтобы заняться самообразованием и улучшением ситуации качественно, а не количественно

Был в похожей ситуации года 3 назад, только без обрубания концов и релокации. Совсем не тянул, спрашивал мелочи у коллег и стыдился, ничего не понимал. Хотелось все бросить и вернуться на прошлое место работы, где можно было спать до обеда. В итоге через 3 месяца ада, ощущения собственной ничтожности и штудирования книг в любой удобный момент, что-то начало получаться. В итоге дорос до человека, у которого джуны спрашивают мелочи.
Сейчас понимаю, что первые несколько месяцев нужно было просто пережить. Это нормально для зеленого новичка в индустрии. Если вы не устроились на позицию сеньер фул-стека, адекватный работодатель не будет от вас требовать мгновенного результата. Если переживаете, честно поговорите с непосредственным начальником, что не вывозите, нужно время на раскрутиться

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится

В 1С заранее предопределенные объекты.
Прикладные программисты не могут создавать произвольные объекты, могут только в предусмотренных создателями объектах вариациях менять их свойства (набор полей) в предусмотренных создателями объектов пределах. "Создатели объектов" = "системные программисты". Vs "прикладные программисты".

Поддерживается создание произвольных объектов - как внешние компоненты - но это за пределами языка 1С. Используется редко. Встроенных хватает для 99% случаев.

1) Большинство (если не все) лицензионных соглашений запрещают не только установку, но и использование контрафактного программного обеспечения. Т.е. использовать ПО, узнав о его пиратском происхождении, уже нельзя. Таким образом ссылаться на то, что ПО было установлено другим специалистом, практически бесполезно.
2) Маленькие компании считают, что они никому из проверяющих не нужны, большие - что у них "всё схвачено и все подмазаны". Чушь. Знаю о небольшом предприятии (порядка 200 сотрудников) пищевой промышленности в маленьком городе (50-70 тысяч населения), которое тряхнули за пиратский софт. Почему их, не знаю; рядом десятки таких же предприятий с тем же уровнем лицензионного порядка. На крупном предприятии в случае проблем как раз виновный будет один сисадмин, так как у руководства "всё на мази", а сисадмин - паршивая овца на абсолютно законном предприятии.
3) Любое письменное обращение к руководству с требованием/прошением/предупреждением о нелегальном программном обеспечении подтвердит информированность специалиста о наличии пиратского ПО и его понимание незаконности действий.

IMHO, если увольняться не вариант, то как минимум не устанавливать ничего лично; информацию донести до руководства, но в недокументированной форме, чтобы потом ещё больше не встрять.
Маловероятно, но гипотетически, если в должностной инструкции указано, что специалист устанавливает программное обеспечение, предоставляемое работодателем, работодатель становится заинтересованным лицом.

В принципе все правильно. Берете и делаете. Серебрянной пули нет.

Особенно порадовало, что "все занимаются тестированием"- это правильно. Лишь бы это не было "все - значит никто". И следите за тем, чтобы тестирование давало результат - либо тикет в системе либо фикс. Если баги находят, но просто говорят о них на кухне - это не тестирование. Если баг фиксится сразу, это не значит что коммит-сообщение можно ляпнуть "fixed some strange bug" - он должен содержать описание сценария в котором он происходит и как он влияет на пользователя.

Улучшайте коммит-сообщения. Так чтобы из них можно было собрать патчноут и красиво показать пользователю. А не куча невнятного "внутряка". Формулируйте с позиции пользы, это заставит разработчиков немного больше гордиться проделанной работой, а следовательно добавит им мотивации. Для примера посмотрите как пишут патчноуты передовые представители игровой индустрии.

По автоматизации .. подводные камни такие:
- если автотестов много - их долго выполнять. Начните с небольшого количества 20-50. На них вы обкатаете внедрение и процесс. Не считайте никакие ROI - это бред. Чем считать ROI лучше написать еще один полезный тест.
- архитектуру тестов старайтесь организовать так, чтобы работу по их написанию можно было распараллелить. Например если у Вас Page Object - один может писать компоненты из которых другой может строить сценарии.
- ваш сервис сильно зависит от доступности источников данных - проверяйте доступность источников регулярно, особенно если эти данные вы получаете не по API, а выковыриваете парсером.
- сделать тестовую базу данных - правильно. Автоматизируйте ее свертывание-развертывание через контейнеры.
- по приоритетам автоматизации - точно так же - по "абстрактной" значимости. Хороший источник для идей - багтрекер. Кластеризуйте ошибки по типам и делайте выводы.
- не делайте автоматизацию ради автоматизации - в первую очередь чините продукт, потом тесты.
- не усложняйте тесты ради того чтобы они справлялись с более сложными условиями, упрощайте условия.
- автотесты будут сыпаться по непонятным причинам. Делайте как можно более полезное логгирование. Если тесты выполняются в произвольном порядке - это тоже может быть одной из причин. Любой рандом в тестировании - зло. Учитывайте это при наполнении тестовой базы данных. Желательно, чтобы тестовая база всегда содержала одинаковые данные. Смотря что у Вас за база. Если это только пользователи это одно, а если у вас там хранятся аггрегированные данные, то нужно время от времени пересобирать тестовую базу из свежих источников и проверять работу тестировочных скриптов с ней.
- автоматизацию тестирования можно применять не только для тестирования конечного продукта, можно тестировать миграции схемы базы данных, восстановление базы из бекапа и прочее.

Можете почитать мои ответы по этому хабу, может найдете там еще ответы на какие-то близкие Вам вопросы.
Вот некоторые из моих советов-ответов более-менее общей направленности:

Как добиться независимости в тестах (phpunit)?
Правильное тестирование Javascript?
Как систематически подойти к тестированию в малой компании разработчиков?
С чего начать изучение на должность QA автоматизатора?
Как создать отдел тестирования?
Какие шаги тестирования сайта?

Читайте:
"Lessons Learned in Software Testing" (Kaner, Bach, Pettichord)
"Experiences of Test Automation: Case Studies of Software Test Automation" (Graham, Fewster)
и вот эту вики: TestAutomationPatterns (Кстати, ее инициатор и редактор та же Dorothy Graham. Есть даже пару записей ее лекций на ютубе - советую глянуть)
В ней прям шаблоны. Проблема - решение. Бесценная вещь. Мне в свое время очень помогло, чтобы понять "что не так" и как это лечить.