개발자를 위한 시프트-레프트 테스트

책의 제목에서 보듯이 눈에 들어오는 키워드가 3가지 있습니다.

① 개발자

② 시프트레프트

③ 테스트

여기서 처음에 그 의미를 잘 파악하기 어려운 단어는 ② 시프트레프트 입니다.

shfit-left  : 직독을 하면 왼쪽으로 이동시킨다는 의미입니다.

무엇을 왼쪽으로 이동시킨다는 의미일까요? 네. 맞습니다. 책에서 애기하는 테스트 과정을 의미합니다.

 

반대개념 및 우리가 보통 일반적으로 사용하고 있는 개념이 시프트라이트(shift-right)라는 개념도 있습니다.

시프트라이트의 의미는 "무엇보다 제품 개발과정에서 가장 분주한 시점을 후반부에 두든것" 이라고 합니다.

 

 

책의 저자분과, 옮긴이의 서문을 보고 이책의 방향성과 어려운 이야기를 매우 쉽고 핵심을 잘 짚어주는 책이라는 느낌이 들었습니다.

저자는 일본인이지만, 경험한 기업은 글로벌한 기업(SAP, MS, 소니)에서 다양한 품질활동을 경험이 있으십니다.

또 소트프웨어 품질연구로 박사학위까지 취득하셔서, 현실과 이론의 적정한 밸런스를 가지고 있으시다고 생각이 들었습니다.

저자는 "개발자가 검증하는 내용" 과 "QA 진행시 검증되는 요소"는 명확히 다르다고 저자는 정의합니다.

역자는 "개발활동 주체"와 "품질활동 주체"가 분리되어 있으며, 개발활동 주체가 발견할수 있는 오류의 영역과, 품질활동 주체가 발견할수 있는 오류의 영여깅 전혀 다르다고 정의합니다.

이러한 내용에 많은 분들이 공감을 하실 거라고 생각이 듭니다. 

 

<저저분의 머리말 내용>

 

얇은 책이지만, 내용만큼은 얇지 않다고 자부합니다. 필자는 항상 책에 담는 문장보다 100배는 더 많은 문헌을 읽고, 요약하며, 20년 이상 직접 경험한 내용을 조합해서 글을 쓰기 때문입니다.

 

<책을 보기전에 알아보고 싶은 것들>

모든 조직의 품질 활동 및 SW릴리즈 전략을 다를것이라고 생각됩니다. 회사의 프로세스가 모두 다르고, 제품 출시가 먼저인 경우 등 품질활동 및 테스트를 수행하는 방식은 모두 다릅니다. 블랙박스 테스트만을 통해서 제품이 나가는 경우도 있고, TDD기반으로 테스트 케이스부터 작성을 하면서 실제 비지니스 로직을 개발하는것이 더 익숙한 곳도 있습니다.

하지만 개발자 입장에서는 누구나 테스트는 중요하고, 테스트케이스 작성으로 통해서 지금은 버그가 없지만, 추후에 지속적으로 품질을 유지하고 싶은 생각은 가지고 있습니다.

• 테스트 케이스를 작성했는데, 잘 작성되고 효율적인 테스트인지 혼돈이 됩니다.
• 테스트 케이스 작성시, 중요하게 생각해야 하는 부분은 무엇인지 궁금합니다.
• 단순히 isEquals를 통해서 커버리지만 높이고, Pass 도출보다 조금 더 큰 그림을 보고 싶습니다.

 

■ 시프트-레프트의 정의

· 소프트웨어 개발 과정과 관련된 접근법

· 제품이나 프로세스 등의 전체 개발 과정에서 품질을 향상하는 중요한 활동을 최대한 조기에 설계하고, 코딩단계에서도 수행하는 전략

·  이론적으로는 누구나 테스트 비중등을 앞으로 이동하고 싶어 합니다. 현실적인 방법에 누구나 궁금할 것입니다.

   아래 그림을 보면서, 공감을 많이 하실것 같습니다. 테스트가 제일 마지막에 몰려서 한꺼번에 진행되는 구조입니다.

■ 소프트웨어 개발시 수행해야 하는 테스트 목록

필자는 단위테스트에서 아래 3가지 기법을 이해하고, 실천할수 있다면 충분하다고 합니다.

· 단위 테스트

· 조합 테스트

· 경곗값 테스트 : 이 테스트만으로도 80% 의 버그를 잡을수 있음

· 상태 전이 테스트 : 상태가 변경되어서 프로그램적으로 영향을 미치는것

· 탐색적 테스트

· 통합 테스트

· 시스템 테스트

 

경계값 테스트를 위한 코드 샘플

■ 코드 기반 단위 테스트

· 함수의 커버리지를 측정해 로직의 확실성을 확인하는 화이트박스 테스트

 

<다음과 같은 항목을 확인합니다>

· 프로그램을 실행하는 도중, 시스템상의 이상 작동을 수행하지 않음(null pointer, 0으로 나누는 계산등)

· 입력값과 그에 대응하는 기댓값을 출력함

· 모든 분기가 올바르게 처리됨(경계값 테스트)

 

· 조건 커버리지 (C1) : 각각의 판정 조건이 true, false인 결과를 적어도 1번식 가지는 테스트 케이스 작성 

· 커버리지 비율 : 80%라고 설명됨 (소스코드의 20%정도는 에러 핸들링 처리인 만큼, 그 코드까지 단위 테스트로 커버할 필요가 없음)

구글의 커버리지 가이드

 

■ 테스트

• 단위테스트 효율화 : 쉬운 단위 테스트
  아래 대화 내용은 글로벌하게 다 비슷한 모습인거 같습니다.

• 단위테스트할 범위를 선정
  • 대부분의 버거는 소스코드 파일 10~20% 부분에서 발생
  • 최근에 여러차례 변경되었거나, 그 변경횟수가 많은 파일에서 버그가 발생
  • 코드의 20%을 커버하면서 차근차근 탐색적 테스트를 수행
• 독자적인 방법 : 파일을 2개로 분리
  • 파일 행수의 길이 / 복잡도 등도 고려
  • 리팩토링 할 사긴이 없다면, 먼저 파일을 2개로 분리하라 (이것만으로 장점이 많아짐)
• 리택토링
  • 단위테스트 단위로 구성이 어려운 복잡한 코드는 리팩토링도 필요
• 코드 리뷰
  • 단위 테스트가 실패하는 상태에서 리뷰를 진행해도 아무런 의미가 없음
  • 리뷰가 테스트보다 더 효율적인 버그 발견 방법
  • 페어프로그래밍은 생산성 뿐 아니라 풀질향상에 기여
• 통합 테스트
• 시스템테스트의 자동화
• 탐색적 테스트
• 수행 지표
  • 코드 커버리지 비율 (C0 아닌 C1)
  • 돌연변이 테스트
  • CK 지표
  • 핫스팟
  • 신뢰도 성장 곡선

"제이펍에서 책을 제공받아 작성된 서평입니다."