Всё сильно зависит от специфики.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.
Даже в мобильных приложениях, где с принудительным обновлением клиентов всё относительно плохо, сейчас стараются делать всё, что бы можно было максимально гибко изменять поведение приложения не меняя клиент.
Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
Ещё раз. Как таковой DevOps ничего не убивает.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.
В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.
Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.
Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.
Во первых, обеспечение качества это не (только) тестирование. И тем более это не только ручное тестирование.
ДевОпс практики никак не ограничивают обеспечения качества, более того, правильно построенный процесс должен не только помогать бесконечно, быстро и прозрачно деливерить, но так же просто, быстро и безболезненно оценивать результаты релиза и, при малейшей необходимости, безболезненно откатываться.
Это то, что называется мониторингом и управлением качеством. QA инженеры неистово радуются такому.
Теперь по поводу ручного тестирования, его смерти и смещения в автоматизацию.
Первое: Автоматизация заменяет регрессионное ручное тестирование.
Это как раз те самые тесты, которые точно так же идут по заранее расписанным сценариям и точно так же, как и автотесты, пропускают всё, что ими не покрыто.
Это регулярно повторяемая, однообразная и не слишком интересная работа — то, что стоит автоматизировать всегда и при любой возможности.
Это освобождает ресурсы вашего отдела тестирования для исследовательского тестирования и тестирования методом свободного поиска. Как раз тех видов тестирования, где нужны интуиция, чувство прекрасного, здравый смысл и аналитические способности. Словом, всё то, что может человек, но не может скрипт написанный человеком.
Убивает ручное тестирование вовсе не ДевОпс, а потребности бизнеса и реалии рынка.
Ручное тестирование убивает скорость.
Сейчас даже у SPA для продажи носков такое количество ручек, состояний и внешних интеграций, что тестировать его руками — долго и неэффективно.
А делать кодфриз на неделю, что бы хорошенько всё оттестить не нужно примерно никому.
В то же время инженеры по тестированию — ограниченный, дорого и плохо масштабируемый ресурс.
Автотесты, в свою очередь, масштабируются очень просто и стоят относительно недорого.
Ну и скопом отвечу на ваши комментарии выше:
1) «Традиционный QA» отлично себя чувствует в полном CI\CD окружении. Потому что тестирование — один из этапов CI\CD.
Размазывание ответственности за качество на всю команду это то, за что будет неистово топить любой адекватный QA инженер. И этот тезис появился задолго до того, как девопс практики вошли в моду.
Может ли команда, следующая devops практикам существовать без QA Engineer как выделенной роли? Да, может.
Значит ли это, что там не будет QA, QC и тестирования как набора активностей? Нет, не значит.
Кажется у человека, на которого вы ссылаетесь, просто каша в голове из понятий.
2) Интеграционное и регрессионное тестирование — отлично поддается автоматизации. Это тривиальнейшая инженерная задача, которой за месяц обучается человек, раньше не писавший код вообще.
Это полтора прикладных инструмента, три паттерна и совершенно типовые архитектурные решения.
3) Код автотестов может содержать ошибки. Это так. Точно так же, как ошибками может обладать документация для тестирования.
Но тут есть одна ключевая разница: автотесты ведут себя одинаково всегда. Вы можете бесконечно расширять их набор, увеличивая покрытие, и их поведение не будет меняться от того, что вам понадобилось прогнать регрессионный набор тестов 12 раз подряд в ночь с пятницы на субботу.
Ручное тестирование всегда обладает человеческим фактором. В случае регрессионного и функционального тестирования — это огромный минус. Потому что глаз замыливается, внимательность может падать, а прогонять нон-стопом регрессионные тесты — это своего рода пытка.
Меняется ли тестирование и QA? Да, меняется.
Происходит ли это за счет популяризации девопс практик и инструментов? Да, в том числе.
Приводит ли это к смерти тестирования? Нет, не приводит. Это приводит к тому, что в тестировании начинают использовать код там, где код эффективнее, оставляя человеку те области, где он (пока что) выигрывает.
P.S. И да, я работаю QA инженером и прекрасно вижу, что происходит на QA-рынке.
Никакой смертью QA там и не пахнет. Зато действительно появляется всё больше компаний, которые понимают, что просто посадить 10 тестировщиков что бы они нон-стопом гоняли одни и те же тесты из релиза в релиз — недостаточно для обеспечения качества продукта.
Всё так, всё так. В целом, про велосипеды была отсылка именно к первой мантре разработчика.
Касательно Zen of Python, я бы сказал что в моей голове это тезис хорошо соотносится с Simplicity is better than Complicity, т.к. «не делать лишнюю работу и использовать готовые решения» — тоже часть упрощения твоего кода. Но в целом да, моё высказывание было не до конца корректным.
Я, конечно, понимаю, что говорю с переводом, но всё же.
Я не увидел в оригинальной статье посыл, что «NPM — зло, давайте забьем разработчиков камнями». Она (на мой скромный взгляд, опять же) про то, что инфраструктура разработки — это тоже вектор атаки на продукт.
И тут хочется отметить несколько моментов:
Первый — автор «ответа» явно передергивает, когда сводит всё к «Автор уговорил разработчиков внедрить свой вредоносный код». Это немного искажает суть: Злоумышленнику достаточно убедить внедрить этот код кому-либо из разработчиков внутри вашего dependency-tree, что бы после обновления зависимостей вы получили у себя в продукте вредоносный код.
Второй — Да, опенсорс строится на доверии. Да, каждый из нас может делать его лучше. Да, подтягивая зависимости мы берем ответственность за последствия.
Это всё очевидно и правильно. Это не отменяет того факта, что в моем домашнем проекте, который я быстро накидал за пару выходных как proof of concept, объем кода в dependency tree в несколько раз больше, чем, собственно, в самом проекте.
Ну, просто потому, что Zen of Python и первая мантра разработчика: не пиши велосипед, используй готовое решение.
И да, я понятия не имею, что происходит под капотом у зависимостей дальше первого уровня дерева (т.е. кроме тех, которые я подтянул сам).
И далеко не у всех команд разработки есть ресурсы (будь-то сила, время или компетенция) изучить полностью древо зависимостей на предмет уязвимостей.
Потому что помимо интерпрайза есть инди-разработчики. Потому что помимо умудренных опытом дримтимов есть ребята, которые делают свой проект на коленке, а потом данные пользователей их мобильного приложения утекают черти куда.
Заслуживают ли такие разработчики пинков коллег, общественного порицания и ночных багфиксов потом? Возможно.
Но их пользователи определенно не заслуживают того, что бы их данные куда-то сливали из-за неосмотрительности разработчика.
Итог:
Сгустил ли автор оригинальной статьи краски про то, как просто всё это осуществить, что бы более драматично обрисовать масштабы уязвимости? Да, определенно.
Действительно ли этой проблеме нужно столько внимания, что бы на её тему поднимать панику и драматизировать? На мой взгляд тоже да.
Затем, что контролем кода занимаются одни люди, а оформлением на себя дополнительной карты — совсем другие.
И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.
upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
Вы знаете, если оторваться на секунду от заоблачных зарплат в заказных постах, и посмотреть на общую картину, о которой говорится в посте: в IT все ещё относительно высокие зарплаты и безумный кадровый голод.
Последнее время приходится искать к себе в команду людей (как раз таки тестирование\QA).
На Питерском рынке все очень плохо. Катастрофически.
Джуниоры, которые приходят, ожидают, что идут в школу. Их надо плотно менторить, следить за каждым их шагом, указывать что и где почитать и чуть ли не домашнее задание выписывать.
Им не достаточно того, что бы им дали практическую задачу, неограниченное время её решение и проверили результат.
Да, многие из них говорят «Я готов работать хоть за еду». Но поймите, мне не нужно, что бы вы работали бесплатно. Мне нужно, что бы вы хотя бы старались учиться и работать самостоятельно. Не получается? Окей, вопросы приветствуются, помощь будет оказана.
Но сидеть и плевать в потолок потому, что ментор не накидал тебе задач и не проследил, что ты их делаешь, серьезно?
С миддлами и синьорами ситуация примерно аналогичная. Да, они уже научились решать типовые задачи по четко заданным инструкциям, но приносить пользу без постоянного менторинга — не могут.
Да, эти люди сидели, и писали автотесты. Да, эти люди тестировали сложные системы ПО и писали к ним горы документации.
При этом на простые вопросы «Почему сделал вот так, а не вот так» они не могут ответить.
Это даже не «Не знаю других решений», это «Зачем мне рассматривать варианты, если я уже нагуглил один ответ?».
И эти парни приходят на собеседования с зарплатными ожиданиями в 100+к, что является вполне хорошей зарплатой для СПБ, на мой взгляд. Для человека с 2-3 годами опыта в отрасли.
К чему я это все?
Да, в отрасль за последние 5-7 лет пришло довольно много людей (в том числе я, например).
Но, даже если закрыть глаза на то, что и сам рынок IT сильно вырос за это время, количество людей, которые хотят работать от этого увеличилось не сильно.
В IT довольно легко «войти», но надо понимать, что на этом вхождении всё не заканчивается.
Впереди ещё огромный путь, полный самообучения, сомнений в собственной компетенции (почти всегда обоснованных) и проблем, которые придется решать самому. Если человек к этому готов — он без проблем найдет работу и довольно стремительно начнет зарабатывать приличные деньги.
P.S. Рынок зарплат и медианные цифры — не сильно показательная картина, на самом деле.
Взять тех же QA инженеров. Я собеседовал довольно много людей, опыт которых при измерении в годах сильно превышает мой собственный. Первые несколько раз меня это безумно сильно беспокоило, типа: «Как так? У этого парня в два раза больше опыта, чем у меня, а я буду его собеседовать?!»
После десятка таких собеседований мне хотелось сойти с этой планеты, потому что люди с 9+ годами опыта даже не проверяли, компилируется ли код, который они высылают в тестовом задании (спойлер: нет, не компилируется). Те, которые проверяли — присылали код хуже, чем взятый мной на работу junior.
Как результат: многие из ребят, с которыми мне доводилось работать, сейчас получают суммы, находящиеся или на верхней границе, или выше Питерского QA рынка зарплат.
Многие из тех, с кем приходилось пересекаться работают Senior QA Engineer на зарплате миддла, и даже её, на мой взгляд, не особенно то заслуживают по уровню своей компетенции.
Давайте начнем издалека:
QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.
Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.
Ты должен уметь работать с данными: не только анализировать те данные, что есть, но и формировать пул требований по метрикам, логированию и аналитике, необходимой тебе для обеспечения качества продукта.
Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).
Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.
В конце концов, это большое количество soft-skills, потому что обеспечение качества продукта — это прежде всего про процессы и работу с людьми. Придется «продавать» свое видение решений членам команды и руководству. Придется «продавливать» использование нужных инструментов.
В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
Но это всё тема для холиваров.
Ну, эта часть пассажа касалась, преимущественно, не разработки. Согласен с вами, не сильно комфортно так сидеть.
Хотя знаю ребят из смежных областей, который при возможности распланировать свое рабочее пространство так, как им хочется — выбрали именно этот.
В любом случае, мне кажется, любая (пере-)планировка должна отвечать интересам команды и людей в ней.
Ну, перекрытия\перегородки тоже бывают разные. Я, например, считаю что возводить сплошняковые стены стоит только в крайней степени (они жрут много «воздуха», особенно с высокими потолками) при этом принося довольно мало пользы.
Зонировать и разделять пространство можно очень по разному и стены — не всегда оптимальный вариант.
(Естественно, не классический кубический вариант, да)
Ну и в любом случае то, как ты планируешь использовать пространство влияет и на выбор здания. Покупать ангар, что бы строить тонну стенок внутри — выглядит не самым идеальным планом, проще найти уже поделенное на кабинеты пространство.
Плюс «открытой» планировки в том, что её можно почти безболезненно адаптировать и перепланировать под себя.
Если у вас есть здание, построенное тремя сочлененными буквами Щ, то любая перепланировка и перераспределение пространства будет сталкиваться с этими ограничениями.
В то время как огромный ангар (на примере фейсбукового) можно зонировать и перепланировать как душе угодно.
Я, лично, являюсь сторонником «островной» планировке, где в большом открытом пространстве образуются отдельные хабы самостоятельных команд, которые при желании можно отделять от внешнего мира (в разумных пределах), обустраивать и планировать под себя.
Нужно много коммуникаций внутри команды — сажаете людей face-to-face за длинные линейки столов и радуетесь. Нужно больше концентрации — расставляете столы по периметру, оставляя в центре пространство для стендапов и прочих вещей.
В общем, если при планировании рассадки учитывать такие важные вещи, как потоки людей (что бы мимо тебя постоянно не слонялись туда-сюда) и наличие свободного пространства, то получается вполне себе хорошо.
Все это зонируется, разбавляется уместными чиллаут зонами и перегородками и получается вполне себе хорошо. При этом при необходимости эти «островки» цивилизации отлично перемешиваются между собой, двигаются или расширяются.
Ну и, конечно, разумная рабочая этика, намекающая что не надо включать свой рэпчик в блютус колонке на полную громкость или орать друг на друга на весь опенспейс.
При чересчур плотной рассадке опенспейс превращается в дикий курятник и некомфортно ни кому, но и кабинетная структура при наличии двух квадратных метров пространства на человека даст себе так себе результат (мне бы, например, не хотелось сидеть в «кабинете» размером с собачью будку).
В целом всё верно. Если все вышеперечисленное вызывает у вас неистовый баттхёрт попаболь — лучше сразу идти к двери, избавите компанию от неадекватного сотрудника.
Я не мешаю, я делаю выводы из написанного. Если бы там было написано «не холиварить за зря по технологиям» — вопросов было бы значительно меньше. Вы же написали «не спорь с руководителем, он умнее».
Но, даже в вопросах применяемых технологий аргументация на уровне «я начальник — мне виднее» это провал.
Тем более, что вы стремитесь, вроде как, набирать классных специалистов.
Если преимущества выбранного мудрым руководителем технического решения очевидны — компании выгоднее, что бы эти преимущества один раз были озвучены, разработчик осознал и получил +100 exp.
Если они не так очевидны, как хотелось бы руководителю всегда можно сказать «это тема для разговора, давай обсудим потом, сейчас дедлайн».
Подход же «начальнику виднее как делать» убивает в людях инициативу. И не особо важно, заключается ли инициатива в том, использовать промиси или нет, или же в какой цвет покрасить кнопку и где её расположить.
Важно, что «кому-то там виднее, как делать — буду делать так», вместо подумать головой, поговорить и понять, почему именно так.
Опять же, у меня не достаточно информации, что бы судить как оно там на самом деле. Я лишь отталкиваюсь от того, что написано в статье. Фидбэк и вот это всё.
На фоне нытья про овертаймы и низкие зарплаты меня больше всего смутило
Не спорь с начальником
как аргумент влияющий на продвижение по карьерной лестнице.
В то время, как во всем мире ищут разработчиков, готовых думать про продукт, а не просто решать спущенные сверху задачи, Яндекс говорит «не твоего ума дела, я начальник — ты дурак».
Классненько.
У вас очень странные выводы.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Уверенность в качестве это когда вы знаете, что API не ответит ошибкой при нормальном user flow.
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
Не очень понимаю, как связаны эти два тезиса.
Если сми очевидно врут — поводов верить им нет, даже когда это единственный источник информации.
Эта вся ситуация настолько шита белыми нитками, что прям ух.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.
Даже в мобильных приложениях, где с принудительным обновлением клиентов всё относительно плохо, сейчас стараются делать всё, что бы можно было максимально гибко изменять поведение приложения не меняя клиент.
Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.
В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.
Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.
Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.
ДевОпс практики никак не ограничивают обеспечения качества, более того, правильно построенный процесс должен не только помогать бесконечно, быстро и прозрачно деливерить, но так же просто, быстро и безболезненно оценивать результаты релиза и, при малейшей необходимости, безболезненно откатываться.
Это то, что называется мониторингом и управлением качеством. QA инженеры неистово радуются такому.
Теперь по поводу ручного тестирования, его смерти и смещения в автоматизацию.
Первое: Автоматизация заменяет регрессионное ручное тестирование.
Это как раз те самые тесты, которые точно так же идут по заранее расписанным сценариям и точно так же, как и автотесты, пропускают всё, что ими не покрыто.
Это регулярно повторяемая, однообразная и не слишком интересная работа — то, что стоит автоматизировать всегда и при любой возможности.
Это освобождает ресурсы вашего отдела тестирования для исследовательского тестирования и тестирования методом свободного поиска. Как раз тех видов тестирования, где нужны интуиция, чувство прекрасного, здравый смысл и аналитические способности. Словом, всё то, что может человек, но не может скрипт написанный человеком.
Убивает ручное тестирование вовсе не ДевОпс, а потребности бизнеса и реалии рынка.
Ручное тестирование убивает скорость.
Сейчас даже у SPA для продажи носков такое количество ручек, состояний и внешних интеграций, что тестировать его руками — долго и неэффективно.
А делать кодфриз на неделю, что бы хорошенько всё оттестить не нужно примерно никому.
В то же время инженеры по тестированию — ограниченный, дорого и плохо масштабируемый ресурс.
Автотесты, в свою очередь, масштабируются очень просто и стоят относительно недорого.
Ну и скопом отвечу на ваши комментарии выше:
1) «Традиционный QA» отлично себя чувствует в полном CI\CD окружении. Потому что тестирование — один из этапов CI\CD.
Размазывание ответственности за качество на всю команду это то, за что будет неистово топить любой адекватный QA инженер. И этот тезис появился задолго до того, как девопс практики вошли в моду.
Может ли команда, следующая devops практикам существовать без QA Engineer как выделенной роли? Да, может.
Значит ли это, что там не будет QA, QC и тестирования как набора активностей? Нет, не значит.
Кажется у человека, на которого вы ссылаетесь, просто каша в голове из понятий.
2) Интеграционное и регрессионное тестирование — отлично поддается автоматизации. Это тривиальнейшая инженерная задача, которой за месяц обучается человек, раньше не писавший код вообще.
Это полтора прикладных инструмента, три паттерна и совершенно типовые архитектурные решения.
3) Код автотестов может содержать ошибки. Это так. Точно так же, как ошибками может обладать документация для тестирования.
Но тут есть одна ключевая разница: автотесты ведут себя одинаково всегда. Вы можете бесконечно расширять их набор, увеличивая покрытие, и их поведение не будет меняться от того, что вам понадобилось прогнать регрессионный набор тестов 12 раз подряд в ночь с пятницы на субботу.
Ручное тестирование всегда обладает человеческим фактором. В случае регрессионного и функционального тестирования — это огромный минус. Потому что глаз замыливается, внимательность может падать, а прогонять нон-стопом регрессионные тесты — это своего рода пытка.
Меняется ли тестирование и QA? Да, меняется.
Происходит ли это за счет популяризации девопс практик и инструментов? Да, в том числе.
Приводит ли это к смерти тестирования? Нет, не приводит. Это приводит к тому, что в тестировании начинают использовать код там, где код эффективнее, оставляя человеку те области, где он (пока что) выигрывает.
P.S. И да, я работаю QA инженером и прекрасно вижу, что происходит на QA-рынке.
Никакой смертью QA там и не пахнет. Зато действительно появляется всё больше компаний, которые понимают, что просто посадить 10 тестировщиков что бы они нон-стопом гоняли одни и те же тесты из релиза в релиз — недостаточно для обеспечения качества продукта.
Касательно Zen of Python, я бы сказал что в моей голове это тезис хорошо соотносится с Simplicity is better than Complicity, т.к. «не делать лишнюю работу и использовать готовые решения» — тоже часть упрощения твоего кода. Но в целом да, моё высказывание было не до конца корректным.
Я не увидел в оригинальной статье посыл, что «NPM — зло, давайте забьем разработчиков камнями». Она (на мой скромный взгляд, опять же) про то, что инфраструктура разработки — это тоже вектор атаки на продукт.
И тут хочется отметить несколько моментов:
Первый — автор «ответа» явно передергивает, когда сводит всё к «Автор уговорил разработчиков внедрить свой вредоносный код». Это немного искажает суть: Злоумышленнику достаточно убедить внедрить этот код кому-либо из разработчиков внутри вашего dependency-tree, что бы после обновления зависимостей вы получили у себя в продукте вредоносный код.
Второй — Да, опенсорс строится на доверии. Да, каждый из нас может делать его лучше. Да, подтягивая зависимости мы берем ответственность за последствия.
Это всё очевидно и правильно. Это не отменяет того факта, что в моем домашнем проекте, который я быстро накидал за пару выходных как proof of concept, объем кода в dependency tree в несколько раз больше, чем, собственно, в самом проекте.
Ну, просто потому, что Zen of Python и первая мантра разработчика: не пиши велосипед, используй готовое решение.
И да, я понятия не имею, что происходит под капотом у зависимостей дальше первого уровня дерева (т.е. кроме тех, которые я подтянул сам).
И далеко не у всех команд разработки есть ресурсы (будь-то сила, время или компетенция) изучить полностью древо зависимостей на предмет уязвимостей.
Потому что помимо интерпрайза есть инди-разработчики. Потому что помимо умудренных опытом дримтимов есть ребята, которые делают свой проект на коленке, а потом данные пользователей их мобильного приложения утекают черти куда.
Заслуживают ли такие разработчики пинков коллег, общественного порицания и ночных багфиксов потом? Возможно.
Но их пользователи определенно не заслуживают того, что бы их данные куда-то сливали из-за неосмотрительности разработчика.
Итог:
Сгустил ли автор оригинальной статьи краски про то, как просто всё это осуществить, что бы более драматично обрисовать масштабы уязвимости? Да, определенно.
Действительно ли этой проблеме нужно столько внимания, что бы на её тему поднимать панику и драматизировать? На мой взгляд тоже да.
И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.
upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
Последнее время приходится искать к себе в команду людей (как раз таки тестирование\QA).
На Питерском рынке все очень плохо. Катастрофически.
Джуниоры, которые приходят, ожидают, что идут в школу. Их надо плотно менторить, следить за каждым их шагом, указывать что и где почитать и чуть ли не домашнее задание выписывать.
Им не достаточно того, что бы им дали практическую задачу, неограниченное время её решение и проверили результат.
Да, многие из них говорят «Я готов работать хоть за еду». Но поймите, мне не нужно, что бы вы работали бесплатно. Мне нужно, что бы вы хотя бы старались учиться и работать самостоятельно. Не получается? Окей, вопросы приветствуются, помощь будет оказана.
Но сидеть и плевать в потолок потому, что ментор не накидал тебе задач и не проследил, что ты их делаешь, серьезно?
С миддлами и синьорами ситуация примерно аналогичная. Да, они уже научились решать типовые задачи по четко заданным инструкциям, но приносить пользу без постоянного менторинга — не могут.
Да, эти люди сидели, и писали автотесты. Да, эти люди тестировали сложные системы ПО и писали к ним горы документации.
При этом на простые вопросы «Почему сделал вот так, а не вот так» они не могут ответить.
Это даже не «Не знаю других решений», это «Зачем мне рассматривать варианты, если я уже нагуглил один ответ?».
И эти парни приходят на собеседования с зарплатными ожиданиями в 100+к, что является вполне хорошей зарплатой для СПБ, на мой взгляд. Для человека с 2-3 годами опыта в отрасли.
К чему я это все?
Да, в отрасль за последние 5-7 лет пришло довольно много людей (в том числе я, например).
Но, даже если закрыть глаза на то, что и сам рынок IT сильно вырос за это время, количество людей, которые хотят работать от этого увеличилось не сильно.
В IT довольно легко «войти», но надо понимать, что на этом вхождении всё не заканчивается.
Впереди ещё огромный путь, полный самообучения, сомнений в собственной компетенции (почти всегда обоснованных) и проблем, которые придется решать самому. Если человек к этому готов — он без проблем найдет работу и довольно стремительно начнет зарабатывать приличные деньги.
P.S. Рынок зарплат и медианные цифры — не сильно показательная картина, на самом деле.
Взять тех же QA инженеров. Я собеседовал довольно много людей, опыт которых при измерении в годах сильно превышает мой собственный. Первые несколько раз меня это безумно сильно беспокоило, типа: «Как так? У этого парня в два раза больше опыта, чем у меня, а я буду его собеседовать?!»
После десятка таких собеседований мне хотелось сойти с этой планеты, потому что люди с 9+ годами опыта даже не проверяли, компилируется ли код, который они высылают в тестовом задании (спойлер: нет, не компилируется). Те, которые проверяли — присылали код хуже, чем взятый мной на работу junior.
Как результат: многие из ребят, с которыми мне доводилось работать, сейчас получают суммы, находящиеся или на верхней границе, или выше Питерского QA рынка зарплат.
Многие из тех, с кем приходилось пересекаться работают Senior QA Engineer на зарплате миддла, и даже её, на мой взгляд, не особенно то заслуживают по уровню своей компетенции.
QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.
Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.
Ты должен уметь работать с данными: не только анализировать те данные, что есть, но и формировать пул требований по метрикам, логированию и аналитике, необходимой тебе для обеспечения качества продукта.
Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).
Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.
В конце концов, это большое количество soft-skills, потому что обеспечение качества продукта — это прежде всего про процессы и работу с людьми. Придется «продавать» свое видение решений членам команды и руководству. Придется «продавливать» использование нужных инструментов.
В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
Но это всё тема для холиваров.
Хотя знаю ребят из смежных областей, который при возможности распланировать свое рабочее пространство так, как им хочется — выбрали именно этот.
В любом случае, мне кажется, любая (пере-)планировка должна отвечать интересам команды и людей в ней.
Зонировать и разделять пространство можно очень по разному и стены — не всегда оптимальный вариант.
(Естественно, не классический кубический вариант, да)
Ну и в любом случае то, как ты планируешь использовать пространство влияет и на выбор здания. Покупать ангар, что бы строить тонну стенок внутри — выглядит не самым идеальным планом, проще найти уже поделенное на кабинеты пространство.
Если у вас есть здание, построенное тремя сочлененными буквами Щ, то любая перепланировка и перераспределение пространства будет сталкиваться с этими ограничениями.
В то время как огромный ангар (на примере фейсбукового) можно зонировать и перепланировать как душе угодно.
Я, лично, являюсь сторонником «островной» планировке, где в большом открытом пространстве образуются отдельные хабы самостоятельных команд, которые при желании можно отделять от внешнего мира (в разумных пределах), обустраивать и планировать под себя.
Нужно много коммуникаций внутри команды — сажаете людей face-to-face за длинные линейки столов и радуетесь. Нужно больше концентрации — расставляете столы по периметру, оставляя в центре пространство для стендапов и прочих вещей.
В общем, если при планировании рассадки учитывать такие важные вещи, как потоки людей (что бы мимо тебя постоянно не слонялись туда-сюда) и наличие свободного пространства, то получается вполне себе хорошо.
Все это зонируется, разбавляется уместными чиллаут зонами и перегородками и получается вполне себе хорошо. При этом при необходимости эти «островки» цивилизации отлично перемешиваются между собой, двигаются или расширяются.
Ну и, конечно, разумная рабочая этика, намекающая что не надо включать свой рэпчик в блютус колонке на полную громкость или орать друг на друга на весь опенспейс.
При чересчур плотной рассадке опенспейс превращается в дикий курятник и некомфортно ни кому, но и кабинетная структура при наличии двух квадратных метров пространства на человека даст себе так себе результат (мне бы, например, не хотелось сидеть в «кабинете» размером с собачью будку).
баттхёртпопаболь — лучше сразу идти к двери, избавите компанию от неадекватного сотрудника.Ничего общего с действительностью, как обычно и бывает в гороскопах :)
Но, даже в вопросах применяемых технологий аргументация на уровне «я начальник — мне виднее» это провал.
Тем более, что вы стремитесь, вроде как, набирать классных специалистов.
Если преимущества выбранного мудрым руководителем технического решения очевидны — компании выгоднее, что бы эти преимущества один раз были озвучены, разработчик осознал и получил +100 exp.
Если они не так очевидны, как хотелось бы руководителю всегда можно сказать «это тема для разговора, давай обсудим потом, сейчас дедлайн».
Подход же «начальнику виднее как делать» убивает в людях инициативу. И не особо важно, заключается ли инициатива в том, использовать промиси или нет, или же в какой цвет покрасить кнопку и где её расположить.
Важно, что «кому-то там виднее, как делать — буду делать так», вместо подумать головой, поговорить и понять, почему именно так.
Опять же, у меня не достаточно информации, что бы судить как оно там на самом деле. Я лишь отталкиваюсь от того, что написано в статье. Фидбэк и вот это всё.
как аргумент влияющий на продвижение по карьерной лестнице.
В то время, как во всем мире ищут разработчиков, готовых думать про продукт, а не просто решать спущенные сверху задачи, Яндекс говорит «не твоего ума дела, я начальник — ты дурак».
Классненько.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Во всём нужен баланс.
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
Не очень понимаю, как связаны эти два тезиса.
Если сми очевидно врут — поводов верить им нет, даже когда это единственный источник информации.
Эта вся ситуация настолько шита белыми нитками, что прям ух.