Конфігураційне тестування: як покривати складні комбінації і мінімізувати ризики

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

Коли я вперше стикнулася з конфігураційним тестуванням, була просто приголомшена. Наш продукт — веб і мобільний додаток, який використовують в різних країнах, на різних платформах і браузерах, з різними ролями та привілеями. Уявіть: Windows, Linux, MacOS, iOS, Android; Chrome, Safari, Edge, Firefox, MI, WebView; плюс локалізація більше ніж на 15 мов; ще й категорії користувачів з різними правами та інтерфейсом.

Я почала рахувати всі можливі комбінації через Classification Tree, і вийшло понад 20 тисяч варіантів 😳

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

Чому конфігураційне тестування важливе

Уявіть ситуацію: користувач з Європи заходить на сайт через MacOS Safari, обирає українську мову. Якщо ця комбінація не покрита тестами, кнопки можуть не поміщатися, текст може обрізатися, флоу для ролі працює не так, як задумано, або навіть підпорядковані правила країни блокують дію.

Тому тестування має охоплювати:

• Платформи та браузери: різне ядро та підтримка функцій.
• Локалізацію: різна довжина текстів, формат дат і чисел, переклади.
• Категорії користувачів: різний інтерфейс, різні флоу, обмеження по країнах.

Classification Tree: що це таке і як допомагає у конфігураційному тестуванні

Якщо ви раніше не стикалися з терміном Classification Tree, ось просте пояснення: це метод систематизації всіх можливих комбінацій параметрів продукту, щоб зрозуміти, що потрібно тестувати.

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

Приклад структури для нашого продукту:

Кожен клас має свої варіанти, і Classification Tree допомагає нам «перемножити» всі можливі комбінації, щоб побачити повну картину тестування. Так ми розуміємо, скільки у нас реально кейсів.

Наприклад, коли я робила свій перший аналіз, у мене вийшло понад 20 тисяч можливих комбінацій. Звісно, частина з них неможлива: MI браузер не використовується на десктопі, деякі ролі доступні лише в мобільній версії, а деякі мови не підтримуються на всіх платформах.

Навіщо це робити:

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

Пріоритезація конфігурацій

Щоб тестування було ефективним, я використовую два підходи:

1. Аналіз статистики користувачів
   Було отримано дані про активність: скільки людей використовують продукт на конкретних платформах, браузерах, мовах і ролях. Це дозволило виділити критичні комбінації для пріоритетного тестування.
2. Аналіз ризиків і дефектів
   Було проведено аналіз багів та звернень у саппорт. Де найчастіше виникають проблеми? Ці комбінації теж потрапили у топ для тестування.

Завдяки такому підходу, навіть тестуючи лише топ-10 комбінацій, ми покриваємо більшість користувачів і мінімізуємо ризики для бізнесу.

Планування конфігураційного тестування на етапі STLC

Щоб ефективно покрити критичні конфігурації для продукту, тестування потрібно планувати якомога раніше. Основні активності:

• Визначення обсягу тестування: які платформи (Windows, Linux, MacOS, iOS, Android), браузери (Chrome, Safari, Edge, Firefox, MI тощо), та інші параметри критично важливі для користувачів продукту.
• Аналіз ризиків: пріоритезація конфігурацій на основі історії дефектів, зворотного зв’язку від підтримки та популярності серед користувачів.
• Врахування локалізацій та ролей користувачів: перевірка роботи продукту у різних мовних версіях та для різних категорій користувачів з урахуванням їхніх специфічних інтерфейсів та прав доступу.
• Планування ресурсів та часу: визначення, хто і на яких середовищах тестуватиме продукт, та скільки часу потрібно для покриття конфігурацій.
• Узгодження критеріїв завершення: визначення, які конфігурації мають бути покритими.

Такий підхід дозволяє зменшити ризики та ефективно використати ресурси QA, забезпечуючи надійну роботу продукту для більшості користувачів. Також shift-left approach економить кошти бізнесу завдяки залученню тестувальників на етапі планування.

Як почати конфігураційне тестування у вашому продукті: покроковий план

1. Зберіть інформацію про користувачів і продукт
   Платформи, браузери, мови, ролі, популярність серед користувачів.
2. Визначте класи еквівалентності
   Складіть таблицю Classification Tree для всіх параметрів.
3. Відсійте неможливі або малоймовірні комбінації
   Наприклад, MI браузер на десктопі, певні ролі на мобільних версіях.
4. Пріоритезуйте конфігурації
   За частотою використання, ризиком дефектів і бізнес-важливістю.
5. Плануйте ресурси та час
   Хто тестує, на яких середовищах і скільки часу потрібно.
6. Регулярно переглядайте та оновлюйте
   Нові функції або зміни у продукті можуть вимагати додаткових комбінацій.

Результати тестування

У кінцевому результаті ми отримуємо:

• Набір пріоритетних комбінацій для тестування, що охоплює більшість користувачів.
• Зменшення ризику дефектів у проді, які могли б вплинути на користувачів або бізнес.
• Зручну методику для наступних релізів: нові функції тестуються одразу на критичних конфігураціях.

Наприклад, для сценарію авторизації ми можемо тестувати топ-10 комбінацій браузер+платформа+мова+роль користувача. Це забезпечує покриття основної частини користувачів і зменшує бізнес-ризики

Висновки

Конфігураційне тестування — це ключ до стабільного продукту:

• Воно дозволяє QA ефективно розподіляти ресурси.
• Покриває найважливіші комбінації платформ, браузерів, локалізацій та ролей.
• Зменшує бізнес-ризики та кількість дефектів у продакшн.

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

Звісно, набір комбінацій може бути будь-який, залежно від вашого продукту. Проте підхід data-driven лишається незамінним помічником у цій непростій справі.