🤓 Сьогодні про те, як обрати рівень абстрагування автотестів, розповідає Артур Шевченко, ех-Director of Engineering, Systems Architect та тренер курсу ISTQB Advanced Test Automation Engineer 2.0.Під час проєктування TAA треба вирішити, скільки абстракції робити на кожному шарі і чи "потягнемо" ми ту додаткову складність у довгостроковій перспективі. По суті, варто чесно відповісти собі на три питання:🔸Навіщо нам ця абстракція?🔸Що поганого вона може принести (витрати, ризики, бюрократія)?🔸Який реальний профіт ми можемо отримати?І тільки якщо видно, що профіт перекриває витрати на впровадження, навчання команди й підтримку, має сенс її реально будувати.Прикладом абстракції може бути використання "любімого" Cucumberʼа для "людських" тестових сценаріїв, або використання патерну Стратегія для асьоршенів, або введення додаткового фасаду для інкапусляції дій користувача, переходячи майже до keyword driven підходу. Абстрагування може бути різним. Але загалом ідея наступна: ми хочемо, щоб тести були більш універсальними, зрозумілішими та писались швидше.Чи є плюси в абстракції? Звісно:✅ Тестові сценарії стають більш читабельними і менше прив’язаними до конкретного інструменту чи технології.✅ Якщо змінюється логіка тесту або інтерфейси SUT, це має менше ламати і вимагати менше підтримки.✅ Нові тести можна робити швидше (наче), бо є шаблонний підхід.✅ Аналіз дефектів може бути простіший, адже замість технічних деталей є єдина людська мова, яка описує поведінку.✅ На рівні інтеграцій можна підключати різні тулзи, не чіпаючи самі специфікації сценаріїв.Але є й зворотний бік:🔻 Щоб писати сценарії в тому ж Cucumberі так, щоб вони реально жили довго і не перетворились у хаос треба досвід і терпіння, і це дуже недешево по часу.🔻Абстракція = більше артефактів. Потрібно створювати й підтримувати банально більше файлів. І це не тільки про огірки. Коли ви абстрагуєте за фасадом інший фасад, який використовує врапер над врапером, в якийсь момент можна здуріти.🔻 У прикладі BDD вам однозначно треба буде більші стартові інвестиції та довший "розгін". Але насправді при високій абстракції тестів та інкапсулації реалізації — новій людині також треба доволі багато часу на онбордінг.🔻 Може знадобитися сильніша команда (більше експертизи), інакше все буде тріщати по швах. Пояснювати людині, як у вас влаштовано, може здатись занадто складно, якщо людина не бачила та не знає патерни, як приклад. Тому далі вже тест архітект і тест-автомейшн-інженер мають по-людськи зважити: чи виправдана ця абстракція саме для нашого випадку і оцінити її строки, вартість, трудозатрати і реальну користь. Ну і приймати рішення. Бажано також це оформити в якийсь документ "на майбутнє", чому ми обрали саме такий підхід, саме такі практики для потомків — з часом ніхто уже не буде памʼятати контекста прийнятих рішень без створених на те артефактів.Розкажіть, як ви у себе на проєктах приймаєте рішення про рівень абстрагування автотестів. А якщо хочете прокачати власну експертизу в автоматизації та отримати сертифікат ISTQB Advanced Test Automation Engineer — чекаємо вас на курсі!