💡 QA 자동화, 어디까지 해야 할까?

※ 이 글은 개인적인 경험과 주관을 바탕으로 작성되었습니다.

 

📌 Introduction

요즘 QA 업계에서 가장 많이 이야기되는 주제 중 하나가 바로 테스트 자동화이다. 나 역시 부트캠프에서 자동화를 중심으로 교육을 받았는데, 당시에는 거의 모든 기능에 대한 테스트 시나리오를 작성하고, 이를 자동화 코드로 구현하는 방식을 경험했다. 하지만 문득, 실무에서도 정말 모든 기능을 자동화할까? 오히려 유지보수 측면에서 더 큰 비용이 들지는 않을까 하는 고민이 생겼다.

 

📌 자동화 하기 좋은 부분

내가 생각하기에 자동화하기 가장 좋은 영역은 핵심적이고 반복적으로 수행되는 테스트이다. 특히 Hotfix나 Release 전에 반드시 확인해야 하는 기능들이 여기에 해당한다. 이러한 기능은 기능적으로 큰 변경이 자주 발생하지 않으면서, 새로운 기능 도입이나 기존 기능 고도화가 있더라도 운영 중인 서비스의 핵심 영역에서 사이드 이펙트가 없는지 확인이 필요한 영역이다.

 

예를 들어, 로그인, 결제, 핵심 UI 버튼 클릭과 같이 반복적인 기능은 자동화가 확실히 도움된다. 반대로 UI가 자주 변경되는 화면이나 신규 기능, 빠르게 진화하는 기능들은 자동화 시 유지보수 비용이 예상보다 더 커질 수 있다. 결국, 모든 기능을 자동화하는 것은 실무에서 거의 불가능하며, 자동화의 이점보다 부담이 커질 수 있다.

 

📌 테스트 자동화 전략

• 우선순위 기반 자동화: 핵심 기능 -> 반복 테스트 -> 안정적인 기능
• 테스트 대상 선정 기준: 변경 빈도, 중요도, 릴리즈 영향도
• 테스트 코드 설계: 코드 모듈화와 재사용성을 고려(POM, 컴포넌트 패턴, BasePage 등)
• UI 변경 대응: XPath, CSS 선택자 등 유연한 선택자 사용 -> UI 변경 시 코드 수정 최소화

 

사실 아직 QA로서의 실무 경험이 많지 않다 보니, 우선순위를 판단하거나 테스트 대상을 선정하는 경험과 감각은 아직 부족하다. 하지만 부트캠프에서는 POM과 컴포넌트 패턴을 활용해 테스트 코드를 설계할 때, 중복 코드를 많이 줄일 수 있었고, BasePage를 통해 공통 기능을 한 곳에서 관리하니 유지보수가 훨씬 수월했다.

 

📌 자동화 장단점

• 장점
  • 반복 테스트 시간 단축
  • CI/CD 연계 가능 -> 배포 전 안정성 확보
• 단점
  • UI/기능 변경이 잦은 경우 유지보수 비용 증가
  • 초기 설계/구현 비용이 비교적 높음
  • 모든 기능을 자동화할 수는 없음

 

즉, 반복은 자동화하되, 변화는 사람이 검증한다.

실무에서는 모든 기능을 자동화하려고 하기보다, 핵심 기능 중심, 우선순위 기반, 유지보수 용이성을 고려한 전략적 접근이 필요한 것 같다.