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

date

Jun 27, 2023

slug

shift-left-test

status

Public

들어가기 앞서

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

책에 대한 생각

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

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

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

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

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

시프트 레프트 테스트

시프트 레프트 테스트란?

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

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

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

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

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

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

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

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

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

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

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

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

알게 된 것들

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

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

경계값 테스트

상태 전이 테스트

CK 지표

통합 테스트 패턴

카오스 엔지니어링

키워드 주도 자동 테스트

탐색적 테스트

돌연변이 테스트

사용자 스토리

글쓴이의 어투

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

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

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

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

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

어떤 사람들은 단위 테스트를 싫어합니다. 그 이유가 무엇일까요?

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

컨설턴트: (복잡도가 40이 넘는 모듈을 가리키며) 이 부분의 단위 테스트 케이스를 보여주실 수 있나요?

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

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