시프트 레프트 테스트란 무엇인가요?

예산을 초과하고 모든 기한을 넘긴 소프트웨어 프로젝트에 참여한 적이 있으신가요? 여러분과 우리를 포함한 모두가 그런 경험이 있을 겁니다. 그런 일이 한 번도 없으셨다면 축하 드립니다. 비결 좀 알려주세요!

소프트웨어 개발 경력을 시작한 초기에 저는 마감일을 기준으로 역산해 계획을 세우는 것의 중요성을 배웠습니다. 프로젝트에 정해진 마감일이 있고 테스트에 일정 시간이 필요하다면, 이를 바탕으로 역산하여 프로젝트 일정을 계획할 수 있습니다. 벽한 방법처럼 보이죠?

사실 그렇지 않습니다. 수동 테스트를 위한 시간을 확보한 덕분에 프로젝트 막판에 스트레스를 어느 정도 완화할 수 있었지만, 여전히 예상치 못한 일이 너무 많았습니다.

QA 테스트를 위한 시간 확보는 이론적으로는 훌륭한 생각이지만, 현실은 첫 버그나 결함이 식별되면 허사가 되고 맙니다.

이 결함을 수정하는 데 얼마나 걸릴까요? 일정에는 얼마나 영향을 줄까요? 새로운 버그가 발생할까요? 처음 발생한 문제를 해결하면서 생겨난 문제를 또 수정하면 이번에야말로 모든 문제가 잘 해결되었음을 확신할 수 있는 시간은 어떻게 벌 수 있을까요?

하지만 결국 QA에 얼마만큼의 시간을 할애해야 하는지에 대한 정답은 찾지 못했습니다. 결국 촉박하게 수정한 코드가 마지막 순간에 병합되곤 했습니다. 그래서 중요한 제품 출시 후 몇 주 동안은 일정을 비워 두는 습관을 갖게 되었습니다. 이렇게 하면 막바지에 서두르면서 놓쳤거나 새롭게 발생시킨 문제를 우선순위에 따라 대응할 수 있습니다.

결국 문제는 테스트에 사용할 수 있는 시간이 아니라 테스트를 수행하는 시점이었습니다. 더 빨리, 더 자주 테스트해야 했던 거죠. 제게 필요한 건 바로 시프트 레프트(Shift-Left) 테스트였습니다.

소프트웨어 개발 프로세스가 왼쪽에서 오른쪽으로 흐르는 타임라인이라고 상상하면 “시프트 레프트 테스트”가 무엇인지 쉽게 이해할 수 있습니다. 간단히 말해, 테스트 전략에 테스터, 개발자 및 이해관계자를 포함한 팀 구성원이 참여하여 초기 단계를 테스트하는 관행입니다. 또한 개발 라이프사이클 전반에 걸쳐 기존 기능과 신규 기능 모두에 대한 테스트를 더욱 자주 수행하도록 통합하는 것도 포함됩니다.

V 모델은 소프트웨어 개발 주기를 개념화하는 데 유용한 방법입니다. 전통적인 워터폴 플로우의 구현 단계에서 Y축을 "뒤집으면" V 모델이 됩니다.

개발 주기는 높은 수준의 요구 사항으로 시작합니다. 이러한 요구 사항의 범위는 단계를 차례로 진행하여 코드 수준 구현 자체에 도달할 때까지 "V"자의 하향을 따라 좁혀집니다. 그런 다음에는 가장 세부적인 단위의 테스트로 시작하여 다시 "V"자의 최저점에서 보다 추상적인 사용자 수용 테스트를 향해 올라가며 구현을 검증합니다.

워터폴 프로세스에서는 프로젝트 전체가 "V"자 하나를 따라 진행됩니다. 결론적으로 개발 업계의 일원들은 모든 검증을 복잡한 프로젝트의 막바지로 미루면 실패를 자초하게 된다는 사실을 배웠습니다.

반복 프로세스에서는 각 스프린트나 반복이 더 작은 "V"자와도 같습니다. 이를 통해 더 빨리, 더 자주 테스트한다는 시프트 레프트의 목표를 달성할 수 있습니다. 그러면 문제가 해결된 것 같지만, 사실 아닙니다.

