CI/CD의 자동화된 테스팅

소프트웨어 테스트는 품질을 보장하는 데 필수적이며 오랫동안 소프트웨어 개발 방식의 일부를 형성해 왔습니다.

워터폴 컨텍스트에서 수동 테스트 또는 QA 테스트 단계는 코드 개발 및 통합 이후의 절차였으며, 그 목적은 사양에 따른 애플리케이션 작동 여부를 확인하는 것이었습니다.

이러한 선형적 접근 방식을 취할 경우 릴리스 프로세스가 지연되며 개발자는 구축한 결과물을 토대로 더 많은 개발이 이루어질 때까지 해당 결과물이 적절히 작동하는지 확인할 수 없습니다. 반면 CI/CD 자동화 프로세스를 활용하면 짧은 반복 주기의 애자일 접근 방식 통해 신속한 피드백을 제공하고 업데이트를 조금씩, 자주 릴리스할 수 있습니다. 이처럼 짧고 반복적인 주기의 핵심은 새로운 코드가 적절히 작동하는지, 다른 코드의 손상은 없는지 자동으로 검증하는 테스트입니다.

지속적 통합 과정에는 마스터 또는 트렁크로의 정기적인 코드 변경 사항 커밋, 적용 가능한 경우 빌드 트리거 및 매번 소프트웨어 보장 등이 포함됩니다. CI의 이점을 활용하려면 팀원들은 최소한 매일 이루어지는 변경 사항의 커밋을 목표로 삼아야 합니다. 하지만 아무리 소규모 팀이라 해도 이 정도 수준의 자동화 테스트를 수동으로 수행할 경우 QA 엔지니어에게 상당한 부담이 가해지며 매우 반복적인 작업이 수반될 것입니다. 그렇기에 자동화된 테스트가 필요합니다.

테스트는 파이프라인 전체의 여러 단계에서 수행된다는 것이 정답입니다.

지속적 통합 및 배포를 처음 접한다면 과도하게 느껴질 수 있지만 CI/CD 및 QA 자동화의 핵심은 팀에서 최대한 빨리 문제를 파악할 수 있게 지원하는 긴밀한 피드백 루프입니다.

문제가 발생한 직후 이슈를 해결하면 잘못된 기반 위에 더 많은 코드가 작성되지 않도록 방지하므로 수정이 훨씬 수월합니다. 또한 팀에서 다음 작업으로 이동하여 컨텍스트를 놓치기 전에 변경 사항을 적용하는 것이 더욱 효율적입니다.

많은 자동화된 빌드 테스트 도구가 CI/CD 도구와 통합을 지원하므로 테스트 데이터를 파이프라인에 공급하고 테스트를 단계적으로 수행한 후 각 단계의 결과를 받아볼 수 있습니다. 사용하는 CI 도구에 따라 이전 단계의 테스트 결과를 기반으로 다음 단계로의 빌드 진행 여부를 선택할 수도 있습니다.

자동화된 테스트를 통해 파이프라인을 최대한 활용하려면 일반적으로 가장 빠른 테스트가 먼저 실행되도록 빌드 테스트를 지시하는 것이 좋습니다. 이렇게 함으로써 긴 시간이 소요되며 더 많은 참여가 필요한 테스트를 실행하기 전에 초기 테스트 통과 여부를 확인할 수 있으므로, 피드백을 더 신속히 제공하고 테스트 환경을 보다 효율적으로 사용할 수 있습니다.

자동화된 테스트 생성 및 실행에 있어 우선순위를 지정하는 방식을 고려할 때 테스트 피라미드 측면에서 생각하면 도움이 됩니다.

테스트 피라미드를 활용하면 CI/CD 파이프라인에서 지속적 통합 테스트의 상대적 개수 및 수행 순서에 따라 우선순위를 지정하는 방법을 편리하게 개념화할 수 있습니다.

Mike Cohn이 처음으로 정의한 테스트 피라미드의 하단에는 유닛 테스트, 중간에는 서비스 테스트, 상단에는 UI 테스트가 표시됩니다.

이름은 다소 부정확할 수 있지만 그 전제는 합리적입니다. 빠르고 쉽게 실행 가능한 자동화된 유닛 테스트로 강력한 기반을 다지고, 작성하기 더욱 복잡하며 실행 시간도 더 오래 소요되는 테스트로 나아간 후, 마지막에 소수의 가장 복잡한 테스트로 완료하는 것입니다. 그렇다면 어떤 유형의 CI/CD 테스트를 고려해야 할까요? 옵션을 한번 살펴보겠습니다.

CI/CD 관행의 일부로 자동화된 테스트를 수행하는 목적은 방금 변경된 사항에 피드백을 신속히 받는 것입니다. 그렇기에 해당 피드백을 경청하고 그에 반응하는 것은 필수적입니다.

일반적으로 CI 서버는 자동화된 테스트 도구와 통합되므로 모든 결과를 한 곳에 표시할 수 있습니다. 개발 팀은 최신 결과를 표시하는 대시보드 또는 라디에이터 디스플레이를 Slack과 같은 커뮤니케이션 플랫폼의 자동 알림과 결합하여 최신 빌드 진행 상황을 전달하기도 합니다.

