시스템 품질 관리 강좌 - 퍼옴

시스템 개발, 구축의 필수 과정인 시스템 검증. 하지만 아직 많은 기업들이 신경쓰지 못하고 있는 것이 현실이다. 시스템 검증은 보다 뛰어난 품질의 시스템을 개발, 구축하기 위한 필수 요건이며, 특히 출시 이후에 벌어지는 각종 문제를 미연에 방지한다는 점에 있어서 비용이나 품질, 안정성 등에 큰 이점을 제공한다. 그동안 멀게만 느껴졌던 시스템 검증이란 무엇이며, 어떻게 이뤄지는가에 대해 알아보자.

강종원 | 엔씨아이 대표/수석 컨설턴트

프로그램 개발이나 시스템 구축시 테스트는 반드시 필요한 과정이다. 아무리 뛰어난 시스템이 있더라도, 품질이 나쁘다면 이용가치는 크게 떨어질 수밖에 없다. 따라서 모든 시스템 개발은 분석, 설계, 개발과 같이 테스트 과정도 일정에 포함하고 있다.
시스템 검증이란 검사나 측정을 통해 시스템을 실제로 동작시켜서 얻은 다양한 데이터를 분석, 평가하고,  프로젝트 진행 중에 작성하는 각종 보고서와 설계서 등의 산출물을 통해 검증 대상의 시스템 품질을 명확히 하는 것이다. 이와 동시에 시스템의 품질을 향상시키기 위한 계획과 검증 결과를 검증 의뢰인에게 제공하는 업무를 통틀어 시스템 검증이라고 한다.
시스템 검증은 좁은 의미에서는 테스트와 동의어로서 사용되고 있다. 물론 테스트는 검증의 중요한 일부지만, 시스템 개발이 종료해도 그것으로 그 시스템이 완성됐다고 할 수는 없다.
개발 후 시스템의 도입과 도입훈련 시스템의 운영, 그리고 안정적으로 가동될 때 성능측정, 가동감시, 부분적인 개조, 새로운 시스템 요구 등 하나의 시스템 전체를 생각하면 시스템 개발이라고 하는 것은 시스템 라이프 사이클의 일부에 지나지 않음을 알 수 있다. 시스템의 검증은 시스템의 라이프 사이클 중에 실시되는 품질의 평가, 개선에 관한 모든 작업을 말한다. 따라서 테스트(검사, 측정의 실시)는 검증 전체의 일부 작업일 뿐이다.
 
테스트 프로세스 개선의 CMM 접근 방법
어떤 소프트웨어 개발에서도 테스트 프로세스는 필요하다. 그리고 테스트 공수는 개발 공수에서도 큰 비중을 차지하고 있다. 따라서 소프트웨어 개발의 생산성 향상과 소프트웨어 품질 강화를 위해서는 테스트 프로세스의 개선을 도모할 필요가 있다.
그럼에도 불구하고 테스트 프로세스의 개선은 개발 프로세스의 개선만큼의 연구가 진행되지는 않고 있다. 여기서는 일반적으로 잘 알려져 있는 소프트웨어 개발 프로세스 개선 모델인 SW-CMM(Capability Maturity Model for Software)를 참고해 테스트 프로세스를 개선하기 위한 성숙도 모델인 Test-CMM를 작성해, 이를 이용한 테스트 프로세스 개선에 관해 고찰해 보자.
최근 소프트웨어 개발에 있어서 단기 납기, 품질 향상은 지극히 당연한 일로 요구되고 있다. 또한 사용자 요구의 다양화에 의해 소프트웨어의 대규모화, 테스트 항목의 증대에 대응하기 위해 소프트웨어 개발 프로세스의 개선이 중요시 되고 있다.
이런 상황에서 소프트웨어 개발 프로세스에 필요한 요소로서 SEI(Carnegie Mellon Software Engineering Institute)에 의한 소프트웨어 성숙도 모델(이하 SW-CMM)이 개발됐다. SW-CMM은 미숙한 조직에서 성숙하고 규율있는 프로세스로 이행해 가는데 있어, 조직이 취해야 할 단계적인 개선 지침을 제시하고 있다. 그러나 개발 프로세스를 효율화했다고 해도 개발 프로세스의 최종 공정인 테스트 프로세스가 충분하게 기능하지 못하면 고품질의 제품을 출시할 수 없다.
또한 최근 각광을 받고 있는 XP(eXtreme Programming)에서도 'TEST FIRST'를 중요 요소의 하나로 열거하고 있는 등, 테스트의 중요성에 대한 인식은 과거보다 점점 높아가고 있다.
여기서는 소프트웨어 개발 프로세스를 개발 프로세스와 테스트 프로세스로 구분해 테스트 프로세스의 개선에 착안해 보기로 하자. 그리고 테스트 프로세스의 단계적인 개선 지침으로서 SW-CMM에 근거한 테스트 프로세스 성숙도 모델로서 Test-CMM을 제시한다.
또 구체적인 테스트 프로세스의 개선 수법으로서 IQUIP에서 구축한 TPI(Test Process Improvement) 모델을 이용해 설명하겠다.

   

테스트 프로세스의 개선
현재 대다수의 개발 프로젝트에서 채용되고 있는 개발 방법은 워터폴 모델이다. (그림 1)은 일반적인 소프트웨어 개발의 V모델이다.
V모델의 좌측을 개발, 우측을 테스트라고 하면, 각각의 개발 프로세스에 대응하는 테스트가 존재한다. 일반적으로 버그의 수정이 공정 내에서 검출되지 않았을 경우 앞의 공정으로 되돌아가는 공수가 발생해 많은 비용을 필요로 하게 된다. 그리고 최종 공정인 테스트에서 버그를 검출하지 못했을 경우에는 버그를 포함한 채로 출시되며, 이때는 수정에 필요한 비용적인 손실과 더불어 기업의 이미지 추락과 같은 사회적인 손실까지 초래할 수 있다.

이같이 테스트는 제품의 버그를 검출할 수 있는 최종 공정으로서 매우 중요하며 많은 개발 프로젝트에서 테스트 공수를 더 많이 할당하기도 한다. (표 1)은 개발공정 전체의 공수에 대한 테스트 공수의 실적이다.
패키지 소프트웨어와 SI에서는 개발공정의 약 30%에서 70%의 비율을 차지하고 있으며 임베디드 소프트웨어 개발에서도 향후 소프트웨어의 비중 확대에 따라 테스트 비율은 증가해 갈 것으로 예상된다.

   

앞에서 설명했듯이 테스트는 소프트웨어 개발 공수 전체에 큰 비율을 점유하고 있다. 또 버그가 포함된 제품의 출시를 방지하는 의미로도 중요한 프로세스다. 테스트 자체로 제품의 품질을 향상시키는 것은 불가능하지만, 품질을 향상시키기 위한 유용한 정보를 제공한다.
테스트는 소프트웨어 개발에 있어서 하나의 공정이지만, 개발기간의 단축과 적용 업무의 복잡성 증대에 따른 소프트웨어 개발의 계획 단계에서 테스트는 반드시 고려해야하는 사항이다. 테스트의 관점에서 다른 프로젝트 상위 공정에 대한 피드백은 설계자나 개발자가 테스트 결과의 정보를 활용해 제품의 품질 개선을 가능하게 한다. 통상 수정 비용은 시스템 개발이 진행됨에 따라 급격히 증가하기 때문에 설계서 리뷰와 테스트는 개발 프로세스의 상위 공정에서 철저히 실행하는 것이 공수 절감에 효과적이다.
테스트를 프로세스로 간주해 소프트웨어 개발 프로세스의 일부로서 개선하는 것은 버그 검출율을 높임과 동시에 개발 비용의 절감은 물론, (그림 2)와 같이 대응되는 개발 프로세스에 피드백을 함으로서 소프트웨어 개발 프로세스 전체의 개선 효과를 높일 수 있다.