V 모델에 구축된 피드백 채널에 verification과 validation이라는 두 개의 레이블이 있음을 눈치채셨을 것입니다. 두 단계 모두 중요합니다.

사용자 요구 사항이 우리가 해결하려는 문제를 실제로 해결하는지 확인해야 합니다. 또한 구현 결과가 사용자 요구 사항에서 도출된 사양과 일치하는지도 확인해야 합니다.

테스트 자동화는 검증과 확인 모두에 적용할 수 있습니다. 행동 주도 개발(BDD)은 validation 과정의 일부를 자동화할 수 있는 Cucumber와 같은 기술의 등장으로 이어졌습니다. 이 문서에서는 검증을 위한 테스트 자동화에 중점을 둡니다.

단위 테스트는 보다 큰 규모의 애플리케이션 내 특정 모듈의 기능을 확인합니다. 모듈은 독립적으로 테스트되며, 여타 외부 프로세스와의 모든 통신은 시뮬레이션되거나 모의로 진행됩니다. 단위 테스트와 TDD는 시프트 레프트 테스트의 첫 개발 단계입니다.

통합 테스트는 서비스나 애플리케이션의 부작용을 비롯한 전체 기능을 검증하려고 시도합니다. 이 프로세스는 뒤에 언급할 여러 가지 이유로 인해 패턴 방지에 해당합니다.

API 테스트는 단일 서비스의 외부 엔드포인트를 확인합니다. API 테스트의 범위는 통합 테스트의 범위와 비슷합니다. 하지만 SOA 또는 마이크로서비스 컨텍스트에서는 API 테스트를 새로운 단위 테스트로 간주할 수 있습니다.

UI 테스트는 사용자 인터페이스 계층에서 애플리케이션의 전체 기능을 확인합니다. Selenium와 같은 도구를 사용하면 UI 테스트 자동화를 쉽게 이용할 수 있습니다.

시프트 레프트는 자동화에만 국한되지 않습니다. 더 일찍, 더 자주 테스트하는 또 다른 방법은 QA 전문가가 발견 및 요구 사항 수집부터 프로세스의 모든 단계에 참여하도록 하는 것입니다. 테스트 엔지니어는 전체 구현을 더 깊이 이해할수록 더 나은 성과를 낼 수 있으며, 이들의 인사이트는 아키텍처를 더욱 개방적이고 복원력 있게 만드는 데 도움이 됩니다.

'더 빨리, 더 자주' 진행하는 테스트를 생각하다 보면 '지속적'이라는 단어가 연상됩니다. 많은(대다수의) 소프트웨어 개발팀은 어떤 형태로든 지속적 통합과 지속적 제공을 실천하고 있습니다. 지속적인 테스트는 이 DevOps 주기의 중요한 피드백 루프입니다.

TDD를 '모놀리식을 위한 시프트 레프트'로 생각한다면, 지속적 테스트는 '분산 아키텍처의 시프트 레프트'로 볼 수 있습니다.

TDD는 우리가 단위 테스트에 집중하게 했습니다. 지속적인 테스트를 위해서는 API 테스트와 계약 테스트에 집중해야 합니다. API 테스트에는 다음과 같이 여러 이점이 있습니다.

• API 테스트는 마이크로서비스 애플리케이션에 오류를 추가하는 가장 흔한 방법 중 하나인 '업스트림 서비스나 다운스트림 서비스와 동기화하지 않은 채 종속성 변경하기'를 방지할 수 있습니다.
   

• API 테스트는 서비스를 소유한 팀이 소유할 수 있습니다.
   

• API 테스트는 부작용 및 구현 세부 사항 테스트의 취약성을 방지합니다.

이러한 API 테스트는 프로덕션 환경과 프리프로덕션 환경 모두에서 지속적으로 실시하는 것이 이상적입니다. 계약 테스트 도구를 사용하면 이 프로세스의 자동화에 도움이 되지만, 이를 위해서는 추가적인 인프라가 필요합니다.

