2. 자동화의 신뢰성을 높이기 위한 액션

QA 컨퍼런스에서 두 번째 발표를 맡아주신 정다정 님의 발표 내용을 정리해 보도록 하겠습니다.
UI 자동화 테스트는 저도 지금 담당하는 업무로 잘 아는 내용이기도 했어서 주제를 봤을 때 가장 흥미롭게 생각한 주제였습니다. 발표를 들으면서 자동화 테스트 구성을 위한 문제 해결을 위해 저와 같은 고민을 많이 했구나 라는 생각을 많이 했던 발표였고, 내용을 하나씩 정리해 보면서 제 생각도 정리해 보겠습니다 👏 

제가 작성하는 내용은 QA 컨퍼런스 후기일 뿐입니다 🫠
QA 컨퍼런스에 직접 참여하셔서 발표를 들어보시는 것을 정말 추천드립니다!

QA 코리아 컨퍼런스 : https://www.qa-korea.com/ 
정다정 님 링크드인 : 링크드인 연결 링크   

 

 

QA 컨퍼런스의 두 번째 발표는 정다정 님이 발표해 주셨고, UI 자동화 테스트를 구성할 때 신뢰성을 높이기 위한 노력에 대한 이야기를 해주셨습니다. 29CM 현업에서 사용하고 있는 사례를 들어서 얘기해 주셔서 좀 더 이해가 잘 됐던 부분도 있었습니다.

 

 

내용은 자동화 스크립트 구성할 때 가장 쉽지 않은 element를 탐색하는 전략에 대해 설명해주셨고, 작성된 코드의 신뢰성 향상을 위한 노력에 대한 내용을 담아서 발표해 주셨습니다.

 

 

서론으로는 테스트 자동화를 구성하기 위한 노력. 명확한 목적과 전략, 테스트 범위를 설정하고, 요구사항에 적합한 툴을 선정하며 일관된 테스트 환경을 구성해야 성공적인 자동화 테스트가 구성되었다라고 설명해 주셨습니다.

부가적인 설명으로는 위 그림처럼 자동화 구성을 하고 반복적으로 수행했을 때 실패율에 대한 분석 그래프를 보여주셨고, 자동화 스크립트의 실패율이 높아지면 신뢰성이 떨어지기에 이를 개선하기 위한 작업을 설명해 주신다고 하셨습니다.

 

 

29CM에서 사용하고 있는 언어 및 툴은 python 언어로 appium 툴을 사용해서 자동화 테스트를 구성한다고 하네요. 요즘 대부분 Application 테스트 부분은 appium이 자리매김한 것 같습니다.

 

이후에 나오는 다른 발표에서도 Application 관련 자동화 테스트가 나올 때 appium은 고정으로 사용하고 계시더라고요. 언어는 살짝 다르긴 하지만 Python이 자리매김 하고, Javascript나 Typescript, 그리고 java 언어 위주로 자동화를 구성하는 것 같았습니다. 그래서 제가 자동화 작업을 진행할 때 지금 사용하고 있는 Javascript 외 Python언어에 대한 공부도 해야겠다는 생각도 들었습니다 😂 

 

그래도 자동화를 구성 시 다들 언어적인 측면의 장벽은 높지 않다고 하니, Python도 기본적인 문법 사용하고 읽을 줄 아는 정도만 공부하면 금방 따라갈 수 있지 않을까 라는 생각이 드네요! (다른 언어를 편하게 쓸 수 있다는 기준으로!)

 

 

이어서 효율적인 Element 탐색 전략에 대한 내용을 설명해 주셨습니다. 자동화에서 가장 문제가 되는 영역인 부분인데, UI로 표시되는 부분에서 어떤 항목을 클릭할 것인지 어떤 항목에서 글자를 입력하거나, 동작을 수행할 것인지를 전달하기 위해 대상 Element에 대한 위치를 알려줘야 합니다. 이를 해결하기 위한 방법으로 Accessibility ID, 즉 식별자 값을 넣어둬서 자동화 수행 시 식별자 ID에 해당하는 항목을 찾게 하고 이후 동작을 수행해!라는 방식으로 작업을 진행했다고 하네요.

 

 

29CM 페이지를 예시로 들어 알려주셨습니다. '의류'라는 항목을 선택하기 위해 Xpath의 위치값을 작성하지 않고 개발팀에 식별자 값을 넣어주는 것을 요청하여 자동화 동작의 실패율을 줄여서 신뢰성을 높였다고 하네요.

 

 

