29CM QA팀이 AI와 협업을 위해 AI Locator를 구현하여 얻은 효과

본 포스팅은 Medium에 먼저 기제되었습니다.

 

지금 사용하고 있는 All Locator

29CM QA팀은 Appium으로 iOS와 Android 테스트 자동화를 수행하고 있습니다. 이 과정에서 작성의 편의성을 위해 All Locator를 구현해 놓고 사용하고 있는데요 이것은 Playwright의 .locator() 와 유사한 기능을 가지고 있습니다.

playwright에 .locator()는 아래와 같이 선택자 구분없이 모든 선택자를 수용하여 편리한 사용이 가능합니다.

page.locator("text=로그인")  # 텍스트 기반
page.locator("#username")    # ID 기반
page.locator("//button[@id='submit']")  # XPath 기반
page.locator("role=button[name='Submit']")  # Role 기반

29CM QA팀은 iOS는 iOS All Locator라는 뜻의 ial, Android All Locator라는 뜻의 aal을 구현하여 playwright에 .locator()과 유사한 기능을 제공하고 있습니다.

# iOS일 경우
ial(wd, '//XCUIElementTypeButton[@name="로그인"]')
ial(wd, 'c_이메일')
ial(wd, 'navi_back_btn')
ial(wd, '전체 동의하기')

# Android일 경우
aal(wd, '//android.widget.Button[@text="로그인"]')
aal(wd, 'c_이메일')
aal(wd, 'com.the29cm.app29cm:id/imgBack')
aal(wd, '전체 동의하기')

ial의 경우
XPATH, IOS_CLASS_CHAIN, ACCESSIBILITY_ID 를 지원하고

aal의 경우
XPATH, CLASS_NAME, ID, ANDROID_UIAUTOMATOR, ACCESSIBILITY_ID
를 지원하도록 구현하였습니다.

그 외에도 복수 element 수집과 클릭, 키입력, contains 쿼리를 편리하게 사용하는 추가 로직들이 포함되어 있으며 이 때를 기준으로 All Locator Ver.1이라고 지칭하여 사용하고 있었습니다.

 

All Locator로 커버가 불가능한 영역이 생기다

작성에 대한 편의성은 확보하였으나 중요한건 테스트 자동화 결과의 신뢰성이였습니다. 신뢰성을 확보하는 것은 QA팀 단독으로진행하는 것 보다는 협업이 훨씬 유리하다고 판단했기 때문에 29CM 엔지니어링 조직의 도움이 필요하였습니다.

29CM 엔지니어링 조직은 QA팀과 매우 긴밀한 협업과 지원이 가능했기 때문에 고유식별자를 추가하는 작업이 원활히 진행될 수 있었습니다. 이로인해 Fail률은 급격히 하락하여 1%대를 유지할 수 있게 되었지만 또 다른 문제가 있었습니다.

바로 UI에 지속적인 변경이였습니다.

하루가 멀다하고 UI가 변경되는 것은 아니였으나 조직이 커지며 인원이 많아진 만큼 배포되는 기능도 많고 유저 대상의 실험도 많이 진행되었습니다.

이 상황에서 크고작은 UI변경이 있었으며 이 때 기존에 추가한 고유식별자가 삭제되는 상황이 발생하는 경우도 있어 고유식별자를 사용했던 코드에서는 Fail이 발생하게 되었습니다.

이러한 상황을 대응하기 위해 AI의 지원을 받기로 하고 구현에 착수하게 됩니다.

 

AI를 활용하기 위한 프롬프트 연구

AI를 활용하는 방식에 관련된 포스팅을 보면 AI를 사용한 자가치유에 대한 이야기가 많습니다. 그래서 자가치유라는 것을 어떻게 사용할 수 있을지 고민하였고 몇가지 방안이 떠올라 완벽한 자가치유가 아닌 응급치료 수준의 자가치유를 먼저 시도해보기로 하였습니다.

여기서 떠오른 방안이란 AI를 통해 Locator를 제안 받는 것이였습니다.

그 전에 ChatGPT를 사용할 계획이였기 때문에 각 모델별 검증이 필요했습니다. 정확한 Locator를 제안받지 못하면 AI도입에 의미가 없기 때문이였습니다.

