в самые трудные времена за борт галеры выкидывают не нужных, а приближенные остаются.

— а чего вы собственно ожидали, что не нужных будут оставлять, а приближенных выкидывать?

Есть другие виды тестирования на других уровнях, кроме модульного, которые выполняются для достижения уймы совершенно различных целей. Тестирование — не просто поиск ошибок в коде, а опробация софта на предмет чего-либо/соответствия какому-либо поведению.

Полностью согласен. Тестирование в частности, и качество продукта в общем — это широкий спектр задач, который не должен (и не может) быть ответственностью тестировщиков или выделенных отделов качества (как бы мы их не называли).

Если мы коснемся QC, то поймем, что часто кто-то, например менеджмент (если он грамотный), хочет быть в курсе состояния дел и иметь постоянно в своем распоряжении картину происходящего с продуктом (...), ну в общем, мониторить.

Ну да. Где это противоречит статье или моему комментарию? Другой вопрос — как это мониторить, и тут отделы качества не всегда помогают т.к. часто излишне сфокусированы на узком определении этого качества через колличество багов обнаруженных / пропущенных. По крайней мере в моем опыте.

Понятно, что если у вас маленький проект или стартап, то у вас будут одни приоритеты, и вы примените одну стратегию/методологию, в которой у вас смогут выполнять минимально необходимое тестирование опытные разработчики. Но, если у вас сложный (что называют complicated) продукт с уймой зависимостей, интеграций, над которым работают несколько команд, время которых на вес золота — вы будете распоряжаться ресурсами иначе, и возможно, наймете целый отдел контроля качества

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

Цель у вас что там, что там всегда будет одна — максимально экономить деньги

В продуктовой компании, каковой насколько я понимаю является описанная people.ai, экономия денег не является целью. Преждевременное зачисление собственно разработки продукта в затраты — классическая ошибка.

ведь QA, QC, Test Engineering — это всё про методы экономии денег

в подходящем контексте — да, но не всегда. Это как дизайн — совсем без дизайна плохо, но можно и переинженерить.

все несогласные — либо тупые, либо врут

с таким сильным аргументом не поспоришь🙂

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

100%. Только вредны они ВСЕМ, а не только тем разработчикам которые привыкли пробрасывать таски «тестеры разберутся — на то они у нас и есть». И собственно убрать тестировщиков или отдел QA (потому что разрабы все равно прочитают как «отдел тестирования») — это наиболее эффективный метод эту ответственность вырасти. По аналогии с ездой на велосипеде — пока с трехколесного на двухколесный не пересядешь — держать равновесие толком не научишься.

«Убрать», кстати — не значит уволить. Тестировщики обычно владеют большим пластом доменного знания, просто увольнять их глупо. Дать другую роль и обязаности. Как и в обсуждаемом случае, насколько я понимаю, произошло.

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

Откуда это видно, что у них не хватает этих проверок? Вполне возможно, эти проверки есть — но не классифицируются как «software testing/QA» — вижу такое в продуктовых компаниях, когда большая часть тестирования/мониторинга происходит как органическая часть bizops/devops.

Если они считают что им это и не нужно — ок, но не нужно сразу писать статью на ДОУ, претендуя на изобретение панацеи.

Ну, не нужно так к ним жестко. Где они претендовали на панацею? Почему не нужно писать статью? Где бы мы это обсуждение проводили, где твои комменты так понравились «Sergey Setti Laravel ninja»?

Возращаясь к своему вопросу, не вижу из твоего ответа почему я не понимаю для чего нужно тестирование. Скорее, по основным вопросам у нас точки зрения совпадают:
— тестирование это намного шире, чем просто нахождение багов в коде
— тестирование в частности и качество в общем — это общая ответственность и не должна быть головняком только отдельно назначенных индивидуумов.

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

Обоснуй. Почему кажется? Потому что считаю что тестирование могут проводить не специально для этого отведенные люди?

Из сложностей — у нас до сих пор есть проблема с тем, чтобы была стабильная среда для интеграционного тестирования.

Полноценная тестовая интегрированая среда может быть недостижима в общем случае с ростом объема и сложности системы.

Перестать тестировать функционал на тестовых средах не думали? Все тестирование либо в изоляции (CI, local dev workstation) либо на продакшине с фича-тоглами и прочими канари-релизами.

mgurov.github.io/...​n-production/#related-art — пара мотивирующих ссылок.

Хорошая статья, и тема жизненная. Согласен на 100% что, к сожалению, наличие тестировщика в команде часто негативно влияет на качество или на скорость выпуска продукта, а чаще — на оба показателя.

Очень занимательно читать стройный хор «да как так можно, точно загубите все, как же дорогих девелоперов на тестирования тратить!» в комментариях. Даже Чернобыль, вижу, приплели.

На европейских конференциях по тестированию сквозной темой последних лет являются «shift left» и «QA specialist as a coach, not a tester»- т.е. сам факт того, что тестирование по-старому не работает уже принят коммьюнити, и опыт многочисленных продуктовых компаний показывает что высокое качество без тестировщиков-привратников (gatekeeping) вполне достижимо.

В корне не согласен с комментаторами о том, что практика «разработчики сами тестируют» работает только с уровнем выпускников MIT из силиконовой долины. Как раз 80% средней медианы QA-няни вредны. Джунам — тем тестеры да, нужны, ибо не ведают что творят. Высококлассным специалистам лишняя пара глаз не мешает — могут и с и без.

Поэтому предлагаю Александру Борнякову поговорить со мной и ответить на вопросы.

— начнем с начала. Зачему ему это?

Потому что при прочих равных с сертификатом можно до разговора дать чуточку более высокий приоритет

По НЛ — на одном английском — комфортно жизни не будет. Имеется ввиду стратегически.

