ROI가 좋은 자동화 테스트 환경을 구성하기

 

저는 테스트 자동화 환경을 처음 구축할 때, "매번 반복되는 회귀 테스트를 자동화하면 테스트 기간을 절약할 수 있겠다"는 단순한 생각에서 시작했습니다.

 

하지만 곧 이런 의문이 들었습니다.

 

"자동화 대상을 선정해야 하는데, 모든 매뉴얼 TC를 자동화하는 것이 목표가 될 수 있을까?"

"자동화를 다 구성한다면 매뉴얼 테스트를 대체할 수 있는 것일까?"

"자동화를 구성해도, 유지보수 공수가 더 든다면 안 하는 게 나은 거 아닐까?"

 

결론적으로, 매뉴얼 테스트를 대체할 자동화를 만드는 것이 목표가 아니라 '투자 대비 효과'가 핵심이라는 걸 깨달았습니다.

 

제가 자동화를 구성하면서 고민했던 자동화로 생성할 TC를 선정하는 과정 'ROI가 높은 테스트 선정 기준'에 대해 정리해보겠습니다.

 

 

---

 

유지보수 비용에 대한 고민

 

자동화를 구성하기 전, 가장 먼저 고려해야 했던 주제였습니다.

 

사실 한 번에 자동화를 구성할 수 있던 것은 아니었고, Katalon이라는 툴을 활용해서 코드 개발 부분을 최소화해서 자동화 환경을 구성해보려고 했었습니다.

 

하지만, 식별자 인식문제나 재사용성, Katalon이라는 툴로 관리하는 방식 등 자동으로 만들어준다는 이점보다 관리 공수가 더 드는 것 같다는 생각이 들어서 첫 도입은 포기하고, 실패했었습니다

 

그래서 가장 먼저 생각하게 되는 것은 자동화 환경을 다 만들어놨더니 수정하는 시간이 더 든다면, 그냥 손으로 테스트하는 게 더 빠를 수 있지 않을까? 였습니다.

 

아마 많은 분들이 이 부분을 생각하며 자동화 환경을 구성하실 것이라고 생각됩니다.

 

그래서 이전 포스팅 했던 글처럼 POM 구조로 자동화 환경을 구성했고, 요소들이나 자주 사용되는 함수를 캡슐화하는 방식으로 구성하며 UI의 변경 사항이 크지 않다면 빠르게 변경사항을 반영하여 자동화 동작을 정상화 할 수 있는 환경을 구성하게 되었습니다.   

 

2024.09.08 - [QA/기능 자동화] - 기능 자동화, POM(Page Object Model) 구조 만들기

기능 자동화, POM(Page Object Model) 구조 만들기

 

그리고, 여러 라이브러리의 기술 조사를 수행하고 Playwright를 자동화 툴로 선정하여 자동화 동작에 대한 안정성을 높였습니다

 

 

Playwright에는 자체적으로 요소가 나타날 때까지 기다리는 방식도 활용하고, 크로스 브라우저 환경을 지원하는 등 업무에 필요했던 기능을 많이 포함하고 있어서 활용하게 되었습니다. (상세한 분석은 다른 포스팅에서 다뤘기 때문에 간단하게 언급)

 

이런 방식으로 라이브러리 특성과 POM 구조를 통해 어느 정도 빠른 대응이 가능한 유지보수 환경을 구성하게 되었고, 어떤 TC를 자동화할 것인지에 대한 고민을 시작하게 되었습니다. 

 

---

 

필수 자동화 대상 선정

 

꼭 해야 하는 자동화 TC는 무엇일까를 고민했고, 빠른 답을 얻을 수 있었습니다.

 

정말 귀찮지만, 매번 테스트 기간에 수행해야 했던 것들.

 

 이것이 자동화를 구성하려던 목적이었기 때문에, 우선적으로 스크립트로 구성했던 TC였습니다.

 

매뉴얼 TC를 관리했을 때, 빠른 릴리즈에 대응하기 위해 필수로 수행해야 하는 스모크 테스트 목록을 모아서 만들어놨던 사용자 시나리오 테스트 케이스를 활용했습니다.

 

