요새는 회사에서 GPT-4를 사용할 수 있어서, 그것을 활용해서 업무를 진행하고 있습니다. 어떻게 시작해야할지 모르는 부분에서 GPT에게 물어보면, 그것이 진짜인지 가짜인지는 둘째치고, 어떤 아이디어를 얻기에는 충분합니다.
얼마 전에는 Playwright를 사용해서 웹 프로덕트의 회귀테스트를 자동화하였습니다. 이전에 Selenium을 쓰던 저에게는 매우 신선했고, Element를 쉽게 도출해낼 수 있었습니다.
근래 팀내 스터디 시간에는 AI를 이용하여 테스트코드를 작성해주는 크롬 익스텐션에 대해서 대화를 해본 적도 있습니다.
이처럼 테스트 자동화 업무는 점점 더 쉬워지고 있는데요, 이것에 대한 생각을 짧게 기재해봅니다.
존재하는 Needs
시스템 테스트, 인수 테스트 레벨을 자동화 하고싶어하는 욕구는 예전부터 존재해왔습니다. 특히 UI를 조작해야하는 많은 양의 유저 시나리오를 포함하고 있는 인수 테스트 레벨, 혹은 매 배포마다 기존 기능이 문제없는지 확인해야하는 회귀 테스트의 경우에는 더욱 그러하였습니다.
반복되는 테스트를 빠르게 수행하고 싶은 조직
애자일화 되어가는 조직의 형태에서는 지속적인 배포를 필요로 하는데요, 여기서 배포를 진행할 때마다 필요한 테스트를 자동화하여 좀 더 빠르게 고객에게 제공할 수 있도록 하는 것이 권장되고 있습니다. 매 배포마다 테스트를 수동으로 해야한다면, 그만큼 애자일하지 못한 제품 제공 속도가 될 것이기 떄문이죠.
그래서 많은 조직에서는 인수 테스트 / 회귀 테스트 (특히 UI의 조작이 필요한 테스트) 를 자동화하고 싶어합니다.
개발 과정에 자동화된 테스트를 녹이고 싶은 조직
굳이 꼭 애자일한 조직이 아니더라도, 코드 통합과정이나 배포 과정에 자동화된 테스트를 포함시킨다면, 어떠한 이슈가 있을 때 메일이라던지 슬랙으로 notification이 간다면 개발자들은 그러한 피드백을 통해 코드 수정을 빠르게 진행할 수 있을 것 입니다.
매 과정마다 이러한 것들이 자동적으로 이루어진다면, 실제 프로덕션 환경에서 발생할 이슈는 현저하게 줄어들 것입니다. 위에서 서술한 제품 배포를 빠르게 하기 위한 테스트 자동화 욕구도 있지만, 제품의 민첩한 개발과 테스트 후 빠른 피드백 반영을 위해서도 테스트를 자동화시키고 싶은 조직들도 있습니다.
반복된 업무를 효율적으로 처리하고 싶은 테스트 담당자와 테스트 조직
한 편, 프로덕트의 매 배포마다 회귀테스트와 같은 반복적인 테스트를 수동으로 수행해야하는 테스트 담당자들에게는 그러한 작업이 매우 지루할 수 밖에 없습니다. 반복적인 테스트를 수행할 시간에 사용성 테스트라던지 탐색적 테스트와 같은 사람의 직관이 필요한 테스트를 수행한다면 더욱 더 의미있는 테스트활동이 될 것 입니다. 더군더나 같은 테스트 내용을 반복적으로 수행하다보면, 제대로 확인하지 않는다던지 등의 Human error가 발생할 수 있습니다. (이슈인 부분을 제대로 알아차리지 못하고 넘어간다던지 등)
테스트의 효율화뿐만 아니라 투자하는 코스트 측면에서도 테스트를 자동화하고 싶어하는 조직도 존재합니다. 프로덕트가 커지면 커질수록, 서비스 기간이 길어지면 길어질수록 수행해야하는 회귀테스트의 크기도 늘어나고, 배포일정에 맞추려면 많은 인원이 투입되어야하는 경우도 발생합니다. 이런 경우라면 테스트를 자동화로 인해 3명이 수동테스트해야할 것들을 2명이서도 가능하게 한다던지, 이러한 코스트의 절약을 원하는 조직도 있습니다.
이러한 고민거리를 가지고 있던 테스트 담당자와 테스트 조직은 자연스레 테스트 자동화에 대해 관심을 가질 수 밖에 없습니다.
커리어 향상을 원하는 테스트 담당자
미국을 포함한 외국에서는 이미 아래와 같은 포지션들이 이전부터 존재해왔습니다.
- Test Engineer
- Software Engineer in Test
- Software Development Engineer in Test
- Test Automation Engineer
하는 역할들은 조금조금씩 다르긴 하지만, 다 테스트와 관련된 직군들이며, 이들의 공통점은 코드를 통해 테스트를 수행한다던지, 자동 테스트를 위한 어떠한 툴이나 프레임워크를 개발한다던지 하는 개발직무들이었습니다.
수동 테스트를 메인 업무로 하던 많은 QA/테스트 담당자들은 자신들의 업무 효율화와 함께 처우를 개선하고자 하는 욕구 및 커리어 발전을 위해 코딩을 하기 시작했고, 테스트 관련 라이브러리와 프레임워크에 대해 공부를 하기 시작했습니다. 이는 곧 QA/테스트 업계에 큰 바람을 불러오게 되었습니다.
(구글링을 하다보면 일부 종사자들은 테스트 자동화가 무조건 짱이야! 라고 생각하는 사람도 있는 것을 알 수 있습니다.)
그럼에도 불구하고 쉽게 하지 못했던 테스트 자동화
그럼에도 불구하고 테스트 자동화는 쉽게하지 못했습니다. 개발자가 작성하는 유닛테스트 혹은 통합테스트 보다 테스트 자동화하기가 까다로우며 자동화를 위한 코스트 투자 대비 성과 가 크게 나타나지 않는 부분이었기 때문입니다.
좀 더 자세히 살펴 보자면..
규모의 문제
일단 기업이 왠만한 규모가 아니고서야 테스트 부분에 투자하기가 어렵습니다. 스타트업 규모의 작은 기업에서는 일단 유닛테스트 정도는 개발자가 작성할 수 있는 부분이고, 시스템 테스트 레벨은 배포 직전에 적당히 기획자, 디자이너, 개발자가 다 같이 세션을 열어서 확인하고 내보내도 된다고 생각하는 사람이 많기도 하고, 실제로도 많은 기업이 그렇습니다.
요새야 작은 기업이라고 해도 QA/테스트 담당자를 고용하는 기업이 많지만, 이들 조차 반복적인 테스트를 자동화 시키기에는 업무가 너무 많아 자동화할 시간을 내기도 빠듯한 상황이죠.
별도의 테스트 자동화 인력을 충원하기에는 회사 규모가 작아 테스트보단 디자인, 개발쪽에 좀 더 리소스 투자 우선순위가 높은 편입니다.
하물며 주로 자동화를 하는 회귀 테스트의 경우, 자동화를 한다고 해서 사람이 못찾아내던 버그를 쉽게 찾아낸다던지 하는 경우는 거의 없습니다. 투자 대비 효과가 크지 않다고 느낄 수도 있습니다. 때문에 적은 규모의 기업에서는 투자 대비 효과가 크게 나타나지도 않는 테스트 자동화에 굳이 투자하고자 하는 마음도 없고, 여력도 없는 것입니다.
즉 테스트 자동화를 하기 위해서는 회사의 규모가 어느정도 되어야지 관련 인원들을 충원하여 시작할 수 있다는 뜻입니다.
관련 기술에 숙달된 인력 부족의 문제
이전까지는 테스트 자동화에 대한 기술에 대해 숙달된 인력이 시장에 부족하기도 하여 관련 인원들을 충원하는 것이 쉽지 않았습니다. 몇몇 기업에서는 개발자에게 시스템 테스트의 자동화를 맡기는 경우도 보았지만, 개발자는 일단 자신이 직접 프로덕트를 만드는 것을 좋아하지, 테스트 코드를 짜는 것을 좋아하진 않습니다.
테스트 자동화 기술을 알려주는 교육기관도 전무하였습니다. 때문에 관련 기술에 대해 어느정도 숙달된 인력이 시장에 공급되지도 않았습니다.
결국 사내 QA/테스트 담당자들이 바쁜 업무 중에도 조금씩 시간을 할애하여 테스트 자동화를 구현하고, 이것이 조금씩 경험으로 쌓여 기술을 익혀나가는 수준이었습니다. 그리고 그 팀에 소속되어 같은 기술을 공유하던 팀원들이 이직을 하면서 조금씩 관련 인력들이 퍼져 나갔습니다.
그러나 이것도 극히 일부의 경우였으며, 테스트 자동화 구축을 원하는 조직의 입장에서는 관련 인력을 충원하여 시작하기가 어려운 상황이기도 하였습니다.
프로덕트의 빠른 Delivery 속도
게다가 테스트 자동화의 허들에는 프로덕트의 빠른 Delivery(배포) 속도도 한 몫을 합니다. 근래의 많은 프로덕트들은 빠른 배포를 통해 시장의 반응을 살피고, Next step을 구상하는 것이 자연스러운데요, 이 과정에서 UI가 자주 변하고, 여기에 많은 양의 A/B테스트를 포함한다면, 유지보수해야하는 자동 테스트 스크립트의 양(특히 UI 조작을 기반으로 하는 회귀 테스트 등)은 매우 많아지게 됩니다.
결국 자동 테스트의 유지보수가 실제 프로덕트의 속도에 제대로 따라가지 못하는 경우가 발생하게 됩니다.
전문 자동화인력이 아닌 기존 QA/테스트 담당자가 이러한 자동 테스트 코드의 유지보수도 해야한다면, 당장의 배포나가야할 기능의 테스트를 하느라 바빠서 유지보수해줘야할 코드가 그대로 레거시화가 되어갈 수도 있습니다.
테스트 자동화의 허들을 낮추는 기술들
위와 같이 기존 수동 테스트를 자동화하고자 하는 needs는 어느정도 있었으나, 여러모로 어려웠었습니다.
그러나 근 1~2년 사이에 테스트 자동화의 허들이 많이 낮아졌습니다. 왜일까요?
라이브러리의 발전
일단 라이브러리들이 매우 편해졌습니다.
특히 마이크로소프트에서 개발하고 있는 Playwright의 경우에는 브라우저에서 직접 element를 식별해서 코드로 옮겨주는 codegen 을 내장해주고 있고, 이슈가 있을 때 debugging을 도와주는 Trace viewer 도 있습니다.
Selenium도 4.0으로 버전업되면서 relative locators 기능을 통해, 특정 Element로부터 상하좌우에 위치해있는 element를 조작하는 기능도 생겼습니다. 조작하기 어려운 element도 조작을 쉽게할 수 있는 기능인 것입니다.
모바일 앱을 자동화할 때 사용되는 Appium은 어떤가요? Appium 2.0에 돌아오면서 이전에는 매우 불편했던 설치과정들이 간편하게 바뀌기도 하였습니다.
테스트 전략에 따라서는 많은 assertion에 대해 유지보수를 하느라 힘들어 할 필요도 없어집니다. visual testing의 경우에는 비교원본과 다른 부분이 있다면 알아서 알려주기도 합니다.
이 외에도 많은 라이브러리들이 복잡하고 어려운 동작들은 추상화를 통해 제공해주고 있으며 사용자들에게 신경써야할 부분들을 더욱 더 줄여주고 있습니다. 최초 코드 작성뿐만 아니라 유지보수 하는데에 있어서도 편의성을 제공해주고 있습니다.
이런 라이브러리들이 여러 프로그래밍 언어에 대응하면서 더더욱 테스트담당자들의 러닝커브는 낮아지고 있습니다. 당장 본인이 흥미가 있는 언어를 선택하고, 자동화를 시작하기만 하면 되죠.
이러한 변화들이 테스트담당자들에게 난이도가 높았던 테스트 자동화를 쉽게할 수 있도록 도와주고 있는 것 입니다.
교육 프로그램의 등장
이전에는 교육 프로그램들이 거의 전무하다시피 했지만 요근래에는 많은 교육플랫폼에 등장하고 있습니다.
대표적으로 Udemy에서는 소프트웨어 테스팅 카테고리가 별도로 있을 정도이며, 해당 카테고리르 조회해보면 현업에 종사하는 테스트 자동화 프로들의 강의를 확인할 수도 있습니다.
GPT를 포함한 AI의 등장
GPT를 포함한 생성형 AI의 등장은 테스트 자동화 난이도를 한층 더 낮추는 역할을 하였습니다. 기존에는 코드를 어떻게 작성해야할지 모르는 테스트 담당자들에게, 첫 삽을 쉽게 뜰 수 있도록 도와준다는 것이죠. 심지어 코드들에 대해 Page Object Model로의 리팩토링도 도와주기도 합니다.
AI는 매우 친절해서 어떤 의존 라이브러리를 설치해야하는지 부터 테스트 코드를 친절하게 작성해줍니다. 이 내용이 실제로 동작이 가능한 코드인지 아닌지 확인하는 것은 둘째치고, 코드를 어떻게 구성하고 어떻게 작성하기 시작해야하는지에 대한 어떠한 Entry point 제공하는 역할로는 충분하다는 것입니다.
더 나아가서는 테스트를 구현해야할 페이지의 html 구조를 분석한 다음 코드를 생성해주는 크롬 Extension도 등장했습니다. 이 익스텐션은 GPT4를 기반으로 동작합니다.
AI/ML를 활용한 No-coding Tool
AI는 테스트 담당자에게 코드를 제공해주는 것뿐만 하는 것은 아닙니다. 이미 많은 기업은 AI와 Machine learning을 이용한 노코딩 툴을 판매하기 시작하였습니다. 코딩을 하지 않으면서도 어떠한 명령어만 조금씩 설정해주면 그대로 수행하는 것입니다.
사실 이러한 상품은 기존 시장에도 존재하였는데, 그것들과 AI를 사용하는 프로덕트와의 차이는 Self-healing, 즉 화면 상에 특정 Element를 찾지 못했을 때 자동으로 페이지를 다시 스캔해서 찾아주는 기능인 것이죠. self healing은 더 나아가 유지보수가 필요없는 자동 테스트라며 광고를 하는 프로덕트들도 있습니다.
Self healing empowers teams to adopt a Shift Left approach in the Agile methodology. Not only does it make the testing process efficient, but it also allows for an increase in productivity and faster delivery. Many open-source and commercial tools are available in the market that support self healing test automation using Machine Learning and Artificial Intelligence (AI).
https://testsigma.com/blog/self-healing-tests-maintenance-testsigma/
이러한 툴 들은 테스트 자동화에 대한 관련 지식이 부족한 테스트 담당자라도 쉽게 사용가능합니다. 크기가 큰 기업이라면 금액을 지불하더라도 오히려 이러한 툴을 사용하는 것이 더 이익일 수도 있습니다.
현업에서 테스트 자동화를 하다보니 이전에 갓 공부를 시작할 때 보다는 허들이 많이 낮아지는 것을 체감하고 있어서, 글을 써봤습니다. 이렇게 쉬워지는 테스트 자동화 덕분에 오히려 구직시장에서는 테스트 자동화의 경험이 큰 어필포인트가 안될 수도 있겠다~ 라는 생각은 듭니다. 앞으로 테스트 자동화쪽으로 커리어 전환을 하고자하는 사람들은 어떻게하면 시장에서 long-run 할 수 있을까요?
끝!
