이규원님의 현실 세상의 TDD 기초, 2편 : 테스트 기법

이번 이야기는 테스트 기법에 대한 이야기다

학습 내용에 내 개인적인 생각도 더한거라

자세한 내용이 궁금하면 이규원님의 TDD 수강을 신청하는걸 권장한다.

The RED : 이규원의 현실 세상의 TDD : 안정감을 주는 코드 작성 방법 | 패스트캠퍼스

 

수동 테스트

1) 흔히 말하는 테스트 전문가인 QA 가 직접 구현된 UI를 통해서 기능 하나하나 품질을 체크해주신다.

 -> 구현된 기능을 하나씩 테스트하거나 복합적으로 다양하게 체크를 진행한다.

 

2) 최종 사용자의 사용 경험과 비슷하게 검증을 실시한다.

 -> 엑셀 같은걸로 사용자의 사용 시나리오를 다양하게 최대한 정리해놓고 순서대로 하나씩 검증을 하는데, 개발자가 생각지도 못한 경우까지 진행한다. 통합 테스트에 많은 수정사항을 받을 수도 있다.

 

3) 실행 비용이 높고 결과의 변동이 크다.

 -> 테스트 전문가가 수동으로 하나씩 UI 로 테스트를 진행하니 다른 테스트 기법에 비해 상대적으로 시간이 많이 소비된다. QA 도 사람이라 실수를 하는 경우도 있어서 결과의 변동성이 존재한다.

 

4) 가장 온전한 코드 실행

 -> 개발된 기능을 테스트로 모두 확인한다

 

5) 인수 테스트

 -> 고객에게 제작된 소프트웨어를 넘길 때 가장 많이 사용되는 테스트다

 

 

소프트웨어 회귀

어떤 소프트웨어의 기능이 어떤 사건 이후에 동작하지 않게 된다.

주로 새로운 기능이 추가될 경우, 영향을 받아 에러가 발생하는 케이스.

기능이 추가되고 많아질 수록, 추가된 영역만 테스트를 해도 기능에 대한 보장을 할 수 없다는 뜻.

이전 기존 코드까지 모두 테스트하면서 살펴봐야 한다.

전문적인 수동테스트팀이 존재해도 시간이 지나면 지날수록 진행해야할 테스트를 감당 못한다.

추가된 기능만 수동테스트 진행하고, 이전은 다른 테스트 기법으로 진행해야 감당이 가능.

 

 

테스트 자동화

1) 기능을 검증하는 코드를 작성

-> 구현된 기능이 제대로 작동하는지 테스트 코드를 작성한다.

 

2) 테스트 코드 작성 비용이 필요, 하지만 실행 비용이 낮고 테스트 결과 신뢰도가 높다

-> 테스트 코드 작업도 시간이 많이 들어간다. 각 기능별 다양하게 테스트를 해야하기 때문, 하지만 테스트 명세서처럼 계속 누적되어 남기 때문에, 추가 기능이 생겨도 이전 기능들은 이미 테스트 코드가 존재하기에 일괄적으로 테스트를 빠르게 실행하여 추가된 기능에 영향을 받아 실패하는 기능이 존재하는지 파악이 쉽다. 

 

3) 테스트 코드 작성과 관리가 개발자의 역량에 영향 받는다

-> 테스트 코드를 많이 작업해본 개발자와 테스트 코드를 안해본 개발자의 테스트 코드는 많은 차이점이 존재한다. 내가 테스트 코드를 접한지 별로 안된것처럼 어떤 기능에 대해 테스트를 진행한다면 내가 생각할 수 있는건 몇가지 밖에 안되고, 사용도구도 몇가지뿐 모르니 작업한 테스트코드도 몇개 없을 것이다. 하지만 테스트 코드를 많이 접해본 개발자는 다양한 방법으로 테스트를 진행한다. 내가 알지 못하는 도구들을 사용하니 테스트코드 개수부터 차이가 많이 난다. 시야부터 다르다.

 

 

 

인수 테스트

1) 배치된 시스템을 대상으로 검증

-> 고객에게 인수되기전 실행되는 검증 테스트라, 최대한 현장과 유사한 환경에서 진행된다.

 

2) 전체 시스템 이상 여부 신뢰도가 높음

-> 테스트 결과에 대한 신뢰도가 높다. 

 

3) 높은 비용 (작업비용 / 관리비용 / 실행비용)

-> 수동으로 진행되니 투입되는 인력과 소비되는 모든 시간이 비용이다

 

4) 피드백 품질이 낮음

-> 테스트 중 문제가 발생되면 현상은 파악은 되지만 원인, 이유 같은건 개발자가 직접 찾아야된다.

 

 

 

단위 테스트

1) 시스템의 일부를 대상으로 검증

-> 기능 별로 테스트를 진행한다. 필요한 부분만 따로 테스트 할 수 있다.

 

2) 낮은 비용 (작업비용 / 관리비용 / 실행비용)

-> 한번 작성된 테스트코드는 계속 남아서 언제든지 실행이 가능하다.

 

3) 높은 피드백 품질

-> 개발자 입장에서 테스트 실행 결과를 받는다. 문제가 생기면 어디서 생겼는지 파악이 쉽다.

 

4) 전체 시스템 이상 여부 신뢰도가 낮음

-> 작은 단위로 테스트를 통과해도, 복합적으로 실행되는 전체 테스트 경우엔 실패할 수도 있다.