책 요약 - 사례 연구: 로이터 제품 승인 그룹 by Paul Goddard

출처: 15장 Case Study 2: Reuters Product Acceptance Group by Paul Goddard, 129~141 페이지,
from “Testing IT: An Off-the-Shelf Software Testing Process” by John Watkins, 2001년

 

이 사례 연구는 현실 세계에서 테스팅 프로세스를 구현한 실제 조직의 예를 제공한다. 책의 1부에서 제시한 테스팅 프로세스의 전통적인 관점을 독자가 자신의 테스트 요구사항에 더 가깝게 적용하는 방법에 대한 통찰을 얻을 수 있으며, 특히 조직 내에서 테스팅 프로세스를 수립하는 책임을 맡은 독자에게 유용하다.

---

 

Reuters Product Acceptance Group(PAG) - 조직 개요

Reuters 서비스는 940,000개 이상의 주식/채권/금융상품에 대한 데이터와 40,000개의 기업 데이터를 제공하며, 세계에서 가장 광범위한 개인 위성 및 케이블 통신 네트워크를 통해 전 세계로 전달된다. 이러한 금융 정보는 260개 거래소와 장외 시장 그리고 5000명의 클라이언트에게서 수집된다. 전 세계적으로 52,800개 장소에서 521,000명 이상의 사용자가 로이터 정보 및 뉴스에 접근한다. 일반적으로 Reuters가 초당 6,000개의 가격 및 기타 데이터 항목을 업데이트하고, 매일 6,500만 개의 변경을 처리한다. Reuters의 데이터베이스에는 실시간 정보와 10년 이상 된 정보까지 다양하게 존재한다. 

로이터의 두 가지 주요 사업 부서가 ‘로이터 정보(RI: Reuters Information)’와 ‘로이터 트레이딩 시스템(Reuters Trading Systems)’이다. RI의 제품에 실시간 및 과거 정보 데이터베이스가 포함되며, 외환과 화폐, 원자재(에너지 포함), 채권, 주식의 네 가지 주요 시장에 주력하고 있다. 로이터 트레이딩 시스템 부서는 로이터 관리 시스템, 트랜잭션 제품, 리스크 관리 제품, 기타 애플리케이션을 담당한다. 

로이터 제품 승인 그룹(PAG: Product Acceptance Group)은 RI 부서 내에서 운영되는 조직으로 런던에 위치하고 있으며, 외부 공급업체가 계약에 따라 개발한 금융 트레이딩 제품의 승인 테스트를 고객을 대신하여 책임지는 대규모 테스트 그룹이다. 이 사례 연구는 1997년 10월부터 1998년 5월까지 PAG의 테스팅 활동에 대한 스냅샷이다.

 

테스팅 요구사항(Testing Requirements)

PAG는 주로 Reuters 3000 제품군의 승인 테스팅(Acceptance Testing)을 책임진다. Reuters 3000 제품군은 거래 전 의사결정(pretrade decision-making)과 거래 후 분석(post-trade anaysis)을 지원하기 위해 고품질의 광범위한 과거 참조 데이터 및 실시간 데이터에 대한 통합 접근을 제공하는 시스템이다. Reuters 3000 제품군이 다음을 포함한다.

• Reuters Treasury 3000: 사용자가 채권의 조건 및 가격 이력을 검색, 분석, 표시, 내보낼 수 있도록 한다. Treasury 3000은 펀드 매니저, 포트폴리오 매니저, 애널리스트, 연구원, 브로커, 트레이더, 영업사원, 중간 및 백오피스 직원이 사용하도록 설계되었다.
• Reuters Securities 3000: 증권 시장에 대해서 위와 비슷한 역할을 한다.
• Reuters Money 3000: 실시간 머니마켓(Money Markets)에 대해서 위와 비슷한 역할을 한다.

 

모든 Reuters 3000 제품들이 서로 데이터 및 서비스를 교환하면서 상호 운용 가능해야 하며, 또한 다른 로이터 시스템(예, 2000-시리즈 실시간 제품, 로이터 그래픽스, 로이터 터미널 제품)과도 상호 운용 가능해야 한다. Reuters 3000 제품이 분석이나 보고서 작성에 사용하는 스프레드시트와 워드프로세싱 패키지 같은 타 상용 제품(COTS)과도 상호 운용 가능해야 한다. 