SW-CMM에 기반한 Test-CMM
Test-CMM은 SW-CMM을 기반으로 테스트 프로세스 개선 모델를 작성한 것으로, 소프트웨어 개발 프로세스 전체를 개발과 테스트로 분리해 테스트만의 프로세스 능력 성숙도를 생각한 모델이다.
Test-CMM의 구조는 기본적으로 SW-CMM과 동일하게 레벨 1에서 5까지의 단계로 구성돼 있으며, 테스트 프로세스 능력 성숙도와 목표를 나타내고, 각 레벨 안에는 KPA(Key Process Area)가 존재한다. KPA는 소프트웨어 개발에서의 테스트 프로세스에 관한 KP(Key Practice)를 상세화하며, 내용 설명과 함께 TPI와 맵핑하고 있다.
Test-CMM의 성숙도는 레벨1에서 5까지 5단계로 나타내고 있으며 다음의 각 레벨은 대상이 되는 조직, 프로젝트는 어떤 상태인지를 설명하고 있다.

   

- 레벨 1 : 초기레벨
테스트가 혼돈 상태이고 프로젝트 성숙도가 크게 낙후돼있는 상태다. 성숙한 프로세스와 미숙한 프로세스가 존재하고 조직에 대한 아무런 규제도 없는 상태. 이 레벨에서 테스트는 프로젝트 리더와 테스트 담당자 등 개인의 노력에 의존하고 형식적인 테스트와 버그 보고만 이뤄진다.

   

- 레벨 2 : 반복 가능한 레벨
조직에서 기본적인 테스트 기법과 방법론을 제도화해, 테스트 그룹은 계획, 설계, 실시라는 테스트 라이프 사이클를 반복적으로 실행하는 레벨이다. 기본적인 프로세스는 형성돼 있지만, 아직 프로세스 간의 불일치가 존재하고 있다.

   

- 레벨 3 : 정의된 레벨
조직 표준의 테스트 프로세스가 제품의 소프트웨어 라이프 사이클에 포함돼 있는 상태. 테스트 프로세스가 조직적으로 제어, 감시돼 표준화가 진행되고 있기 때문에 프로세스 간의 불일치가 감소한 상태다. 또 테스트에서 얻은 데이터는 데이터베이스에 기록돼 있는 상태다.

   

- 레벨 4 : 관리된 레벨
조직 전체에 테스트 프로세스가 구축돼 프로세스의 데이터가 정량적, 일관적으로 수집되고 있는 상태. 테스트 품질관리는 테스트 품질계획을 기본으로 실시되고, 테스트는 정량적으로 분석, 파악되고 제어되고 있다. 프로세스 간의 불일치는 가능한 평균치에 가깝고 표준화돼 있다. 또 이 레벨에서는 평균치의 예측이 가능하다.

   

- 레벨 5 : 최적화하는 레벨
테스트 프로세스가 정상적으로 잘 운영돼, 조직이 계속적인 테스트 프로세스 개선에 집중할 수 있는 상태. 또 조직은 테스트 프로세스에서 데이터를 분석함으로 결함을 미연에 방지할 수 있는 기술을 갖고 있으며 여기서 얻어진 정보(테스트 프로세스의 변경과 신기술)는 다른 프로젝트에 피드백된다. 이같이 테스트 프로세스가 최적화돼 있어 프로젝트 간의 불일치가 없어지고 평균치의 제어가 가능하다.

   

Test-CMM은 테스트 프로세스에 한정된 개선 모델이지만, SPI(Software Process Improvement)의 관점에서 소프트웨어 개발 프로세스 전체와의 밸런스가 중요하다. 개발 프로세스가 성숙돼 있지 않으면 고품질의 소프트웨어를 개발할 수 없다. 역으로 개발 프로세스가 성숙되어 있는 경우에는 고품질의 소프트웨어가 개발됐다고 해도 그것을 보증할 환경이 준비돼 있지 않은 것이 된다.
따라서 테스트 프로세스를 개선하는 것과 동시에 개발 프로세스와 상호간 정보나 피드백을 통해 소프트웨어 개발 프로세스 전체의 균형을 잡을 수 있도록 개선해야 한다.

   

테스트 프로세스 개선을 위한 TPI
TPI는 테스트 프로세스 개선 접근 모델을 말하며, 이것은 유럽에서 IT 시스템의 테스트에 특화된 기술을 보유한 IQUIP의 경험과 지식을 통해 나온 것이다.
현재는 TPI의 사용이 급속하게 확대돼 네덜란드에서는 소프트웨어 표준으로 제정하려는 움직임이 일고 있다. 이 접근 방법은 CMMI(연속 표현은 프로세스 영역마다 능력 레벨 평가가 가능한 것)와 비슷하며, 테스트 프로세스의 다양한 KA(Key Area)에 대해 조직의 성숙도를 객관적으로 자기 평가해 강점과 약점을 나타내고 레벨을 부여해 개선에 도움을 주도록 돼 있다.
테스트 프로세스는 개발 프로세스 전체의 일부이며, (표 2)와 같이 TQM(Total Quality Management)과 SPI을 수행하는 조직에 있어서 TPI는 일부분에 속한다. TPI는 테스트 프로세스를 구조화하는 것으로 테스트에 관한 많은 문제를 해결하는 것을 목표로 하고 있다. 구조화된 테스트로부터 테스트 프로세스의 모든 시점을 포괄하는 일련의 액티비티, 순서, 기법을 나타내고 있다. TPI에서는 KA마다 레벨이 부여돼 있으며 그것을 일람표 형식으로 표현한 것이 TPI_Sheet다.

   

품질 테스트는 시대에 따라 점차 영역이 확장되면서 초기의 오류 확인에서부터 이제는 시스템의 품질을 향상시키는 과정으로 정의가 바뀌어가고 있다. 이번에는 테스트의 정의에서부터, 필요성, 역할 등을 알아보고, 테스트 조직의 관리와 이때 주의해야 할 점은 무엇인지에 대해 알아보겠다.

강종원 | 엔씨아이 대표/수석 컨설턴트

IEEE 표준은 작성해야 할 테스트 문서의 사양을 명확히 하는 점에서는 우수하지만, 테스트 문서를 작성하는 방법과 그것을 사용하기 위한 프로세스(계획, 분석, 설계, 실행 등)를 개발하는 방법은 기술하지 않고 있기 때문에 이를 보완하기 위해 등장한 것이 STEP(Systematic Test and Evaluation Process)다.
STEP 방법론은 준수해야 할 전반적인 규칙을 확립하는 것이 아니라 가이드라인만을 제시한다. 따라서 소프트웨어 엔지니어가 이 가이드라인을 사용할 때 자신들의 요구와 기대에 맞도록 수정할 수 있으며, 또한 수정하는 것이 바람직하다.
수많은 사람들이 품질 높은 소프트웨어를 개발하기 위해 독자적인 STEP 방법론과 이에 바탕을 둔 프로세스를 사용하고 있다. 그러나 STEP의 상세한 설명을 하기 전에 지금까지 어떤 방식으로 소프트웨어 테스트를 시행해 왔는지 대략적으로 파악해 보자.

