Дякую за ваш фідбек, інтерес до статті та цікаві запитання!

1. Яка кількість QA в загальному, що дозволяє робити такі зміни майже не помітно для просідання будь-яких метрик під час такого повного розвороту в системі?

Кількість розробників та QA весь час варіюється, тому точних чисел і не можу сказати відповідно. Проте практично завжди ми маємо співвідношення 1 до 3 на користь розробників.

Також варто сказати, що запорукою успіху такого розвороту системи стала не кількість QA, а ретельно здійснена підготовка до впровадження такого процесу.

2. Чи користуєтесь мануальною регресією, чи все під автотестами?

Ні, не користуємося взагалі. Все під unit/integration/autotests. Звісно все автоматизувати неможливо як і неможливо все протестувати вручну. Зміни, що несуть певні задачі мають всій радіус впливу на систему, розробник підкреслює QA команді їх. Ось ці зони впливу ми можеме протестувати вручну (свого роду локальна регресія), але в більшості випадків це покрито уже автотестами.

3. Чи усі в команді пишуть автотести, чи є окрема команда під це?

Кожен робить це на своєму місці згідно піраміди тестування. Розробники пишуть unit/integration тести. QA пишуть E2E (можна назвати їх UI тести або автотести). Коли я тільки прийшов в компанію, то було 2 QA інжера (я став третім). Писав тести тільки один із них. Моя ціль була, щоб кожен в моїй команді володів ± однаковою експертизою та навиками. Зараз тести пишуть у моїй команді всі (хтось швидше, хтось повільніше, але всі)

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

Коли я читаю «існують такі фічі, на котрі хочеться накатати по 20 тест кейсів», то сприймаю це як існує певна бізнес логіка, яку потрібно протестувати. Питання в тому як? На нього я завжди отримую відповідь із піраміди тестування.

Згідно піраміди тестування чи можемо ми собі дозволити покрити одну (хай навіть велику) фічу середнього по палаті і розміру продукту 20 автотестами? Ні, не можемо, тому що бізнес логіка тестується на рівні unit тестів (вони швидкі, стабільні, їх можна писати багато, саме тому вони знизу в основі піраміди). Кількість наших автотестів ми стараємося тримати на рівні десятків, а не сотень чи тисяч. Нашими автотестами ми тестуємо основні USER FLOW.

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

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

Новий функціонал ми тестуємо уже по Traceability Matrix (в якійсь мірі це наші «хлібні крихти», якщо нам потрібно звернутися до деталей).

Декілька слів ще про 80 автотестів. Ми закладуємо в них прицип Парето. За 20% зусиль досягти 80% результату. Одни тест покриває основний сценарій (наприклад, це 60%), ще 1-2 тести покривають основні розгалуження (це ще +20%). Корнер цейси в основному покриті на рівні unit тестів.

І останнє, ми оперуємо таким поняттям як Error Budget — ризики, які ми готові прийняти як допустимі для оптимального балансу витрачених сил та отриманого результату.

-------
Я впевнений, що не відповів на усі ваші питання і думки, то ж готовий продовжити дискусію) Перепрошую також за довгу відповідь

¯\_(ツ)_/¯

Якщо сприймати QA не лише як робітника, що «тестує» тікети, а діє в повну силу своїх Quality Assurance процесів, то так, важко не погодитися.
Можливо ще також тому, що робота девів лежить на поверхні — ось код, ось продукт, пощупайте. То робота QA може бути не видною в моментів, а лише на довгій дистанції, яку важче оцінювати. (no offence розробники)

Дякую! Відповім на ваші запитання. Якщо не на все відповім нижче, то задавайте уточнюючі запитання)

як Вам вдалось 80 е2е «змістити» в менш як 4 хвилини.

Завдяки наступним речам:
— повністю незалежні тести один від одного (так звана відсутність звʼязності)
— реалізація горизонтального масштабування. Раннер типу Kubernetes Executor із можливістю підняти стільки под, скільки потрібно. Плюс кожна джоба запускається на оптимально підібраній машині (8 cpu відповідає 4 потокам тестів, по Playwright документації на один поток тестів виділяти 2 cpu. Практичні заміри показали аналогічні результати)ʼ
— використання тестових ендпойнтів, які роблять складну бізнес логіку і забирають необхідність довгий юзер флоу покривати від початку до кінця по декілька разів. Проте кожна частина юзер флоу покривається справжніми сценаріями. Вплив на тривалість тестів колосальна
— кардинальне підвищення стабільності тестів, тобто мінімальна кількість ретраїв
— використання кешу на ранері для зменшення тривалості білду солюшину (виграли 10-15 секунд на кожен раннер)
— «перекладування» публічних докер імеджів у свої докер регістрі. Виграли пару секунд на швидкість завантаження імеджа на раннер + виграли у стабільності (були випадки недоступності публічного регістрі і використання квот на завантаження)

Тривалість тестів можемо звести в середньому до 90-120 секунд, якщо використаємо х2 раннерів (тобто 8 замість 4х). Але все одно упремося в 90 секунд (30 сек на накладні витрати на раннері, 60 секунд — тривалість найдовшого тесту, який уже не можна поділити). Поки економічно недоцільно, якщо не скажуть «запускати на всі гроші».