Reuters 3000 제품은 계약을 통해 제3자 공급업체가 구현하였으며, 해당 업체가 PAG에 납품하기 전에 테스트 대상 애플리케이션(AUT)의 단위, 링크, 시스템, 통합 테스트를 책임진다. PAG가 성공적으로 승인 테스트를 마치고 나면, AUT는 고객 사이트로 전달되어 실제 사용(live use) 전에 사용자 테스팅(User Testing)을 거친다. 

고객들은 다양한 사양과 구성을 가진 하드웨어/소프트웨어 플랫폼에서 Reuters 3000 제품을 전개하는 데, 여기에 타 소프트웨어 제품(예: 스프레드시트, 워드프로세싱, 통신 소프트웨어)의 공존으로 인해 상황이 더 복잡해진다. 이러한 고객 컴퓨터 플랫폼의 이질성(heterogeneity) 때문에 PAG가 승인 테스팅 프로세스에서 철저한 상호운용성(Interoperability) 테스팅과 호환성 테스팅(Compatibility)을 수행해야 한다. 

이런 요구사항을 지원하기 위해 PAG는 약 40대의 PC, 서버, 네트워킹 장비와 광범위한 분야의 테스트 소프트웨어로 구성된 테스트 랩(test laboratory)을 갖추고 있다. PAG 테스트 Lab은 현실적인 승인 테스트 활동을 수행하기 위해 고객의 다양한 설치 모델(환경)에 따라서 신속하게 테스트 환경을 구성할 수 있는 안전한 시설이다. 

PAG에 전달된 모든 Reuters 3000 제품은 두 갈래의 테스트 스트림에 들어간다.

• 참조 데이터베이스(Reference Database) 승인 테스팅: AUT의 데이터 서비스 측면이 올바른지 확인한다. ‘RDB Acceptance Testing’으로 지칭
• 클라이언트 사이트(또는 Graphical User Interface) 승인 테스팅: AUT의 고객 측면이 올바른지 확인한다. ‘GUI Acceptance Testing’으로 지칭

 

 

테스팅의 관리 및 계획

그림 15.1은 PAG의 조직 구성, 로이터 내에서의 위치, 타사 개발자 및 로이터 고객과의 관계에 대해 보여준다.

[그림 15.1 로이터 PAG 조직]

• PAG Manager: PAG 그룹의 일상 운영을 책임진다. 로이터 영국 운영 매니저에게 보고를 하고, RDB 및 GUI 승인 매니저의 보고를 받고, 개발 팀 리더와 연락하여 AUT의 제공 날짜를 합의하고, AUT의 개발 및 테스트에 올바른 절차가 적용되었는지 확인한다. 또한 FIP(Financial Information Products) 구현 그룹과 연락하여 그들이 후속 설치 및 사용자 테스팅을 할 수 있도록 승인 테스트를 거친 AUT를 넘겨준다.
• RDB/GUI Acceptance Managers: AUT가 고객에게 공식적으로 릴리즈될 준비가 되었는지 여부를 결정할 책임이 있다. RDB 승인 매니저는 AUT의 참조 데이터베이스 측면이 올바른지 확인해야 하며, 지원가능성(supportability)과 운용성(operability)을 테스트한다. GUI 승인 매니저는 AUT의 고객 측면이 올바른지 확인하기 위해 기능 요구사항(functional requirements), 상호운용성(interoperability), 사용용이성(usability) 등을 테스트한다.
• RDB/GUI Test Planner: 전통적인 테스팅 프로젝트에서 테스트 팀 리더가 하는 여러 역할을 통합 수행한다.
• Test Analyst: 주로 테스트 프로젝트 내에서 테스트 케이스 및 테스트 스크립트의 설계와 구현을 담당한다.
• Tester: 주로 테스트 분석가가 작성한 테스트 스크립트의 실행을 책임진다.
• 독립적인 테스트 관찰자(Independent Test Observer): 테스팅 프로세스가 올바르게 준수되었는지 확인할 책임이 있다. 공식 테스팅 프로세스에서 심각한 이탈을 목격하였고 이를 테스트 팀 리더와 해결할 수 없는 경우 이 문제를 PAG 매니저에게 직접 보고할 수 있다.

  

테스팅 계획의 관점에서 PAG는 전통적인 V 모델 접근 방식을 사용하며, PAG의 고유한 테스트 요구사항을 위해 그림 15.2에 표시된 것처럼 V 모델을 확장하였다. 앞에서 언급했듯이 타사 공급업체가 단위, 링크, 시스템/통합 테스트를 포함한 테스트의 초기 단계를 수행할 책임이 있다. V 모델 원칙에 따라 소프트웨어 개발의 요구사항 단계(the Requirements phase) 동안 PAG 내에서 승인 테스트의 계획 및 준비가 시작되며, RDB 테스트 플래너와 GUI 테스트 플래너가 각각 그 책임을 진다.