1979년에 글렌포드 마이어스는 'The Art of Software Testing'이란 책에서 '테스트란 에러를 찾기 위한 프로그램 또는 시스템을 실행하는 과정'이라고 설명했다. 마이어스가 그 책을 집필했을 당시는 이같은 정의가 최선인 동시에 당시의 사고를 반영하고 있었다. 간단히 얘기하면 테스트는 에러를 발견하는 것을 주목적으로 소프트웨어 개발 사이클의 최후에 실시하는 것이었다. 
1983년부터 테스트의 정의가 변천해 단순히 에러를 발견하기 위한 프로세스가 아니라 소프트웨어 품질의 평가를 포함하게 됐다. 'The Complete Guide to Software Testing'이란 책에서 빌 헤첼은 '테스트란, 프로그램 또는 시스템의 속성을 평가하는 것을 목적으로 하는 모든 활동이다. 테스트는 소프트웨어의 품질을 측정하는 것'이라고 서술하고 있다.
마이어스나 헤첼의 정의도 현재까지 물론 유효하다. 양쪽 모두 소프트웨어 테스트의 특정 국면을 대응하고 있기 때문이다. 그러나 이같은 정의에는 범위에서 문제가 있다. 이를 해결하기 위해서는 '테스트란 대상으로 하는 소프트웨어의 품질을 측정해 개선하기 위한 테스트웨어를 엔지니어링하고, 사용해 보수하면서 동시 병렬적으로 진행하는 라이프사이클 프로세스'라고 테스트의 정의를 새롭게 내릴 필요가 있다.
이 정의에서는 결함을 발견하는 것에는 직접적으로 관여하지 않는 것에 주목하기 바란다. 그러나 결함을 발견해 내는 것은 엄연히 테스트의 중요한 목적중 하나다. 또 이 정의에는 소프트웨어의 품질을 측정하는 것뿐만 아니라 개선하는 것도 포함돼 있는 점을 주의하기 바란다. 이것을 예방 테스트라고 한다.

   

테스트의 정의
테스트는 개발 작업을 효과적으로 평가할 수 있도록 필요한 정보를 모으는 작업도 포함될 수 있으며, 소프트웨어 품질 특성을 객관적으로 평가하고 측정하는 작업도 테스트 작업으로 봐야 한다. 또한, 다음과 같이 테스트는 개발과정 전체에 걸쳐 일어나는 광범위한 작업이라는 점을 명심해야 한다.

   

- 프로그램을 명세와 비교해 확인하는 작업
- 프로그램의 버그를 찾는 작업
- 사용자가 인수할 수 있는지 결정하는 작업
- 시스템이 사용할 준비가 돼 있는지 확인하는 작업
- 시스템이 작동한다는 확신을 얻는 작업
- 프로그램이 정확히 작동한다는 것을 보이는 작업
- 오류가 없음을 보이는 작업
- 성능의 한계를 이해하는 작업
- 시스템이 무엇을 할 수 없는지 알게 되는 작업
- 시스템의 능력을 평가하는 작업
- 문서를 검증하는 작업
- 작업이 완료됐다는 것을 스스로 확인하는 작업 등

   

즉, 개발 과정에서 수행되는 워크스루, 인스펙션, 각종 리뷰 작업도 테스트 작업이라 할 수 있다. 이런 작업의 목표는 쉽고 효과적인 방법으로 소프트웨어에 대한 품질 정보를 수집하는 것이다.

   

테스트 계획의 필요성
이상적인 테스트 계획을 모르면 그 타당성의 판단이 어렵다. 테스트 계획서의 문서 형식을 규정하는 규격은 있지만 테스트 계획의 좋고 나쁨의 판단 기준에 대한 해설은 없다.
여기서는 테스트 계획의 기준적인 개념과 임해야 할 역할, 만족할 만한 조건을 나타내고, 특히 각각의 기능이 기준을 만족시키고 있는지를 판단할 때에 도움이 되는 사고를 설명한다.
다음은 테스트 과정에서의 중요한 용어와 개념들이다.

   

- 테스트 계획 : 테스트 계획은 테스트에 대한 사고를 표현한 것으로 테스트 프로세스를 설명하고 실 작업의 방침이 된다.
- 테스트 계획서 : 테스트 계획의 컨셉을 전하기 위한 것을 목적으로 하는 다양한 문서
- 테스트 전략 : 테스트 전략은 테스트의 임무를 말하며, 테스트 전략은 무엇을 어떻게 테스트할 것인지 명확히 한다.
- 테스트의 순서 : 테스트 전략을 실천해 결과를 전하는 수단으로 누가, 언제, 어디서 테스트를 하는지, 필요한 자원의 조달은 어떻게 하는지 등의 상세한 사항이 포함된다.
- 테스트 프로세스 : 많은 의미를 갖는 용어지만 본 내용에서는 실제로 테스트를 어떻게 전개할 것인지를 의미하는 용어로 사용된다.

   

테스트 계획의 역할
테스트 계획의 역할은 계획대로 작업이 수행되도록 하는 것이다. 테스트 계획서에 서술되는 것은 테스트 전체 내용의 일부에 지나지 않으며, 나머지 부분은 다른 문서에 서술되거나 특별한 문서없이 테스트 관리자나 담당자의 판단으로 실시되기도 한다.
테스트의 계획은 품질평가에서 개발자가 적시적소에 제품에 관한 결단이 가능하도록 지원해야 하며, 테스트 전략의 타당성을 제품의 요구 사양과 리스크를 관련시켜 이점과 한계를 인식해야 한다. 또한, 테스트 프로젝트를 실행하기 위한 조직과 체계 정비를 지원하며, 구체적으로는 준비작업, 인원의 배치, 권한 위임, 테스트 환경과 테스트 계획, 스케줄 관련 내용을 포함해야 한다.
이외에도 테스트 프로젝트의 성과물과 제공방법을 규정해야 하며, 프로세스 감사와 프로세스 개선, 차기 테스트 프로젝트를 위한 이력 정보를 기록해야 한다.

   

테스트 조직 관리
테스트 팀의 역할은 나쁜 뉴스를 발견해서 보고하는 것이다. 그것을 듣고 프로젝트의 중지를 경영진이 결단하는 경우도 있고 스케줄을 조정해 출하를 늦추는 경우도 있다. 프로젝트가 지연되면 작업이 늘어날 뿐 아니라 벤처 기업의 경우는 도산할 수도 있다.
따라서 테스트 관리는 스트레스가 많이 쌓이는 작업이며, 거의 칭찬받는 경우가 없다. 회사가 특별히 테스트 팀을 설치하는 주된 이유는 품질을 개선하는 비용을 삭감하는 효과가 있기 때문이다.
테스트 팀이 좋은 역할을 하기 위한 필요한 것을 열거해 보자.

   

