Это и проблема it, что из-за многих факторов на верхах не хотят техническую часть знать, поэтому и происходит «у нас самые крутые Технологии, лучшие методики», мы с одним руководителем однажды на слабо поспорили, он в течении 1 месяца сидел простым тестировщиком, в результате сказал, что да, херовенько все...

Хотел бы посмотреть на такой спор вживую, запомню идею, вдруг доведётся применить

Норм тема. Я лично не жду от начальника знаний всех деталей своих проектов, но вот то что он должен знать статус, причины тех часть частично это да. А вот выше его..уже только по названию проектов. Но это норм. Это позволяет масштабироваться. Иначе я другого способа не знаю и не жду от ceo что он будет понимать разницу между еластиком и люсином

Какие аргументы были с разных сторон?

Там ситуация была такая: он пришел к моему директору и говорит : качество херовое на проекте, потому что проверяете херово. Я говорю: а может быть херовое потому что нет совместимости между версиями компонент и никто даже из тех кто пишет их не скажет будет ли оно работать друг с другом и может быть улучшить процессы по раскатке, а то от devOPs только одно слово и что нужно сроки как-то согласовывать, а не обещать на право и на лево даты с потолка? потом слово за слово я и сделал предложение: давай месяц ты работаешь в роли инженера, отчетики мы попишем тебе, автоматизируем выгрузки, а ты поразвертываешь систему, протестируешь одну компоненту, если все действительно работает, то я при всей команде заявляю, что я - некомпетентный и пишу заявление, если буду я прав, то просто больше не заикаешься про крутые процессы и технологии с инструментами. первые полторы недели он держался, потом начал ругаться с разработчиками из команды и соседних команд, потом пришел к выводу, что действительно раскатка новых версий с кучей параметров через запрос JIRA- это не лучший способ, потом признался, что нужно как-то понимать, что и с какой версией будет работать и даже выделил время разработчикам и тестировщикам, чтобы создали матрицу, затем все же согласился , что к указанной дате не успеем и нужно как минимум 2 месяца на стабилизацию....

а потом через полгода он уволился...

а проект был сдан с интересной формулировкой "ПСИ проведены, версия не рекомендована к промышленной эксплуатации"

и люди даже премии получили

Хэппи энд

Хоть где-то справедливость торжествует))

как сказать... мне ввалили звездюлей за агрессию

я довел человека до увольнения своим поведением, он же был слабохарактерным...внушаемым

это мне так сказали

Пострадал за правое дело) я думаю сатисфакшен от доказательства своей правоты того стоил)

😄👍win

Уххахахха

Ну правильно
Такие хорошие технологии были, всё у людей работало.
А потом опять пришли тестировщики и всё сломали

самое убогое, не побоюсь этого слова, что в профессии тестировщика всегда приходится отгребать звездюлей..
всегда виновато тестирование..
поэтому я советую всем новичкам хорошо подумать..

Ну, хз хз. От процессов и понимания зависит. На прошлом проекте у меня разрабы всегда огребали - потому что багрепортики-то вот они, матрица вот она, чеклист вот он, автоматизация на месте. А когда чего-то нет, то давайте сроки посмотрим - когда там был билд сдан? Ага? Ну вот и всё

А вот на позапрошлом да - ну чойто вы крит баги в прод упустили?
Ну да, билд сдали на 3 недели позже, так вы тестируйте что есть, сами себе билд соберите? Не собирался - так вы разрабов дёргаете, чтоб собрался? Они все заняты были? Ну как-то у вас процессы тестирования не отлажены ребята, как это так вы ситуацию не контролируете.