사용자 시나리오를 수행했을 때 정상적으로 수행된다면, 제품의 상세한 테스트까진 아니어도, 정상적으로 돌아가는 제품이구나를 판단하는 기준이었고, 이를 자동화로 구성하였습니다.

 

시나리오를 구성할 때 생각했던 것은, 여러 시나리오를 병렬로 동시에 수행하여 많은 테스트를 빠르게 처리하는 환경을 생각했습니다.

 

그럼 중요한 것은 시나리오 간 동시에 수행해도 영향을 받지 않는 스크립트

 

 

Playwright의 장점인 병렬로 동시에 테스트를 수행할 수 있는 장점을 살리기 위해, 제품에서 스크립트 간 서로 영향을 주지 않는 범위를 구성했고, 영향을 주지 않기 위한 환경 구성은 사전 데이터 생성 스크립트를 작성하게 되었습니다.

 

자동화를 한 번도 수행해 본 적이 없는 환경인 경우, 사전 데이터 생성 스크립트를 딱 한번 수행하고, 이후엔 자동화 시나리오만 바로 수행할 수 있는 환경을 구성해서 빠른 실행과 결과를 얻을 수 있는 환경을 만들게 되었습니다.

   

---

 

E2E 자동화 테스트에서 ROI(투자 대비 수익 효율)가 좋은 TC 선정

 

앞서 유지보수 관점과, 필수 테스트에 대해 얘기한 것은 ROI를 얘기하기 위한 빌드업이었습니다.

 

이전에 설명한 것처럼, 유지보수와 핵심 테스트, 빠른 테스트를 위한 설계는 진행했고, 테스트 케이스를 확장해야 하는 단계에 도착했습니다.

 

많은 매뉴얼 테스트 케이스를 전부 자동화로 변환하는 것은 비효율적이라고 생각되었고, 어떤 기준으로 TC를 선정할지 고민하게 되었습니다.

 

 

테스트 피라미드에 나오는 설명처럼 Unit Test, API Test, E2E Test로 구분하여 테스트 담당 영역을 구분하는 것이 필요했습니다.

 

E2E 테스트에서 중요하게 봐야 할 것은 무엇인지 생각해 보게 되었고, 데이터 검증이나, 기능 검증 부분은 API와 Unit 테스트로 대체하거나 가끔 수작업으로 검증하자는 생각을 하게 되었습니다.

 

즉, 각자의 역할을 잘 살릴 수 있는 자동화를 구성하면 효율적인 환경 구성이 될 것이라고 생각했습니다.

 

---

 

우선순위 매트릭스 구성

 

사실 업무를 진행할 때는 매트릭스까지 구성을 하면서 작업을 하진 않았지만, TC를 확인해 보며 선정했던 방식을 명확하게 표현할 수 있을 것 같아서 작성해 보겠습니다.

 

 

모든 매뉴얼 TC에 기준을 적용하여 체크하진 않았지만, TC를 하나씩 확인해 보며 우선적으로 작업해야 할 대상을 선정할 수 있었습니다. 

 

각각의 TC마다 적용하는 게 오래 걸린다면 간단하게 체크리스트로 만들어서 우선순위를 적용해도 좋을 것 같습니다.

 

예를 들면,

• 배포 때 항상 수행해야 하는 TC인가?
• TC가 실패하는 경우 비즈니스 영향도가 큰가?
• 자동화 구성하는데 단시간에 구성할 수 있는가?
• 자주 변경되지 않는 기능인가? 

등등.. TC를 스크립트로 작업할 내용인지 빠르게 검토하고 개발할 수 있는 기준을 체크리스트로 만들 수 있을 것 같습니다.

 

---

다수의 매뉴얼 TC를 하나의 시나리오로 구성 

 

아래 내용은 제가 생각한 설계 방식이었고, 회사마다 추구하는 방향이 다를 수 있어서 의견이 다를 수 있을 것이라 생각됩니다!! 
내용 참고만 해주세요!

 

우선순위가 높은 매뉴얼 TC를 선정하고, 이를 시나리오화 하는 작업을 진행했습니다.

 

