시프트 레프트 테스트

시프트 레프트 테스트(shift-left testing)는 품질 활동을 더 일찍, 즉 요구사항에서 릴리스로 이어지는 타임라인의 왼쪽에서 수행하는 것을 말합니다. 개발이 끝난 뒤에 테스트 단계를 두는 대신, 테스터와 개발자가 함께 요구사항을 리뷰하고, 인수 조건(acceptance criteria)에 합의하고, 코드와 함께 자동화 테스트를 작성하며, 커밋마다 이를 실행합니다. 요구사항 리뷰에서 발견된 결함은 대화 한 번으로 해결되지만, 같은 결함이 운영 환경에서 발견되면 장애 대응이 필요합니다.

실무에서의 모습

• 리파인먼트(Refinement). 코드가 존재하기도 전에 테스터가 “쿠폰이 만료되었으면 어떻게 되나요?“라고 묻고, 그 답이 인수 조건이 됩니다.
• 설계. 안정적인 테스트 ID, 데이터를 준비하기 위한 API 엔드포인트, 기능 플래그(feature flag) 등 테스트 용이성을 미리 논의합니다.
• 개발. 단위 테스트와 API 테스트를 몇 주 뒤가 아니라 기능과 함께 작성합니다. 정적 분석과 린팅은 에디터와 풀 리퀘스트에서 실행됩니다.
• CI. 모든 풀 리퀘스트에서 빠른 테스트 스위트를 실행하고, 실패하면 머지를 막습니다.

시프트 레프트와 시프트 라이트

시프트 라이트 테스트(shift-right testing)는 이를 보완하는 개념으로, 모니터링, 카나리 릴리스, 기능 플래그, 합성 모니터링(synthetic check), A/B 실험을 통해 운영 환경에서 배우는 것입니다. 실제 트래픽 패턴이나 외부 서비스 장애처럼 운영 환경에서만 드러나는 실패도 있습니다. 성숙한 팀은 둘 다 합니다. 왼쪽으로 옮겼다고 해서 릴리스 이후의 상황을 관찰하지 않아도 되는 것은 아닙니다.

흔한 실수

• 이름만 바꾸고 아무것도 바꾸지 않기. 테스터가 여전히 완성된 빌드와 마감일을 함께 넘겨받는다면, 아무것도 옮겨지지 않은 것입니다. 판단 기준은 코드가 작성되기 전에 품질에 관한 대화가 이루어지는지입니다.
• 모든 테스트를 개발자에게 떠넘기기. 시프트 레프트는 테스트를 팀 전체로 분산하는 것이지, 테스트 역량이 필요 없어지는 것이 아닙니다. 테스터는 흔히 코칭, 테스트 설계, 도구 개발 쪽으로 역할을 옮깁니다.
• 자동화만 앞으로 옮기기. UI 테스트를 더 일찍 실행하는 것도 도움이 되지만, 가장 큰 효과는 대개 요구사항을 명확히 하고 검증을 단위 및 API 수준으로 내리는 데서 나옵니다.