조직의 코드레벨 테스트와 커버리지에 대해 현재 상황을 파악(설문, 코드 검토)하고 몇가지 개선계획 중 현실성 있는 2가지 개선안을 선정하여 진행한 사례입니다. 2018년 Pilot 수행 후 2019년 확산하여 진행.

1. 테스트 커버리지
개선 T/F 2018
작성일 : 2018 . 12 . 17

2. Contents
1. 팀 구성과 미션
미션 T/F 팀의 시작과 최초 받은 미션에 대한 설명
2. 현황 파악 및 개선 계획 수립
방향 설정을 위해 설문을 하고, 기본적인 조사를 수행
3. Pilot 수행 결과
두 가지 개선방안에 대해 3개월여갂 Pilot 수행 내용
4. 향후 계획
후속, 향후 짂행 계획

3. 팀 구성과 미션(5월)
미션 T/F 팀의 시작과 최초 받은 미션

4. 티.코.팀?
본업 외에 자율 의지에 따라 모인 QE유닛 내 소규모 미션 팀
인원 수는 적지만 알찪 팀
업무 외에 추가로 하는 일이니
저희들에게 배움의 시간도
되었으면 좋겠습니다
기졲에 개발팀 앆에서 밀접하게
일한 경험이 많이 있는데, 이
경험이 도움이 되었으면 합니다
테스트 커버리지 측정이 실제
개발팀에도 도움이 되는 지 알고
싶고 더 개선할 방법을 찾고
싶습니다
숫자상의 테스트
커버리지가 아니라
코드레벨 테스트가 잘
이루어 졌으면 좋겠어요

5. Mission is...
업무 외에 추가로 하는 일이니 저희들에게 배움의
시갂도 되었으면 좋겠습니다
숫자상의 테스트 커버리지가 아니라 코드레벨
테스트가 잘 이루어 졌으면 좋겠어요
테스트 커버리지 측정이 실제 개발팀에도 도움이
되는 지 알고 싶고 더 개선할 방법을 찾고 싶습니다
기졲에 개발팀 안에서 밀접하게 일한 경험이 많이
있는데, 이 경험이 도움이 되었으면 합니다
"왜 커버리지가 향상되지 않을까? 개발자 관점에서 생각해 보자“
"현재 취합 대상이 적젃할까?"
"실제 의미있는 측정이 되도록 하는 방법(실효성)을 찾자“
"커버리지 취합, 정말 의미있는 홗동일까?"
"우선은 현재 상태에 대해 제대로 된건지 확인하는 걸 시작으로"
"개발팀도 공감할 수 있는 방향으로 짂행되었으면 한다"
"Top-down 푸시가 아니라, 낮은 셀에서 개선되고 이게 좋은 사례로
자연스레 젂파되었으면"
“실제로 의미있는 테스트 코드와 커버리지 측정이 되기 위해”
“현재 상태를 알아보고 개선 방앆을 찾아보자”

6. 수행계획
팀 구성 현황파악 개선 Pilot 수행 확산
2018년5월
팀 구성 및 방향 설정
2018년6월-7월
CTO 조직대상 설문 및 코드 검토
2018년8월-11월
2개 개선 방안 선정하여Pilot 수행
(1)셀별 상세 현황 제공
(2)교육과정
2018년12월~
QE인력교육을시작으로2019년도
부터 확산 짂행
2018년 5월~11월 2018년 12월~

7. 현황파악(6,7월)
#1 설문
#2 개발/테스트 코드 검토

8. #1 설문조사 결과 (2018.6월말~7월)
[ 응답자 정보 ]
1) 응답자 수 및 근무연차
2) 수행 직무/역할
. 응답현황,총 32명 응답(서버 개발자 25명(78%))으로 테스트 코드 작성 경험이
있는 (연차 높은)인력이 주로 응답
. 테스트 코드 작성에 관해, 젂반적으로 테스트 코드 작성의 장점에는 공감하
나 테스트 데이터 확보, 의졲 관계에 있는 타 모듈 등 홖경적 어려움이 있어 가이
드(BP)/교육 등을 원함
. 테스트 커버리지 측정에 관해, 측정 자체는 필요하다고 공감하나 테스트 실
패가 있음에도 숫자만 관리하는 등의 접근에는 문제가 있다고 생각함
젂체요약

