#testing #automation
Часто бачу у кандидатів в резюме та на співбесіді таку фразу - “я маю досвід побудови тестових фреймворків з нуля”. Інколи це правда. Але в багатьох випадках кандидат має на увазі трохи інше, а саме - test automation solution.
Але в чому різниця? Давайте похоліваримо (бо у кожного своє розуміння)!
📖Що нам говорить книга “Test Automation Fundamentals”?
A test automation solution (TAS) is a specific instance of a TAA* and consists of the test environment and its corresponding automated testware. The latter includes automated test cases (which may be grouped into test suites), test data, and specific configuration files. A TAS is therefore not a monolithic tool or framework, but rather a combination of tools, components, and testware brought together for the purpose of automating testing processes.
* TAA - test automation architecture
A test automation framework (TAF) can, however, be used to provide a test environment, tools, test libraries, or additional test frameworks that can then be reused for faster automated test creation and execution.
🌐 Що говорить Wiki?
A test automation framework provides a programming environment that integrates test logic, test data, and other resources. The framework provides the basis of test automation and simplifies the automation effort. Using a framework can lower the cost of test development and maintenance. If there is change to any test case then only the test case file needs to be updated and the driver script and startup script will remain the same.
❗️Окей, але що з того?
💡Тобто фреймворк - це бібліотека чи набір бібліотек, на основі яких можна писати автотести. Ключове тут - легке перевикористання не тільки між схожими, а між будь-якими абсолютно різними проєктами. Фреймворк може задавати структуру до написання тестового коду.
Наприклад тестові фреймворки JUnit, TestNG, pytest, Jest - можна використовувати для написання тестів для web, mobile, api та інших систем.
Приклади фреймворків в розробці: Spring, Hibernate в Java, Django, Flask, FastAPI в Python, React, Vue, Angular в JS.
Деякі великі компанії, яким треба автоматизовувати купу ідентичних проєктів, можуть розробляти свої фреймворки, заточені під потреби цих компаній. Або ж для уніфікації підходів, інструментів та знань.
💡Солюшен (рішення) - це застосування тестового фреймворку + купи додаткових утиліт, тестових даних, запуск на CICD чи в контейнерах на хмарах, репортинг. Та що найголовніше - набір тестових даних, клієнтів та тестів заточених під конкретний продукт.
Написання солюшену буде так чи інакше включати в себе написання деякої частини, яку можна назвати фреймворком. Але ця частина стає фреймворком, якщо її приймають як стандарт для багатьох проєктів у вашій компанії. І якщо вона достатньо легко переноситься з проєкту на проєкт.
В усіх інших ситуаціях, коли ви пишете кастомну автоматизацію під конкретний проєкт - ви не пишете фреймворк. Ви вирішуєте проблему. Ви з готових частин, наче конструктор Lego, складаєте солюшен та пишете автотести. Навіть - коли ви робите це "з нуля".
Сучасні інструменти, такі як Playwright - дають більшість компонентів фреймворку прямо з коробки. То ж етап створення фреймворку часто дуже умовний або відсутній.
🎓Висновки
Коли ви пишете автотести - ви в будь-якому разі працюєте в контексті конкретного солюшену для автоматизації написаного з застосуванням того чи іншого фреймворку. А чи відокремите ви потім частину солюшену в окремий "внутрішній фреймворк" - покаже час.
Але якщо ви написали аналог pytest чи JUnit - тут ви безперечне написали фреймворк.
Але памʼятайте - що автоматизація тестування повинна починатися з питання - а яку проблему ми вирішуємо за допомогою цього солюшену? (Привіт Артем!)
А ви пишете фреймворки чи солюшени?