но это лишает удобства и занимает больше времени

xunitpatterns.com/...​nditional Test Logic.html

Тести потрібні для того, щоб легше підтримувати та розвивати ваш продукт.
Спочатку ви фігачете швидко і воно працює. За тиждень розробляєте половину продукту. А пізніше ваш темп падає. Потрібно писати нові костилі, підпирати існуюючий код, баги лізуть зі всіх дір і час на розробку росте. І у вас вже не стильний та модний молодіжний стартап, а legacy яке було би добре переписати
Тести, можуть вам зменшити подібну біль

это один из признаков развития общества

розділення праці != розділення обов’язків. Ви ніяк не можете мене зрозуміти.
У певних сценаріях, задля ефективного процесу, роботу можна розділяти. Але у певних сценаріях можна і не розділяти. Наприклад, коли проект маленький. Або той рівень якості який забезпечує команда без тестувальника, задовольняє замовника чи клієнтів. І це ок.

І для того, щоб трошки подумати www.youtube.com/watch?v=qd9N9eU1Qn0

тестировщиков достаточно и у Гугла, и у Майкрософта

вони то там є, але у великій меншості і також займаються девелопментом. За якісь та тестування там відповідають розробники
testing.googleblog.com/...​ts-software-part-two.html
Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Тобто, тест інженери також є девелоперами

заменить QA инженера девелопер не может

а чому тоді у лідерів ринку (Google, Microsoft) практично немає тестувальників ?

Это специалисты разного профиля

ось в цьому і проблема. Ми починаємо розділяти обов’язки між людьми, створюємо ролі і тд і тп. І у нас виходять учасники проекту які не знають як працюють їхні колеги. І у нас виходить команда, де кожен знає лише свою маленьку пісочницю і нічого не знає про проект в цілому. І це проблема

читал и о ровно противоположных по смыслу

Ви бачите процес з чітко розподіленими ролями і відповідальностями. Десь як у 90-тих, там воно працювало бо середовище таке було.У сучасному швидкому світі все йде до спільних відповідальностях та розмитих ролях — DevOps, FullStack development і тд і тп. І все тому, що потрібно швидше і швидше роботи delivery. Практики 90-тих вже не працюють
Якщо дев не розуміє як тестувати — результат його роботи буде важко тестувати, або і взагалі неможливо. Йому пофіг як хтось буде виконувати тестування, він свою роботу зробив. Якщо дев повинен ще і тестувати свою роботу — йому доведеться зробити її так, щоб можна було тестувати.

та ок. але хороший девелопмент опирається на тестування. І будь який хороший девелопер займається тестування, на тому чи іншому рівні. Хтось пише юніт тести, а хтось e2e тести. Це все тестування. Багато девів також перевіряють свої зміни ручками.
Тому, не завжди потрібна окрема людина для тестування

Это не ок, поймёте это позже)

багато команд можуть працювати без окремих тестувальників без проблем
Та і взагалі за цим майбутнє — continues testing, shift-left testing і тд це тенденції які не хочуть бачити окрему людину, яка тестує, а пропонують тестувати всі команді, на всіх рівнях

unit testing\TDD — це не mindset девелоперів ?

Не могут

чому ?

ви не знаєте як працює конкретна команда, якщо вони можуть самі забезпечити собі тестування, без окремої людини, то це дуже правильний напрямок руху.

Это не ок

не ок одразу оцінювати. ви не знаєте контексту та який проект, не знаєте цілей
Якщо розробники норм тестують, тех дебт та рівень дефектів їх не тормозить — не бачу потреби їх навантажувати ще і додатковим тестувальником

воно обов’язково наєбнеться в наступному кварталі

власне, ось ці всі тести допомагають відтермінувати наступний квартал

потрібно це обговорювати. Якщо, замовник погоджується з цим, ну то він буде платити пізніше більше.

бувають різні ситуації і різні люди. Буває по вашому, але і є багато зацікавлених у якості проектів. Такі речі завжди можна обговорювати та шукати рішення чи компроміс.

трохи не зрозумів, до якого саме твору йде відсилка ? і якої цитати ?

1) не з автоматизаторів зробити мануальщиків, а залучати до командних активностей типу планування і тому подібне. Не раз стикався з тим, що автомейшини живуть дуже окремо, у своєму власному світі
2) взагалі, оцей поділ на мануальщиків та автомейшинів шлях в нікуди. Тестувальник повинен вміти і потестити руками, і написати код. Нажаль, так не є, але варто йти цим шляхом.
3) дуже підтримую розширення відповідальностей. Дев має не лише написати код, він повинен вміти і тестувати. Тестувальник також, має вміти не лише тестувати

100% покриття коду не гарантує те, що все покрито. Рядки коду то покриті, а чи всі вхідні дані ?
Для кінцевих користувачів без різниці скільки і які у вас тести. Тому, краще зосередитись на основних та критичних бізнес сценаріях

аби дешевше вийшло

поясніть йому, якщо сьогодні «дешевше», то через півроку ціна на багфікс та новий функіонал буде рости експоненціально.
Тести вони ж не для галочки, тести дають впевненість, що ваші зміни нічого не ламають. Їхня користь проявляється не одразу, а пізніше.
Якщо замовник має довготермінові плани на продукт — без тестів ніяк. І також, якщо замовнику цікаві часті релізи — без тестів ніяк. Ну можна, але доведеться платити за овертайми, хотфікси на прод, бо у юзера щось поламалось і простенький функціонал будуть робити не день, а тиждень, бо ніхто не знає як воно працює і скільки потрібно перетестувати

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

я проганяв всі тести по 3 рази

оо. хотів запропонувати це. а в таблицях середній результат за всі прогони ? чи якоїсь однієї ?

від реалізації http клієнту та багатопоточності

скоріш за все. + можливо, ще метрики по різнову оцінюються. Я колись копав у доках Jmeter, то там Response time рахується від надсилання першого пакету tcp, до отримання першого пакету. Можливо інші тули це по іншому рахують

круто ! дуже крута стаття ! Сам давно цим цікавлюсь і думав над подібним проектом.
Дуже дивно побачити такі відхилення по RPS та response time. Цікаво би знайти корінь проблеми і як зрозуміти, що ці дані корелюються з реальними метриками кінцевих користувачів.
Моя думка, що це може бути проблема з NAS або мережею. Було би круто задеплоїти кудись в клауди і спробувати там