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

Крута робота!
Але здається запізно почали автоматизувати)
Наступного разу раджу відразу йти по шляху автоматизації перевірок, швидше регресія буде проходити
Я працював колись на tickets.ua і автоматизував ~60 локалей по базовому функціоналу, переходи з мета пошуківців (десь 10) на ті самі сайти, кожен продукт сайту на 5 локалях та в основну регресію (приблизно 100 тестів після pairwise)
В мене нічого б не вийшло якщо б я не навчив інших інженерів автоматизації. Щоб вони самі вели автоматизацію своїх продуктів
До автоматизації тестування займало десь 3 тижні, після автоматизації 2 дні, а потім я пішов) оскільки далі компанія в процесах не хотіла розвиватись

Ціна на заняття відкрита, тобто ви самі обираєте скільки вам буде коштувати заняття :)

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

А я і не казав, що юніт/інтеграційні тести тільки я пишу, здебільшого я їх рев’юваю та раджу, що ще можна додати по перевірках.
Юніт та інтеграційні пишуть розробники ±98%, результам їх виконання ±98% часу приділяють розробники, я тільки іноді втручаюсь та їх відповідно всі знаю і краще розумію на якому рівні, що я маю та можу покривати

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

це що таке? ти шо, гіт то космос, всі на зіпах сидимо і на дискєтах

p.s. запитання не валідне для треда

А чому відходити? Чому б теорію не вносити в реальний світ?
Звісно якщо тобі не дають код розробників бо тестери та автоматчікі сидять в окремій кімнаті, окремого департамнету, окремої компанії, країни, світу, реальності то так. Тому погоджуюсь, що не вийде приносити нормально профіту
Але якщо дійсно привнести в команду «теоретичні» підходи та практики — то щось з цього може вийти
Атвічаю, я спробував і мені зайшло! Назад в іну реальність повертатись не хо!

Всі отримані кошти йдуть на благодійність :)
Також є можливість прийняти участь без благодійного внеску, але звісно краще з ;)

Захід о 19:15 :)

0_o што?)) Де пруф?) баланс рахунку не змінився)

якщо що, то він відмінений

шикардосіна

якщо що, то є сторінка заходу в фб ще
www.facebook.com/events/2788996337815019

Зарепостив на мою сторінку QA Club Lviv)

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

Тільки там посилання на телеграм канал бите)
Якщо шо: t.me/qa_club_lviv

Ууууух о то накатала!

Ну це ІМХО
Оскільки нажаль в автоматизації перевірок за допомогою жс, слід досить часто вказувати авейт, ібо ЖС асінхроний — а перевірки мають бути «синхроними» (мають мати чітку послідовність кроків)

Супер :)
Просто в статті є тільки одна непряма згадка про це)
Тому зауважив цей підхід до вибору
Ну і хочу ще наступне зауважити: що відповідний підхід зручно використовувати ще й для бекенд тестування :)