- 능력 : 테스트 담당은 테스트 기술에 정통하지 않으면 안된다. 그리고, 건설적인 의견을 교환할 필요도 있으며, 테스트에 대한 프로 의식을 갖고 있어야 한다. 

- 테스트 기간 : 테스트 담당자는 테스트를 위해 배치해야 하며, 테스트를 완료하기 위해 확보하는 것이지 프로그래밍과 문서 작업을 위한 것이 아니라는 점을 명심해야 한다. 이것은 프로그래머가 개발 시 테스트하는 것과는 전혀 다른 것이다.
- 독립성 : 테스트 결과는 프로젝트 매니저가 아니고 테스트 팀의 매니저에게 보고해야 하며, 중요한 장해를 놓치거나 숨길 경우에는 엄하게 질책할 필요가 있다.

   

테스트 관리는 인내를 필요로 하며 이동이 많은 역할이기도 하다. 그 이유는 스트레스가 많기 때문에 다른 업무로 옮기려고 하기 때문이다. 또 하나는 자신의 문제이다. 인간관계의 파탄을 초래하거나, 제품을 형편없이 만들거나, 같이 일해온 사람의 생활을 어렵게 만들 수도 있다.
하지만 원만한 인간관계를 유지하면서 직권의 남용도, 직원을 혹사시키지도 않으며, 품질의 개선에 크게 공헌하는 훌륭한 테스트 팀의 관리가 결코 불가능한 것이 아니다.  이를 위해서는 성실하며 프로의식, 윤리관, 인격을 손상하지 않도록 테스트 팀을 관리하지 않으면 안된다.
테스트 팀은 4종류가 있으며 각 조직의 방침에 기초해 서로 다른 권한을 부여하고 있다.

   

- 품질 관리(QC : Quality Control) 형태：표준과 규칙을 준수 시킨다.
- 품질 보증 (QA : Quality Assurance) 형태：품질을 어떠한 방법으로 보증한다.
- 테스트 기술 형태：프로젝트 매니저(회사)에게 버그의 발견과 보고라는 특수 기능을 제공한다.
- 개발 기술 형태：프로젝트 매니저에게 테스트를 하려고 하는 각양각색의 기술 서비스를 제공한다.

   

품질 관리 형태의 그룹
QC 형태의 그룹은 커다란 권한을 갖고 있다. 표준대로 작업이 수행돼 지적한 장해가 수정될 때까지 제품의 출하를 거부할 수도 있다. 테스트 기능 형태와 개발 기능 형태의 그룹은 부러워할 수도 있지만, 실제로 이런 권한을 갖기 위해서는 큰 보상이 따른다.
소프트웨어의 QC 그룹은 공장의 긴 생산 라인에서 토마토 통조림을 몇개 추출해 검사를 하는 것이 아니다. 회사에 단 1라인 밖에 없는 생산라인을 수 일에서 수 주간, 때로는 수 개월 정지시키기 때문에 경영진은 QC 그룹의 출하 정지에 곧바로 따를 필요성이 있는지, 또는 프로젝트 매니저의 요청을 받아들여 출하를 지시할 때도 있다.
어찌보면 진정한 의미의 품질 관리 그룹은 경영진이라고 할 수도 있다. 테스트 팀의 역할은 경영진의 판단을 돕는 데 있다. 테스트 팀은 남아 있는 불량의 심각함을 보고하고, 출하의 가부 결정은 경영진이 판단 하는 것이다. 따라서 QC 그룹이 갖고 있는 실질적 권한은 경영진이 숙고해 판단할 때까지 출하를 정지해 두는 권한이다. 그러나 QC 그룹에 의한 출하정지의 판단을 경영진이 뒤집어 버리면 QC 그룹의 입장이 난처해질 수 있다.
또 QC 그룹이 강한 권한을 갖는 것처럼 보이기 때문에 개발 측은 공포와 불신감을 갖게 될 수도 있다. 결과적으로 프로젝트 매니저는 QC 그룹에게 적절한 압력을 행사하게 된다. 그러나 적절함은 잘 정의돼 있는 것이 아니다. 예를 들어, 다음과 같은 경우는 테스트가 적절하다고 할 수 없다.

   

- 테스트의 각 사이클에서 새로운 테스트 케이스를 추가하는 것
- 실제에는 결코 입력되는 않는 극단적인 값으로 테스트하는 것
- 일부러 이상한 데이터를 읽어 들이는 것
- 현장에서 바로 테스트 케이스를 작성하는 것
- 특수한 경우에만 발생하는 조그만 버그를 보고하거나 설계의 잘못을 지적하는 것
- 장해 리포트에 개선 요망 사항을 기록하는 것
- 장해 리포트에 설계서의 잘못을 기록하는 것
- 사전에 명시돼 있는 테스트에 합격되지 않았다고 테스트를 거부하는 것
- 해결하는데 시간이 걸린다고, 단 1개의 불량 때문에 테스트를 거부하는 것

   

프로젝트 매니저 중에는 제품과 자신이 불리하게 될 경우 모든 것을 부적절하다고 판단하는 사람도 있다. 그래서 QC 부문의 책임자가 부적절하다고 판단하는 것 자체가 부적절하다고 거절하는 경우도 있다. QC라는 직책을 수행하고 있는 동안은 테스트 과정과 결과가 적절한지에 대해 장시간 의논해야 한다는 것을 각오해야 한다.
필자의 경험으로는 QC 그룹은 미움을 받고 잠재적으로 적대관계에 있다고 인식된다. 또한 평가는 낮고 품질에 대해 별다른 공헌을 하지 못한다고 생각되고 있다. 또, QC 그룹이 갖고있는 권한은 매우 한정돼 있으며, 간단히 뒤집힐 수도 있다는 것을 명심해야 한다.

   

품질 보증 형태의 그룹
QA 형태의 그룹은 품질 보증을 위한 그룹이다. 그러나 테스트만으로 품질을 보증하는 것은 불가능하다. 품질이 안좋은 프로그램을 철저하게 테스트해 버그를 수정해도 '충분히 테스트한 품질 나쁜 프로그램'에 지나지 않는다.
사실은 QA 그룹은 전 개발공정에 관여할 필요가 있다. 표준을 책정해, 리뷰 방법을 생각하고 설계나 개발을 개선하는 방법을 지적한다. 즉 QA 그룹의 성과는 불량의 예방에 있다. 물론 테스트도 하지만 그것은 업무의 일부분 일뿐이다.
실제로 QA 그룹은 엄청난 기술을 갖고 있지 않으면 안된다. 다시 말해 분석, 설계, 실행, 프로젝트 관리, 문서 작성 등 모든 일에 유능할 필요가 있다. 그렇지 않으면 신뢰 받기 어렵기 때문이다.
'품질 보증'이라고 부르는 방법은 매우 위험하다. 만약 어떤 그룹이 품질을 보증하면 다른 부문은 보증하지 않아도 괜찮은 것인지 생각할 필요가 있다. 이같은 문제는 1989년 조셉 주란으로부터 제기된 것으로, 독립된 QA 그룹을 배치한다는 생각은 제 2차 세계대전 이전에 생겨났으나 안타깝게도 제대로 기능을 하지 못했다.
적어도 소프트웨어 개발조직에서 작업을 한 경험이 있다면 프로젝트 매니저가 "나의 일은 납기까지 제품을 완성시키는 것이지 품질을 확보하는 것은 내가 할 업무가 아니라 QA가 할 일"이라는 불만을 들은 적이 있을 것이다.
회사 전체, 특히 경영진이 품질에 책임을 갖지 않으면 안 된다. 이것은 일본과의 경쟁에 의해서 얻은 교훈으로(W. E. Deming, 1982), TQM(Total Quality Management)의 기초가 되는 생각이다.

   