9. Q.테스트 코드 작성의 좋은 점은?
1위.개발한 코드에 대해 바로 테스트가 가능하다
2위.단위테스트를 하면서 코드 리팩토링이 가능하다
Q.테스트 코드 작성의 문제점은?
1위. 테스트 데이터 확보 및 유지가 어렵다
2위. 코드 테스트로는 실행이 불가한 개발코드가 많다
3위. 코드 작성에 필요한 시갂이 배분되지 않음
4위. 상세한 테스트코드 작성 가이드가 필요하다
Q.테스트 커버리지 측정/취합의 문제점은?
1위. 숫자만 체크하고 실제 테스트가 잘 짜여져 있는지에 대한
확인은 하지 않는다
2위. 월말에 취합하므로 그 때만 테스트 데이터를 맞추고
보여주기식으로 수행
[ 테스트 코드 작성에 대한 의견 ] [ 테스트 커버리지 측정/취합 에 대한 의견 ]
[ 몇가지 개선 방앆에 대한 의견 ]
테스트 코드/커버리지 교육과정
커버리지 측정대상 정책(제외 정책)
셀별 상세한 코드 테스트 현황 제공
Jenkins 빌드 제한(테스트 모두 성공 등 기준 만족시에만 배포)

10. #2 개발/테스트 코드 분석
2개 레파지토리 대상 SonarQube 품질지표 기준으로
1) 라인 커버리지가 낮은 개발코드(파일) Top 5
2) 브랜치 커버리지가 낮은 개발코드(파일) Top5
3) 해당 파일 등을 커버하는 테스트 코드 젂반적인 리뷰
4) SonarQube가 제공하는 코드 정적검사 결과 약식 검토
분석젃차
. 테스트 실패가 있음(테스트 데이터 변경 등으로)
. SonarQube의 정적 검사 룰 위반
. 테스트 코드 미작성 케이스 발견
. 여러 분기에 대해 각 분기에 대한 테스트 누락 케이스 발견
(주로 방어 코드 부분들)
. 분기는 있으나 대안흐름 없이 단순 log찍고 끝내서
테스트 코드 추가하기 애매한 케이스 발견
. 커버리지만을 높이기 위한 단순 실행 코드 케이스 발견
분석결과(요약)

11. 개선 방안 선정
※ 8개 개선방앆 중 현실성, 효과 등을 검토하여 2개 방앆을 선정
1. 개발 파트별 상세한 테스트 코드/커버리지 리포트 제공
2. 테스트 코드/커버리지 관렦한 이론+실습 형태의 교육 짂행

12. Pilot 수행(8-11월)
#1 상세 리포트 제공
#2 교육과정 계발

13. Pilot 수행 개요 1/2
구분 업무(셀) 기졲 현황 가설 수행내용 수행 결과
Case#1
정*산
. 이미 커버리지 목표치(65%)를 달성
. 이미 담당 QE가 개별적으로 현황을
제공
이미 QE가 유사한 공유를
하고 있고, 목표를 달성하
고 있는 셀에서도 변화가
있는지 확인
기졲 커버리지 관렦 공유
내용을 보완하여 개발팀에
제공
. 이미 목표치를 달성하고
있어서 큰 변동은 없음
검*색
Case#2
딜*리
. 커버리지 목표 미달, 테스트 실패 건
이 졲재
. 별도 커버리지 관렦 상세 공유 내용
없음
커버리지가 미흡하고, 기
졲에 아무런 홗동이 없던
셀에서의 변화 확인
. 정기적으로 커버리지 상
세 현황을 공유
. 데일리 미팅, 메싞저 등
을 통해 리마인드 및 개선
사항을 실시갂 공유함
. 라인, 컨디션 커버리지,
테스트 실패 건이 점차적
으로 좋아짐
딜*세
[ Pilot 수행내용 요약 ]
. 상황이 다른 4개 셀을 대상으로 커버리지 상세 리포트가 효과가 있는지 검증 짂행
. 기간 : 2018년 8월부터 3-4차례

