+

Бачився з цією компанією ще в далекому 2018 році. Вони ще й блокчейн до усього намагались прикрутити. А точніше проводили ICO в той час, випускали свій токен і здається таким чином зібрали перший капітал. А як і переважна кількість компаній, які тоді застрибували в блокчейн, на довгострокову, чисту роботу вони схоже не дуже розраховували. Це моя персональна думка

Думаю, можна було б змінити назву статті на «Чому у 2023 вже не круто обирати Selenium як основний фреймоврк для автоматизації UI. Тестуємо з Plywright». І клікбейтно :) і більше передає суть.

Так як перестати боятись? :) Я думав, що прочитаю якісь рекомендації по написанню перших тестів, найочевидніших сценаріїв, або приклади як же виглядає продакшн-тест.

То й шо, звичайний понеділок у Києві :)

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

Аналітичні стратегії тестування — це фундамент. Оті самі black box техніки, це звідси. Тож так, аналітичної роботи у тестувальників вистачає.

Оооо, як би ж то тест виконувався один раз, чи хоча б 10 раз, чи хоча був написаний один раз. А щоб клієнти і перевіряли продукти під час acceptance тестуваннч. Хех, ото б був дивний новий світ!

А на звільнений час можна прийти додому ... І зробити якусь DIY-хрінь, або полуницю на балконі виростити, або раком півдня на дачі провести. Прогрес! :)

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

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

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

Там впливає ще попит і пропозиція. Тестувальників потрібно значно менше ніж розробників.

Щодо мануальних макак, то це точно узагальнення. Статистично це довести не вийде

А є ще комплаєнс, безпека, перформанс. Ті кейси може і вузькі, але можуть дорого коштувати. Он Google тільки у Франції виплатив у минулому році 57 млн. євро за порушення GDPR. Ризики теж розробники будуть прораховувати?

Тільки замість «бажання» я би поставив вимоги до розробки, що здебільшого переводиться в час та гроші.

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

Так звичайно, девів у нас тут як собак нерізаних, хоча б з 5 роками досвіду

Хех, Діма, ви прям матьорий аналітик. Той, що ніколи не скаже в одному реченні ЩО і КОЛИ відбудеться. «Що» обмалювали, а от «коли» — вирішуємо кожен для себе.

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

Давайте рівнятися на кращих, саме в компаніях з західними цінностями людям набагато комфортніше працювати

Це що за комплекси меншовартості? І як це фото в резюме призводить вас до висновку про західні цінності, які краще ніж українські? В Україні треба рівнятись на український менталітет, клієнта, ринок. Не на американський. От якщо мені доведеться наймати американців, працюючи у Гуглі десь у Пало-Альто, то звичайно, буду орієнтуватись на місцеві стандарти і рекомендації.

дискримінація по будь яким ознакам ( в тому числі по знанням з рибалки чи кінематографу

та яка ж тут дискримінація? :) Тут тема для розмови і можливість задати творчі питання при чому на комфортному для кандидата полі.
От дивіться:

— які види тестування провалили перші версії матриці?

На мою думку, сфейлились usability або performance (soak чи resilience) тести. Чому я дійшов такого висновку.
Usability — система була спроектована і розроблена як заплановано. При чому людям було заготовлене щасливе життя, повне насолод. Проблема полягала в тому, що люди не захотіли такого продукту, і страждання були необхідною невід’ємною частиною. Поведінка клієнта не була очевидною для машин, що і стало причиною change request на більшу кількість імперфектності.
Performance (soak або resilience) — можливо були прототипи і вони показували гарні результати. Але не була перевірена робота системи на довгому відрізку часу. І машини не побачили, що у людей накоплюється роздратованість ідеальним життям. Або вони тестували на малій вибірці і не побачили проблем, які виникнуть на великій вибірці данних.
І тут є декілька моментів. По-перше правильної відповіді не існує. По-друге, я вам продемонстрував свої скіли thinking out of the box, problem-solving та stress resistance. По-третє, я відсік стандартні теоретичні питання, відповідь на які можна просто завчити (і на які ви точно вже завчили, якщо це не перше ваше технічне інтервю). Якщо ви вступите зі мною в полеміку — тим краще, я побачу як ви відстоюєте свої ідеї, як ви їх врешті-решт узгодите з іншою людиною. Це все — прототипи реальних кейсів, які вам зустрінуться в команді і в роботі.
А всю ту рутину накшталт вибору селекторів можна легко запихнути у тести або тестове завдання. Навіщо на банальну базу витрачати час менеджера?