[서평] '개발자를 위한 시프트 레프트 테스트'를 읽고

개발자를 위한 시프트 레프트 테스트 | 다카하시 주이치 - 교보문고

 

들어가기 앞서

테스트 주도 개발 서평 이후로 처음 쓰는 서평인데, 사실 그 사이에 여러 책들을 더 읽긴 했지만, 이펙티브 자바 같이 이미 너무 많은 서평이 인터넷에 올라와있는 책들은 굳이 내가 또 서평을 더 올리는 의미가 별로 없을 것 같아서 올리지는 않았었다..

 

책에 대한 생각

원 주제로 돌아와서, 개발자를 위한 시프트 레프트 테스트라는 책에 대해 이야기해보자.

 

책의 부제가 '단위 테스트, 리팩터링, 애자일 개발 시 품질 담보, 테스트 자동화 등 소프트웨어 품질을 높이는 개발자 테스트 실천 기법' 이었기 때문에 테스트 코드를 잘 짜는 코드적인 방법에 대한 이야기들이 주가 될 줄 알았지만 그렇지는 않았다.

 

이 책의 저자는 일본의 제일 가는 품질 컨설턴트이고, 이 책은 그가 컨설턴트로서 다양한 회사들과 이야기해보며 오랜 세월 축적해온 경험을 바탕으로 '실제 업무 현장에서 프로덕트 품질을 위해 요구되는 테스트의 모든 것'들을 정리해놓은 책이다.

 

따라서 일반 개발자가 읽는 것보다는, 여러 사람들이 한 프로젝트를 개발하는 개발 팀의 리더가 읽으면 좋겠다는 생각이 들었다.

현업에서 개발을 하는데 버그를 잡는 데에 어려움을 겪고 있거나, 테스트를 작성은 하지만 잘 하고 있는지 모르겠다는 느낌이 드는 사람들이 읽을 때 도움이 되겠다는 생각이다.

 

시프트 레프트 테스트

시프트 레프트 테스트란?

그렇다면 이 책의 저자가 우리에게 중요하다고 강조하는 이 시프트 레프트 테스트란 무엇일까?

개발은 보통 '요구 사항 정립', '아키텍처 설계', '코딩', '테스트', '유지보수'와 같은 순서로 진행이 된다. 그리고 이 모든 과정에서 버그가 발생할 수 있다.

 

Caper Jones - Zone of Chaos

보통의 개발 과정 (소위, 폭포수 모델)에서는 프로그램을 개발하는 것이 완료되면 그제서야 테스트를 진행하게 되는데, 이 경우 앞의 모든 과정에서 발생한 버그들을 마지막 과정인 '테스트'와 '유지보수' 단계에서 맞이하게 된다.

 

다시 말해서 프로젝트 후반부에 이런 버그들을 해결하는 비용을 전부 감당해야 한다는 뜻이고, 프로젝트 후반에 이런 일을 하는 비용은 전반에 드는 비용의 수 배에 달한다. 결국 버그들이 완전히 해결되지 않은 채 프로젝트가 마무리되게 되는 것이다.

 

 

이게 맞다

시프트 레프트 테스트는 이러한 연유로 탄생한 것이다.

각 단계에서 발생한 버그는 그 단계에서 감지되어야 한다. '요구사항 설립' 단계에서 발생한 버그는 '요구사항 설립' 단계에서 탐지되어야 한다는 뜻이다.

그러면 버그 수정 비용도 적게 들며, 출시일이 거의 다 되어서 버그 때문에 혼란해지는 상황도 잘 발생하지 않게 된다.

 

시프트 레프트 테스트.. 그냥 하기만 하면 될까?

물론 이런 시프트 레프트 테스트를 마음 먹는다고 다 잘 된다면, 누가 돈을 못 벌겠는가.

 

참 많은 회사들이 이에 대해 '생각은 하지만 예산/납기일 때문에 도입을 못한다'거나, '도입은 하지만 허울뿐인 테스트로 개발자들의 스트레스만 늘고 버그 해결에 큰 도움은 안된다'거나 정말 가지각각의 이유로 무너졌을 것이다.

 

실제로 책에서도 그런 안 좋은 사례들에 대해 이야기를 한다.

애자일을 회사에 도입해보려고 했지만 현실의 벽에 무너졌던 사람들이라면 이해가 잘 될 것 같다.

 

알게 된 것들

이론과 현실의 벽은 참 높다고 깨달았다.

다양한 테스팅 기법들에 대해 알게 되었는데, 키워드들만 좀 나열을 해보겠다..

 

