Дякую Ром, що зашерив інфу.
Так, якщо прикинути, то хороший, базовий сетап збирається на 5-6к легко (ну для мене базовий) :D

Мені здається недоречним порівняння застосунків різного типу.
Якщо вже почали з TestRail, то потім порівнюйте із застосунками того ж типу.
Так-то у вас у порівнянні 3 из 5 застосунків — це розширення до Jira :D

Як писав нижче Роман, то булоб непогано подивитися на testomat.io (Українська ТМС), testmo, testiny.

Давайте хоч тут Джиру не чіпати :D

А далі питання, чи будуть рахувати це в продуктових компаніях? Зазвичай не будуть рахувати, бо в очевидь, якщо продукт не має кінцевої дати життя, то автоматизація буде мати сенс.
І тут скоріше ми можемо зіштовхнутися з іншими обмеженнями:
1. кваліфікація команди.
2. моливість зміщувати фокус.
3. інфраструктурні, архітектурні проблеми.
4. і тд.

ну це те, про що я писав, ага :)

Дякую Олексій, за підняття цієї теми. І звичайно ком’юніті, яке так бурхливо на це реагує, бо є дійсно що обговорити. І це схоже на те, як ми з Романом робили естімейти по тестуванню діалогового віконця в Телеграмі :D

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

Мені здається, що не розглянуті деякі речі щодо того, які бенефіти буде мати компанія від автоматизації.
Окрім просто скоротити регресію (так собі мета насправді). Ми можемо додатково отримати покращення ТТМ (time to market), скоротити витрати на багфікс (бо ми ж то знаємо скільки буде коштувати виправлення багу на більш піздніх етапах). Тобто загально я б тут все таки дивився в сторону бізнесових бінефітів напевно.

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

А відповідно до темплейту, інколи деякі бібліотеки приходиться докручувати. Ми трішки доробляли ліби для пайтона (точно request), щоб легше було дебажити, при помилках. І ще робили власні ліби.
Нажаль я не технічна людина, тому тут деталей на скажу :(

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

я думаю, це слушна думка для аутсорс компаній мати фреймворки під стеки проектів, які вона бере. При хорошому knowledge-sharing в компанії можна швидко відпрацьовувати best-practice.
І це стосується не тільки тестування, та автоматизації, а ще і розробки. Бо якщо одразу ми думаємо про розробку+автоматизацію, можемо закладати певні патерни одразу.

То було півтори роки тому, до початку лей офів.

Так, наче правильно написано.
А в чому питання, я тільки не розумію? :)

Ну якщо брати, власні думки то так. Різниця є між посадами і навіть можна їх обгрунтувати.

Зараз, вакансії, які я бачу виглядають так «Test Lead/Manager», «QA Test Lead/Manager», або наприклад «QA Manager» де в описі вакансії перший пункт: «Lead the QA across the Engineering and Growth departments, align QAs on the strategy, vision and drive the QA to focus on the company’s and department’s OKRs.»

З точки зору ринку це майже завжди якийсь мікс.

Я зараз на посаді QA Manager в одній компанії, але в задачі входить не тільки менеджмент тестування та аналіз всяких метрик і тд. Моя задача лідити, в тому числі.

В деяких компаніях, з якими я спілкувався ця посада має більш операційне значення (я тут про QA Management).

Дякую за запитання.
Мої останні дослідження вакансій та спілкування показують, що в цілому набір задач і зон відповідальностей майже одинаковий (тут зазвичай треба питати винаймаючих менеджерів і тд, що вони мають на увазі).
Яб сказав, що це більше стаття для QA Lead позиції.

Влучно дуже!
Дякую Петро!

В цілому так )

дякую! :)

дякую! :)

Якось пропустив твою статтю :D
Дякую, можливо колись я до цього дійду :D

Найм — це загальна проблема індустрії :)
Не вміють знаходити людей собі в команду/компанію.

Тебе просто не беруть до уваги, якщо бачать що немає досвіду (навіть з гарним резюме).
І так, це проблема культури найму яка зараз є на ринку праці :)

Хороша стаття від Алана.
Все написано по ділу і те як зараз трансформується робота в ІТ.
Не знаю про шо сперечатись, тим паче він приводить аргументи як в одну так і іншу сторону. 🤷‍♂️