По-моему, это проблема не людей, которые сидят головой в 6-7й джаве, а самой джавы, которая не может предложить фич, которые мотивировали б разрабов мигрировать. Люди не будут трогать то, что работает, ради пары минорных апгрейдов.

Не спорю.. Но почему-то людям эта надстройка приходится полезной)

Но если Java не сделает киллер фичи в течении двух-трех релизов, новый энтерпрайз рынок будет отдан .NET, как по мне..

(внимание, IMHO) Показательно то, что строго типизированнная адаптация языка, делает успех над слаботипизированным прародителем.. А еще говорят, что профессия программиста вымрет через 10 лет.. Ага, как же

Ну, мне кажется, тут больше обсудили еще то, что с этими деньгами делать и как их не просрать впустую, а не только как продать, если «у них есть деньги».
Если что, коммент не в стиле «извините, разрешите до*баться». Интересно узнать почему у вас всё свелось к

У них є гроші, вони готові щось покривати

imho, маловато смысла вы тут увидели)

Гетманцев також назвав унікальним спеціальний правовий режим для айтішників Дія City, завдяки якому, переконаний він, білоруські програмісти переїжджають в Україну.

Лукашеску: — Ну да, ну да, пошел я нахер

Что ж, советую тогда предлагать кандидату развернутый фидбек по тестовому за бутылку хенеси :))

Если кандидат отвечает что-то в духе

«ну, нам на курсах что-то рассказывали про git»

То это либо интерн, и тогда это должно быть ок, либо непонятно как этот человек вообще попал к вам на интервью ))

Ок, у всех разный опыт.. Из своего, даже учитывая ваши приведенные примеры, не могу представить себе ситуации, когда я бы отправил интервьюера в гитхаб смотреть как я что-то использую.. Скорее, просто расскажу и отвечу на возникающие вопросы. Если бы собеседовал я, то и тут мне бы дало больше понимания то, что человек расскажет как он бы сделал в данной ситуации и почему именно так, какие есть альтернативы. Код себе в репо можно и скопипастить, попросить кого-то за бутылку хенеси сделать тестовое, а ход мысли — нет :)

Про участие в опенсорс проекте спорить не буду — однозначно плюс в копилку, а вот выполнение тестовых — такая себе инициатива. Требовать тестовое у человека с опытом — вообще, считаю, моветон. Разве что оплачиваемое, и то если необходимо проверить ооочень важную для проекта узкую специализацию :)

Так и не увидел в статье аргументов почему нужно делать тестовое и заниматься наполнением своего гитхаба всяким мусором. Какой-то призрачный «бренд». А ну-ка назовите мне кто-то «известный бренд» в QA сфере, построенный на выполнении тестовых.

Скорее, автор сам еще и деконструирует свои доводы:

Я уже слышу взрыв негодования: «Почему я должен работать бесплатно??? Еще и в свое свободное время!!!1!»

Ответ в духе: потому что так надо.. Ну, ок.. Надо.. Зачем надо?

Я могу выучить техники тест-дизайна и принципы ООП, но значит ли это, что я умею их применять? Я могу заучить названия паттернов, но использую ли я их в своем проекте?

Так а на шо тогда интервьюеру язык с мозгами, если он не может задать уточняющий вопрос/сообразить задачку?

В итоге, автору просто нравится делать тестовые — ну пусть делает.. А объективно профитного отношения эффорт/резалт я лично не наблюдаю..

Я же написал, кажется. Потому что изначальный менее подробный комментарий меня обескуражил радикальностью утверждения «QA/QС не нужны». Сейчас я согласен, в большинстве вопросов взгляды у нас с вами сходятся.

Но, вы сами говорите

Отличие вижу в тактических подходах построения процесса software delivery, что само по себе сильно зависит от фазы развития организации, инженерного и бизнес-контекста. Типа заводить QC команду в engineering или покрывать этот аспект в рамках общего бизнеса.

А это уже отличается от изначального посыла в первом комментарии :)

