먼저 그림 2.3[IPA17]을 함께 살펴보겠습니다. 일본 IPA(정보처리추진기구)에서 발표한 수치로, 조기 단계에서 품질을 보증하는 편이 출시 후의 품질을 더 높인다고 명확하게 기재되어 있습니다. / 만약 조기 단계에서 85% 이상의 버그를 발견할 수만 있다면, 대부분의 프로젝트에서 큰 폭의 일정 지연이 발생하거나 출시 후에 치명적인 버그가 나타나는 일은 없을 것입니다. 85%의 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로는 불가능하며, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야 합니다.
--- p.18
단위 테스트(unit test)의 정의에 관한 역사는 깁니다. 먼저 1970년의 〈Managing the Development of Large Software Systems〉라는 논문까지 거슬러 올라갑니다(그림 4.1). / 여기에서 말하는 ‘코딩과 단위 테스트’가 단위 테스트에 해당합니다. 하지만 업무를 하다 보면, 단위 기능 테스트(프린트 기능, URL로 점프 기능 등)도 단위 테스트라 부르기도 합니다. 소프트웨어 개발에서 용어 정의는 대단히 중요한 부분인 만큼, 개발을 시작하기 전에 단위 테스트가 코드의 정확성을 확인하는 테스트인지, 혹은 단위 기능에 관한 테스트인지를 명확하게 해야 합니다.
--- p.39
‘그렇다면 시스템 테스트의 자동화도 그런 구조로 넣으면 되지 않을까?’라고 생각할 수도 있습니다. 실제로 필자도 넣어봤지만, 셀레늄(Selenium)도 애피움(Appium)도 실행 속도가 너무 느립니다. 게다가 병행해서 실행하려면 수많은 PC나 인스턴스를 실행해야 하고, 실패했을 때 (실제 버그인지, 테스트 코드의 버그인지) 그 원인을 파악하는 데 시간이 걸립니다. / 하지만 만약 함수 단위의 단위 테스트라면, 실행 속도도 빠르고 병렬 테스트도 간단하게 실행할 수 있습니다(그림 8.3).
--- p.111
캡처 & 리플레이 도구는 스크립트의 규모가 커질수록 유지보수성이 떨어집니다. 같은 테스트를 수행하는 스크립트도 함수화되지 않은 채 그저 복사 & 붙여넣기로 가득 차기 때문입니다. 그 결과 복사 & 붙여넣기가 차츰 증가하고, UI를 한 군데만 변경하더라도 모든 스크립트가 작동하지 않는 현상이 발생합니다. / 앞에서 이미 설명한 내용이지만, 단위 테스트와 시스템 테스트 모두 자동화할 때 가장 먼저 고려할 점은 유지보수성입니다. 최초 자동화까지의 속도와 비용에 아무리 메리트가 있다고 해도, 계속해서 자동화할 수 없다면 의미가 없습니다.
--- pp.141~142
그림 13.1을 한 번 더 참조해보면 어떤 품질을 달성하고 싶은지, 어떤 정량적인 품질 목표를 세울 것인지, 그리고 그 정량적인 품질 목표에 관해 어떤 테스트를 달성할 것인지가 애자일에서의 대표적인 품질 보증에서 중요하다는 것을 알 수 있습니다. / 따라서 이번 장에서는 애자일에서의 정략적 품질에 관해 설명하겠습니다. 필자가 보기에 애자일에 적합한 대표적인 품질 지표는 다음과 같습니다.
ㆍ 코드 커버리지 비율(C0가 아닌 C1)
ㆍ 돌연변이 테스트
ㆍ CK 지표
ㆍ 핫스팟
ㆍ 신뢰도 성장 곡선
--- p.162
먼저 JaCoCo로 조건 커버리지가 확실하게 작동하고 있는지 확인해보겠습니다. 개발자는 ‘명령 커버리지와 조건 커버리지의 차이는 커버리지 비율이 단지 10% 정도 다른 것뿐’이라고 평가하는 경우가 있습니다. 하지만 테스트 담당자에게 명령 커버리지는 품질 보증 관점에서 아무런 도움도 되지 않습니다. 왜냐하면 가장 중요한 테스트 기법인 ‘경곗값 테스트’가 확실히 이루어졌는지를 명령 커버리지로는 판단할 수 없기 때문입니다. / 다소 난폭한 방법이지만, 테스트된 함수가 분기되었는지만 확인하기 위해 테스트할 소스 코드를 리스트 15.3과 같이 변경합니다. 이 코드에서는 분모에 0이 오는 경우, 그대로 return 0으로 빠져나갑니다.
--- pp.205~206