경계값 테스트
상태 전이 테스트
CK 지표
통합 테스트 패턴
카오스 엔지니어링
키워드 주도 자동 테스트
탐색적 테스트
돌연변이 테스트
사용자 스토리

 

글쓴이의 어투

마지막으로 글쓴이의 어투에 대해서도 ㅋㅋ 얘기해보고 싶다.

생각보다 뭔가 정곡을 찌르는 문장들이 많은데, 되게 말넘심 느낌으로 찌른다. 몇 가지 문장들이 기억에 남아서 책을 보면서 메모를 해두었다.

옮겨 적으면서 약간의 문장 수정이 있을 수도 있다!

 

갑자기 가장 마지막 단계에서 테스트 집단 (주로 협력 회사)이 들어와 시스템을 막무가내로 조작해서 많은 버그를 만들어내는 것 또한 건전한 제조업으로서 올바른 자세가 아닙니다..

기계나 전기 설계 분야에서도 이런 무모한 짓은 하지 않습니다. 예를 들어, 오토바이가 설계서대로 만들어졌는지 확인하기 위해 시제품 오토바이를 갑자기 운전하다가 "아, 여긴 설계대로 만들어지지 않았습니다!" 라고 하는 것은 그저 어리석은 행동일 뿐입니다.

 

출시한 뒤에 버그가 발생할 거라고 알고 있지만 예산이 없고, 출시일이나 기능 구현만 고려한 채 출시 후의 리스크 (버그에 의한 매출 저하, 시장 버그 비용)에 대해 조직 전체가 눈을 감고 있지는 않습니까?

 

어떤 사람들은 단위 테스트를 싫어합니다. 그 이유가 무엇일까요?
자신이 작성한 소스 코드에 자신이 없는 걸까요?
어쩌면 생산성을 낮춰서 야근 수당을 받고 싶은 걸까요?
아니면 밤늦게까지 비효율적인 디버그를 하는 모습을 상사에게 보여서 인정 받고 싶은 걸까요?

 

현대의 소프트웨어는 20년 전에 비해 훨씬 복잡해졌지만, 여전히 "버그를 완전히 없애자"고 말하는 회사들이 있습니다.

하지만 이런 버그가 있더라도 소프트웨어가 사용자의 요구사항을 충분히 제공한다면 크게 문제가 될 일은 아니지만, 그런데도 크게 중요하지도 않은 세세한 테스트를 하거나 작은 버그를 수정하느라 엔지니어들은 지쳐갑니다.

이러한 현상을 부추기는 또 하나의 예는, 시장에서 발생한 버그의 재발 방지 대책의 대부분이 '리뷰를 강화한다', '테스트 케이스를 추가한다'라는 점입니다.

현재의 업무를 줄이지 않으면서 다른 일만 추가하는 것은 개선이라고 말할 수 없습니다.

 

컨설턴트: (복잡도가 40이 넘는 모듈을 가리키며) 이 부분의 단위 테스트 케이스를 보여주실 수 있나요?
회사: (의기양양한 태도로)여기 단위 테스트 소스가 있습니다.
컨설턴트: 커버리지 비율은 높지만 기댓값 체크는 하지 않았네요?
회사: (어두워진 표정으로) 네. 발주 측에서 커버리지 100%라고 했기 때문에 그 지시대로 하고 있고, 발주서에 기댓값 체크에 대해서는 아무런 언급도 없습니다.
컨설턴트: (위험한데..)

컨설턴트: 커버리지 100%라고만 기재되어 있어서, 소프트웨어 전체에 걸쳐 기댓값 확인을 하지 않는 단위 테스트가 만들어져 있습니다. 이래서는 그저 불필요한 투자일 뿐입니다. 이 단위 테스트는 아무런 의미가 없습니다.
회사: ...

이런 경우 대개는 본인의 기술 영역을 넘어서는 이야기를 듣고 멍한 반응을 보이며, 불필요한 투자라는 말의 의미를 이해하지 못합니다. 이후 상대방은 보통 필자가 하는 말을 최대한 그냥 넘길 수 있는 방법이 없을지 필사적으로 고민하게 됩니다.

 

개발자 A: 코드 복잡도가 40을 넘었다고? 이 switch 문 안의 if 안의 if 문을 어떻게 좀 하라고! 머리가 있다면 이렇게 작동하는지 아닌지 정도는 알 수 있을거 아니야!

개발자 B: 그럼 복잡도를 줄이죠! 코드 작성이 끝났으니 리팩토링을 하면 되겠네요! 버그가 발생하면 당신 때문입니다!

 

... 정말 무서운 사람이다 이 사람.