시스템 구축 프로젝트에서, 성공여부를 직접 알 수 있는 것은 테스트단계이다. 분석과 설계 단계의 산출물이 코드로 개발되고, 실제 작동여부를 확인할 수 있기 때문이다. 구축 단계 테스트는 개발자가 수행하지만, 테스트단계는 현업 사용자가 직접 참여하여 테스트를 주도한다. 개발된 물량을 누가 어디까지 테스트할 것인가가 이슈가 된다. 테스트 전략을 잘 세우는 것이 테스트의 완전성과 생산성을 좌우한다. 

테스트는 개발단계에 따라 구분할 수 있다. 단위 모듈에서 실행되어야 할 입력, 수정, 삭제 등의 단위 기능들을 시험하는 단위 테스트(unit test)를 시작으로 업무 흐름에 따라 정상 혹은 오류 처리되는지, 업무 간 연계되는 데이터 처리가 되는지 등을 확인하는 통합 테스트(integration test), 오픈을 결정하기 위해 가동 환경에서 정상 작동 여부를 확인하는 시스템 테스트(system test), 개발이 완료된 시스템과 데이터베이스를 운영팀으로 인계하기 위한 인수테스트(acceptance test) 등이 있다. 또한 특정 목적으로 테스트를 수행하기도 한다.

 

테스트 FAQ

Q) 개발자가 개발한 모듈을 단위 테스트 케이스에 따라 수행한 결과를 증적 자료를 첨부하여 제출하였습니다. TF 담당자가 별도로 또 테스트해야 하나요?  

프로그램을 개발한 개발자가 모두 테스트하고 증적을 남겼을지라도 TF의 담당 고객이 개발된 결과물을 직접 동작해보는 테스트는 반드시 필요하다. 

첫 번째, 커뮤니케이션 오류로 사용자의 요구사항을 잘못 분석하여 사용자가 원하는 기능 요건을 충족하지 못했을 수 있기 때문이다. TF 담당자가 직접 테스트를 통해 결함을 조기 식별하여 커뮤니케이션 오류로 발생하는 리스크를 줄일 수 있다. 

두 번째, 개발자 관점에서 발견하지 못한 문제점을 TF 담당자 관점에서 찾아낼 수 있기 때문이다. 일반적으로 개발자들은 프로젝트에 투입된 후 길어야 3개월 정도 현행 시스템을 파악하고 개발을 실시한다. 하지만 수년간 현행 시스템을 사용해왔던 고객사의 담당자는 개발자보다 업무 흐름, 처리 기능 등에 대한 이해도가 높기 때문에 개발자 관점에서 발견하지 못한 결함을 찾아낼 수 있다. 

세 번째, 단위 테스트를 충분히 수행하지 않고 통합 테스트로 넘어왔을 때의 리스크가 크기 때문이다. 통합 테스트가 시작되면 업무 처리 흐름에 따라 데이터가 막힘없이 잘 흘러가지는지, 타 업무와 연계된 값이 제대로 처리되는지 등을 확인하면서 결함을 발견해 나간다. 하지만 단위 테스트에서 구현된 기능들을 충분히 테스트하지 못했다면 통합 테스트 단계에서 단순한 기능 결함을 잡는데 많은 시간을 소모하게 되고 이는 더 큰 또는 더 치명적인 한 결함을 찾아내는 방해요소가 된다.

따라서 TF 담당 고객이 직접 화면, 배치, 인터페이스 등 기능을 꼼꼼히 점검하여 단위 테스트의 목적 달성 여부를 직접 확인하고 방점을 찍어줘야 한다. 하지만 여러 명의 개발자가 쏟아내는 개발 물량을 고객 TF 담당자 한두 명의 사람이 감당하기에 어려우므로 TF 조직을 구성할 때 적정한 인원을 배분하고 충분한 개발 기간을 확보하는 것이 무엇보다 중요하다.

Q) 통합 테스트 시나리오와 단위 테스트 케이스는 어떤 차이가 있나요? 단위 테스트 케이스를 특정 단위로 묶은 것이 통합 테스트 시나리오가 되나요? 시나리오는 누가 작성해야 하나요?

단위 테스트와 통합 테스트의 목적을 생각해보자. 

단위 테스트 시 사용되는 단위 테스트 케이스는 한 개의 모듈/컴포넌트가 가진 기능이 모두 정상적으로 작동하는지, 잘못된 정보 입력 시에는 오류 처리되는지 등을 파악하기 위해 사용된다. 프로그램의 단위 기능을 검증하는 단위 테스트 케이스를 얼기설기 묶어 놓는다고 각 업무의 주요 흐름 또는 타 업무와의 연계 등을 고려한 통합 테스트 시나리오와 케이스가 될 수 없다. 통합 테스트 시나리오 및 케이스를 작성하는데 단위 테스트 케이스를 참고할 수는 있으나 두 산출물은 목적이 다르므로 작성 시, 유의해야 한다. 