관측 가능성 도구에 내장된 지속적 API 테스트를 사용할 수 있다면 어떨까요? Instana에서 출시할 예정인 합성 API 테스트 기능을 사용하면 최소한의 노력으로 모든 환경에 API 테스트를 지속적으로 실시할 수 있습니다.

시프트 레프트에는 소프트웨어 개발 라이프사이클의 비교적 초기 단계로 테스트 활동을 당겨 더 빠르게 피드백을 제공하고 버그 수정에 필요한 시간과 노력을 줄이는 일이 수반됩니다. 다음은 민첩한 개발에서의 시프트 레프트 테스트 모범 사례입니다.

1. 조기 참여: 테스트 활동은 개발 프로세스에서 가능한 한 일찍 시작해야 합니다. 테스터는 프로젝트 범위, 목표 및 사용자 기대치를 이해하기 위해 요구 사항 수집 단계부터 참여해야 합니다.

2. 협업 및 커뮤니케이션: 개발자, 테스터 및 기타 이해관계자 간의 긴밀한 협업과 소통을 촉진합니다. 일일 스탠드업 회의, 스프린트 계획 세션 및 정기적인 회고를 장려하여 이해와 조율 사항을 공유할 수 있습니다.

3. 테스트 자동화: 테스트 자동화에 투자하여 빈번하고 효율적인 테스트가 가능하도록 하세요. 자동화된 테스트는 개발 프로세스와 함께 생성되어야 하며 지속적인 통합 및 배포 파이프라인에 통합되어야 합니다. 이를 통해 결함을 조기에 발견하고, 회귀 문제를 줄이며, 피드백 주기를 단축할 수 있습니다.

4. 테스트 중심 개발(TDD): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 작성하는 TDD를 실천하도록 장려합니다. 이 시프트 레프트 테스트 접근 방식은 원하는 동작과 예상 결과를 미리 정의하여 보다 강력하고 테스트 가능한 코드를 만드는 데 도움이 됩니다.

5. 지속적인 통합 및 지속적인 업데이트(CI/CD): CI/CD 파이프라인을 구현하여 빌드, 테스트 및 배포 프로세스를 자동화합니다. 이렇게 하면 각 코드 변경 사항을 철저하게 테스트하고 프로덕션 환경에 빠르게 자주 배포하여 통합 문제의 위험을 줄일 수 있습니다.
    

6. 시프트 레프트 보안 테스트: 개발 프로세스 초기에 보안 테스트 관행을 통합하는 것이 좋습니다. 보안 코드 검토, 정적 코드 분석 및 보안 중심 테스트를 수행하여 취약점을 식별하고 사전 예방적으로 해결합니다.
    

7. 탐색 테스트: 자동화된 테스트와 함께 사용자 관점에서 애플리케이션을 살펴볼 수 있는 탐색 테스트를 권장합니다. 숙련된 테스터는 자동화된 테스트에서 놓칠 수 있는 잠재적인 사용성 문제, 엣지 케이스 및 시나리오를 식별할 수 있습니다.
    

8. 성능 테스트: 성능 테스트를 조기에 수행하여 잠재적인 병목 현상과 확장성 문제를 파악합니다. 이는 애플리케이션의 성능을 최적화하고 필요한 성능 기준을 충족하는지 확인하는 데 도움이 됩니다.
    

9. 테스트 환경 및 데이터: 현실적인 소프트웨어 테스트를 보장하기 위해 프로덕션 환경과 매우 유사한 테스트 환경을 프로비저닝합니다. 또한 실제 시나리오를 시뮬레이션할 수 있는 충분한 대표 테스트 데이터를 사용할 수 있는지 확인합니다.
    

10. 지속적인 학습 및 개선: 지속적인 학습과 개선의 문화를 조성합니다. 정기적인 회고를 통해 테스트 프로세스를 되돌아보고, 병목 현상을 파악하고, 변경 사항을 구현하여 시프트 레프트 테스트의 효율성을 높이도록 장려합니다.

이러한 모범 사례를 구현함으로써 애자일 팀은 시프트 레프트 테스트를 통해 더 나은 협업, 더 빠른 피드백 및 더 높은 품질의 소프트웨어 제품을 달성할 수 있습니다.

