[경험담] 프로젝트 성공을 위해 중요한 통합테스트 이야기 (단위테스트, 테스트 주도 개발 등 소스코드 레벨 이야기 아님)

테스트 종류

프로젝트 테스트에는 크게 두 가지가 있습니다. 

1. 단위테스트

하나의 기능(모듈)을 테스트하거나, 여러 기능이 제공되는 하나의 웹서비스 화면 하나를 테스트하는 걸 의미합니다. 

아무래도 프로그래밍 개발코드와 관련된 테스트를 의미하죠. 

요즘 TDD(Test-Driven Development, 테스트 주도 개발) 이란 말이 많이 나오고 있는데, 단위 테스트를 활용하여 보다 높은 수준의 코드 품질을 확보하는 개발 방법 중 하나입니다. 

아무튼 단위 테스트는 결국 소스코드(기능), 또는 웹서비스 화면 하나를 대상으로 진행합니다. 그리고 그걸 테스트하는 사람은 결국 개발자 또는 주변 개발자 동료(코드 리뷰)인 거죠. 

 

2. 통합 테스트

단위 테스트를 마친 전체 기능, 전체 웹서비스를 테스트하는 겁니다. 화면 여러 개를 테스트한다고 해서 통합 테스트가 아닙니다. 통합 테스트는 반드시 서로 관련이 있는 기능, 또는 화면들을 테스트해야 의미가 있습니다. 그래서 단순히 CRUD에서 끝나고 다른 기능에 영향을 미치지 않는 웹서비스(예, 게시판)는 통합 테스트라고 보기 어려운 거 같습니다. 이 정도는 개발자가 테스트할 수 있으니까요

프로세스가 비교적 단순한 웹서비스라면 모르겠지만, 프로세스가 복잡한 웹서비스의 경우 통합 테스트의 중요도는 상당히 높습니다. 

 

 

오늘은 두 가지 테스트 중 통합 테스트에 대해서 집중적으로 이야기하려고 합니다. 예전에 통합 테스트의 중요성을 아주 뼈저리게 느낀 프로젝트를 경험했었거든요. 여러 업체, 그리고 돈이 관련된 프로젝트라 업무 프로세스가 상당히 복잡했습니다. 그때 경험담을 토대로 프로세스가 복잡한 웹서비스의 통합 테스트를 어떻게 준비해야 하는지 말하려고 합니다. 

 

---

 

다양한 고려사항을 검토해서 통합테스트 일정 재산정 필요

보통 RFP(제안요청서)를 보면 전체적인 프로젝트 기간이 나옵니다. 이걸 토대로 프로젝트 투입 시 각 업무별 일정(WBS)을 산정하게 됩니다. 

 

공공기관 RFP에 명시된 추진일정 예시.

 

그런데 일정을 산정할 때 업무 프로세스를 고려하지 않고 대부분 한 달, 또는 6주 이런 식으로 산정합니다. 이렇게 일정을 산정하게 되면 나중에 통합 테스트를 막상 시작하게 되면 빡빡한 일정에 다들 야근 모드에 들어가게 됩니다. 반드시 다음 고려해야 할 사항들을 보고, 그에 맞게 일정을 재산정해야 합니다. 

 

고려해야할 사항

• 프로세스에 타 시스템과 관련된 부분이 있는가?(데이터 연계, API 활용 등)
• 데이터베이스에 초기 데이터 구축 또는 데이터 이관이 필요한지? 
• 업무 프로세스가 얼마나 복잡한가? (단순 CRUD 제외)
• 사용자 관점에서 다양한 시나리오가 나올 수 있는가? 
• 통합 테스트에 참가할 수 있는 사람이 누구인가?(PL, 고객, 콜센터 등 업무 프로세스를 아는 사람)
• 단위 테스트는 확실히 끝났는가? (화면 오류로 인해 통합 테스트가 진행이 멈추면 안 됨)
• 통합 테스트를 위한 다양한 테스트 사용자 정보(ID, PW, 공인인증서 등)가 제공되는가?(권한별 사용자 정보)

 

 

통합테스트 절차

단위 테스트가 확실히 끝나는지 확인!

통합 테스트 진행 도중 에러가 발생해서 더이상 테스트가 진행이 안될 경우 많은 사람이 대기를 해야할 수 있습니다. 

통합 테스트 전까지는 단위테스트 체크리스트 등을 만들어서 모든 개발자가 본인이 맞은 기능에 대해 테스트를 했는지 작성해서 제출하도록 하는게 좋습니다. 그리고 문제 발생시 신속하게 오류 사항을 수정하고 통합테스트 서버에 반영이 될 수 있도록 자동화된 통합빌드-배포 시스템이 구축되어 있어야 하겠죠. 

 

 

2. 통합테스트 시나리오 작성

모든 발생 가능한 케이스를 고려해서 작성해야 합니다. 

예를 들어 아래와 같은 프로세스가 있다고 하겠습니다. 갑-을-병-정... 구조로 돈을 주고받는 형태입니다. 

복잡한 프로세스 예시.

이때 시나리오는 발생 가능한 모든 케이스를 작성해야 합니다. 

갑-을-병-정 업체 중

정 업체가 있는 경우 없는 경우, 1개인 경우 여러 개인 경우

병 업체가 있는 경우 없는 경우, 1개인 경우 여러개인 경우

을 업체가 있는 경우 없는 경우, 1개인 경우 여러개인 경우

갑 업체가 여러 개인 경우 

돈 달라고 했는데 문서를 잘못 작성해서 반려처리된 경우

반려 처리된 걸 다시 수정해서 요청하는 경우

여기에 돈의 종류(예. 계약금, 중도금, 준공금 등)에 따라 화면 구성 및 프로세스가 조금씩 다르다면 케이스를 전부 따로 작성해야 합니다. 

 

