소프트웨어 결함은 초기에 잡는다 - 시프트 레프트 테스트

 

시프트-레프트 테스트의 정의와  필요성

소프트웨어 품질은 조기에 결정되므로 개발 과정에서 테스트를 뒤로 미루지 않고 최대한 앞 단계에서부터 수행하자는 것이 ‘시프트-레프트(Shift-left)’ 접근법입니다. 즉, 프로그래밍과 테스트를 동시에 수행하는 것이죠.
 
이는 소프트웨어의 기술의 역할이 점점 커지고 있는 현시대에 매우 필요한 방법론입니다.
예를 들어 자동차의 경우에는 소프트웨어의 품질이 보장되지 않는다면 안전의 문제로 직결됩니다. 
 
아래는 결함이 발생한 단계와 발생한 결함을 수정하기 위한 비용을 나타낸 그래프입니다. 이 그래프를 보면 많은 결함이 코딩 단계에서 주입되고, 발견이 늦으면 늦을수록 결함을 수정하기 위한 비용이 크게 증가한다는 것을 알 수 있습니다. 
 

개발 후반으로 갈수록 결함을 수정하는데는 비용이 기하급수적으로 증가한다.

레프트-시프트와 기존 테스트 방법의 비교

 

테스트 라이프 사이클 (Test Life Cycle)

 
테스트의 사이클은 크게 단위테스트 -> 통합테스트 -> 시스템 테스트 순으로 이뤄집니다.
이 중에서 단위 테스트는 기능테스트이자 화이트박스 테스트라고 할 수 있고, 통합테스트와 시스템테스트는 비기능 테스트이자 블랙박스 테스트라고 할 수 있습니다.

기능테스트: 소프트웨어가 명세된 기능을 올바르게 수행하는지 확인하는 테스트.
비기능테스트: 소프트웨어의 성능, 사용성, 신뢰성 등 기능 이외의 품질 속성을 테스트.
화이트박스테스트: 소프트웨어의 내부 구조, 코드, 알고리즘 등을 알고 테스트.
블랙박스테스트: 내부 구조나 동작을 알지 못한 채 외부에서 소프트웨어의 기능을 테스트. 

 
 
레프트-시프트 테스트에서 중요한 것은 위 테스트 사이클 중 단위테스트입니다.

 

특히 코드를 기반으로 경곗값 테스트, 상태전이 테스트, 조합테스트 등 다방면으로 테스트가 이뤄져야 합니다. 
이는 처음 보면 시간이 많이 소요될 것이라고 생각하지만, 오히려 나중에 버그가 발생되어 수정하는 것보다 비용과 시간 모두 압도적으로 줄일 수 있습니다.
 
 

기존의 방식을 뒤집다 

흔히 개발 순서를 생각하면 코드 작성 -> 테스트 -> 리팩터링이라고 생각하기 쉽습니다. 
하지만 테스트 주도 개발(TDD)은 아래와 같이 반대로 수행하며 이 과정을 반복합니다.  

1. 실패 테스트 작성 -> 2. 테스트를 통과할 최소한의 코드를 작성 -> 3. 리팩터링 

 
 

어디부터 어디까지? - 커버리지 

그럼 모든 함수를 테스트해야 해야 되느냐?라고 질문할 수 있습니다. 
자동차 분야 같은 경우는 함수의 커버리지가 100%가 되어야 합니다. 안전과 직결되기 때문입니다. 
하지만 일반적으로는 80% 정도면 준수하다고 합니다. 
 
또, 그러면 문제가 있는 부분을 어떻게 찾느냐라고 질문할 수 있습니다. 
여기서도 파레토의 법칙 이 적용됩니다. 전체 코드 중 20%에서 버그의 80%가 발생한다는 것입니다.
이는 최근 변경된 파일에서 핫스팟이라고 하는 값이 크면 그 소스를 확인하는 방법 등으로 접근해 볼 수 있습니다. 
 
 

코드 리뷰도 테스트만큼 중요하다.

코드를 함께 리뷰하는 과정도 매우 중요합니다.
코드리뷰는 남의 코드의 문제점을 지적하는 것이 아니라, 본인이 깨닫는 과정을 거치는 것입니다.
이를 통해 질문을 던질 수 있으며 코드를 효율적으로 짤 수 있고 문제점을 조기에 발견할 수 있습니다.
 
 

결론

1. 레프트-시프트 테스트는 요구사항이 잦은 개발 상황에서 비용과 시간을 줄여준다. (애자일 방법론) 
2. 핫스팟값을 이용한 효율적인 단위테스트를 수행한다. 특히 단순히 명령 커버리지를 테스트하는 것이 아닌 조건 커버리지(경곗값을 확인가능한)를 테스트한다.
3. 개발 과정 초기부터 코드리뷰를 함께 진행한다.