또한 작성 주체도 이슈가 있다. 일반적으로 단위 테스트 케이스는 프로그램 개발자가 작성한다. 하지만 단위 테스트 케이스를 개발자가 만들었다고 하여 통합 테스트 시나리오 및 케이스도 개발자가 작성해야 한다는 생각은 버려야 한다. 업무 흐름을 더 잘 알고 있는 시스템 운영자/관리자 또는 사용자가 합동 작성하는 것이 가장 바람직하다. 시스템 관점의 시나리오와 사용자 관점의 업무 시나리오가 결합되어 작성된다면 보다 탄탄한 테스트 시나리오를 만들 수 있다. 하지만 여러 가지 여건 상 수행사가 통합 테스트 시나리오를 작성해야 하는 상황이라면, 업무를 잘 알고 있는 고객과 짝을 이루어 전체 관점에서 업무 설명이나 절차가 공유된다면 시너지 효과를 낼 수 있다. 만약 개발 사업 이전 선행사업으로 PI를 수행했다면 그 자료를 활용하는 것도 좋은 방법이 될 수 있다.

성능 테스트

Q) 성능 테스트는 언제 수행해야 하나요? ‘성능 테스트’ 기간에 집중 검토하는 태스크인가요?

성능을 통합 테스트 후반 또는 테스트가 모두 끝난 이후 ‘성능 테스트’ 기간에 성능을 체크하기엔 너무 늦다. 

애플리케이션 성능은 모니터링 도구(Jennifer 등)를 사용하여 개발 중에 주기적으로 체크하고 SQL 튜닝 등의 성능 개선 활동을 수행하여야 한다. 개발 완료 후 별도의 성능 테스트를 수행하여 개선해야 할 성능 프로그램을 식별하고 시정 조치하겠다는 생각은 안타깝지만 현실적으로 불가하다. 개발자마다 배정된 개발 물량을 소화하는데도 어려움이 있어 지연이 발생하고 각 태스크마다 제출해야 할 산출물 작성, 추가 SR 반영 등 시기마다 해야 할 일이 산더미이다. 일단 개발해 두고 이후에 성능 개선하겠습니다! 라는 생각은 매우 위험하다. 

또한, RFP 성능 요건에 충족하지 못하는 대상은 빨리 식별하고 성능 개선 활동을 수행해야 한다. 간혹, 처리 프로세스가 복잡하다거나 기타의 사유로 성능 요건 제외 대상으로 선정하는데, 이렇게 대상을 미리 선정해 놓으면 다른 프로그램 성능 개선 활동에 더 신경 쓸 수도 있다. 성능 관련 요건 충족 여부는 일정 기간 동안 집중적으로 테스트하는 개념이 아닌 주기적으로 그리고 반복적으로 관리해야 하는 대상임을 명시해야 한다.

Q) 결함을 해결하고 나면 또 다른 결함이 발견됩니다. 현업에 테스트 요청해야 하는데, 시기를 늦춰야 할까요? 충분히 시간을 들여 테스트했는데, 얼마나 더 테스트해야 할까요?

테스트 단계의 성공 기준은 오류를 최대한 많이 찾아내고 발견한 오류를 최대한 해결하는 것이다. 오류는 연산 처리 장치의 잘못된 동작이나 소프트웨어의 잘못 때문에 생기는 계산값과 참값과의 오차이다. 당연히 오류는 As-Is 시스템에서도 충분히 발생할 수 있다. TF 담당자 입장에서 밤낮없이 달려왔음에도 현업에 To-Be 시스템 테스트를 요청해야 하는데, 지속적으로 결함이 발견된다는 점에 대해 굉장히 부담스러워한다. 하지만, 개발팀은 이미 수차례 각종 테스트를 수행하여 발견할 수 있는 결함을 최대한 식별했으니, 이제는 제3자 시각에서 검증이 필요한 순간이다. 결함을 다 못 잡았다고 두려워하지 말고 오픈 이후에 발견될 결함을 최소한으로 줄이기 위한 활동에 집중해야 한다. 결함을 모두 발견하고, 모두 해결해야만 테스트가 끝나는 것은 아니다. 테스트 완료 기준을 세우고, 목표 기준에 들어오면 테스트를 종료하는 것이 합리적이다.

지금까지 테스트와 관련하여 많은 사람들이 오해하고 있는 사항에 대하여 알아보았다. 성공적인 시스템 오픈을 위해 테스트 이외에도 각 단계별로 수많은 사항들이 고려되어야 한다. 하지만, 시스템 오픈에 가장 큰 영향력이 있는 테스트 관련 사항만큼은 참과 거짓을 구분하여 목적에 맞게 수행해 나간다면 성공적인 오픈을 향해 한 발자국 더 나아갈 수 있다.