여기에 업무 처리할 수 있는 사용자 권한이 섞이게 된다면 더욱 복잡해지는 거죠. 

관리자가 로그인한 경우

경리(사원) 담당자가 로그인한 경우

회계(관리급) 담당자가 로그인한 경우 

등등등.

 

경리 담당자가 로그인해서 잘 처리되었는데, 회계담당자가  로그인했더니 처리가 안 되는 문제가 발생할 수 있기 때문입니다. 아니면 보이지 않아야 하는 버튼이 보인다거나 하는 문제 등이요. 

 

 

3. 테스트할 다양한 사용자 정보 준비

사용자 권한별로 접근 가능한 화면(메뉴)이 잘 나오는지, 또는 직접 URL로 접근했을 때 적절하게 에러 메시지를 표시해주는지, 동일한 화면인 경우 권한에 맞게 버튼이 적절하게 보이는지 등을 테스트하기 위해서 권한별로 설정된 사용자 정보를 준비합니다. 

 

통합 테스트와 관련된 외부 시스템 협조 요청

외부 시스템의 API를 호출하거나 외부시스템에 데이터를 보내거나 받아야 하는 경우 외부시스템 담당자와 통합 테스트 날짜를 협의해야 합니다. 이게 참 어렵습니다. 외부 담당자도 잘 안 해주려고 합니다. 본인 공수를 잡아먹으니까요. 다양한 케이스로 테스트를 해야 하는데 그냥 대표적인 케이스 한, 두 개만 테스트하게 되고, 이러면 꼭 시스템 오픈 후 문제가 터집니다. (예:을 업체가 두 번째 프로세스에서 특정 청구서를 반려한 경우 등)

 

5. 테스트 데이터 만들기

앞에서 작성한 시나리오를 수행하기 위한 테스트 데이터를 만듭니다. 이 데이터는 데이터 이관 전, 즉 시스템 개발하기 전 운영 데이터를 이용해서 만드는 걸 의미합니다. 

만약 DB(ERD) 변경이 없다면 그냥 첫 프로세스부터 통합 테스트를 시나리오대로 진행하면 됩니다. 

하지만 데이터 이관이 있다면 특정 시점의 프로세스부터 테스트를 수행할 수 있도록 미리 테스트 데이터를 만들어 놔야 합니다. 그래야 데이터 이관 테스트 후 정상적으로 데이터 이관이 되었는지, 프로세스가 중간부터 정상적으로 진행되는지 테스트를 할 수 있기 때문입니다. 

 

6. 데이터 이관 스크립트

데이터 이관이 있는 경우에는 당연히 데이터 이관 스크립트를 작성해야 합니다. 

이관 스트리트 검증도 해야 하고요. 이런 것도 전부 일정에 영향을 미칩니다.  (이걸 DA가 해야 한다. 업무 PL이 해야한다 엄청 싸웠습니다. 결국 업무PL이 하게 되었죠)

 

7. 데이터 이관 테스트

데이터 이관 테스트를 진행합니다. 즉, 데이터베이스가 두 개가 준비되어 있어야겠죠? 그리고 이관 스크립트를 돌려서 데이터가 정상적으로 이관되는지, 시간은 얼마나 걸리는지 확인합니다. 

 

업무 프로세스를 아는 사람들이 통합 테스트 시작

데이터 이관을 마치고 테스트 서버의 웹서비스를 오픈했다면 PL(프로젝트 리더)와 고객, 콜센터 직원 등 업무 프로세스를 아는 사람이 테스트를 시작합니다. 이때 테스트 시나리오별로 테스트한 사람, 성공여부, 오류내용 등을 작성해서 제출하도록 해야 합니다. 

이 때 심각한 오류가 발생해서 테스트 진행이 안될 경우 참 골치 아파집니다. 

즉각 개발자에게 오류 내용을 알리고, 오류 수정을 수정해서 SVN 커밋해 놓으면

관리자가 통합 테스트와 관련된 모든 사람들에게 테스트 중단 요청을 합니다.

그리고 젠킨스를 이용해서 빌드를 돌린 후 성공하면(이때 먹구름이 뜨는 건 상상도 하기 싫네요)

테스트하는 사람들에게 다시 테스트 시작을 전파합니다. 

 

9. 테스트 결과 취합 & 보고

그날 나온 테스트 결과를 취합해서 오류 내용을 개발자에게 전파하죠. 그리고 개발자는 오류사항 우선순위를 고려해서 오류를 수정하는데, 만약 다음날 테스트에 영향을 미치는 오류는 밤을 새워서라도 고쳐야 하는 거죠

그리고 테스트 결과를 문서화해서 고객 또는 PM 등에게 보고를 합니다. 물론 언제까지 어떻게 고치겠다를 함께 보고해야 하죠 ㅜㅜ

 

---

 

지금까지 통합 테스트에 대해 이야기를 쭈욱 해봤습니다. 통합 테스트는 무시할 수 없는 아주 중요한 업무입니다. 단위 테스트와 통합 테스트 일정을 같이 묶어서 단순하게 한 달 정도 하면 되겠지? 이렇게 생각하면 큰코다칠 수 있습니다.  일단 단위 테스트와 통합 테스트 일정을 분리하는 걸 추천드립니다. 

 

앞에서 살펴본 것처럼 통합 테스트는 '개발'과 관련된 업무는 아닙니다. 하지만 대부분 개발자 출신의 업무 PL이 관여되는 경우가 많습니다. 중요한 건 통합 테스트를 준비하고 실시하는데 예상보다 큰 '공수'가 들어간다는 거고, 이를 경시할 경우 PL 업무가 많아져서 전체적인 프로젝트 일정에 차질이 발생할 수 있다는 겁니다.