14. 1) 이메일로 셀별 상세현황 제공
Pilot 수행 개요 2/2
QE
~ 어제는 저희 코드 테스트 현황
정리해서 공유드렸구요~
커버리지는 어느 정도 만족하고
있는데 테스트 실패 건이 있어서
확인이 필요할 거 같습니다!!
~~님, 지금꺼 포함해서 테스트해보
니
커버리지 64.3%!!!! 2줄만 더!!!!
3) 메싞저
2) 셀 (데일리) 미팅
(AS-IS)
젂체대상현황 공유,(커버리지)숫자위주의공유
(TO-BE)
셀(레파지토리)별개별공유(이메일,데일리,메싞저등)
테스트가왜 실패했는지실패내용과
어떤파일에 어떤커버리지가부족한지 상세정보제공
CTO 조직 젂체 대상, 젂체 현황 공유
보완
X 조직별 현황 표/추이 X

15. ※ 이메일 공유 항목 상세보기
라인/브랜치 커버리지가 낮은 파일에 대한 현
황 및 상세 정보 링크
한정된 수싞자에게 구체적인 정보를 젂달하여 정보 젂달력을 높임
기본 현황 및 목표 대비 미흡 수준 공유
1) Junit 테스트 현황 (젂체 / 성공 / 실패)
2) 테스트 커버리지 현황(라인 / 컨디션 커버리지)
테스트 실패 건에 대해 샘플링하여 어떤 테스트가 어떤 이유로 실
패하는지를 이메일 본문에 작성하고 젂체를 확인할 수 있는 링크
제공 ☞숫자(건수) 공유가 아니라, 실제 도움이 되는 정보를 제공
실패한 테스트에 대한 현황 및 상세 정보 링크
1) 젂반적인 코드 품질 현황/추이 제공
0) 셀/레파지토리별 수싞인 설정
어떤 파일에 어떤 커버리지가 낮은지 이메일 본문에 작성하고, 상
세 확인할 수 있는 링크를 제공
☞실제 어떤 테스트를 추가해야 하는지 정보 제공
테스트 코드 작성에 대한 FAQ 정보 제공
#간단한 테스트 코드 작성 팁 정보 제공

16. Case#1 (검*색, 정*산): 기졲에 이미 담당 QE가 주기적으로 현황을 공유하고 있었으며 커버리지 목표도
어느정도 달성하고 있어 테스트 실패 건수나 커버리지에 큰 변화는 없음
Case#2 (딜*리, 딜*세): 상세 정보를 제공한 후 미흡한 커버리지나 테스트 실패건수가 크게 개선됨
라인
커버리지
컨디션
커버리지
커버리지
목표치
65%
Pilot 결과 (정량적 결과)
Case#1
Case#1
Case#2
Case#2
테스트 실패 상세내용은
따로 공유하지 않음
(커버리지 현황만 공유)

17. 수행인력(QE/개발팀) 회고 (정성적 결과)
좋았던 점 아쉬운 점
QE
개발
• 이메일만으로 무슨 효과가 있을까 했는데
실제 커버리지, 테스트 실패 건이 수정되었다
• 이제는 개발코드 PR에 테스트 코드도 같이
반영되는 경우가 있다
• 이메일 공유 후 데일리, 메싞저 등을 통해서
테스트를 추가했다는 피드백을 받을 수 있었다
• 입/퇴사로 인해 커버리지 젂파를 다시해야 한다는 점
• 상대적으로 컨디션 커버리지를 높이는 방법에 대해
어려워한다
• 리마인드 된다, 알게모르게 압박이 된다
• 굳이 찾아보지 않아도 알림을 받을 수 있다
• 어떤 레파지토리가 미흡한지 상세하게 파악할 수 있다
• 앞으로는 API 테스트 코드 작성 주체가
명확하지 않을 수도 있을 것 같다
☞ 정기적인 교육과정 등의 접근 검토
☞ 개발코드와 테스트코드를 같이 작
성하고 배포하는 개발문화 정착 필요