[그림 15.2 로이터 PAG 그룹의 V 모델 뷰]

 

 

테스팅 단계(Testing Phases)

Reuters 3000 제품의 단위, 링크, 시스템/통합 테스트는 라이브 데이터의 대표 사본을 사용하여 개발 컴퓨터(NCR 5100 시리즈 머신)에서 개발자가 수행한다. PAG는 Reuters 3000 제품군의 신규 제품에 대한 승인 테스트와 현 Reuters 3000 제품의 신규 버전/릴리즈에 대한 승인 테스트를 담당한다. 후자의 경우 PAG는 AUT에 대한 엄격한 회귀 테스트를 수행하여 새로운 기능이 기존 기능의 올바른 성능에 영향을 미치지 않았음을 확인해야 한다. 

승인 테스팅은 PAG Lab에서 수행되는 데, 이곳에 여러 고객 설치 환경을 대표하도록 다양한 하드웨어 및 소프트웨어 구성을 설정한다. 승인 테스팅은 테스트 결과의 정확성에 대한 추가적인 확신을 얻기 위해 라이브 Reuters 3000 데이터 소스에 대해서 수행한다. 성공적인 승인 테스팅을 마치고 나면 AUT가 고객에게 전달되며, 고객은 라이브 환경에서 라이브 데이터를 사용하여 사용자 테스팅(User Testing)을 수행한다. 그림 15.3은 테스팅 단계와 장소, 데이터 요구사항에 대한 개요이다.

[그림 15.3 Reuters 3000 테스팅 단계 요약]

 

Unit, Link, Systems, and Integration Testing

개발자는 적절한 단위 테스팅, 링크 테스팅(전통적인 통합 테스팅 단계를 가리키는 개발자 용어), 시스템 테스팅, 통합 테스트팅(시스템 통합을 가리키는 개발자 용어)을 수행할 책임이 있다. 시스템 테스팅과 통합 테스팅은 결합되어 하나의 테스트 단계에서 함께 수행된다. 개발자가 관리하는 테스팅 단계에 사용되는 데이터는 Reuters 3000 제품에서 사용하는 라이브 데이터의 복사본이며, 현실적이고 대표성을 가지는 테스팅을 보장하기 위해 PAG가 개발자에게 제공한다. 개발자가 경계 조건 및 오류 조건을 테스트하기 위해 직접 데이터를 만들어 라이브 데이터를 보강할 수도 있으며, 그러한 데이터는 공식적인 설계 기법(책 3장에 기술된 테스팅 기법)을 사용하여 생성한다.

 

Acceptance Testing

PAG는 Reuters 3000 제품이 고객에게 전달하기에 적합한 품질이라는 확신을 얻기 위해 승인 테스팅을 수행한다. 승인 테스팅에서 제품의 아래 측면들을 확인한다.

• 설치 테스트(Installation testing)
• 제품에 미치는 영향: 제품의 변경되지 않은 모든 요소에 대해 동일한 수준의 기능/성능/품질이 사용자에게 계속 제공되는지 확인하는 회귀 테스팅(Regression Testing)
• 상호운용성 테스트(Interoperability testing)
• 운용성 테스트(Operability testing): 운영 그룹(Operations group)이 일상적인 모니터링 및 지원을 할 수 있는가? 예를 들어, 오류/정보 메시지가 적절한 의미를 주는가? 기존 운영 규범/요구사항에 부합하는가?
• 지원성(Supportability): 개발 그룹이 제품을 장기적으로 지원할 수 있는가? 예를 들어, 명명 규칙(naming conventions)이나 DBA 관행에 대한 표준을 충족하는가? 표준 인터페이스 및 공통 함수(common functions)를 사용하는가?
• 사용용이성 테스트(Usability testing)
• 벤치마킹: 추세 관찰을 위해 시간 경과에 따라 모니터링한 성능 결과를 포함한 성능 테스팅

 

PAG의 승인 테스팅을 거치는 각 Reuters 3000 제품은 RDB 승인 테스트(AUT의 참조 데이터베이스 측면이 올바른지 확인)와 GUI 승인 테스트(AUT의 고객 측면이 올바른지 확인)의 두 갈래의 테스팅을 거치게 된다. 특정 AUT에 대한 RDB 및 GUI 테스트는 모두 PAG Lab에서 수행되기 때문에 테스트 시설에 대한 경합을 피하기 위해 적절한 테스트 계획이 필요하다. 