다양한 모델이 있었지만 최신 모델을 사용하기로 합니다.
GPT-4 계열 중 최적화가 잘 되어 성능이 좋다고 알려진 gpt-4o를 대상으로 하고 gpt-4o-mini를 비교군으로 테스트를 시행했습니다.

전체 페이지 코드를 제공하고 거기서 원하는 keyword를 제시해서 부합하는 element를 찾도록 했습니다.

2개 모두 속도 차이는 거의 없었으나 각각 다른 답변을 주었고 확인 결과 gpt-4o는 정확히 요소가 찾아지는 경로를 주었으나 gpt-4o-mini는 찾지못하는 경로를 제안해준 것이 확인되었습니다.

이로써 gpt-4o 모델을 사용하기로 결정하고 프롬프트를 최적화 하는 작업을 진행했습니다. 원하는 것은 다른 내용 없이 경로만 정확히 받는 것인데 응답으로는 항상 경로와 함께 다른 문자를 포함해서 전달해주는 경우가 많았습니다.

1. 네 {경로} 입니다.
2. 이것을 사용해보세요. {경로}
3. {경로} 를 사용해보시고... 중략
4. 등등

1. 저는 정확히 경로 자체만 필요했기 때문에 경로만 전달하도록 프롬프트를 테스트 하며 수정했습니다.
2. 그 후 경로만 정확히 받게 되었지만 Locator가 혼용되는 문제가 새로 발생하였습니다. 그래서 이 부분은 XPATH로만 전달할 수 있도록 다시 프롬프트를 수정하였습니다.
3. keyword를 받아서 찾는 방법도 있지만 추가적으로 직접 서술해서 element를 찾는 상황도 발생할 것이라고 예상해서 description용 AI Locator도 추가하였습니다.

이렇게 ailo와 aideslo를 구현하였고 사용지점을 정하기 위해 상황들을 고려하기 시작합니다.
* 현재는 팀에서 ailo보다 aideslo를 더 많이 사용중입니다.

AI Locator는 어느 지점에 사용해야할까

자동화 코드는 POM구조로 되어있어서 page_action 쪽에 element를 찾는 find_ 코드들이 모두 작성되어 있었습니다. 그래서 최초에는 여기서 element를 찾다가 못찾으면 AI Locator를 사용하려고 생각했지만 이럴경우 모든 page_action쪽에 코드를 추가해야 하기 때문에 비효율이라고 생각해서 기존 All Locator와 AI Locator를 합치는 계획을 실행합니다.

All Locator Ver.2 가 시작되는 순간입니다.

All Locator Ver.2 시작

기존 All Locator 코드가 수행되다 NoSuchElementException이 발생할 경우 매개변수의 keyword혹은 des의 값을 체크하여 AI Locator가 호출되도록 하였습니다.
(All Locator는 이미 많은 곳에서 사용되고 있기 때문에 AI Locator를 사용하기 위한 매개변수 값이 필수면 문제가 생기게 됩니다. 그래서 기본값을 설정하여 기존 사용코드들에 문제가 발생하지 않도록 했습니다)

기존에 사용하던 All Locator에 AI Locator 기능을 합쳤기 때문에 사용도 간단했습니다. 매개변수로 값만 넣어주면 별다른 작업없이 사용이 가능했습니다.

NoSuch를 대비해서 AI Locator를 사용하고 싶어!

이렇게 매개변수만 추가하면 사용가능합니다.

효과는 성공적이였다

코드 한줄 추가로 AI Locator를 사용할 수 있게 되었습니다.

자가치유는 아니고 응급처치에 가까운 AI 도입이였지만 실제 AI Locator가 전달해준 XPATH로 자동화 코드가 정상 동작하는 것을 경험한 팀원분들이 신기해 하며 이 기능을 사용하고 있습니다.

아마 이러한 사용경험이 쌓이면서 프롬프트도 좀 더 정교해지고 정확해질 것으로 예상됩니다.

이제 AI를 처음 도입하여봤습니다. 확실히 든든한 지원군으로 여겨지고 있고 앞으로 다른 영역에도 적극적으로 도입해볼 계획이 생겼습니다.

항상 포스팅으로만 봐오고 생각만 하고 있던 것을 간단하게나마 구현해보니 팀이나 저에게 모두 많은 도움이 되는 것 같습니다.

앞으로 더 많은 도움을 받을 수 있을 것 같습니다.