Реліз без драм і травм: як QA не згоріти до чортиків

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

За кілька років у тестуванні я бачила дуже різні сценарії: від повної відсутності регресії і хаотичних деплоїв у бізнес-години — до нічних релізів після ретельної перевірки.

Часто саме на плечі бідного QA лягає відповідальність за успішність релізу (ми таке засуджуєм!), і тут потрібно бути послідовним і не вестись на маніпуляції.

Я — Віталіна, Middle QA в компанії Sombra. Хочу поділитись порадами, як пройти реліз і не згоріти до чортиків.

1. Створюємо regression suite заздалегідь.

Не «коли буде час десь перед релізом». (його не буде ніколи)

Ще на етапі написання тест кейсів — можна позначати певні тести тегом @regression. Це вже зекономить багато часу.

2. Визначаємо, що саме будемо тестувати.

На жаль, чи на щастя, протестувати геть усе не вийде — на це просто не буде ресурсів. То як визначити межі?

• чудово, коли є автотести інтегровані в СІ (нікому не кажіть, бо будуть заздрити)
• дуже корисна річ — impact analyses з командою.

✨impact analysis✨- це буквально гідазепам для всієї команди, а для QA тим паче. Ви сідаєте й оцінюєте усі зміни, які робились для поточного релізу, щоб розуміти, що і якою мірою зазнало втручань, які можуть бути ризики і чому варто приділити особливу увагу.

3. Готуємо стабільне середовище для регресії.

Важливо мати окремий pre-prod, максимально наближений до продакшну — так буде менше сюрпризів.

4. Закладайте час на exploratory testing.

🔎 Настав час увійти в роль Шерлока, який використовує свою тестувальницьку дедукцію — шукаємо баги на основі принципів логіки й досвіду.

На цьому етапі корисно звернутись до основ й згадати один з принципів тестування: кластеризацію дефектів, або в народі — принцип Парето: 80% багів можна знайти в 20% модулів.

Це все добре, скажете ви, але ... Що коли ви бачите, що не встигаєте ніяк?

👉Оцінюємо ситуацію:

• ми не встигаємо, бо....гортали меми? ➡️ cорі гайз, викручуйтесь як можете, беріть тестуйте хоча б критичні сценарії й найслабші місця в системі.
• але якщо ви не встигаєте, бо в ході регресії знаходили нові баги, більше часу знадобилось на слабкі місця чи ще є якісь обʼєктивні причини ➡️ переодягаємось в адвоката своїх юзерів і аргументуємо необхідність перенесення релізу, повідомляємо про ризики, говоримо про бізнес і гроші.

⛔Коли точно НЕ варто релізитись:

• критичні баги не пофікшені/не протестовані;
• зміни в конфігах, і ніхто не може чітко сказати, на що це впливає — досліджуємо!
• появились баги невідомого походження й вимагають часу на інвестігейт
• з`явилась інформація про зміни в third party, які ще не перевірені;
• в бізнес години і в пʼятницю — хіба ви любите екстрим.

Головне для QA під час регресії чи будь-якої іншої активності в рамках SDLC — не мовчати. Недостатньо знань про те, які модулі зазнали змін — кажи. Бачиш ризики, про які ніхто не казав, — кажи. Щось не дає спокою — кажи. Потрібна допомога — кажи.

Діліться своїми порадами й думками щодо регресії перед релізом.

Бажаю всім спокійних релізів і менше тривоги 🤍