승인 테스트 스크립트와 테스트케이스는 PRS(Product Requirements Specification) 및 PFS(Product Function Specification) 문서와 기타 추가 설계 자료(예, 프로토타입 소프트웨어 또는 사용자 가이드 문서)에 제공된 정보를 기반으로 테스트 분석가가 설계한다. 테스트 스크립트는 테스터에 의해 실행되는 데, 이들은 테스트케이스의 결과를 기록하고 관찰된 에러를 문서화한다. 

테스트 결과 기록서(Test Result Record Forms) 분석 후 확인된 에러를 상용 결함 추적 시스템에 기입하고, 이는 개발자에게 보고되어 상호 합의된 시간 내에 수정되도록 한다. 테스터는 결함이 수정되었는지 확인하고 적절한 회귀 테스트(결함 수정 과정에서 AUT의 기존 기능이 손상되지 않았음을 보장하기 위함)를 위해 AUT를 재테스트할 책임도 있다. 

승인 테스트가 성공적으로 완료되면 AUT를 FIP로 전달하여 사용자 테스트 수행 및 고객에게 배포되도록 한다.

 

Regression Testing

Reuters 3000 제품의 새 릴리즈(예, 개선 릴리즈 또는 결함 수정 릴리즈)는 철저하고 엄격한 회귀 테스트를 거쳐 소프트웨어 품질에 대한 최대 신뢰도를 제공하도록 되어 있다. PAG는 회귀 테스트에 소요되는 시간과 노력을 절약하고 일관되고 철저한 접근 방식이 유지되도록 하기 위해 가능하면 기존 테스팅 자료를 재사용하여 회귀 테스트를 최대한 효과적이고 효율적이도록 한다. 

승인 테스트를 마치면(그리고 AUT의 새 릴리즈 이후) 테스터가 테스트 스크립트, 테스트케이스, 그리고 기타 관련 테스트 자료(예, 테스트 데이터)의 복사본을 만들어 재사용팩(Re-use Pack)에 넣으며, 이는 다음 승인 테스트에서 잠재적 재사용을 위해 제출된다. 다음 승인 테스트의 계획 단계에서 RDB/GUI 승인 매니저, 테스트 플래너, 테스트 분석가는 현 테스팅 단계에서 재사용할 수 있는 적절한 테스트 자료를 식별하기 위해 기존 재사용팩을 검토한다.

 

User Testing

사용자 테스팅은 알파 및 베타 테스팅을 담당하는 FIP 제품/프로젝트 매니저에 의해 수행된다. 이 테스팅의 결과물은 일반적으로 다음 릴리즈의 요구사항으로 입력된다.

 

산출물(Artifacts)

테스팅 프로세스의 품질과 일관성을 유지하고 테스팅 문서 생성에 소요되는 시간, 노력, 비용을 아끼기 위해 표준 문서 템플릿이 PAG 직원에게 제공된다. PAG 테스팅 프로세스에서 사용하는 테스팅 아티팩트가 다음을 포함한다. 

• 제품 요구사항 명세서(PRS: Product Requirements Specification): FIP에서 초안을 작성하고 PAG에서 이를 보완하여 테스트 목적에 따른 사용자/운영/제품 요구사항을 포함하도록 작성한다.
• PFS 프로젝트 계획서
• PAG 작업 방법 문서: Reuters 3000 제품 테스트에 대한 철학과 접근 방식을 설명하고, PAG 테스팅 프로세스(표준 문서 템플릿 포함)에 대한 설명을 제공하는 상위 수준 정책 문서이다.
• PAG 승인 테스트 계획서(PAG Acceptance Test Plan)
• PAG 승인 테스트 명세서(Acceptance Test Specification)
• 재사용팩(Re-use Packs): 테스트 사양서 사본, 테스트 로그 사본, 테스트 스크립트(또는 테스트케이스) 사본, 전자적으로 보관된 데이터 복사본에 대한 참조 정보 등
• 테스트 로그(Test Logs)
• 테스트 스크립트(Test Scripts)
• 테스트 결과 기록서(Test Result Record Forms)
• FIP 또는 RDB 운영팀에 전달되는 테스트 요약 보고서(Testing Summary Report): 여기에 결함 관리 계획(Deficient Management Plan)이 포함될 수도 있는 데, 현 릴리즈에서 수용하기로 결정한 결함과 향후 결함 해결 계획(또는 미해결로 남겨둘지)에 대해 문서화한 것이다.