테스트 실패 시 코드베이스에서 어떤 영역이 테스트와 관련되었는지 이해하고 테스트에서 생성된 정보를(예: 스택 추적, 출력 값 또는 스크린샷) 확인하면 근본적 원인을 규명하는 프로세스 속도를 개선할 수 있습니다. 시간이 걸리더라도 테스트를 신중하게 설계하는 것이 좋습니다. 그렇게 해야 각각의 검사로 한 가지 사항을 확인하고 실패한 부분의 이해를 위해 상세한 라벨을 지정할 수 있습니다. 테스트 실패에 대한 추가 정보를 제공하는 지속적 통합 테스트 및 CI 도구도 빌드가 그린 상태로 조속히 돌아가는 데 유용합니다.

항상 그렇듯 도구와 방식은 일부 요인에 불과합니다. 좋은 CI/CD 자동화 방식이 자리 잡으려면 자동화된 CI/CD 테스트의 가치뿐 아니라 실패한 테스트에 신속하게 대응하여 소프트웨어를 배포 가능한 상태로 유지하는 것의 중요성을 인식하는 팀 문화가 필요합니다.

CI/CD를 처음 접하는 사람들이 흔히 하는 오해는 자동화된 테스트가 수동 테스트 및 전문 QA 엔지니어의 필요성을 제거한다는 것입니다.

CI/CD 자동화는 QA 팀원에게 여유 시간을 제공하지만 테스터의 일이 사라지는 것은 아닙니다. 반복 작업에 시간을 소비하는 대신 엔지니어는 관련 케이스를 정의하고, 자동화된 테스트를 작성하고, 탐색 테스트를 통해 창의성과 독창성을 발휘하는 데 집중할 수 있습니다.

컴퓨터로 실행하도록 신중하게 스크립팅된 자동 빌드 테스트와 달리 탐색 테스트의 검토는 다소 여유롭게 진행됩니다. 탐색 테스트의 가치는 계획적이고 구조화된 테스트에서 누락된 부분을 발견하는 데 있습니다. 기본적으로 아직 고려하거나 테스트 사례를 작성하지 않은 문제를 찾아야 합니다. 탐색할 영역을 결정할 때 새로운 기능과 프로덕션에서 문제가 발생할 경우 가장 큰 피해를 초래할 시스템 영역을 모두 고려하세요.

탐색 테스트가 점차 수동적이고 반복적인 테스트로 변질되어선 안 됩니다. 탐색 테스트의 취지는 매번 동일한 테스트 세트를 수행하지 않는 것입니다. 탐색 테스트 중 문제를 발견해 이를 수정하는 경우 시간을 할애해 자동화된 테스트를 작성합니다. 이런 방식을 취하면 해당 문제가 다시 발생할 경우 포착되어 프로세스에서 훨씬 조속히 처리됩니다. 테스터의 시간을 효율적으로 사용하려면 자동화된 테스트를 모두 통과한 후에만 수동 테스트를 실시해야 합니다.

자동화된 테스트는 모든 CI/CD 파이프라인에서 핵심 역할을 담당합니다.

자동화된 테스트를 작성하는 데 시간과 노력이 투입되지만, 신속한 피드백과 코드 배포 가능성에 대한 가시성이라는 이점이 있기에 결과적으로 자동화된 테스트는 시간을 훨씬 단축시키는 것입니다. 하지만 테스트 도구의 구축은 일회성으로 처리하고 잊어버리는 일이 아닙니다.

자동화된 빌드 테스트는 코드의 다른 부분 만큼 애플리케이션에서 많은 부분을 구성할 것이므로 관련성 있고 유용한 테스트를 유지하기 위한 관리가 필요합니다. 따라서 코드에 적용하는 지속적 개선은 테스트에도 적용됩니다.

지속적으로 새로운 기능에 대한 자동화된 테스트 커버리지를 구축하고 탐색 테스트 결과를 제공함으로써 테스트 도구를 효과적이고 효율적으로 유지할 수 있습니다. 또한 테스트 성과를 살펴보고, 더욱 신속한 피드백을 위해 작업 단계를 재정렬하거나 세분화할 가치가 있는지 확인하는 데 시간을 할애하는 것이 좋습니다.

CI 도구는 파이프라인 최적화에 도움이 되는 다양한 측정 기준을 제공하는 데 반해, 불안정한 테스트 지표는 잘못된 확신이나 우려를 줄 수 있는 신뢰도 낮은 테스트를 표시합니다. 측정 기준이 자동화된 테스트 프로세스를 개선하는 데 유용할 수 있지만 테스트 커버리지 자체를 목표로 생각하게 되는 사고의 함정에 주의해야 합니다. 실제 목표는 정기적으로 작동하는 소프트웨어를 사용자에게 제공하는 것입니다. 자동화는 빠르고 신뢰할 수 있는 피드백을 제공하여 이러한 목표를 달성하므로, 소프트웨어를 프로덕션에 배포할 때 확신을 가질 수 있습니다.