개념
코드 없이 자동화를 구성한다는 것
모듈 13에서 배운 Playwright는 코드로 테스트를 작성했다. Tricentis Tosca나 Micro Focus UFT(Unified Functional Testing) 같은 도구들은 모델 기반(Model-Based) 또는 키워드 기반(Keyword-Driven) 접근으로, 코드를 몰라도 화면 요소를 조합해 테스트를 구성할 수 있게 한다.
코드 기반(Playwright): 개발자가 직접 코드로 로직을 작성
코드리스(Tosca 등): 화면 요소와 동작을 마우스로 조합해 시나리오를 구성왜 이런 도구가 필요한가
QA 조직 전체가 반드시 코드를 짤 줄 아는 건 아니다. 특히 규제 산업(금융, 보험, 제조)에서는 도메인 지식은 깊지만 프로그래밍 경험은 없는 QA 인력이 많다. 코드리스 도구는 이런 인력도 자동화에 직접 참여할 수 있게 해준다 — 모듈 8에서 다룬 표준화된 문서 체계를 중요시하는 조직일수록, 이런 도구가 제공하는 시각적 흐름도(순서도 형태의 테스트 구성)가 문서화와도 자연스럽게 연결된다.
모델 기반 테스트(Model-Based Testing)의 개념
Tosca 같은 도구는 애플리케이션의 화면 요소를 모듈로 인식하고 재사용 가능한 형태로 저장한다.
모듈 13의 POM: 화면을 클래스(코드)로 감쌈
Tosca의 모듈: 화면 요소를 시각적 구성요소로 등록해 재사용개념적으로는 모듈 13(레슨 4)에서 배운 Page Object Model과 매우 비슷하다 — "화면 요소를 한 곳에 모아 재사용 가능하게 만든다"는 원칙은 코드 기반이든 코드리스든 똑같이 적용된다. 다만 이걸 표현하는 방식(코드 vs GUI 구성)이 다를 뿐이다.
코드리스 도구의 장단점
장점
- 비개발자도 자동화 구성에 직접 참여할 수 있다
- 시각적 흐름도가 그 자체로 문서 역할을 한다(모듈 8의 산출물 문서와 연결)
- 엔터프라이즈 소프트웨어(SAP 등)와의 통합을 미리 지원하는 경우가 많다
단점
- 라이선스 비용이 크다(모듈 11 레슨 3의 ROI 계산에서 이 비용도 반영해야 한다)
- 세밀한 로직(복잡한 조건 분기, 데이터 처리)은 코드보다 표현하기 번거로울 수 있다
- Git 같은 버전 관리 도구와의 통합이 코드 기반보다 상대적으로 불편한 경우가 많다(모듈 9 레슨 7과 비교)
코드 기반과 코드리스, 경쟁이 아니라 상황별 선택
한 조직 안에서도 두 접근을 함께 쓰는 경우가 흔하다 — 개발팀과 가까운 QA 자동화는 Playwright 같은 코드 기반으로, 업무 부서와 가까운 회귀 테스트는 코드리스 도구로 구성하는 식이다. 모듈 11(레슨 5)에서 배운 자동화 전략에는 "이 조직에 어떤 인력 구성이 있고, 어떤 도구가 그 인력에 맞는가"까지 포함되어야 한다.
실무에서 왜 필요한가
"우리 팀은 Playwright를 쓰는데, 왜 다른 부서는 아직도 UFT를 쓰나요?"라는 질문에, 단순히 "오래된 방식이라서"라고 답하면 부정확하다. 그 부서의 인력 구성과 시스템 특성을 고려하면 코드리스 도구가 여전히 합리적인 선택일 수 있다는 것을 이해하는 QA는, 조직 전체의 자동화 전략을 더 균형 있게 설계할 수 있다.