테스트 기술 형태의 그룹
프로젝트 매니저에게 테스트 기능을 제공하는 것이 테스트 기술 형태의 그룹이다.
주어진 역할은 프로그램 버그를 발견하고 상세하게 설명해, 알려야 할 사람에게 확실하게 정보를 제공하는 것이다.
테스트 기술 그룹에는 제품을 출하하는 권한도 출하를 정지하는 권한도 없다. 프로그램의 불량과 테스트 실시의 상황 등을 보고하면 경영진이 최종판단을 내리게 된다.
그룹에 따라서는 제품의 일부만을 테스트 하는 경우도 있다. 특히 각 사이클의 테스트에서 전부를 테스트하는 경우는 없다. 또 회사의 방침으로 프로그래머가 테스트를 주로 담당하고 테스트 그룹은 보조 작업만을 하는 경우도 있을 수 있다.
테스트 기술 그룹의 작업은 상세한 기능 일람의 작성과 순서를 기술하는 것으로 필요하다면 테스트의 자동화를 수행한다. 테스트의 분석, 설계, 설치, 실시, 기록의 모든 책임을 지는 역할이다.
프로젝트 매니저 중에는 테스트 기술의 제공보다는 품질 관리의 책임을 테스트 기술 그룹에 희망하는 사람도 있다. 무리하게 QC 형태로 운영하려고 하기도 한다. 또한 테스트의 책임은 전부 테스트 팀에 있으며, 프로그래머는 화이트 박스 테스트조차 필요 없다고 선언하는 경우도 있다. 테스트 팀이 발견하지 못한 버그는 수정하지 않아도 좋다고 말하며 버그를 발견 못한 것을 비난하기도 한다.
이런 태도는 품질에 대한 책임을 포기하려 한다고 이해할 필요가 있다. 품질을 강요하는 듯한 책략을 사용할 때에는 강하게 저항 해야 한다. 다른 부문과 대립하는 상황이 되기 쉬우니 상사에게 업무의 조율을 부탁하도록 한다.
'프로젝트 매니저야 말로 진정한 품질보증의 리더다. 테스트 기술그룹은 기술적인 정보를 제공하고 설명하는 것으로 품질에 관한 판단을 돕는데 있다'는 정의는 테스트 기술 그룹의 책임을 회피하는 것이 아니라 테스트의 실시와 문서의 작성 테스트 결과의 해석에 관해서 질 높은 작업을 신속하게 제공할 책임이 있기 때문이다.
테스트 기술 그룹은 프로젝트 매니저와 의논하거나 경영진에 정보를 제공하는 권한이 있으며, 이같은 권한을 잘 살리기 위해서는 데이터의 수집 능력과 표현 능력의 향상이 필요하다. 생산라인의 정지나 새로운 순서의 제시보다도 데이터를 기초로 정확한 표현으로 설득하는 편이 성과가 크다.

   

개발 기술 형태의 그룹
개발 기술 형태의 테스트 팀은 테스트 기술 형태를 확장한 것으로 기술을 제공하지만 관리나 판단은 하지 않는다. 정치적인 교섭도 하지 않는다. 테스트의 전문기술에 더해 품질의 개선, 개발 지원, 개발자가 전문성을 배양할 수 있도록 품질 향상 기술의 제공이 개발 기술 그룹의 역할이다.
개발기술 그룹에 있어서 테스트는 주 업무이고 어떠한 조직에 있어서도 요구되는 것이다.

   

- 디버그
- 고객에 대한 기술지원
- 매뉴얼 교정
- 매뉴얼의 기술적인 평가(보통 테스트 담당자보다 훨씬 강한 권한으로 기술적 검증을 수행한다)
- 조작성 테스트
- 호환성 테스트
- 고객 만족도 조사

   

담당자에 따라 기술과 취향에 차이가 있어, 이같은 작업이 경력의 발전에 도움이 되는 경우가 있는가 하면 지겨워 죽을 정도로 하기 싫어하는 작업으로 느끼는 경우도 있다. 테스트 이외의 일을 포함해 어떤 작업을 하고싶은지 질문해 도움이 될 수 있도록 하자.
필자는 QC와 QA라고 하는 종래의 개념을 초월한 4가지 형태의 그룹 테스트 팀 개념을 추천한다. 특히 개발 기술 형태의 그룹의 발상은 마음에 들지만 충분히 시험한 것이 아니며 적용 시에는 주의가 필요하다. 테스트 기술 형태의 그룹은 잘 운영 되지만, 부하 직원의 경력에 주의하지 않으면 전직을 할 수도 있다는 것을 명심하자.
테스트 팀이 없는 개발 부문에서는 코드가 정확하게 동작하는 것을 자신이 보증하지 않으면 안된다. 그러나 테스트 팀이 있으면 긴장이 풀려 버그를 놓칠 수도 있다.
개발자 자신이 테스트해서 정상인지 아닌지 신경 써 주기를 테스트 팀에서는 바라고 있다. 이같은 방법이 보다 확실하게 버그를 발견할 수 있고 비용을 낮출 수 있기 때문이다. 또한 버그의 대부분은 프로그래머가 먼저 발견하기 때문이다. 바로 프로그래머가 누구보다도 코드를 잘 이해하고 있고 버그가 있을만한 곳을 잘 알고 있다. 테스트 팀은 프로그래머가 놓친 버그를 발견하지만 프로그래머도 물론 테스트에서는 놓친 버그를 발견할 수 있다.
프로그래머는 비교적 낮은 비용으로 버그를 발견한다. 문제의 발견이 빠르면 빠를수록 발견과 수정에 드는 비용이 감소한다. 그 이유를 열거해 보면 다음과 같다.

   

- 문제를 파악하기 위해 몇 번이고 테스트를 반복해 재현할 필요가 없다. 버그가 있을만한 부분을 직접 조사할 수 있으며, 더구나 발견되면 즉시 수정할 수 있다.
- 타인에게 불량을 설명할 필요가 없다.
- 설계서를 확인하거나 장애 보고를 하거나, 수정 사항을 보고할 필요가 없다. 보고서를 작성할 시간에 버그를 수정하는데 힘을 쏟을 수 있다.

   

애석하게도 프로그래머에 의한 테스트는 점점 줄어드는 추세다. 개발측의 매니저는 테스트에 시간이 걸리는 것을 인식하고 있기 때문에 프로그래머에게 테스트를 생략하도록 지시해 개발을 빨리 완료시키려한다. 자주 일어나는 일이지만 심한 경우는 프로그래머가 테스트를 거의 하지않아 테스트 작업 시 패닉 상태에 빠지기도 한다.
테스트 팀을 조직할 때는 마음속으로 준비해 둬야 할 사항이 있다. 종래의 사내 표준에 따라 테스트 한다고 해도 대단한 작업이기 때문에 테스트 팀은 자신을 포함해 최저 4명 이상으로 구성할 필요가 있다는 것이다. 월간 온더넷 2006년 11월호

