BI
может потому что дешевле нанять джуниоров ?
Ну скорее всего да. Но думаю сейчас могут зайти некоторые, и не согласиться, с учётом того, что надо тратить время и тп) но при чем это тут?
Size: a a a
2020 July 24
AG
Ну, я бы посмотрел с радостью на всеобщее горение от вакансии для тестировщика, где в требованиях будет необходимость деплоить платформу из кучи всего на разные клауды силами кубернетеса , и это в каком нибудь стартапе где первый билд даже не задеплотися успешно. Зачем делить работу между людьми с разной специализацией , если можно нанять тестировщика, который будет знать все, и ещё баги в принципе пофиксит. Но да ладно. Ситуации разные, не спорю что наверняка этим и тестировщики занимаются
Конечно. Пусть тестировщик в кнопки тыкает, а если что - там и разработчики с девопсами разберутся.
AG
Поддерживаю.
В
А сложно ли научиться пользоваться Дженкинс и докером/кубером?
В
Может подскажете хорошие туториалы по этих инструментах
EB
Docker and Kubernetes: The Complete Guide на Udemy.
BI
Конечно. Пусть тестировщик в кнопки тыкает, а если что - там и разработчики с девопсами разберутся.
Ну, я слышал что разделение полномочий это рабочая схема, проще найти хорошего разработчика/хорошего девопса/хорошего тестировщика а не человека который будет знать сходу все это. Может на уровне синиора границы стираются, и синиор автоматизатор будет в принципе понимать все остальное , но все равно, есть ещё как минимум бюрократия в каком то плане. Зачем давать всем доступ во все возможные клауд консоли и в деплоер? Обычно вроде ограничивают такие вещи но хз. Все равно дивно. У тестировщика вроде своих дел хватать должно, всегда есть автоматизация в которой можно много чего делать
AG
Ну, я слышал что разделение полномочий это рабочая схема, проще найти хорошего разработчика/хорошего девопса/хорошего тестировщика а не человека который будет знать сходу все это. Может на уровне синиора границы стираются, и синиор автоматизатор будет в принципе понимать все остальное , но все равно, есть ещё как минимум бюрократия в каком то плане. Зачем давать всем доступ во все возможные клауд консоли и в деплоер? Обычно вроде ограничивают такие вещи но хз. Все равно дивно. У тестировщика вроде своих дел хватать должно, всегда есть автоматизация в которой можно много чего делать
Разделение обязанностей отлично работает на конвеере, где цепочка не самых квалифицированных людей делает свой кусочек работы строго по инструкции.
С чем-то более сложным это начинает работать плохо и медленно.
Тут приходит время вместо распределения обязанностей включать распределение зон ответственности, ну или primary и secondary доменные области.
Есть устойчивое мнение, например, что человек который умеет писать код (читай создавать программные продукты) при прочих равных будет значительно лучше руководить командой разработки, чем человек не имеющий такого опыта.
Это не значит, в общем-то, что его прямой обязанностью будет сидеть и писать этот самый код, хотя есть ситуации, когда это будет наилучшим из возможных решений.
С чем-то более сложным это начинает работать плохо и медленно.
Тут приходит время вместо распределения обязанностей включать распределение зон ответственности, ну или primary и secondary доменные области.
Есть устойчивое мнение, например, что человек который умеет писать код (читай создавать программные продукты) при прочих равных будет значительно лучше руководить командой разработки, чем человек не имеющий такого опыта.
Это не значит, в общем-то, что его прямой обязанностью будет сидеть и писать этот самый код, хотя есть ситуации, когда это будет наилучшим из возможных решений.
AG
Ну, с куаками примерно та же история. Человек, который понятия не имеет как вообще собирается продукт, который он тестирует, в ряде ситуаций будет делать это менее эффективно, чем тот, который понимает процесс сборки и деплоя.
МЁ
знать как это происходит в более или менее общих чертах - это одно. одной рукой девопсить другой куачить а третьей еще что-нибудь - это другое. хотя зависит от продукта конечно.
BI
Ну, с куаками примерно та же история. Человек, который понятия не имеет как вообще собирается продукт, который он тестирует, в ряде ситуаций будет делать это менее эффективно, чем тот, который понимает процесс сборки и деплоя.
Звучит здраво. В принципе всегда лучше знать много, чем мало, если это что то релевантное. Просто все на жаль знать невозможно, и тем более знать достаточно хорошо
AG
знать как это происходит в более или менее общих чертах - это одно. одной рукой девопсить другой куачить а третьей еще что-нибудь - это другое. хотя зависит от продукта конечно.
А что бы собрать самому продует в рамках существующей модели сборки, надо прям девопсить-девопсить?
АБ
знать как это происходит в более или менее общих чертах - это одно. одной рукой девопсить другой куачить а третьей еще что-нибудь - это другое. хотя зависит от продукта конечно.
Все-таки помимо классического "куаки тычут в кнопки" существует еще и вариант, когда qa делает еще кучу вещей. И непосредственно тестирование в этом может занимать вообще процентов 10-30. Что совершенно нормально для некоторых компаний, кстати, и ничего страшного в этом нет.
МЁ
моя мама была поначалу инженером, а потом в бурных 90х стала налоговиком. так вот знание всяких инженерных гостов ей не раз помогло в разборке криво слепленых фейковых документов
EB
знать как это происходит в более или менее общих чертах - это одно. одной рукой девопсить другой куачить а третьей еще что-нибудь - это другое. хотя зависит от продукта конечно.
Одной рукой девопсю, другой тестирую, третьей бороду чешу
АБ
А еще да, вовсе не обязательно, собирая билд и деплоя, считать себя чуточку девопсом :)
✨
А еще да, вовсе не обязательно, собирая билд и деплоя, считать себя чуточку девопсом :)
как это?!
✨
Одной рукой девопсю, другой тестирую, третьей бороду чешу
а в четвёртой смузи!
♪
А 5 ковыряться в 5 точке 😜😜😜
D
Если кто-то ещё думает в какую сферу пойти, то вот интересное видео на эту тему
https://www.instagram.com/p/CC6SiHpnBtv/?igshid=ilz3nq96vy3p
https://www.instagram.com/p/CC6SiHpnBtv/?igshid=ilz3nq96vy3p