식별자를 있을 때와 없을 때 자동화 동작의 차이는 분명히 있을 수 있습니다. 식별자가 있다면 명확하게 대상 항목을 찾아서 동작하지만 없다면 절대경로를 사용하는 xpath나 css, text로 찾을 수 있겠지만 한 화면에 동일한 다른 요소가 있다면 이제부터 혼돈의 시작입니다 😫

 

두 가지 이상의 요소가 있다면, 스크립트를 동작하는 컴퓨터는 어떤 것을 선택해야 할지 모를 수 있고, 하드코딩으로 무조건 첫 번째 요소를 클릭해!라고 한다면, 화면 개선이나 추가 개발로 인해 구성이 변경되는 경우 유지보수하는 공수가 많이 들어가게 될 것입니다. 😥

 

 

29CM는 개발자와 협업하여 요소에 ID 값을 넣어주는 작업을 수행하는 방식을 통해 식별자가 없어서 요소를 찾지 못해 테스트 중단 및 실패에 대한 문제를 해결했다고 하네요!

 

저도 이 방법을 가장 추천드리긴 하지만 회사마다 다르게 반응할 수 있을 것 같습니다 😥 개발팀에 요청하여 식별자를 넣어주세요! 하는 방법이 있으나.. 협업이 잘 되는 경우가 아닐 수 있고, 개발팀에서는 QA팀의 자동화의 중요성을 크게 이해하지 못하는 경우도 있고, 개발팀 인력이 부족해서 식별자를 일일이 넣어주는 공수를 추가하기 어려워요라고 말할 수 있을 것 같습니다. (제가 경험한 내용입니다 😂)

 

잠깐 제 의견을 넣어보자면 저는 개발팀과 어느 정도 조율을 통해 식별자 추가를 요청했습니다. 예를 들면 모든 버튼이나 레이어에 식별자를 넣어주는 것이 아닌 UI 레이아웃만 봐도 기능이 구분될 법한 항목의 div에 id를 넣어준다면 그 그룹 내에서 요소를 찾는 거는 div 위치부터 상대경로로 찾거나 Text를 검색하거나 특정 태그(h2, svg, span, button 등)를 찾아서 처리하는 방식으로 진행하긴 했습니다. 모든 요소에 식별자를 넣는 것은 개발팀에도 많은 공수가 필요할 수 있어서 요청하기도 어렵기 때문에 나름의 조율을 해서 요청드렸더니 이 정도는 괜찮다고 하시면서 식별자를 넣어주시더라고요! 

 

 

이후에는 신뢰성 향상을 위한 코드 작성 전략에 대해 말씀해 주셨습니다. 자동화 테스트를 UI 수행 부분에 초점을 두지 않고, API 테스트와 연계하여 신뢰성을 확보할 수 있었다고 알려주셨습니다.

 

 

자동화 테스트를 통해서 요소의 정상 출력 여부만 확인하다면 발견하지 못할 부분에 대한 설명을 바로 와닿을 수 있게 설명해 주셨습니다. 예시 케이스에 보이는 것과 같이 화면은 정상적으로 표시되어 이상이 없는 것처럼 보이지만, 데이터를 확인해 보면 항목이 서로 뒤바뀌어 표시되고 있다는 것을 알 수 있습니다.

 

이처럼 화면은 정상 표시되어도, 내용이 다를 수 있기에 API 테스트를 보조 수단으로 사용하여 기능 테스트에서 그냥 넘어갈 수 있는 부분들을 잡아주어 신뢰성을 향상했다고 하시네요.

 

다른 케이스로는 상품 옵션에 대한 설명과 사용자마다 다르게 표시되는 화면을 예시로 말씀해 주셨습니다. 상품별로 옵션 선택 항목이 다르기에 기능테스트에서 상품마다 다르게 동작해야 하는데, API를 보조 수단으로 사용하여 상품에 어떤 옵션을 가지고 있는지 읽어와서 테스트 수행을 지원한다고 하네요. 

 

API와 병행해서 자동화 테스트를 구성하는 것은 새롭게 알게 된 영역이었습니다. 자동화를 구성하다 보면 기능 테스트로 확인하기엔 스크립트가 너무 많아지거나 너무 상세한 항목까지 확인해야 하는 부분이 있어서 API 테스트 부분에서 테스트해주세요~! 하고 넘길 수 있는데, 오히려 API 테스트의 데이터를 끌어와서 기능 테스트에 적용한다면 화면상으로 불필요하게 작업할 내용들을 API 테스트가 지원해 주니 안정성도 올라가고 스크립트 작성 공수도 줄일 수 있을 것 같네요!

기회가 된다면 업무에 적용해 볼 수 있도록 할 예정입니다! 좋은 아이디어 감사합니다 🙇‍♂️

 

 