이번에는 지난달에 이어 실제 테스트에 들어가기 위해 준비해야 될 과정과 어떤 테스트를 어떻게 수행해야 하는지, 또한 시스템 구축 과정에서 각종 장애 요소에 대한 장애 리포트 작성 방법 등 테스트 공정의 전 과정에 대해 알아보자.

강종원 | 엔씨아이 대표/수석 컨설턴트

지난 호에서는 테스트의 정의에서부터, 필요성, 역할 등을 알아보고, 테스트 조직의 관리와 이때 주의해야 할 점은 무엇인지에 대해 알아봤다. 이번에는 실제 테스트를 수행함에 있어 테스트 전략의 수립에서부터 테스트 계획서 작성, 테스트 요건 정의, 테스트 케이스 설계, 테스트 실행, 결함 리포트 작성 등 테스트의 전 과정에 대해 알아본다.

   

테스트 전략
테스트 종류에는 단위 테스트(Unit Test), 통합 테스트(Integration Test), 시스템 테스트(System Test), 리그레션 테스트(Regression test) 등이 있다. 단위 테스트는 모듈이 구현된 후에 개별적인 모듈에 대해 수행하는 테스트로 단위 테스트를 위해서는 상세 설계 정보를 이용한다. 단위 테스트는 기본적으로 각 모듈이 올바른 기능을 수행하는지 판별한다.
통합 테스트는 모듈간의 인터페이스를 테스트하는 것을 주목적으로 하며, 소프트웨어 시스템을 통합하는 전략과 밀접한 관계가 있다. 모듈간의 의존관계를 보여주는 구조 설계 문서가 통합 테스트에 필요하다.
시스템 테스트는 모듈을 통합해 완전한 시스템이 구성될 때 개발자에 의해 수행되는 테스트다. 개발된 시스템이 사용자의 요구사항에 맞게 구현됐는지 시스템 전체에 대해 검사한다.
리그레션 테스트는 오류를 제거하거나 수정한 프로그램이 예상대도 됐는지 여부와, 오류 제거와 수정에 의해 의도하지 않았던 새로운 오류가 발생하지 않고 명시한 요구사항을 충족시키는지 등을 확인하는 일종의 반복 시험을 뜻한다.
유지보수 단계에서 소프트웨어가 수정된 후에도 변경이 올바르게 됐는지 검사하기 위한 테스트를 수행해야 한다. 유지보수 단계에서는 (그림 1)과 같은 이유로 소프트웨어에 수정이 가해진다.

   

테스트 계획서 작성
테스트 계획을 평가하는 데는 기능의 실현방법과 품질의 평가방법에 관해 고려할 필요가 있다. 효과적인 경험치가 지표화돼 표에 기재된 경험치는 항상 동일하게 중요한 것은 아니다. 상황에 의해 적용할 수 없는 것도 있지만 일반적인 해설과 간단한 근거를 나타내고 있다. 근거 항목에는 적용을 판단할 때에 도움이 되는 정보를 서술한다. 이같은 근거 항목에는 ▲테스트 계획 ID ▲서문 ▲테스트 항목 ▲테스트 대상 기능 ▲테스트 대상 외의 기능 ▲테스트 방법 ▲합격/불합격 기준 ▲테스트 시작 조건과 중단 기준, 재개 요건 ▲성과물 ▲테스트 작업 ▲환경 ▲책임자 ▲인원 및 교육 ▲스케줄 ▲리스크 ▲승인 등이 있다.

   

테스트 요건 정의
테스트의 요건 정의는 무엇을 테스트하고 테스트의 우선순서를 어떻게 설정하고, 어느정도 수준까지 깊게 테스트할 것인지 결정하는 것이다. 리스크 분석을 실시하면 가능한 철저하게 테스트해야 할 리스크가 높은 애플리케이션과 발생하기 쉬운 경향이 있는 컴포넌트 등 테스트 담당자가 명확하게 파악하는데 많은 도움을 준다. 이상적으로는 조직 내의 각 그룹에서 선출한 전문가 팀이 리스크 분석을 실시해야 한다. 또한 개발 라이프사이클에서 가능한 빠른 단계에서 실시해야 한다(요건이 명확화된 시점).
테스트 요건 정의 과정은 다음과 같다.

   

① 브레인스토밍 팀 결성
그룹의 멤버로부터 도출할 수 있는 리스크 아이디어 수를 증가시킨다.

   

② 기능 일람표 작성
해당 시스템의 모든 기능과 속성, 업무처리의 일람을 작성한다.

   

③ 가능성 판단
현재 지식을 기반으로 어떤 기능 또는 속성이 장애를 일으킬지 또는 비정상적으로 작동될지 가능성은 어느 정도인지 지표를 할당한다.

   

④ 영향 판단
어떤 기능 또는 속성의 장애 발생시 사용자에게 어떤 영향을 주게 되는지 지표로 할당한다. 가능성 지표와 동일하게 H, M, L로 표현한다.

   

⑤ 수치 할당
가능성과 영향 양방향의 지표 H, M, L에 수치를 할당한다.

   

⑥ 리스크도 산출
장해 가능성에 할당한 수치와 장해 영향도의 수치를 합산해 각 기능별 리스크 정도를 파악한다.

   

⑦ 수치 리뷰와 수정
각 기능 또는 속성의 장해 가능성에 관해 팀 리뷰를 통해 합의를 끌어내고, 신규 추가 분석에 근거해 수치를 수정한다.

   

⑧ 기능 우선순위 부여
브레인스토밍 팀은 기능과 속성 리스트를 리스크도 순으로 재편성한다.

   

⑨ 대상 외 설정
리스크도를 소트한 후 '대상 외 선'을 설정한다. 이 선 이하의 기능은 테스트 대상 외로 한다.

   

⑩ 경감책 검토
테스트 또는 개발 담당자는 리스크 저하 또는 경감시킬 수 있는 방법을 검토한다.

   

⑪ 계획 리스크와 대응책
리스크 관리의 반대 측면으로 테스트 계획에서 리스크가 발생했을 경우를 대비해 최선의 대응책을 결정해 둔다.

   

테스트 케이스 설계
시간이 무한하다면 1억 개, 혹은 1조 개의 테스트를 수행하면 좋을 것이다. 하지만 실제 현장에서는 수백에서 많으면 수천 개의 테스트를 할 시간밖에 주어지지 않는다. 따라서 무엇을 테스트할 것인지 신중하게 도출하지 않으면 안된다.
테스트의 목적은 버그를 발견하는 것이다. 테스트 케이스 설계를 착안할 경우에는 역방향으로 생각하는 것이 좋다. 다시 말해 버그를 어떻게 발생시킬 것인가를 생각하는 것이다. 다음과 같이 해당 항목을 생각하며 설계해야 한다.

   

- 버그 검출 가능성이 높은 것
- 중복되지 않은 것
- 최선의 선택인 것
- 지나치게 단순하지 않고 복잡하지 않은 것
- 검출 방법이 명시돼 있을 것

   

이같은 테스트 케이스의 설계 시 동치 클래스와 경계 조건을 이해하는 것은 불가결하다. 입력에 대한 프로그램의 응답과 출력을 확인하기 위해서는 경계 조건 테스트는 필수다. 경계 조건을 충분히 이해하면 다른 테스트 방식에도 효과적으로 적용할 수 있는 프로그램 분석법을 습득할 수 있다.

   

