해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 7 - Isn't Test Automation A Silver Bullet
새로운 기능을 구현하지 않더라도 기존 기능의 동작을 변경하거나 업데이트하는 경우가 많은데, 이는 CI/CD를 하고 있음을 의미하고 당연히 지속적인 테스팅도 필요하다는 것을 의미한다.
이런 점에서 테스트 자동화는 매우 중요하며, 자동화된 테스트 코드가 있다면 훨씬 빠르고 안정적인 실행으로 더 넓은 범위를 커버할 수 있다. 하지만, 테스트 케이스를 자동화하였다고 신뢰성, 견고성, 안정성이 해결된 것은 아니다.
따라서, 해당 강의에서는 테스트 자동화에서 아직 존재하는 잠재적 위험과 도전과제에 대해서 논의한다.
애자일 환경에서는 고객 피드백에 따라 기능의 동작이 자주 바뀌기 때문에, 테스트가 실제 기능과 동기화되지 않으면, 고객의 기대와 전혀 다른 것을 테스트하고 있을 위험이 있다.
따라서, 테스트 케이스를 기능의 구현상황에 맞추어 지속적으로 업데이트하고 동기화해야한다.
따라서, 개발팀이 개발 초기 단계부터 QA 팀과 소통하고 참여를 유도하여, 설계 단계부터 QA가 참여하여 기능의 '테스트 용이성 (Testability)' 에 대해 논의해야한다.
특히 프론트엔드 자동화에서는 웹 페이지의 동적인 스크립트 때문에 어려움이 많아 테스트 결과가 실패하는 경우가 빈번합니다.
따라서, 자주 변경되는 CSS 클래스 이름 같은 불안정한 식별자 (locator) 대신, 개발팀과 협력하여 data-test-id와 같이 변경 가능성이 적고 신뢰할 수 있는 고유 식별자를 사용하여 테스트의 안정성 (Robustness)을 크게 높일 수 있다.
다른 시스템에서 데이터가 생성되어야만 우리가 테스트하려는 기능이 동작하는데, 그 데이터를 생성할 권한이나 방법이 없다면 테스트를 시작조차 할 수 없다.
따라서, 개발팀과 협력하여 테스트 목적으로 특정 조건을 발생시킬 수 있는 '별도의 API나 Interface'를 만들어달라고 요청할 수 있다. 또는, '실제 연동 시스템을 흉내 내는 가짜 객체, 목 (Mock)이나 스텁 (Stub)'을 활용하여 의존성을 해결할 수 있다.
하드웨어와 연동되는 소프트웨어를 테스트하려면, 하드웨어에서 오는 신호나 메세지를 시뮬레이션해야하는 제약사항이 존재하며, AI나 ML 모델의 경우 인공지능이 추천하는 검색 결과의 관련성이 높은지 기능 테스트만으로 검증하기 어렵다.
따라서, 하드웨어의 동작을 흉내 내는 시뮬레이션 환경을 구축하거나, AI/ML 기능은 수동 테스트, 탐색적 테스팅, 벤치마킹 등 다양한 활동으로 품질을 보완해야 한다.
품질은 기능뿐만 아니라 성능, 사용성, 안정성 등 여러 비기능적 요소를 포함하며, 테스트 자동화만으로는 이러한 모든 측면을 보장할 수 없다.
따라서, 자동화 테스트를 기본으로 삼되, 수동 및 탐색적 테스트 (버그 배쉬, 도그푸딩)를 병행해야한다. 또한, 카오스 테스팅과 같이 시스템의 일부에 의도적으로 장애를 발생시켜 예기치 않은 상황에서 시스템이 어떻게 반응하는지 복원력을 테스트할 수 있다.
이를 해결하기 위해 반복되는 코드는 별도의 Helper 클래스나 유틸리티 함수로 만들어 재사용성을 높이거나, 병렬 실행을 도입하여 불필요하게 오래 걸리는 테스트 단계를 최적화 한다.