18. Pilot 회고 정리
테스트 커버리지가 미흡한 셀에 변화(개선) 확인
. 이미 목표치를 달성한 셀(Case#1)은 변화가 미미했으나, 미흡한 셀(Case#2)에서는 개선 효과가 있음
. 개발팀과 담당 QE간 다양한 커뮤니케이션이 효과가 있음(이메일 외에 데일리 미팅, 메싞저 등)
근본적으로 테스트 코드 작성에 대한 문화/마인드의 변화가 필요
. 테스트 코드 작성을 개발과 테스트의 자연스런 단계가 아닌, 별개의 업무로 인식
(개발코드 반영 후 별도 작업으로 테스트 코드를 작성)
. 기졲 셀 체제가 없어지는 경우도 있어, 개발 코드 반영 시 테스트 코드 작업이 같이 수행되지 않으면
이후 작성 주체가 명확해지지 않을 수 있음
젂체 셀 대상으로 확산하여 변화 확인
테스트 코드의 필요성과 방법을 젂달하는 교육 운영

19. 교육교재/실습
코드 레벨 테스트와 커버리지 중요성을 설명하는 Basic 과정,
샘플 어플리케이션 대상으로 실습을 해보는 Advanced 과정 두가지로 분류하여 계발
기본이론 실습위주+

20. Basic 교육 구성

21. Advanced 교육 구성

22. 향후 계획(12월~)
마무리 및 확산

23. 향후 일정 및 계획
2018년 12월 마무리 후 2019년부터 적용(확산)
코드 커버리지 제외 룰
적용 프로세스 도입
코드 커버리지 측정
대상 확대
정적 코드 품질지표
가이드
실제 티몬 개발코드 대상 테
스트 코드 BP 작성/교육
5월 6-7월 8-11월 2019년12월
팀
구
성
및
방
향
수
립
현황파악
개선계획 수립/
Pilot 수행
상세 리포트
작성 가이드 완료
희망자 대상 분기별 교육
상세 리포트 공유(매월말)
QE 인력
작성방법
교육
Advanced 교육과정
계발완료 QE 인력 대상
교육 (2회)

24. 감사합니다

25. 월별 상세 수행 일정(2018년)
구분 5월 6월 7월 8월 9월 10월 11월 12월 +1년차
계획
QE조직
내부수행
CTO조직
수행
설문
역량
강화
설문
준비
확산계획수립팀
구성
개선방앆&우
선순위 선정
코드검토 Pilot#1 준비
Pilot 계
획수립
설문 등 결
과 정리
Pilot#2-교육계발
확산Pilot#1-셀별 상세현황 제공
Pilot#3-제외
룰
Basic 교육교재/실습코드 작성
Advanced 교육교재/
실습코드 작성
교육
-Basic&
Advancde
d
교육
-Basic
돌아가기
#별첨.월별 상세 수행일
정

26. #별첨.Pilot 수행회고 상
세
수행회고 1/2 –수행 QE(5명)
좋았던점 아쉬운점, 개선할점
이메일만으로 무슨 효과가 있을까 했는데 실제
커버리지, 테스트 실패 건이 수정되었다
이제는 개발코드 PR에 테스트 코드도 같이 반
영되는 경우가 있다
잘 수행하던 인원이 퇴사한다
상대적으로 컨디션 커버리지를
높이는 방법에 대해 어려워한다
돌아가기

27. 수행회고 2/2 – 개발팀(11명)
좋았던점 아쉬운점, 개선할점
돌아가기