В любом случае, разница лишь в том, что я больший приверженец выделения по возможности QC команды (именно команды или роли в команде, а не отдела), а вы — ее упразнения. Возможно, это следствие того, что я всю свою сознательную (и небольшую относительно вашей) карьеру провел в роли Software Test Engineer , а вы, судя по профилю на линкдин — в роли Software Engineer, и видим мы проблемы в первую очередь с точки зрения роли, в которой нам приходилось их решать, и личного опыта, который формировался возможно где-то в схожих, а возможно и в кардинально разных условиях. Но суть этого уже не столь важна. Я могу понять вашу позицию и тезисы о том, что

Выделенные тестеры (будь то внедренные в комманду или выделенные в отдельный отдел) становятся узким горлом как раз при росте сложности системы и интеграции частей ее, обычно становясь (невольно) препятствием к frequent delivery.

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

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

Что касается вышеупомянутой компании и этой статьи, я сомневаюсь, что они действительно глубоко продумывали реструктурирование. Сложилось впечатление, что тестеры у них были какой-то оторванной от общих процессов субстанцией, и им не нравилось, что тестеры дискаверили баги в тот момент, когда у всех остальных был запланирован офигенно удачный кастомер-колл и легкий непринужденный релиз. А тут тестыры со своими багами, уу собаки, убрать! Вот они не мудрствуя лукаво и пораспихивали остатки тестирования (качество которого и так было под большим вопросом) по разным промежуткам SDLC, да еще и статейку на ДОУ выкатили, какие молодцы, посмотрите!

Подчеркну, это всё исключительно моё ИМХО, разжевывание почвы которого потянуло бы на еще одну не менее объемную (и возможно не менее убогую) статейку на ДОУ, за сим что либо аргументировать по этому поводу я отказываюсь :D
Я ни разу не претендую на авторитетность своего мнения, я не СЕО, не СTO, не НЛО и даже не 23х-летний тимлид, чтобы рассказывать как кому проекты пилить. Может ребята реально сделали прорыв, и через пару лет я буду стачивать зубы скрипя челюстью от осознания своей некомпетентности, пока толпы айти менеджеров будут расхватывать бестселлеры Андрея и Татьяны под названием «Как тестировщики не давали нам жить», кто знает...

Просто сначала вы говорите про наличие «тестировщика» в команде и его негативное влияние, а потом говорите что тестирование проводить, все-таки, нужно, но его могут выполнять и девелоперы. Но вы упускаете из виду, что тестирование (не говоря уже о QC и QA активностях) не ограничивается тестированием кода (статическим анализом, юнит-тестами, интеграцией), которое могут и должны(!) проводить разработчики. Есть другие виды тестирования на других уровнях, кроме модульного, которые выполняются для достижения уймы совершенно различных целей. Тестирование — не просто поиск ошибок в коде, а опробация софта на предмет чего-либо/соответствия какому-либо поведению. Проводится оно не только для нахождения багов в коде, но и для проверки соответствия установленной бизнес-логике, работоспособности при стабильных и экстремальных нагрузках, интегрируемости в системы и взаимодействия с дургими системами/сторонними продуктами, проверки обратной совместимости, удобства использования. Если мы коснемся QC, то поймем, что часто кто-то, например менеджмент (если он грамотный), хочет быть в курсе состояния дел и иметь постоянно в своем распоряжении картину происходящего с продуктом (правильные ли у нас требования, правильно ли они интерпретированы разработчиками, какие фичи имплементированы, какие уже можно пускать в продакшен, какие нужно дорабатывать, какие проявили себя как нежизнеспособные, где у нас слабые места и уязвимости или где они могут возникнуть, я уже не говорю о сборе всевозможных метрик...), ну в общем, мониторить.
Не будет тут черного и белого, типа тестировщики — это плохо, СДЕТ — панацея. Всё зависит от ваших целей. Понятно, что если у вас маленький проект или стартап, то у вас будут одни приоритеты, и вы примените одну стратегию/методологию, в которой у вас смогут выполнять минимально необходимое тестирование опытные разработчики. Но, если у вас сложный (что называют complicated) продукт с уймой зависимостей, интеграций, над которым работают несколько команд, время которых на вес золота — вы будете распоряжаться ресурсами иначе, и возможно, наймете целый отдел контроля качества. Цель у вас что там, что там всегда будет одна — максимально экономить деньги (ведь QA, QC, Test Engineering — это всё про методы экономии денег, и все несогласные — либо тупые, либо врут), принцип будет один и тот же: превенция неисправностей/ошибок, а так же максимально быстрая их локализация и устранение, методы достижения будут разные и зависят исключительно от способности грамотно распорядиться ресурсами.