동치 클래스
2개의 테스트를 실행해서 같은 결과를 기대할 때, 2개의 테스트는 동치라고 한다. 같은 그룹의 테스트가 다음 조건을 만족하면 동치 클래스를 형성한다.

   

- 같은 기능을 테스트 한다.
- 하나의 테스트에서 장애가 발견되면 나머지 테스트에서도 발견된다고 예상된다.
- 하나의 테스트에서 장애가 발견되지 않으면, 나머지 테스트에서도 발견되지 않는다고 예상된다.

   

각각 다른 사람의 동치 클래스 리스트를 통합하면 비슷한 테스트를 반복하는 비능률을 제거할 수 있다. 동치 클래스는 많은 테스트 케이스가 필요하지 않다.
부정 입력 치에 따른 장애는 매우 많다. 부정치 입력 또는 예기치 않은 입력에 대한 프로그램의 응답을 철저하게 테스트하는 프로그래머는 많지 않기 때문에, 테스트를 하면 할수록 많은 버그를 발견할 수 있다. 다음 내용을 참조해 동치 클래스를 추출해야 한다.

   

- 수치 입력에 따른 무효 동치 클래스를 잊지 말 것
- 동치 클래스는 굉장히 많은 입출력 조건과 관계하기 때문에 정리해 둘 것
- 범위로 취급되는 데이터를 정리할 것
- 그룹의 요소를 정리할 것
- 선택할 데이터를 찾을 것
- 항상 같다고 할 수 없는 변수를 찾을 것
- 시간적인 동치 클래스를 열거할 것
- 조합해서 계산하는 데이터를 열거할  것
- 출력 이벤트에 착안할 것
- 동작 환경에 착안할 것
- 동치 클래스의 경계조건을 이용하여 테스트를 설계할 것
- 프로그램의 상태에 따라 정보가 전이되는지 확인할 것

   

테스트 실행
질 높은 테스트 케이스를 설계해도 적절하게 실행하지 않으면 전혀 의미가 없다.
구체적으로는 입력한 데이터에 대한 처리를 전부 실행해 정확한 결과를 얻을 수 있는지 확인할 수 있는 테스트 순서를 항상 작성해야하며 표준을 따라야만 한다.

   

부하 테스트(기능 관련)
문서에 기재돼 있는 모든 한계에서의 테스트는 절대적으로 필요하다. 파일의 크기를 최대한으로 크게 만들거나 프린터를 상한까지 증설, 단말기나 모뎀의 수, 메모리 크기 등을 한계치로 해서 테스트해야 한다. 한계까지 많은 파일을 열고, 모두 정확하게 동작하고 있는지, 지나치게 늦어지지는 않는지 등을 확인할 필요가 있다.

   

직감을 믿는다.
논리적으로 설명할 수 없지만 어떤 종류의 테스트를 하면 프로세스 충돌이 발생할 것이라는 예감이 들 때가 있다. 이같은 경우에는 자신을 믿고 테스트해 보자. 경계값 이외라도 잘못 처리되는 경우가 있을 것이다. 직감에 이유를 달거나 해서는 안 되며 아무튼 테스트해 결과를 보자. 복잡한 상황에서는 직감을 이용해 이전에 비슷한 상황에서 버그를 발견했다는 경험을 떠올릴 때가 많다. 상황이 비슷하다는 것이 생각나지 않을 때와 이전의 상황을 기억조차 하지 못할 때는 직감을 이용해야 한다. 이것이 프로의 자질이다. 본능을 믿어보는 것이다.

   

함수 등가 테스트
함수 등가 테스트란 2개의 프로그램이 같은 처리를 수행하는지 테스트하는 것이다. 동치 클래스와는 특별히 관계가 없다. 같은 처리를 시켜 항상 동일 결과를 얻을 수 있으면 공식 또는 함수의 처리가 등가라고 결론을 내리는 테스트다.

   

회기 테스트
장애 리포트를 작성할 때는 불량을 발견한 순서를 프로그래머에 정확하게 전달할 필요가 있다. 프로그래머도 각양각색이기 때문에 소스코드를 엄밀히 조사해 수정 테스트하는 사람이 있는가 하면 단순하게 보고된 현상만을 표면적으로 확인하는 사람이 있다. 그 외에 보고서의 내용을 오해해 장애가 아닌 곳을 수정해 버리는 프로그래머, 어둠 속에서 헤매며 소스코드를 수정해 수정한 곳에서 또 다른 버그를 작성하는 어리석은 프로그래머로부터 프로그램을 보호하기 위한 만전을 기해야 할 필요도 있다.
수정했음에도 불구하고 1/3은 새로운 버그를 만들고 완벽히 수정하지 못했다는 이야기를 자주 듣는다. 마틴 맥클러에 의하면 프로그래머가 수정 후 처음 테스트할 때 절반 정도만 정상 동작한다고 한다. 수정이 잘됐는지 확인하는 테스트를 회기 테스트라고 한다.
이런 회기 테스트의 목적은 테스트가 끝난 프로그램에서 새로운 장해를 검출할 수 있는 가능성을 희생시키지 않고 테스트에 필요한 공수를 줄이기 위해서이다. 이를 위해서는 다음과 같은 해당 관련 항목을 확인해야 한다.

   

- 중복된 테스트는 생략한다.
- 수정된 테스트를 제거한다.
- 테스트 케이스를 잘 조합한다.
- 가능한 테스트를 자동화한다.
- 선택해 테스트 한다.

   

결함 리포트 작성
결함 리포트가 이해하기 어려우면 버그를 수정하기 어렵다. 가능한 빨리 작성하고 수정할 수 있도록 최대한의 노력으로 리포트를 작성하지 않으면 안 된다. 결함 리포트의 내용과 표현으로 수정할 것인지 아닌지 결정된다.
질 높은 결함 리포트 작성을 위해서는 결함의 재현 절차를 명확히 해야 할 뿐 아니라 결함을 분석해 재현 절차를 최소화해야 한다. 또한 누락없이, 알기 쉽고, 모순이 없도록 작성해야 한다.
또한 재현성이 높은 결함의 분석을 위해서는 가장 치명적인 현상을 명확히 하고, 가장 간단하고 제약이 없는 조건을 명확히 할 뿐 아니라 동일한 결함을 발생시키는 다른 절차를 찾아내야 한다. 이외에도 관련된 결함을 찾는 과정을 거쳐야 한다.

   

성능 테스트는 기능 테스트와 함께 서비스 개시 전에 반드시 거쳐야 하는 과정이다. 이를 통해 예상치 못한 성능 저하나 오류를 미연에 방지해 비용 절감과 기업의 신뢰도를 쌓을 수 있는 중요한 요소다. 이번에는 성능 테스트가 왜 필요한 지와 함께 성능 테스트의 기준과 평가 요소는 무엇인지 알아보자.

강종원 | 엔씨아이 대표/수석 컨설턴트