А також які критерії для QA no.

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

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

Критерії попадання роадмапної задачі під QA no (наведу тільки основні):
— або ± все те ж, що і для бекложної задачі
— або задачу неможливо протестувати в моменті. Наприклад, в епіку 20 задач, зробили 1шу задачу по підготовці архітектури на беку (накидали базові класи, єнами і т.п.). Testing Status = Safe. Задача зазвичай буде покрита в рамках комплексного тестування по Traceability Matrix.
— або задачу недоцільно тестувати в моменті в повну силу. Але тут важливо зауважити, що смоук тестування для кожної задачі (чи із беклогу, чи із роадмапу) ніхто не відміняв і це є обовʼязковою вимогою до кожного розробника. Плюс є набір різних тестів, що нас страхують. Testing Status = Safe (інколи Passed). Задача зазвичай буде покрита в рамках комплексного тестування по Traceability Matrix

Щиро дякую за твій фідбек та інтерес до статті!
Спробую відповісти на непрості питання :)

1. Скільки часу потрібно, щоб навчити/заонбордити колег новому процесу вразі необхідності використання нових інструментів і в разі використання тих самих інструментів (якщо такий досвід був)?

Все залежить від системи координат, в якій ми знаходимося. Я не проводив точних замірів, відпишу на основі внутрішніх субʼєктивних метрик і спостережень, а також на основі розуміння твого запитання. Попробую розглянути декілька випадків:
1) Новий процесс + на основі нового інструменту (аналогів в компанії немає) + одна власна команда.
1-6 тижнів на провадження і коригування. Перед цим, звісно, ініціатор невизначену кількість часу проводить дослідження і описання самого процесу перед його безпосереднім впровадженням (пишу саме від момену анонсу нового процесу). Тут небагато людей, всі на відстані одного «рукостискання», проблем мінімум.
2) Новий процесс + на основі нового інструменту (аналогів в компанії немає) + декілька команд (децентралізація).
2-4 місяці на провадження і коригування. Тут набагато складніше. Окрім власного пропрацювання процесу, тобі потрібно погодити новий процес на рівні менеджерів (отримати їх фідбеки, внести коррективи, отримати підпис). Процес узгодження і раундів обговорення може бути досить тривалим. Потім після погодження і анонсу, тобі потрібно як в керлінгу протрекати динаміку впровадження процесу. Потім лише злегка коригувати (бажано на основі метрик, саме тому в статті я робив на них акцент)
3) Новий процесс + на основі нового інструменту (аналоги Є в компанії) + декілька команд (децентралізація).
2-5 місяців на провадження і коригування. Все те ж саме, що описано в пункті 2), але при наявності старіших/інших інструментів, що виконують ± схожу функцію, то виникає проблема «викорінення» старих інструментів і заміну на нові. Людський мозок опирається змінам і йому звичніші речі, до яких він звик.
4) Новий процесс + на основі існуючого інструменту + декілька команд (децентралізація).
1-3 місяці на провадження і коригування. Все ж цей варіант є дешевшим, ніж 2). Якщо влаштовує арсенал існуючого інструменту та просто потрібно поправити/впровадити процес, то у нас немає накладних витрат на освоєння/покупку/початкове адміністрування інструменту.

Мої ключові думки тут:
— чим більший/вищий поріг входу в інструмент, тим важче впроваджувати процеси на його основі. Якщо складна навігація, 100500 вкладеностей, хаос із доступами, то ховайся. Наприклад, саме тому я обрав Google Sheets замість інших наворочених систем
— чим більша група обговорення, тим важче прийняти рішення і добитися консенсусу. Розбивай людей на невеликі робочі групи, давай їм розкритися і «бути почутими» і прогрівай їх.
— підготовка — це наше все. Чим краща підготовка, тим легше буде провдигати процес. Схемка, візуалізація значно допомагають. Текст не працює.
— у процесу повинен бути спостерігач/овнер. Вільне плавання не діє на ранніх етапах, потрібно «доливати» масла у вогонь

2. Скільки часу витрачається на те, щоб моніторити правильність виконання і корегувати після впровадження такого процесу?

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

P.S. Відповідаю після опівночі, сподіваюся, що думки не переплутав))

Дякую за хороше запитання!
Як офіційні присідання під кожен хай/хаєст баг — ні. В той же час у нас є ретро по фічі (в основному для проблемних), де ми піднімаємо такі питання і дивимося, що і чому пішло не так.
Для інцидентів ведемо постмортеми, де також на це можемо звертати увагу.

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

Розглядали X-Ray, хороша альтернатива, дякую за згадку) Проте простота і доступність використання мене підкупає в Google Sheets все ж більше

До речі, рішення під IOS ми також зробили. Знайти все можна в репозиторії github.com/...​r8-toolkit/PMetriumNative

Працював із Олександром, гідна людина. Слава Герою!

Випадково натрапив на статтю, прочитав! Дякую за думки)

У PMetrium Native v2.0 я саме підготую реалізацію автоматизації для збору метрик без необхідності запуску XCode, там не буде застосовано os-signpost (принаймні поки що), але підходи мають бути зрозумілі

Так, не надто великий арсенал API для такої роботи. Проте на IOS уже є подібний, описаний вами API, на основі «os-signpost»