그리고, 테스트 케이스 간 독립성을 확보하여 테스트 중 앞서 수행된 테스트가 실패하더라도 이후 테스트에 영향을 끼치지 않도록 개발했다고 하셨습니다. 각 테스트 수행 전에 초기화하는 코드를 추가하여 항상 데이터 초기화를 한 뒤 작업을 수행할 수 있도록 진행했다고 하네요. 

 

 

그 결과로 여러 테스트가 수행되어도 다른 테스트에 영향이 없으므로, 실패한 테스트는 그대로 로그를 표시하고, 다음 테스트를 진행하여 로그를 남긴다고 하네요.

 

이 부분도 제가 자동화 작업을 할 때 많이 고민했던 부분이었습니다. 자동화 수행 도중 실패했을 때 나머지 테스트는 동작하지 않을 텐데..? 이건 어떻게 처리해야 할까 생각하다가 저도 비슷하게 시작 전 초기화 스크립트를 추가하여 이전 테스트로 인해 데이터 꼬이는 현상을 없애기도 했고, 테스트마다 계정을 별도로 만들어서 애초에 서로 영향을 끼칠 수 없는 환경을 만들기도 했습니다. 

 

 

그리고 POM 구조를 사용하여 중복 코드를 줄이고 요소가 변경되는 경우 한 부분만 수정하면 모든 시나리오에 적용되는 효과를 볼 수 있다고 말씀해 주셨습니다.

 

이 부분도 저도 사용하고 있는 부분이었고, POM 구조를 사용하지 않을 경우 불필요한 구조나 코드가 많아지고, 유지보수 비용이 많이 들어서 매우 불안정한 자동화 코드가 될 수 있기 때문에 당연히 필요한 구조 수립이라고 생각합니다. 필수!!

 

 

마지막으로, 화면 변경이나 추가 개발로 인해 요소의 ID가 빠지거나, 태그 값이 변경되는 영향으로 테스트가 동작하지 않을 때 특정 항목에 대한 Xpath 검색을 통해서 요소가 없어도 한번 더 확인해 보는 예외처리 방식을 구성했다고 하네요.

 

이 부분도 조금 놀라웠습니다. 당연히 Element의 속성이나 태그가 변경되면 자동화 부분도 수정을 해줘야 하고 당연히 안 돌아가겠지~ 생각했는데, 예외처리를 해서 2차 방어선을 구축한 느낌이랄까... 식별자 ID도 코드에 넣어줘야 하고, Xpath까지 넣어준다면 엄청 귀찮은 작업일 텐데..?라고 생각했습니다. 그러나 생각해 보면 모든 항목에 2가지 방법을 넣어주는 게 아닌 주로 사용하는 항목이나 필수로 거쳐가야 다른 테스트가 진행되는 항목에 대해서 대비를 해둔다면 신뢰성이 높아지는 방법 일 것 같았습니다. 

 

그리고, 같은 동작을 수행했지만 수행 환경에 따라 다른 결괏값이 나오는 경우에 대한 처리 방식도 알려주셨습니다. 기기에 페이스북 로그인이 이미 되어있는 경우 페이스북 동의를 얻는 페이지가 출력되지 않지만, 페이스북을 한 번도 로그인하지 않은 기기는 동의를 얻는 페이지로 이동하기 때문이죠.

 

이 부분은 저와 비슷한 방식으로 진행한 것 같았습니다. 저도 자동화를 수행할 때 다른 브라우저나 다른 환경에서 로그인된 계정으로 로그인을 수행하는 경우 "이미 로그인 된 계정입니다"라는 팝업이 출력되며 로그아웃시키고 로그인하겠냐는 질문 팝업이 뜨게 되는데, 다른 환경에서 이미 로그인되어있지 않다면 안 나와서 예외처리를 해줘야 하는 상황이었습니다. 제가 처리한 방식과 유사하게 버튼을 클릭하고 기다렸다가 특정 Element가 있는지 확인해서 있으면 강제 로그인을 수행하고, 없으면 다음 작업을 수행하는 방식으로 진행했습니다 😎

 

마무리로는 자동화 실패율을 낮추는 것은 물론, 유지보수의 효율성도 고민하고 있다고 말씀해 주시며 발표를 마무리하셨습니다. 

 

이번 발표는 제가 잘 사용하고 잘 아는 분야라서 더 깊게 듣게 되어 글이 길어졌네요 😅

아는 내용도 있었고 새로운 내용도 있어서 더 재밌게 들었던 것 같습니다

다음 포스팅에서 만나뵙겠습니다 :)