90DaysOfDevOps (Day 7)

고태규·2025년 9월 8일
0

DevOps

목록 보기
6/21
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 7 - Isn't Test Automation A Silver Bullet


1. 테스트 자동화의 도전 과제와 해결 방안


새로운 기능을 구현하지 않더라도 기존 기능의 동작을 변경하거나 업데이트하는 경우가 많은데, 이는 CI/CD를 하고 있음을 의미하고 당연히 지속적인 테스팅도 필요하다는 것을 의미한다.

이런 점에서 테스트 자동화는 매우 중요하며, 자동화된 테스트 코드가 있다면 훨씬 빠르고 안정적인 실행으로 더 넓은 범위를 커버할 수 있다. 하지만, 테스트 케이스를 자동화하였다고 신뢰성, 견고성, 안정성이 해결된 것은 아니다.

따라서, 해당 강의에서는 테스트 자동화에서 아직 존재하는 잠재적 위험과 도전과제에 대해서 논의한다.

1-1. 잦은 업데이트와 변경

애자일 환경에서는 고객 피드백에 따라 기능의 동작이 자주 바뀌기 때문에, 테스트가 실제 기능과 동기화되지 않으면, 고객의 기대와 전혀 다른 것을 테스트하고 있을 위험이 있다.

따라서, 테스트 케이스를 기능의 구현상황에 맞추어 지속적으로 업데이트하고 동기화해야한다.

1-2. 애자일 환경의 시간적 제약

2~3주 정도의 짧은 스프린트 후에 작동하는 제품을 만들어야하므로, 테스트 활동을 개발과 동시에 시작하지 않으면 시간 내에 완료하기 힘들다.

따라서, 개발팀이 개발 초기 단계부터 QA 팀과 소통하고 참여를 유도하여, 설계 단계부터 QA가 참여하여 기능의 '테스트 용이성 (Testability)' 에 대해 논의해야한다.


1-3. 테스트의 불안정성 (Instability)

동일한 기능에 대해 여러 버전을 배포하여 테스트 하는 A/B 테스팅이나 Canary Deployments 시, 테스트 결과가 불안정하게 나오는 경우가 있다.

특히 프론트엔드 자동화에서는 웹 페이지의 동적인 스크립트 때문에 어려움이 많아 테스트 결과가 실패하는 경우가 빈번합니다.

따라서, 자주 변경되는 CSS 클래스 이름 같은 불안정한 식별자 (locator) 대신, 개발팀과 협력하여 data-test-id와 같이 변경 가능성이 적고 신뢰할 수 있는 고유 식별자를 사용하여 테스트의 안정성 (Robustness)을 크게 높일 수 있다.


1-4. 테스트 용이성 (Testability) 문제

다른 시스템에서 데이터가 생성되어야만 우리가 테스트하려는 기능이 동작하는데, 그 데이터를 생성할 권한이나 방법이 없다면 테스트를 시작조차 할 수 없다.

따라서, 개발팀과 협력하여 테스트 목적으로 특정 조건을 발생시킬 수 있는 '별도의 API나 Interface'를 만들어달라고 요청할 수 있다. 또는, '실제 연동 시스템을 흉내 내는 가짜 객체, 목 (Mock)이나 스텁 (Stub)'을 활용하여 의존성을 해결할 수 있다.


1-5. 특수 컴포넌트 테스트 (하드웨어 및 AI)

하드웨어와 연동되는 소프트웨어를 테스트하려면, 하드웨어에서 오는 신호나 메세지를 시뮬레이션해야하는 제약사항이 존재하며, AI나 ML 모델의 경우 인공지능이 추천하는 검색 결과의 관련성이 높은지 기능 테스트만으로 검증하기 어렵다.

따라서, 하드웨어의 동작을 흉내 내는 시뮬레이션 환경을 구축하거나, AI/ML 기능은 수동 테스트, 탐색적 테스팅, 벤치마킹 등 다양한 활동으로 품질을 보완해야 한다.


1-6. 비기능적(Non-functional) 측면의 품질

품질은 기능뿐만 아니라 성능, 사용성, 안정성 등 여러 비기능적 요소를 포함하며, 테스트 자동화만으로는 이러한 모든 측면을 보장할 수 없다.

따라서, 자동화 테스트를 기본으로 삼되, 수동 및 탐색적 테스트 (버그 배쉬, 도그푸딩)를 병행해야한다. 또한, 카오스 테스팅과 같이 시스템의 일부에 의도적으로 장애를 발생시켜 예기치 않은 상황에서 시스템이 어떻게 반응하는지 복원력을 테스트할 수 있다.

1-7. 구현 및 유지보수의 어려움

  • 복잡한 테스트 환경 설정 : 테스트를 위해 이메일 서버를 구축하는 등 복잡한 환경 설정이 필요할 수 있음
  • 긴 실행 시간: 테스트 실행 시간이 너무 길어지면 CI/CD 파이프라인을 지연시킴
  • 코드 중복: 여러 테스트케이스에 동일한 코드가 반복되면 유지보수가 어려워짐
  • 버그 관리: 테스트 실패시, 실제 버그인지 테스트 코드의 문제인지 파악하기 어려움

이를 해결하기 위해 반복되는 코드는 별도의 Helper 클래스나 유틸리티 함수로 만들어 재사용성을 높이거나, 병렬 실행을 도입하여 불필요하게 오래 걸리는 테스트 단계를 최적화 한다.


0개의 댓글