저는 각 TC에 1:1로 매핑해서 스크립트를 운영한다면 대상 기능을 수행하기 위한 사전 과정(로그인이나 테스트에 필요한 환경 생성 등) 이 불필요하게 반복된다고 생각되어서 시나리오로 구성해야겠다고 생각했습니다.

 

예를 들면, 고객과 상담사의 채팅 중 파일 전송을 검증하는 TC가 있다면,

• 고객이 진입하여 대화방을 만드는 TC
• 상담사가 로그인하는 로그인 TC
• 상담사에 새로운 대화가 생겼을 때 알림 확인하는 TC
• 상담사의 대화 가능 상태로 변경하는 TC
• 고객과 상담사의 채팅 내용이 정상적으로 표시되는지 확인하는 TC
• 고객이 전송한 파일을 상담사가 확인할 수 있는 TC

 

이런 TC들을 하나의 파일 전송 확인 시나리오로 만들어서 하나의 자동화 시나리오가 여러 TC를 처리할 수 있도록 구성하였습니다.

스크립트에는 어떤 TC들이 사용되었는지, Step으로 구분해서 관리하여 중간에 실패하는 경우 어떤 TC에서 실패했는지 확인할 수 있도록 작업했습니다.

 

---

매일 수행할 수 있는 환경으로 구성 (Jenkins)

 

자동화 환경을 구성하면, 기계가 테스트를 수행하는 만큼, 개발건이 있을 때마다 혹은 매일 돌리는 환경을 구성하는 게 필요하다고 생각했습니다.

 

사실 이 내용은 다른 포스팅에서 다뤘던 내용이기에, 상세한 내용은 링크한 포스팅에서 확인해 주세요 :)

 

https://qa-subi.tistory.com/37

기능 자동화 기술조사부터 환경 구성까지

 

---

자동화를 구성하고, 기존 대비 ROI가 좋아졌는가?

 

매뉴얼 TC를 재 분류하여, 기능, API 테스트에서 대체될 수 있는 TC로 구분했고, 기능 부분에 해당하는 항목 중 우선순위가 중간급 이상인 항목들은 자동화 스크립트로 구성하게 되었습니다.

 

자동화를 수행하는 것만으로 제품이 정상적으로 돌아간다는 것을 확인했고, 매일 수행되는 작업이기에 신규 개발건에 Side Effect를 바로 확인할 수 있는 환경이 구성되었습니다.

 

그래서 애자일 환경에서도 자동화가 구성되지 않은 신규 기능만 확인하면 되는 환경을 구성할 수 있게 되었고, 2주 정도 소요되던 테스트 기간을 3~4일로 단축했기 때문에 ROI가 좋아진 환경을 만들었다고 말할 수 있을 것 같습니다.

 

 

그래도 아직 남아있는 문제는 매뉴얼 TC 중 우선순위가 낮은 항목까지 자동화 스크립트로 구성해야 할까라는 고민은 남아있습니다.

 

자동화를 구성한다면, 상세한 항목까지 매일 테스트되는 것이니, 도움 되는 것은 맞지만, 새로운 기능에 대한 자동화를 처리할 시간이 부족한 점, 여유 있는 리소스는 아니기 때문에, 효율적이지 않은 부분까지 해야 할까 라는 고민...

 

다른 곳은 어떻게 하고 있는지 궁금한 내용이기도 하네요 🤔

 

---

 

예전 포스팅에서 자동화를 구성한 방식을 정리한 적은 있지만, 스크립트를 어떻게 선정했고, 효율적으로 다뤘는지에 대한 내용이 없었던 것 같아서 작성해 보게 되었습니다.

 

제가 정답이라고 생각하지 않고, 나는 이렇게 했는데 다른 사람들은 어떻게 했을까? 생각해 보게 되었고, 아직도 개선할 점이 곳곳에 보이는 자동화 환경 구성 프로젝트였습니다.

 

많은 기업에서 환경 구성한 방식이나, QA 팀을 어떻게 구성했고, 어떤 식으로 운영되는지 많이 알려주고 있는 것 같아요.

저도 많이 참고해서 더 좋은 QA가 되기 위한 노력을 하는 것으로...! 포스팅을 마무리하겠습니다.

 

읽어주셔서 감사합니다 :)