На европейских конференциях по тестированию сквозной темой последних лет являются «shift left» и «QA specialist as a coach, not a tester»

Что касается «shift left», эта стратегия вообще не про отказ от тестировщиков, а про смещение фазы тестирования в начало SDLC и распараллеливание с дизайном и разработкой. «QA specialist as a coach, not a tester» — тоже не про отказ от тестировщиков как класса, а про разделение ролей QA и test engineer. QA — это вообще не должность. Это процесс.

Как раз 80% средней медианы QA-няни вредны.

Вредны они только тем, кто возлагает на них часть ответственности за СВОЮ работу или надеятся, что кто-то за них что-то проверит. QA — это когда все отвечают за качество: и разработчики, и тестировщики, и менеджмент.
На примере статьи скажу, что ребята вроде оптимизировали процессы и все заработало лучше, но исходя из того, что я увидел, у них все еще не хватает целого пласта проверок. Если они считают что им это и не нужно — ок, но не нужно сразу писать статью на ДОУ, претендуя на изобретение панацеи.

Я не спец по трендам, особенно в США, но звучит логично. Т.к. QA — это подход, процесс (если художественно сказать — культура). Это не должность, это процесс, который сторится людьми на разных позициях (разработчики, менеджеры, аналитики, тестировщики и т.д.). Если мы говорим о позициях QC и Test инженеров, то я бы назвал это не отказом от QA, а переквалификацией. Область обеспечения и контроля качества так же развивается как и разработка, появляются новые инструменты и методологии, требующие бОльших технических навыков. Цель остается та же, роли те же, меняется инструмент и название.

Кажется, вы вообще не понимаете что такое и зачем нужно тестирование, и чем оно отличается от QC и QA.

Кто-нибудь, скажите этим людям, что QA — это не определенная позиция, а роль, а они у себя внедрили SDET, хотя им нужно было Continuous Testing & TestOps (ну, ребята сами пишут что проблемы были с релизами и продом). Я понимаю, конечно, что комментить постики — не процессы оптимизировать, но тут явно нарушены причинно-следственные связи. Роль QA у вас осталась, это раз. Упразднили онли ручное тестирование — это двас. И, на сколько я понимаю, у вас не было нормального тест анализа и дизайна и с присутствием «КУА команды», исходя из фразы

«И один из трюков, которые мы используем, — тест-кейсы продумываются еще на этапе написания дизайн-документа для проекта.»

. Потому как это вовсе не «трюк», а основа(!) грамотного тест-дизайна. Как говорится, это классика, это знать надо! Короче, улучшения качества вы добились (и то, это еще выяснить надо, потому как качество — это не только кол-во найденых и пофикшеных багов) сугубо за счет реорганизации дев процессов и внедрения QA культуры и QC инструментов в разработку, но никак не за счет отказа от выделенных QC инженеров (тут я решаю назвать это грамотно, наконец). Так же интересно как отнеслись разработчики к той новости, что им теперь еще нужно заниматься тест-дизайном. Не верю я в понятие «человек-мультитул», да еще и без доплаты лол.
Резюмируя вышесказанное, уверен, что если добавить к проделанным изменениям грамотную QC тиму (пусть даже это будет всего пара человек), которая будет качественно пилить тест-дизайн и планирование, а так же выполнять необходимые виды тестирования на всех необходимых уровнях (сомневаюсь, что для продукта достаточно юнит и аксептанс тестов) и, все-таки, будет индикатором готовности продукта для выхода в прод (а это главное, Карл!), то как минимум разработка пойдет быстрее, а как максимум у менеджмента будет полная раскладка по состоянию продукта в целом, состоянию фич, состоянию спринта и т.д.