지난 수십 년 동안 IT는 비즈니스 업무에 필요한 기능 구현을 목표로 발전돼 왔다. 기능 테스트를 만족하면 성능에 대한 보장없이 프로젝트의 완성으로 간주하고 서비스를 개시하는 것이 일반적이었다.
그러나 사전 성능 테스트 없이 서비스를 시작함으로 인해, 예상치 못한 성능 저하 문제나 심각한 시스템 오류 현상에 직면하곤 한다. 이는 추가적인 비용의 발생뿐 아니라 고객으로부터 기업에 대한 신뢰도를 저버리게 하는 엄청난 결과를 초래하게 된다.

   

   

인터넷이 발전하면서 최근, 기업들의 IT 인프라는 점차 고객지향형으로 변화하고 있다. 이로 인해 운영 서비스의 품질 저하는 내부 사용자의 업무 효율을 저하나 외부 고객의 불쾌감을 유도하게 된다.
따라서 과거와는 달리, 운영되는 서비스의 성능을 관리하는 임무는 기업 활동에 있어서 절대적인 위치를 차지하고 있다. 이것은 '시스템의 성능'을 '비즈니스의 성능' 또는 '비즈니스의 경쟁력'으로 간주하고 있기 때문이다.
'시스템의 성능'을 높이는 일은 '서비스의 질'을 높이는 것을 말하며 고객이 체험하는 질을 향상시키는 것을 의미한다. 이런 효과를 얻기 위해서는 운영되는 시스템의 병목 현상을 해결해 자원의 활용도를 높이고, 미래에 발생할 수 있는 문제점을 파악하여 미연에 방지하는 작업 즉, 성능 테스트, 진단, 튜닝의 필요성이 높아지고 있다. 이런 행위가 사전에 이뤄진 뒤에 서비스가 개시돼야 제대로 된 서비스가 가능해진다.

   

   

성능 측정의 기준과 평가요소
운영 시스템의 성능을 향상시키기 위해서는 성능 수치의 측정이 가능해야 하고 평가요소 또한 존재해야 한다. 그렇다면 성능을 평가하는 요소는 무엇인지 알아보자.
자장면을 만드는 중국집을 예로 들어보자. 전국에서 효율성(성능)이 가장 좋은 중국집을 선정하기 위해 최종 2곳이 선정됐다. 둘 중 성능이 좋은 업체를 뽑기 위해 어떤 기준을 적용해야 하는가.

   

기준 1. 배달 시간이 빠르다.
  - A 중국집은 평균 50초 이내에 자장면 배달
  - B 중국집은 평균 100초 이내에 자장면 배달

기준 2. 적은 재료로 음식을 만든다.
  - A 중국집은 자장면 1그릇 만드는데 4명이 밀가루 100g 사용
  - B 중국집은 자장면 1그릇 만드는데 2명이 밀가루 50g 사용

기준 3. 동시에 많은 손님에게 서비스를 제공한다.
  - A 중국집은 1초에 최대 10명의 손님에게 음식 서비스 제공
  - B 중국집은 1초에 최대 5명의 손님에게 음식 서비스 제공

   

여기에 소개된 3가지 기준은 모두 가장 좋은 중국집을 선정하는 판단 근거로 사용할 수 있다. 그러나 만일 한가지 기준만 선택해야 한다면, 평가자의 관점에 따라 다양한 의견을 선택할 수 있을 것이다.
성능 측정의 평가 요소를 무엇으로 해야 하는지 생각해보기 위해 중국집의 사례를 들어봤다. 하지만여러 선택 기준 중 명확하게 한가지를 선택하기 어렵다는 것을 이해했을 것이다. 이제 앞에서 소개했던 3가지 기준을 운영 시스템에 적용해보자.

   

- 배달 시간이 빠르다 : 응답시간(Response Time)
- 적은 재료로 음식을 만든다 : 자원 사용률( Resource Usage)
- 동시에 많은 손님에게 서비스를 제공한다 : 일 처리량(Throughput)

   

중국집 사례에서 언급한 기준들은 운영 시스템의 측면에서 바라보면 '응답시간', '자원 사용률', '처리율'로 대체될 수 있다. 일반적으로 운영 시스템은 이 3가지를 성능 측정의 기본 요소로 사용한다.

   

   

(그림 2)는 사용자의 증가에 따라 변화되는 3가지 성능요소의 수치를 보여주고 있다. 시스템의 자원 사용량은 증가하다가 어느 시점에 증가를 멈추게 된다. 자원의 양은 한정돼 있기 때문에 당연한 현상이라고 볼 수 있다. 응답 시간의 경우는 사용자가 늘어남에 따라 시간이 점점 늦어지는 것이 일반적이다.
사용자가 늘어난다는 것은 그만큼 시스템이 처리해야하는 일의 양이 많아지는 것이므로 처리 시간은 점점 늦어지게 된다.
처리율은 컴퓨터 시스템의 처리 능력을 나타내는 개념으로, 단위 시간당 처리할 수 있는 업무 단위 양을 말한다. 시스템의 처리 능력을 초과하기 전까지는 사용자의 증가에 따라 처리율은 증가한다. 그러나 처리 용량을 초과하는 업무의 요구가 발생된다면 미 처리된 업무는 쌓여가게 된다. 이는 곧 서비스 지연이나 시스템 장애로 발전할 가능성을 갖게 된다.
이상이 사용자의 요구가 지속적으로 증가되는 상황에서의 3가지 성능수치의 일반적인 변화 상태다. 응답시간, 자원 사용률, 처리율은 서로 유기적인 연관성을 가지며 모두 중요한 성능요소다. 그리고 이들 중 중심이되는 성능 기준치가 있다.

   

   

IT가 기업의 비즈니스와 직접적으로 연관되면서 경영자 및 사용자의 관심이 시스템 중심 에서 서비스 중심으로 변하고 있다. 따라서 IT의 성능을 측정하는 기준이 CPU 사용율, 메모리 잔여율 등과 같은 '자원 사용률' 보다는 사용자가 느끼는 '응답속도'가 비즈니스 중심적인 측면에서 더 중요하다. 그러나 이런 '응답속도'도 '처리율'보다는 중요도에서 떨어질 수 있다.
즉, 단위시간당 최대 처리 가능한 건수가 더 중요한 의미를 갖는다. 물론 응답 속도가 빠르면 단위시간당 처리 건수가 시스템 품질 관리 강좌 높아지지만, 응답 속도는 동시에 몇 개가 수행되느냐에 따라 수치가 달라질 수 있는 가변적 요소다. 때문에 '응답속도' 보다는 '처리율'을 성능 측정의 기준으로 삼는다.
Max TPS(Transaction Per Second)는 단위시간당(초) 최대 처리건수를 의미한다. TPS가 높다는 것은 단위시간당 더 많은 일(Transaction)을 할 수 있고 이는 곧 더 많은 동시사용자(Concurrent User)의 요구(Request)를 수용할 수 있음을 의미한다. 따라서 Max TPS를 성능측정의 기준으로 삼는다.
즉, TPS를 높이려는 시도를 하는 것이 튜닝이고 성능개선 행위다. 이것은 성능에 장애가 되는 병목을 찾아 해결함으로써 가능해진다. 일반적으로 운영시스템에서 도출되는 병목은 소프트웨어 환경의 최적화 부족, 데이터베이스, 애플리케이션의 구조, 네트워크 속도 등 다양하다.

[출처] [시스템 품질 관리 강좌 4] 성능 테스트의 필요성|작성자 공룡