문서요약 - TMAP 방법론 기반 마이그레이션 테스팅 by Baarda

제목: TMAP 방법론 기반 마이그레이션 테스팅(TESTING OF MIGRATIONS BASED ON TMAP)

저자: Rob Baarda, Sogeti Nederland, 네덜란드

문서유형: 화이트페이퍼(총 32페이지), 2005년

 

테스팅 서비스 제공 업체인 Sogeti의 마이그레이션 프로젝트 테스팅 방법에 대하여 기술한 자료

---

마이그레이션 특유의 용어

• POC(Proof of Concept 또는 Proof of Confidence): 마이그레이션 프로젝트의 시작 단계에서 시스템의 대표적인 부분을 소규모로 마이그레이션 해 봄으로써 마이그레이션상에 문제가 있을지를 미리 확인하는 작업
• Pre-migration situation and post-migration situation: 마이그레이션 수행 전 상황과 이후 상황
• 마이그레이션(Migration)과 전환(Conversion) 구분: 대개 마이그레이션이 전환보다 추상화 레벨에서 한 단계 더 상위인 것으로 간주됨. 예) 프로그램 또는 데이터베이스는 전환되고 시스템은 마이그레이션 된다.

마이그레이션 종류(Migration types)

정보 시스템과 그 주변 컴포넌트를 새로운 환경으로 바꾸는 마이그레이션은 아래처럼 다양한 유형이 존재한다.

무엇이 변경되는가	무엇을 마이그레이션 하는가	예
프로그래밍 언어	스크린을 포함한 소프트웨어. 때때로 데이터	Cobol에서 C로
프로그래밍 언어의 버전	소프트웨어	Oracle 5i에서 Oracle 6i로
데이터베이스 시스템 또는 데이터베이스 시스템의 버전	소프트웨어와 데이터, 관련 통제 도구	IDMS에서 DB2로 Oracle 5i에서 Oracle9로
시스템 소프트웨어	“JCL”, 잡스케쥴링 등	VAX-DCL에서 IBM-JCL로
시스템 소프트웨어 버전	소프트웨어	CICS x에서 CICS x+1로
하드웨어/인프라구조 (데스크탑 제외)	하드웨어/인프라구조 위에 놓인 모든 것(JCL, 스케쥴링, 데이터베이스 시스템, 데이터, 스크린 포함 소프트웨어)	IBM S/390에서 AS/400으로 Server W-NT에서 W2000으로
기능	소프트웨어 데이터	Y2000, 유로, 전화번호나 은행계정 번호의 자리수 확장
부서/조직 통합	데이터 소프트웨어	두 개의 데이터베이스를 통합(종종 기능 변경도 필요)
소프트웨어 패키지의 도입 또는 교체	데이터 소프트웨어	SAP 또는 CRM 도입 웹 콘텐츠를 CMS로 마이그레이션
소프트웨어 패키지 버전	자체 제작 소프트웨어	SAP 4.1에서 SAP 4.6으로
OS를 포함한 데스크탑	작업 장소	Windows-NT에서 Windows-XP로

마이그레이션 목적

비용 절감, 오래된 기술을 신기술로 대체 등의 이유로 수행되는 마이그레이션은 기존 기능을 이전되는 새로운 기술 환경에서도 그대로 동작하도록 만드는 데 목적이 있지만, 아래와 같은 추가적인 목적도 있을 수 있다.

• 사용 안하는 코드(=dead code)를 프로그램에서 제거
• 프로그램 코드 재구조화(Restructuring)
• 사용 안하는 프로그램을 마이그레이션에서 제외
• 데이터 마이그레이션 수행 전에 데이터 개선(예, 빠진 데이터 보완, 오용되는 데이터 필드를 구조적으로 해결)

 

마이그레이션 프로젝트 생명 주기

아래 그림은 마이그레이션 프로젝트의 단계별 주요 액티비티를 나타낸다.

비전, 시나리오, 방법(Vision, scenario & approach)

• 마이그레이션 대상 분석
• 상세 분석을 통해 마이그레이션 규모를 예측하고, 여러 다른 종류의 컴포넌트를 구별하고(예, 컴퓨터 언어, 스크린 디스패치, 보고서 생성기, JCL/스크립트, 스케쥴링), 잠재적인 문제 영역을 식별

로드맵(Road maps)

• 전환 방법을 구체화한다(예, 빅뱅 어프로치 또는 점진적 마이그레이션 어프로치 도입)
• 가용한 기 테스트 자원(testware) 조사

POC(Proof of Concept 또는 Proof of Confidence)

• 성공적인 마이그레이션이 가능하도록 일부를 대상으로 시험 삼아 해보는 POC 수행
• 데이터 전환의 경우 종종 통제 메커니즘(control mechanisms)이 구축되며, 특수한 데이터 전환 소프트웨어가 개발되고 테스트 된다. 현 생산/운영 데이터(current production data)의 전환을 수행하여 시험 전환(trial conversion)을 해본다.
• 선별된 소프트웨어에 대한 POC 전환을 수행하고 테스트 한다. 발견된 구조적 문제점이 해결되도록 계획된 전환 방법을 조정한다.

