<div id="readability-page-1" class="page"><div>| 단점을 보완하여 하반기 워크샵 시작!상반기 워크샵 이후 약 5개월이 경과하였습니다. 테스트 자동화는 많은 진척이 있었고 전체 시나리오의 약 70% 정도를 커버할 수 있는 시나리오로 구현이 되었습니다. 하지만 과거의 경험을 빗대어 보면 구현률 보다 중요한 것은 유지보수 였습니다. 테스트 자동화에서 결과가 실패일 경우 얼마나 빠르게 해당 내용을 확인하고 보완할 수 있는지가 관건이였습니다.하반기 워크샵에는 유지보수에 대한 효율적인 방법을 찾는 것과 팀원분들이 5개월간 진행하며 학습하게된 내용을 서로 공유하는 자리를 마련하기로 하였습니다.물론 시간에 대한 제약을 없애기 위해 CTO님께 워크샵에 대한 방향성과 목표를 정확히 말씀드리고 흔쾌히 결제를 받아 하루를 온전히 워크샵에 사용하게 됩니다. (워크샵 장소로 출근!)<figure><figcaption>All in One Locator 그 시작</figcaption></figure><figure><figcaption>UI 테스트 자동화에 API 를 접목했을 때의 시너지</figcaption></figure><figure><figcaption>다시 견고하게 만드는 QA 프로세스</figcaption></figure>효율적인 유지보수를 위해서 테스트 스크립트 작성에 들어가는 시간을 줄이는 방법을 모색하게 되었습니다. 그 결과로 All in one Locator를 만들어서 작성시간을 줄이는 제안을 팀 내에 하게되었습니다.기존에는 하단의 코드를 element를 제어해야 할 상황이 있을 때마다 반복적으로 작성해야 했습니다. 코드의 길이도 짧지 않을 뿐더러 AppiumBy 뒤에 Locator도 상황에 맞게 변경해야 했기에 다소 번거로운 작성이 계속되었었죠.<pre>webdriver.find_elements(AppiumBy.</pre>이러한 비효율적인 부분을 없애고자 모든 Locator를 커버하는 Locator 함수를 별도로 제작하였습니다. 코드 작성 길이는 줄이고, Locator를 고민하는 시간도 없애기 위한 시도였죠.iOS는 ial (iOS All in one Locator) Android는 aal (Android All in one Locator) 라는 이름으로 사용할 수 있도록 하였습니다.<figure></figure>직접 Locator를 지정해서 element를 찾는것보다 속도면에서 차이가 없도록 Locator 식별값 자체를 체크해서 적절한 Locator를 지정하도록 했습니다. 실제로 시간 테스트를 했을 때 직접 Locator 지정방식과 시간 차이가 거의 없는 것으로 확인이 되었습니다..click() 이나 .send_keys() 도 가능하도록 click은 ialc, aalc 로 사용할 수 있도록 하고 send_keys는 ialk, aalk로 가능하도록 구현했습니다.</div><div>UI 테스트 자동화 진행 시 해당 화면에 표시되는 데이터에 대한 정합성 체크를 API로 진행하는 것도 팀 내에 공유하였습니다. 각 화면에서 사용되는 API를 사용하여 데이터가 중복으로 출력되거나 잘못된 값이 나오고 있지는 않은지 검증에 사용하였고, 테스트 시 임의의 상품을 대상으로 하는데 그럴때마다 옵션값이 모두 다를 수 있는 상황을 해결하기 위해 해당 상품의 정보를 조회하는 API를 사용하여 옵션정보를 가져와 Locator 값으로 사용하기도 하였습니다.<figure></figure>이렇게 워크샵을 진행하며 엔지니어링 관점에서 개선과 변화를 시도를 하였습니다. 여기서 중요한 점은 이러한 내용이 공유 되었을 때 팀원분들이 그것을 단순히 따르는 것이 아니라 그 자리에서 궁금증을 해소하기 위한 문의와 실제 효과에 대한 토론이 진행되었다는 것입니다.건강한 토론을 위해 팀원분들도 비방이나 맹목적인 신뢰에서 한걸음 벗어나서 최대한 객관적인 판단을 할 수 있도록 노력했습니다. 그 과정에서 의견을 냈던 owner가 미처 생각하지 못했던 부분이 수면위로 떠올라 개선포인트를 찾을 수 있었고 더 나은 방향이 제안되어 방향이 조금 변경된 내용도 있었습니다.워크샵은 쉬는시간을 포함하여 9시간 가까이 진행되었습니다. 이 과정을 지루하게 여기지 않고 모두 집중력을 유지하며 진행할 수 있었던 것은 해당 워크샵을 진행하기 전에 워크샵의 목적에 대한 공유가 되었고 모두가 공감했기 때문이라고 생각합니다.현재 우리의 문제점이 무엇인지 명확히 파악하고 그것을 해소하기 위한 공동의 목표를 위해 모두 노력할 수 있었다는 것이 하반기 워크샵의 가장 큰 성공요인이라고 볼 수 있을 것 같습니다.이렇게 많은 결과를 낼 수 있었던 하반기 워크샵은 즐거운 저녁 회식으로 마무리 되었습니다. 내년에도 QA팀은 워크샵을 진행할 예정이고 올해 하반기 워크샵의 성공적인 진행을 발판삼아 개인과 팀의 성장을 위해 더 생산적인 워크샵이 될 수 있도록 계획할 예정입니다.이 글의 서두에 이야기 했던 것 처럼 워크샵은 팀원의 팀워크를 위해 사용할 수도 있습니다. 그렇기 때문에 29CM QA팀이 진행했던 워크샵 방법만이 정답은 아닙니다. 하지만 이런것도 또다른 방향이라고 생각합니다. 환경과 효율개선을 위해 모든 팀원이 치열하게 고민하고 논의하는 시간을 별도로 마련하여 진행하는 것이 정말 놀라운 결과를 가져올 수 있었던 것을 경험할 수 있었습니다. 워크샵의 또다른 가능성을 볼 수 있었고 앞으로도 이런 방향의 워크샵을 진행하게 될 충분한 이유가 되었습니다.이제 2024년 입니다. 벌써부터 상반기 워크샵에 대한 기대가 되고 있습니다. 그것이 끝났을 때 QA팀은 또 한걸음 성장해 있을 것이라는 것을 의심치 않기 때문입니다.여러분들도 워크샵을 효과적으로 사용하여 많은 성장과 도움을 받으실 수 있으면 좋겠습니다. 감사합니다.</div></div>

29CM 기술블로그 - Medium

29CM에서는 연 최대 2회로 1인당 10만원의 비용을 지원하여 임직원의 워크샵 활동을 도모하고 있습니다. QA팀도 2023년에 2번의 워크샵을 다녀왔는데요 이것을 어떻게 활용하여 어떤 결과를 얻게 되었는지 이야기를 해보려합니다.
| 워크샵때 뭐 할까요?
물론 팀워크 향상을 위한 레크레이션이나 엔터테인먼트 활동을 하는 것도 가능하지만 이 때 당시 QA팀이 생겨난지 6개월도 되지 않은 시점이였기 때문에 워크샵을 통해 팀원들의 빠른 온보딩과 팀의방향성에 대한 싱크를 맞추는 것이 우선이라고 생각했습니다.
그래서 상반기 워크샵에는 QA팀이 테스트 자동화를 도입하려는 이유에 대해서 설명하고 그 첫발을 잘 내딛을 수 있도록 팀원 모두 테스트 자동화 셋팅을 완료하고 테스트 자동화 프레임워크에 대한 이해도를 높일 수 있는 구성으로 진행되었습니다.
29CM 개발팀의 규모는 그 때 당시 약 60여명 이였습니다. QA팀은 3명이였기 때문에 개발자와 QA의 비율은 약 20:1 수준이였습니다. 동시적으로 개발이 되어 기능이 나온다면 QA인원이 매우 부족할 수 있는 비율이였습니다. 또한 앱 정기배포는 일주일에 1회 였으나 웹이나 서버는 수시로 배포되었고 파트너사에서 사용하는 별도의 admin도 존재하는 상황이라 테스트 대상 플랫폼이나 기능이 모두 많은 상황이였습니다.
테스트 자동화를 진행하지 않는다면 3명의 인원이 소화할 수 없는 양이였기 때문에 필수적으로 테스트 자동화가 필요한 상황이였습니다. 일단 가장 높은 효율을 낼 수 있도록 반복적인 릴리즈 테스트가 진행되고 있는 앱 테스트 자동화를 먼저 진행하기로 하였습니다.
저는 과거에 1.22.x 버전의 Appium을 사용했었습니다. 하지만 해당 버전에서 심각한 보안이슈가 발생하였고 필연적으로 2.0.0 beta 버전을 사용해야 하는 상황이 되었습니다.
appium-desktop/README.md at master · appium/appium-desktop
이에 빠르게 2.0.0 beta 버전에 대한 정보를 수집해 설정방법을 학습하고 팀내에 가이드하기 위한 준비를 하였고 워크샵 때 이러한 내용을 바탕으로 설정방법을 가이드 하였고 팀내 모든 인원이 모바일 앱 테스트 자동화 설정을 성공적으로 마치게 됩니다. 
(현재는 정식 릴리즈가 되었으며 2.2.x 버전까지 릴리즈 되었습니다)
이 때는 업무를 한 뒤 4시간 정도의 시간을 내서 워크샵을 진행했었습니다. 그러다보니 이동 시간도 있고 환경 셋팅도 해야 해서 4시간을 온전히 사용하지 못했습니다. 
그러다보니 팀원분들도 쫒기듯이 학습하며 테스트 자동화 셋팅을 해 나가서 본인들의 지식으로 흡수할 수 있을 만한 환경을 제공해주지 못한것 같았습니다. 그나마 일반 회의실이 아니라 파티룸 형식의 장소를 빌려서 대형 TV와 화이트보드가 있어 활용할 수 있는 것은 많았지만 시간분배의 아쉬움이 남는 워크샵이였습니다.
그래서 하반기때는 꼭 시간을 여유롭게 하겠다는 다짐을 하게됩니다!
| 단점을 보완하여 하반기 워크샵 시작!
상반기 워크샵 이후 약 5개월이 경과하였습니다. 테스트 자동화는 많은 진척이 있었고 전체 시나리오의 약 70% 정도를 커버할 수 있는 시나리오로 구현이 되었습니다. 하지만 과거의 경험을 빗대어 보면 구현률 보다 중요한 것은 유지보수 였습니다. 테스트 자동화에서 결과가 실패일 경우 얼마나 빠르게 해당 내용을 확인하고 보완할 수 있는지가 관건이였습니다.
하반기 워크샵에는 유지보수에 대한 효율적인 방법을 찾는 것과 팀원분들이 5개월간 진행하며 학습하게된 내용을 서로 공유하는 자리를 마련하기로 하였습니다.
물론 시간에 대한 제약을 없애기 위해 CTO님께 워크샵에 대한 방향성과 목표를 정확히 말씀드리고 흔쾌히 결제를 받아 하루를 온전히 워크샵에 사용하게 됩니다. (워크샵 장소로 출근!)
효율적인 유지보수를 위해서 테스트 스크립트 작성에 들어가는 시간을 줄이는 방법을 모색하게 되었습니다. 그 결과로 All in one Locator를 만들어서 작성시간을 줄이는 제안을 팀 내에 하게되었습니다.
기존에는 하단의 코드를 element를 제어해야 할 상황이 있을 때마다 반복적으로 작성해야 했습니다. 코드의 길이도 짧지 않을 뿐더러 AppiumBy 뒤에 Locator도 상황에 맞게 변경해야 했기에 다소 번거로운 작성이 계속되었었죠.
webdriver.find_elements(AppiumBy.
이러한 비효율적인 부분을 없애고자 모든 Locator를 커버하는 Locator 함수를 별도로 제작하였습니다. 코드 작성 길이는 줄이고, Locator를 고민하는 시간도 없애기 위한 시도였죠.
iOS는 ial (iOS All in one Locator) 
Android는 aal (Android All in one Locator) 라는 이름으로 사용할 수 있도록 하였습니다.
직접 Locator를 지정해서 element를 찾는것보다 속도면에서 차이가 없도록 Locator 식별값 자체를 체크해서 적절한 Locator를 지정하도록 했습니다. 실제로 시간 테스트를 했을 때 직접 Locator 지정방식과 시간 차이가 거의 없는 것으로 확인이 되었습니다.
.click() 이나 .send_keys() 도 가능하도록 click은 ialc, aalc 로 사용할 수 있도록 하고 send_keys는 ialk, aalk로 가능하도록 구현했습니다.
추가적으로 테스트 자동화 프레임워크의 구조 변화를 시도했습니다. 
기존에는 시나리오별 구현 방식이였기 때문에 다른 시나리오에서 동일한 element를 사용하는일이 자주 발생하였는데 해당 element의 수정이 필요할때면 관련된 시나리오의 코드를 모두 바꿔야 하는 상황이였습니다.
코드 재활용성이 매우 낮은 상태였기 때문에 코드를 재활용할 수 있는 구조로의 개편이 필요한 상황이였습니다.
큰 비용이 들 것으로 판단되었지만 현재 시나리오 베이스 구현 방법에서 페이지 구조화 방식으로 대대적인 개편을 진행했습니다.
각 화면에서 사용할 element들을 별도의 페이지 파일에 정의해놓고 테스트 크스립트에서는 해당 페이지 파일에 있는 element 컨트롤 코드를 불러와서 하나의 시나리오를 만드는 방법이였습니다.
재활용성은 높아지고 코드 가독성이 상승하게 되었습니다. 다만 시간이 많이 소요될것으로 예상되었기 때문에 장기적인 계획으로 진행하고 있습니다.
UI 테스트 자동화 진행 시 해당 화면에 표시되는 데이터에 대한 정합성 체크를 API로 진행하는 것도 팀 내에 공유하였습니다. 
각 화면에서 사용되는 API를 사용하여 데이터가 중복으로 출력되거나 잘못된 값이 나오고 있지는 않은지 검증에 사용하였고, 테스트 시 임의의 상품을 대상으로 하는데 그럴때마다 옵션값이 모두 다를 수 있는 상황을 해결하기 위해 해당 상품의 정보를 조회하는 API를 사용하여 옵션정보를 가져와 Locator 값으로 사용하기도 하였습니다.
이렇게 워크샵을 진행하며 엔지니어링 관점에서 개선과 변화를 시도를 하였습니다. 여기서 중요한 점은 이러한 내용이 공유 되었을 때 팀원분들이 그것을 단순히 따르는 것이 아니라 그 자리에서 궁금증을 해소하기 위한 문의와 실제 효과에 대한 토론이 진행되었다는 것입니다.
건강한 토론을 위해 팀원분들도 비방이나 맹목적인 신뢰에서 한걸음 벗어나서 최대한 객관적인 판단을 할 수 있도록 노력했습니다. 그 과정에서 의견을 냈던 owner가 미처 생각하지 못했던 부분이 수면위로 떠올라 개선포인트를 찾을 수 있었고 더 나은 방향이 제안되어 방향이 조금 변경된 내용도 있었습니다.
워크샵은 쉬는시간을 포함하여 9시간 가까이 진행되었습니다. 이 과정을 지루하게 여기지 않고 모두 집중력을 유지하며 진행할 수 있었던 것은 해당 워크샵을 진행하기 전에 워크샵의 목적에 대한 공유가 되었고 모두가 공감했기 때문이라고 생각합니다.
현재 우리의 문제점이 무엇인지 명확히 파악하고 그것을 해소하기 위한 공동의 목표를 위해 모두 노력할 수 있었다는 것이 하반기 워크샵의 가장 큰 성공요인이라고 볼 수 있을 것 같습니다.
이렇게 많은 결과를 낼 수 있었던 하반기 워크샵은 즐거운 저녁 회식으로 마무리 되었습니다. 내년에도 QA팀은 워크샵을 진행할 예정이고 올해 하반기 워크샵의 성공적인 진행을 발판삼아 개인과 팀의 성장을 위해 더 생산적인 워크샵이 될 수 있도록 계획할 예정입니다.
이 글의 서두에 이야기 했던 것 처럼 워크샵은 팀원의 팀워크를 위해 사용할 수도 있습니다. 그렇기 때문에 29CM QA팀이 진행했던 워크샵 방법만이 정답은 아닙니다. 
하지만 이런것도 또다른 방향이라고 생각합니다. 환경과 효율개선을 위해 모든 팀원이 치열하게 고민하고 논의하는 시간을 별도로 마련하여 진행하는 것이 정말 놀라운 결과를 가져올 수 있었던 것을 경험할 수 있었습니다. 워크샵의 또다른 가능성을 볼 수 있었고 앞으로도 이런 방향의 워크샵을 진행하게 될 충분한 이유가 되었습니다.
이제 2024년 입니다. 
벌써부터 상반기 워크샵에 대한 기대가 되고 있습니다. 
그것이 끝났을 때 QA팀은 또 한걸음 성장해 있을 것이라는 것을 의심치 않기 때문입니다.
여러분들도 워크샵을 효과적으로 사용하여 많은 성장과 도움을 받으실 수 있으면 좋겠습니다. 감사합니다.
이렇게 QA활동과 지식공유 활동이 활발하게 이루어지고 있는
‘29CM 엔지니어링 조직에 합류하세요!’
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr
29CM QA팀의 2023년 워크샵 200% 활용기 was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

29CM QA팀의 2023년 워크샵 200% 활용기

댓글