100%. И тут «все говорят по-английски», особенно в обозначенных городах, становится немалым таким препятствием для овладения Голландским.

Купить жилье — врядли реально.

опыт многочисленных моих знакомых понаехав (даже в Астердаме) показывает обратное. Впрочем, сейчас рынок не самый лучший.

Отношение к украинцам, такое же как и ко всем с восточной Европы — строители, собиратели клубники. Не оч уважают славиков, но терпимо.

Не прочувствовал. В бизнес среде к Восточно-европейцам, кстати, в целом весьма позитивное отношение. Программисты, в частности, котируются, не смотря на хронический lack of soft skills.

Все ждут выборов в марте.

Ну тут вроде особых неожиданностей не предвидится. Хотя и в победу Трампа мало кто верил — так что посмотрим, конечно.

Не все так радужно в прекрасном королевстве.

 ну то везде свои тараканы.

да ладно вам к мелочам уж придираться

Навіть, не знаю як на це реагувати.

позитивно, само собой. Знает и понимает свои слабые еще места.

Не всегда БД — это лучшее место для решения вопросов производительности.

Есть для этого уже операторов...

операторов / не операторов — они в принципе плохо скейлятся если ACID.

То что очередь сообщений и ES внедрили — не гарантирует консистентность и отсутствие побочки.

Что такое ES ? Если нормально очередь сообщений внедрили (консистентная публикация — через те же strongly consistent исходящие таблицы в реляционной базе), и дедупликацию на принимающей стороне от at least once сделали — откуда и какие побочки вылезут?

В современных СУБД обычно просто strong eventual consistency с two-stage commits просто из-за требований ACID’а...

Я так понимаю, мы про реляционные ACID СУБД тут говорим? Что-то не представляю как это в таком контексте «strong eventual consistency с two-stage commits» может быть ? ACID вроде как strong immediate consistency гарантирует (при правильном уровне изоляции транзакции). two-stage commits — это тот который распределенные транзакции обещал? Жутко медленный и гарантированно не работающий?

В распределённых системах, с кучей зависимых сервисов, консистентностью обычно просто жертвуют под соответствующими притворными предлогами... until shit hits the fan...

Какой консистентностью кто жертвует? Или ты предлагаешь сложные системы полностью сильно-консистентно строить?

Потому «шило на мыло»: упростили БД — усложнили операционку, проигнорировали риски...

Ну как-бы базы похуже скейлятся. Так что может и усложнили, но риски этим уменьшили.

Ну часто всплывал вопрос «может ли DBA полезть в сишку и написать EXTENTION что бы потом в CREATE AGGREGATE можно было»... в мускуле плагины не настолько гибкие, а у Oracle работает только то что предусмотрено функционалом СУБД. Потому решает чаще гибкость и безопасностью чем непосредственно удобство.

Я что-то запутался. Где правда? Что пользовать?

online/incremental materialized views, пока есть только патч на incremental
• кроме ZHeap не хватает хранилищ на LSM-tree с Commitlog’ом для хранения денормализированных представлений (пока обходимся FDW в Scylla)
• было бы очень хорошо так же иметь какой-то официальный SPDK-enabled storе
• банально не хватает нормального дашборда (типа pgDash) и встроенного профилятора — что бы не нужно было лезть в pg_flame / plprofiler / sr_plan и прочее, когда неправильно срабатывает встроенный планировщик (на кривых схемах — часто)

Понял. Ну да, с точки администрирования Оракулы всякие и Мускулы для DBA поприятнее будет. Но там и цены на лицензии становятся астрономическими при серьезном росте. С точки зрения разработки, большинство этих проблем сносно решается на уровня приложения, IMHO. Ничего критического.

Стоимость долгосрочной эксплутации и поддержки таких БД слишком дорога и может стать причиной большего количества проблем при росте продукта...

по секрету скажу — при серьезном росте нужно будет что-то менять по любому. Мне вот пять лет назад пришлось срочно мигрировать базу с Оракла на постгрес из-за роста ;)

Ждать по 5-7 сек запроса к 8-10Тб базе это не хорошо — такие решения сложно называть жизнеспособными. А держать какое-то DynamoDB и платить по 40-50$ за транзакцию на запись «потому что DBA не нужны» и «вообще всё в облаках» — довольно наивно.

Ну еще вопрос, что дешевле — наивно платить в облака, или толковому DBA запрлату. Терабайтные таблички это никак не типичный случай, и вполне вероятно — архитектурная проблема скорее, чем базы.

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

Базы данных важны. Важнее зачастую кода. Но это не значит они должны быть переусложненны до того, когда это реально нужно.

В целом, входной барьер для тестирования таки ниже, чем программирования — ситуация ассиметрична.

Программист может сам протестировать примерно с тем же качеством, что тестировщик может сам написать.

В смысле, проверить то, что работает не только на машине разработчика, но и на проде?

В целом, входной барьер для тестирования таки ниже, чем программирования — ситуация ассиметрична.

Другое дело, что система, и особенно постановка тестирования ее может быть сложной, но это в 80% случаев проблема процесса.

Зачем тогда QA вообще нужны ?

ну не для того, чтобы за девелоперами подтирать и проверять что на проде тоже работает. Exploratory testing, сложные случаи, организация процесса. И не всегда они нужны, в зависимости от рисков и сложности системы. Зачастую даже вредны.

Просто цирк «а зачем нормализировать схему до 4-5ой нормальной формы ?» имеет место быть почти везде.

То есть по твоему мнению, всегда и везде нужно нормализовать схему до 4-5ой нормальной формы ? Такого даже в рассвет нормализации не было принято — консенсус тогда был, что 3й обычно достаточно. А особым мастерством была выборочная денормализация.