Є багато хороших книг по тестуванні : Канер, Маєрс, Паттон. Автори мають світове визнання, на них посилаються всі ті хто пишуть про тестінг чи займаються ним. Савін аж ніяк не може бути «основою основ»

Сейчас, когда на рынке труда переизбыток начинающих тестировщиков, приоритет дают самым сертифицированным

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

Основа основ: книга «Тестирование dot com» Романа Савина.

Гіршої поради не придумали ?

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

Але у обох випадках — якщо немає розуміння проблеми, гугл так собі допоможе.

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

недавно на співбесіді, у кандидата на лиці було видно, що гугл відкриває ) у темній кімнаті, біла сторінка дуже палиться

Раз на день на півгодинки можна вже заставити себе і труси одягнути

для чого ? у мене камера ловить лише вехню частину. тут головне, футболка. Хоча можна і вище підняти, то і те, що у костюмі Адама ніхто не побачить

от 80 до 100 тыс. тестов

це все UI тести ?

а як розгортаєте це все ? є якийсь infrastructure-as-a-code ?

ви описали, те що отримали в кінці.
Але мені цікавить власне, що передувало цьому — якісь проблеми були у простішій зв’язці ?
і скільки тестів та як часто запускаєте ?

ну власне, те що я описав — все у одному кластері.

он поднимает под эту задачу отдельный слейв в качестве кубернетес pod

і тести запускаються з цього слейва ?

і напевно основне питання : нафіга то все ? яку проблему воно вам вирішує ?

Тобто, у вас є кубер, у якому є дженкіс. Дженкіс запускає Moon, який також є у цьому ж кубері. Moon запускає браузер у цьому ж кластері ? правильно я все зрозумів

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

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 девелоперів ?