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

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

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

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

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

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

테스트 자동화는 검증과 확인 모두에 적용할 수 있습니다. BDD(행동 중심 설계)는 검증 프로세스 일부 자동화할 수 있는 Cucumber와 같은 기술의 개발로 이어졌습니다. 이 문서에서는 검증을 위한 테스트 자동화에 중점을 둡니다.

단위 테스트

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

Integration Testing

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

API 테스트 및 계약 테스트

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

UI 테스트

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

복원력이 뛰어난 아키텍처

접근성이 높은 소프트웨어일수록 누구나 쉽게 사용할 수 있는 것처럼, 테스트 가능한 소프트웨어일수록 추론하고 유지 관리하기가 더 쉬울 수 있습니다. 테스트를 조기에 고려하면 우려 사항을 더 잘 분리하고 전반적인 아키텍처를 더욱 탄력적으로 만들 수 있습니다.

전반적인 품질 향상

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

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

저장되지 말아야 할 기록이 데이터베이스에 저장되는 등, 발생할 수 있는 부작용을 테스트하는 것은 매력적으로 느껴질 수 있습니다. 하지만 구현의 세부 사항을 시험하는 테스트는 특유의 높은 취약성 때문에 비효율적입니다. 이러한 테스트는 애플리케이션이 변경될 때마다 변경해야 할 수 있습니다. 사용자 인터페이스도 구현 세부 사항이므로, UI 테스트도 마찬가지입니다.

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

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

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

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