Тести пишуть люди | QA

Речі, про які я не думала, коли була junior, і які мене хвилюють зараз 🤓😂

1️⃣ Feature Toggle – або в народі під назвою Feature Flag. Наче проста і складна річ одночасно. Feature Toggle – це механізм, який дозволяє динамічно вмикати або вимикати певний функціонал без зміни коду чи нового деплою. Якщо Feature Toggle неправильно реалізований, він може ламати продакшн, навіть якщо код тестувався.
Тому важливо мати процес в команді, де кожен може легко побачити, які фічі зараз увімкнені. Враховувати це при написанні тест-плана і тестуванні. А також гарною практикою вважається при створенні тимчасових флагів – одразу заводити таску, наприклад, ЧЕРЕЗ реліз по видаленню цього флага.

Хто відповідає за видалення Feature Flags?
Зазвичай це Developers + Product Managers. QA зазвичай контролюють процес, тестують зміни, дають рекомендації.

Занадто багато Feature Flags = технічний борг, який важко виправити пізніше.

2️⃣ SLA
Термін, який є в багатьох сферах. Але в тестуванні має специфічний відтінок.
В деяких командах і компаніях про це взагалі не говорять, а в деяких компаніях SLA стоїть на рівні з KPI. Якщо у вас він є – бажано глибоко зрозуміти всі параметри.

Не буду зараз писати детально про нього, просто якщо не зустрічали – погугліть і подумайте, чи є у вас?

3️⃣ Мутаційне тестування
Досить складна і цікава штука. Часто компанії, які сильно вкладаються в автоматизацію, мають цей процес, і якщо в ньому розібратися – це дійсно мега цікаво і корисно.
Але складно.
Якщо у вас є час і можливість – попрактикуйтеся в цьому. Ви одразу по-іншому відчуєте автоматизацію.

Років 9 назад я не чула про таке тестування – і щоб ПЕРЕВІРИТИ АВТОТЕСТИ, ми ламали щось в базі (часто при цьому підході виникає проблема з кешем). Тому це все старі методи.
Зараз для перевірки автотестів є спеціальні інструменти.

Інструменти для мутаційного тестування:
🔹 Python: MutPy
🔹 Java: PIT
🔹 JavaScript: Stryker
🔹 C#/.NET: Stryker.NET

Коли варто використовувати мутаційне тестування?
✅ Коли тестове покриття високе (90%+), але ви не впевнені в ефективності тестів.
✅ Коли ви хочете покращити якість автоматизованих тестів.
✅ У критичних системах, де помилки можуть мати серйозні наслідки

➡️Test Result Trend
Вони відрізняються в різних системах test reports та можуть виглядати по-різному. Але суть одна - показати історію тестів: скільки тестів проходило, скільки падало тощо.
Це дуже проста й очевидна річ.

Говоримо зараз про CI, де тести запускаються в пайплайні.

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

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

Я спеціально взяла для прикладу тренд із падаючими тестами, бо мова НЕ про стабільність тестів, а про те, ЩО САМЕ ми запускаємо.
Якщо по тренду неможливо побачити якусь тенденцію, це означає, що пайплайн запускає РІЗНІ тести в кожному прогоні або має РІЗНІ налаштування і такий тренд втрачає сенс.
Адже ми змішуємо історію різних запусків.

Тренд має показувати, наприклад, що:
▪️Коли ми додаємо нові тести → їхня кількість зростає.
▪️Коли ми видаляємо тести → загальна кількість зменшується.
▪️Кількість тестів, що падає.
▪️Кількість тестів, яка стабільна.

Як уникнути проблем:
✔️Не запускати всі тести в одній job через параметри, що змінюють набір тестів.
✔️Розділяти тести по окремих не залежним пайплайнам для кожного test suite(якщо треба запускати окремо певний функціонал)
✔️Не змішувати запуск тестів з різних environments: наприклад, НЕ запускати тести одночасно для development і staging в одній job, оскільки вони матимуть скоріш за все різну історію.
✔️Відокремлювати регресійні прогони від запусків інженерів на своїх змінах.
Якщо в тренд потрапляють і звіти з регресії на master, і звіти з тестів, запущених вручну з певними змінами і налаштуваннями - тренд втрачає сенс.

➡️ Як лінкувати мануальні тести й авто-тести?

Це досить болюче питання, яке часто викликає купу обговорень і аргументів за і проти.

Коли є мануальний тест — на нього написаний авто-тест.

Наприклад, у Xray. Чи має мануальний тест бути прив’язаним один в один до автотестів?
А якщо мануальний тест великий і покритий декількома автотестами?
А якщо він параметризований?

Є багато-багато питань.

Часто чую думку, що «класно, коли всі тести прям 1-в-1 прилінковані, і код автотесту дублює кроки мануального тесту. Тоді ми впевнені, що автотести круто все покрили, і за потреби можемо запустити автотести на певний сьют. А якщо, наприклад, автотести зламалися з якоїсь причини — пройти тести вручну».

Я не дуже підтримую цей підхід.

Є багато-пребагато нюансів.

Просто хочу поділитися тим, як роблю я (коли маю на це дозвіл) і як «люблю».

1️⃣ Якщо автотест написаний, видаляти мануальний тест із регресії. Вимикати. Забувати про нього. Мати одне джерело правди — автотести. Якщо у вас класно налаштовані звіти й ви розумієте, що роблять тести, вам не потрібно мати те саме ще й із поміткою manual.

2️⃣ Якщо життя потребує лінкувати автотести з мануальними тестами — не прив’язувати їх 1-в-1. Не намагатися «натягнути» одне на інше, бо вони різні й мають різну структуру. Можливо, я не права, але з мого досвіду всюди, де починалося 1-в-1 лінкування мануальних і автотестів, закінчувалося це не на користь авто-тестів.

Неважливо, написано на один мануальний тест 10 автотестів чи 1 автотест.

Такий мій підхід. Поділіться, як у вас?

Всім гарних вихідних, гарних doc і швидких фіксів ❤️