Shift Left Testing이 어떻게 버그, 시간 그리고 돈을 아낄까?

이번에 소개해드리는 글은 Shift Left Testing이 무엇인지 소개하는 글입니다. 사실 그보다는 제품을 만드는 과정에 대해 거시적으로 살펴볼 수 있도록 합니다. 이 내용이 도움이 되었다면 함께 일하는 동료와 논의해보는 것도 정말 좋을 것 같습니다.

버그의 책임은 누구에게 있는가?

이 글은 가장 먼저 제품에서 발생한 버그의 책임은 어디 그리고 누구에게 있는지 간단하게 알아봅니다. 사실 이 문장에서 조금 뜨끔한 포인트가 있습니다. 제품을 개발하는 과정 마지막에 제품이 정상적으로 동작하고 기대한 동작을 하는지 검증하는 과정(QA)이 있다면 코드를 작성하면서 은연중에 아래와 같이 생각한다는 것입니다.

"마지막 검증 과정에서 중요한 버그는 발견되고 이후 수정 기간에 수정하겠지"

하지만 이렇게 했을 때 결과는 그리 유쾌하지 않습니다. 아래는 검증 과정에 강하게 의존하면 발생하는 문제에 대한 제 생각입니다.

1. 신뢰가 떨어집니다. 이러한 태도는 좋지 않은 질을 가진 코드를 생산해냅니다. 그리고 마지막 검증 단계에서 발견되는 버그의 갯수가 감소하지 않습니다. 결국 다른 구성원이 개발자를 신뢰하지 못하는 문제가 발생합니다.

2. 시간과 돈이 많이 듭니다 1. 신뢰가 낮다면 비용은 증가합니다. 개발자가 만든 코드에 대한 신뢰가 낮기 때문에 검증 시간과 인력이 많이 듭니다.

3. 시간과 돈이 많이 듭니다 2. 배포 하기 전 마지막 단계에서 하는 검증이기 때문에 이 때 발견된 버그는 수정할 시간이 부족하고 급하게 처리하다보면 또 다른 버그를 만들어내기 마련입니다. 만약 버그를 고치지 못했다면 제때 배포하지 못하고 다음 스프린트로 넘어갑니다.

그리고 이 글에선 아래와 같이 강조합니다.

The quality of the code is a shared responsibility among the entire team.

좋은 결과물에 대한 책임은 마지막 검증 단계, 개발자 등 특정 단계나 팀의 책임이 아닙니다. 각자가 자신의 책임이라 생각하는 태도가 중요합니다.

Shift Left Testing이란?

따라서 마지막 단계에 의존하는 검증이 아니라 개발 과정의 왼편(Left)으로 검증(Test) 과정을 이동(Shift)시킴으로써 더 나은 방법의 검증을 해야 한다고 강조합니다.

Shift Left Testing에 대해 저자는 아래와 같이 소개합니다.

Shift left testing means focusing on testing from the very beginning when we start thinking about how to approach a task.

이 방법의 자세한 수행 방법을 요약하면 아래와 같습니다.

1. 자세한 인수 조건(acceptance criteria)

2. 관계된 모든 구성원이 인수 조건을 파악함

3. 개발자는 마지막 검증 단계 전에 반드시 테스트를 해야함

4. 개발 과정에서 PM과 검증 팀으로부터 지속적인 피드백

이 방법은 실제로 업무를 하며 개선해나가는 과정과 닮아 있어 더욱 공감이 됐습니다. 이 방법을 처음 도입하거나 도입하는 중이지만 잘 안 된다면 아래 세부 내용을 살펴보는 게 도움이 되리라 생각합니다. 이 내용은 제가 추가한 내용입니다.

1. PM 또는 모든 괸계자는 자세한 인수 조건을 준비하고, 개발자는 인수 조건에 따라 개발해야 합니다. 이 글에서 소개한 것처럼 준비하는 것만으론 충분하지 않습니다. 때로 이 과정은 매우 번거롭고 힘듭니다. 저 처럼 덤벙대는 성격을 가진 사람이라면 더욱 그렇습니다. 하지만 훈련해야 합니다.

2. 인수 조건이 자세하게 준비되어야 하는 이유는 버그는 코드로부터 나오는 것 뿐만 아니라 애초에 잘못된 인수조건에서 나올 수 있기 때문입니다. (이 글에서도 이 부분을 강조하고 있습니다.)

3. 보통 전문 QA 팀이 있지 않은 조직에선 모든 관계자가 함께 검증을 합니다. 그렇기 때문에 더욱더 인수 조건을 모두 파악하고 있어야 합니다. 그래야 발견하지 못한 문제 케이스를 발견할 수 있습니다.

4. 개발자는 마지막 검증 단계 전 반드시 테스트를 해봐야 합니다. 여기엔 단위 테스트, 개발자 간의 테스트 등을 포함합니다. 이 방법은 마지막 검증보다 비용이 낮고 속도가 빠릅니다.

5. 시작부터 마지막 단계까지 지속적으로 피드백을 주고받아야 합니다. 왜냐하면 우리 모두 사람이기 때문에 각 과정에서 문제를 발견할 수 있기 때문입니다.

6. 지속적인 피드백과 개선이 필요하려면 변경에 유연한 코드를 작성해야 합니다. (이 역시 소개한 글에서 강조하고 있습니다.)

더 자세한 내용은 소개해드리는 글을 참고해보시는 걸 권해드립니다. 위 내용을 더 자세하게 설명하는 것 뿐만 아니라 실제 적용 결과를 공유하고 있기도 합니다.

뿐만 아니라 테스트와 관련해 이전에 공유해드린 '테스트는 센서다'라는 글을 다시 공유드립니다.