IT 프로젝트에서 분석, 설계단계를 마치고 개발단계로 들어가게 되면 이제부터는 '실물 영접'을 할 수 있거나 아예 '눈에서 사라져 버리는 영역' 이 두 가지 길로 들어서게 된다.
전자의 대표적인 경우가 화면 개발이다. 그동안 엑셀과 파워포인트로 볼 수 있었던 To-Be 이미지를 드디어 화면으로 볼 수 있게 되면서 요구사항이 어떻게 반영되었는지 눈으로 확인 가능하다.
후자의 경우가 성능, 가용성, 운영절차, 모델 등이 된다. 보이지는 않아도 시스템 어딘가에 또 다른 형태로 구체화된다.
애플리케이션, 데이터 전환, 인프라 영역 모두 단위테스트 과정을 거치게 되나 그 내용은 다르다.
이번 글은 일반적으로 말하는 애플리케이션 단위테스트에 대한 이야기다.
'개발을 한다'는 말은 '설계서대로 코딩을 한다'라는 의미다. 따라서 개발을 다 끝냈다면, 일정대로 프로그램 코딩을 완료해야 하고 이어 기능이 제대로 동작하는 지를 확인하기 위해 기본 기능 테스트를 통과해야 한다. 이것이 단위테스트다.
그래서 개발단계 완료는 단위테스트까지 완료하고 이 기간 발생한 모든 결함을 다 수정조치하였음을 의미한다.
단위테스트는 테스트 케이스를 설계하고 이를 토대로 테스트하여 성공/실패 여부를 기록하는 것이 기본이다. 테스트케이스는 그냥 작성하는 것이 아니라 '설계서'를 보고 최대한 많은 테스트케이스를 도출하게 된다.
단위테스트의 테스트케이스는 크게 2가지 유형이 있다.
하나는 표준을 준수하였는가, 두 번째는 기능이 제대로 구현되어있는가.
이때 단위테스트에서 제외되는 것은 일반적으로 환경의 제약과 데이터 제약으로 인해 테스트할 수 없는 영역이다. 인터페이스 테이스, 실 데이터를 활용한 테스트, 업무 간 연계 테스트, E2E test (End to End test) 등이 그 예로 통합테스트 단계에서 수행해야 한다.
표준 준수 여부는 화면 표준을 준수하였는지, 개발 표준을 준수하였는지에 대한 검증을 말한다.
디스플레이 용어 표준을 사용하였는지, 화면 색상/글자 색상, 폰트, 글자의 우정렬/좌정렬 까지도 모두 포함하지만, 메뉴 구성이나 화면 펼침/접음, 타 시스템 화면 연동의 디스플레이 방식, 자료 조회 방식 등 아키텍처 상 결정사항도 포함된다.
개발 표준의 경우는 별도 code inspection을 도입하기도 한다. 프로그램을 코딩할 때 개발 표준을 배포하게 되는데 이때 형식적인 표준뿐 아니라 금지해야 할 사항, 보안준수를 위한 원칙 등에서 반드시 지켜야 할 사항들을 rule로 체크하도록 한 것이 code inspection이다.
프로젝트할 때 뿐 아니라 운영할 때도 소스 신규/변경은 발생하므로 code inspection은 개발과 더불어 함께 진화 발전해야 한다.
사실 표준보다 더 중요한 것이 기능 검증이다. 단순 조회 화면이라 하더라도 검색 조건에 따라 여러 케이스를 테스트하게 되며, 복잡한 화면의 경우, 케이스 수는 상당히 증가하게 된다.
최소 분기 조건에 따른 경우는 모두 테스트해야 한다.
기능 검증은 정상 이외에 예외 케이스도 해야 한다. 예외 케이스를 테스트해야 하는 이유는 예외 사항도 로직의 한 부분이기 때문이다. 이에 대한 처리를 해 놓지 않으면 시스템에 구멍이 뚫리게 되고 garbage 데이터가 쌓이게 된다.
값에 대한 검증도 정상 값의 범주에 해당하는 유효값 검증, 경계값에 해당하는 boundary test, 유효값 바깥에 있는 예외 값 검증을 모두 수행해야 로직 상 최소한의 빈틈이 없게 된다.
여기까지 했다 하더라도 추가 테스트 유형이 더 필요하다. 업무 요건에 따라 특정 주제를 정해서 테스트를 진행해야 한다. 이를 테마테스트라고 부르는데 테스트 환경의 제약 사항에 따라 단위테스트 기간과 통합테스트 기간 중 정해서 진행할 수 있다.
예를 들어 주변기기와 연계테스트(프린터기, FAX, 생체인증 등)를 통합테스트 환경에서 가능하다면 통합테스트 단계에 별도 테마테스트 범위로 정해서 수행할 수 있다. 또 하나 예로 전 화면 단축기 테스트가 필요한데 개발환경에서 테스트 가능하다면 개발테스트 단계에 테마테스트로 정해서 수행할 수 있다.
단위테스트는 최대한 많은 테스트 커버리지를 가져가야 하고 최대한 많은 결함을 찾아내는 것이 목표여야 한다. 그래서 단위테스트 케이스 설계 시 단위를 결정하는 게 상당히 중요하다.
모든 입력 요소 (라디오 박스, 리스트 박스, 버튼 등)의 조합으로 케이스를 최대한 뽑아내는 프로젝트가 있는가 하면, 화면당 겨우 한두 개의 케이스를 도출하는 프로젝트도 있다.
당연히 전자가 품질이 높을 수밖에 없다.
개발자가 자신이 개발한 프로그램에 대해 최대한의 테스트케이스를 도출하는 것 자체가 스스로에 대한 일 량을 늘리는 것 같은 생각이 들 수 있다. 테스트를 마치면 증적 첨부까지 해야 하므로 맞는 말이기도 하다.
그래서 테스트에 대한 가이드를 정확히 주고 일 량을 제대로 파악해야 하나, 갈수록 이런 고민들이 사라지고 있는 분위기다.
많은 경우, 테스트 가이드나 샘플을 보면 두리뭉실하게 정리되어 있다 보니 개발자들은 자의적인 해석에 따라 최소한의 테스트케이스를 설계한다. 경험이 많고 뛰어난 개발자들은 가이드의 수준에 상관없이 상세한 케이스를 도출하고 알아서 다양하면서 깊이 있는 테스트를 수행하지만, 대부분은 그렇지 않다.
테스트 관리자는 테스트케이스를 분석하여 충분한 케이스가 도출되었는지 검증 작업을 해야 하나 이를 제대로 하는 프로젝트는 희귀할 정도이다.
그래서 단위테스트 기간 동안 잡아내야 할 각종 오류들이 통합테스트 기간에 현업의 테스트 참여를 통해 도출되는 경우가 많다. 이렇게 되면 통합테스트 목표 달성에 어려움을 겪게 된다.
IT 프로젝트에서 변치 않는 진리는 하나다.
오늘 할 일을 내일로 미룬다고 '절대 사라지지 않는다.'