마이그레이션 수행 및 테스트(Migrate and test)

• 전환할 소스를 클러스터로 나눈다.
• 작업 패키지의 클러스터별로 전환 수행

통합 및 승인 테스트(Integrate and acceptance test)

• 모든 소프트웨어를 한 환경으로 통합하여 이를 테스트한다
• 전환 계획에 따라 데이터의 시험 전환(Trial conversion) 수행
• 필요 시 테스트 실행을 통해 고객 승인을 받는다

쉐도우 런(Shadow run)

 

생산/운영 단계로 전이(Transfer to production)

마이그레이션 프로젝트의 조직 구성 측면

아래 그림은 마이그레이션 프로젝트의 조직 구성의 예를 보여준다

• 고객: 수행할 마이그레이션의 스폰서
• 시스템 통합: 마이그레이션 실행의 책임을 진다, 내부 IT 부서와 외부 IT 공급업자(또는 전문 서비스 제공 업체)의 인원들로 팀 구성
• 승인: 승인 기준이 충족되었는지를 판단하여 SI 활동의 결과를 받아들인다. 승인 테스트는 승인 프로세스의 한 부분으로 기능성, 사용성, 성능 측면을 확인한다.
• 프로그램과 JCL 전환은 도구와 해외 인적 자원을 활용하여 작업하는 전문 업체에 아웃소스 될 수 있다

일반적인 마이그레이션 승인 기준(acceptance criteria)

• 기능 정확성과 완전성 확인
  - 하루 또는 일주일의 실 업무/운영을 시뮬레이션
  - 모든 기능이 적어도 하나 이상의 트랜잭션을 수행하도록 만듬
  - 모든 들어오고 나가는 인터페이스가 모든 종류의 메시지를 처리하도록 만듬
  - 가용 테스트 케이스를 완전하게 실행(마이그레이션 전과 후가 일대일로 동일한 경우 the pre-migration의 시스템 동작이 테스트 기준이 되고 기존 테스트 스크립트 사용 가능)
• 마이그레이션 전과 적어도 동일한 성능을 내는지 확인(배치와 온라인 모두)
• 데이터 전환의 경우 총합계가 정확한지 확인(총계가 달라지는 경우 차이가 나는 합당한 이유가 있고 관련 조직이 이를 승인하는지 확인)
• 데이터 전환의 정확성을 상세 레벨에서 증명할 필요가 있을 수 있는데, 이 경우 증명을 위해 추가적인 도구가 종종 사용된다.
• 사용자 대다수가 스크린의 전반적인 디자인(the look-and-feel)에 만족하는지 확인
• 유지보수 프로그래머 대부분이 전환된 소프트웨어를 이해하고 유지보수 하는데 문제가 없는지 확인
• 모든 자동화된 프로세스가 계획된 순서대로 계획된 시점에 시작하고, 함께 어울려 적절하게 동작하는지 확인
• 보안이 주어진 표준에 여전히 부합하는지 확인

테스트 레벨

마이그레이션 프로젝트에 공통적으로 포함되는 추가적인 테스트 레벨은 POC-test이다. 전체 테스트 계획의 테스트 레벨이 아래와 같다.

POC-test(the Proof-of-concept test)

• 계획된 마이그레이션 방법이 효과적인지 확인하기 위해 정보 시스템에 포함된 모든 종류의 소프트웨어를 소규모로 전환해 봄(시스템의 10%를 전환함으로써 문제의 90%를 발견할 수 있다)
• 많은 문제가 발견되는 경우 전환 프로세스를 개선하고 POC-test를 다시 반복
• 성능이 주요 이슈인 경우 효율성 측정을 통해 성능도 테스트 해 본다.

프로그램 테스트(Program test)와 프로그램 통합 테스트(program integration test)

• 전환이 완전하고 정확한지, 프로그램 구조와 데이터베이스 구조가 안정적으로 함께 동작하는지를 확인하는 테스트로 전환 클러스터 별로 수행된다.
• 전환된 클러스터(the converted cluster)와 전환 소프트웨어(the conversion software)의 프로그램 코드 검토(the code review) 수행

시스템 테스트(System test)와 시스템 통합 테스트(system integration test)

• 통합된 소프트웨어와 데이터베이스의 기능 정확성 확인, 성능 테스트와 효율성 측정
• 매해 주요 배치 기능(yearly important batch functions) 실행, 내부 및 외부 인터페이스도 가능한 최대로 테스트한다.
• 실험실 환경 보다는 실제 생산/운영 환경에서 테스트 수행이 더 바람직하다.

승인 테스트(Acceptance test)

• 실제 생산/운영 데이터(the production data)의 시험 전환 수행
• 전환된 운영 데이터를 가지고 실제 업무 상황에서 기능 정확성 및 완전성 확인, 성능 확인(배치와 온라인), 타 시스템과의 연계 확인
• 시스템 관리자가 JCL-생산 스크립트, 패러미터 세팅, 보안 이슈, 전형적인 시스템 관리 도구(예, sniffers, data checks), 잡스케쥴링(PAT)을 테스트 할 수 있는 기회