시프트 레프트 프로세스에 내장된 짧은 피드백 루프는 여러 면에서 큰 이점을 제공합니다. 몇 가지 예를 들자면, 결함을 더 빨리 찾을 수 있고, 수정 사항을 더 효율적으로 적용할 수 있으며, 한 번의 반복에서 배운 교훈을 다음 반복에 적용할 수 있습니다.

팀이 어떤 프로젝트 관리 방법론이나 릴리스 주기를 가지고 있든, 시프트 레프트 테스팅을 통해 검증 피드백 루프를 단축할 수 있습니다.

개발자의 로컬 머신에서 자동화된 단위 테스트를 통해 발견된 결함은 식별 및 수정하는 데 비용이 적게 듭니다. 하지만 결함이 고객 대면 환경으로까지 확산되면 이를 해결하는 데 드는 비용이 증가합니다.

테스트 자동화 및 CI가 올바르게 수행되면 소프트웨어 엔지니어는 설사 다음날이 쉬는 날이어서 즉시 대응할 수 없더라도 안심하고 자주 배포할 수 있습니다. 결함을 더 빨리 발견하면 모두에게 당혹스러운 일들을 줄일 수 있습니다. 릴리스가 간편한 만큼 소수의 오류가 발생하더라도 더 빠르고 쉽게 해결할 수 있습니다.

접근성이 뛰어난 소프트웨어가 모두에게 더 사용하기 쉬운 것처럼, 테스트하기 쉬운 소프트웨어는 이해하고 유지 관리하기도 더 쉽습니다. 테스트를 조기에 고려하면 우려 사항을 더 잘 분리하고 전반적인 아키텍처를 더욱 탄력적으로 만들 수 있습니다.

고객 경험을 개선하는 것이 우리의 목표입니다. Shift-left 키를 사용하면 사용자가 겪을 수 있는 일부 사고를 제거하고 다른 사고의 영향을 줄일 수 있습니다. 관측 가능성을 활용하면 이 피드백 루프를 완성하고 소프트웨어의 전반적인 상태를 개선할 수 있습니다.

강력한 자동화 툴을 자유롭게 사용할 수 있으므로 모든 코드 라인에 모든 종류의 테스트를 구현하고 싶을 수 있습니다. 하지만 이러한 접근 방식은 위험한 경로입니다.

부작용을 테스트하는 것(예: 해당 레코드가 데이터베이스에 저장되었는지 확인하는 것)은 매력적인 접근 방식처럼 보일 수 있습니다. 하지만 구현 세부 사항을 테스트하는 것은 이러한 테스트가 쉽게 깨지기 때문에 안티패턴입니다. 애플리케이션이 변경될 때마다 이러한 테스트도 함께 수정해야 할 수 있습니다. 사용자 인터페이스 역시 구현 세부 사항이므로 UI 테스트도 같은 문제를 안고 있습니다.

검증 테스트는 '어떻게'나 '왜'가 아니라 '무엇'에만 관심이 있습니다. 이상적으로는 사용자 요구 사항이 '왜'를 검증하도록 설계되어야 합니다. '어떻게'라는 질문에 답하려면 관측 가능성 플랫폼의 형태로 제공되는 더욱 강력한 자동화를 활용할 수 있습니다.

시프트 라이트(Shift-right) 테스트는 보통 프로덕션 환경에서 개발 프로세스의 후반부에 테스트를 진행하는 관행입니다. 이상하게 들릴 수 있지만, 시프트 레프트 테스트와 시프트 라이트 테스트는 상호 보완적입니다.

시프트 라이트 테스트를 통해 고객보다 먼저 프로덕션 문제를 파악할 수 있습니다. 그리고 시프트 레프트 테스트의 짧은 피드백 루프를 통해 이러한 프로덕션 문제에 신속하게 대응하고 이를 해결할 수 있습니다.

관측 가능성 플랫폼의 일환으로 합성 API 테스트를 진행하는 것은 시프트 레프트 및 시프트 라이트 관행의 이점을 결합하는 완벽한 방법입니다.