[CISA 이론 정리 - 3장] 03 전통적 시스템 개발 방법론의 단계 구성 (2/2)

5. 테스트

(1) 연계 테스트(Interface test)

① 시스템을 구성하는 하드웨어와 소프트웨어 요소들 간 연결 상태를 평가한다.

② 이질적 시스템 요소들 간에 데이터와 명령이 원활하게 이동하는지 확인한다.

(2) 통합 테스트(Integration test)

① 시스템의 구성 요소들이 하나의 시스템으로 통합되어 유기적으로 작동하는지 확인한다.

② 연계 테스트보다 더 넓은 관점에서의 연계와 시스템 전체의 통합성을 확인한다.

(3) 시스템 테스트(System test)

① 매우 극단적이고 유동적인 환경에서 시스템 신뢰성, 성능, 보안, 복구 능력을 테스트한다.

※ 연계 테스트와 통합 테스트는 안정적이고 통제된 기술 환경에서 수행된다.

 

(4) 테스트 관련 용어

상향식 테스트(Bottom-up Test)

• 개별 모듈을 테스트한 후 상위 단위로 통합해 가면서 테스트한다.

• 단위 테스트, 연계 테스트, 통합 테스트 순으로 테스트한다.

하향식 테스트(Top-down Test)

• 시스템 전체에서 개별 모듈로 관점을 좁혀 가면서 테스트한다.

• 일반적으로 잘 따르지 않는 테스트 접근법이다.

파일롯 테스트(Pilot Test)

• 시스템의 일부 또는 일부분만 예비적으로 테스트한다.

• 초기 개념 증명(Proof of concept)도 일종의 파일롯 테스트이다.

기능/확인 테스트(Function/Validation Test)

• 요구 사항과 시스템 기능 간 추적 가능성을 확인한다.

• 시스템에 요구 사항에 맞게 올바로 개발되었는지 확인한다.

회귀 테스트(Regression Test)

• 발견된 오류를 수정하거나 시스템을 변경한 후에 새로운 오류가 발생하는지 확인하기 위해 이미 수행한 테스트를 다시 수행한다.

병행 테스트(Parallel Test)

• 신규(또는 변경된) 시스템의 안정성을 기존 시스템과 비교한다.

• 기존 시스템과 신규 시스템의 처리 결과가 일치하는지 검토한다.

사회성 테스트(Sociability Test)

• 신규(또는 변경된) 시스템이 설치되면서 기존 시스템에 부정적 영향을 주지 않는지 확인한다.

6. 구현

(1) 의의

① 구현(Implementation)이란 시스템을 사용자 환경으로 이관(migration)하는 것이다.

② 구현은 사용자들에 의한 인수 테스트를 마친 후 사용자 부서의 최고 책임자가 승인을 해야 이루어지므로, 구현 단계에서 일차적으로 수행해야 하는 활동은 인수 테스트이다.

(2) 인수 테스트(Acceptance Test)

① 최종 사용자들이 인수 기준에 따라 시스템 요구 사항이 충족되었는지 직접 확인한다.

② 사용자들의 대표 그룹에 의한 사용자 테스트를 알파 테스트라고 한다.

③ 알파 테스트 후 불특정 다수의 사용자들에 의한 사용자 테스트는 베타 테스트라고 한다.

④ 인수 테스트가 수행되는 환경은 실제 생산(production) 환경과 같아야 한다.

⑤ 인수 테스트를 성공적으로 마치면 사용자 부서의 관리자로부터 인수 서명을 받는다.

⑥ 통제 보안 관점에서 평가하고 보증을 제공할 목적으로 인정/인가 과정을 거친다.

인정(Certification)

• 독립적 전문가가 평가

• 관리/운영/기술 통제 표준이 기준

• 제품의 통제/보안 수준의 적정성을 판단

인가(Accreditation)

• 제품 인수 조직의 고위 경영진이 평가

• 상호 합의한 위험 및 보안 요구 사항

• 공식적으로 제품 사용 허가 및 위험 감수

(3) 사용자 및 운영자 교육

사용자 지침서와 운영 매뉴얼을 완성한다.

사용자와 운영자를 교육/훈련할 강사를 양성하고 교육/훈련을 제공한다.

헬프 데스크를 조직하여 활동을 시작한다.

(4) 데이터 변환(Data Conversion)

① 데이터 변환이란 새로 개발된 시스템에서 정의한 형식으로 데이터를 변경하는 것이다.

② 새로 개발한 시스템이라면 기존에 종이 문서에 기록되었던 데이터를 전산화한다.

③ 이미 존재했던 시스템을 변경했거나 독립적으로 존재하던 시스템들을 통합한 경우라면 통일된 데이터 포맷에 맞추어 데이터의 형식과 값을 변환한다.

(5) 전환(Transition)

① 응용을 사용자 환경에 배포/설치하고 새로운 시스템을 사용하기 시작한다.

② 시스템 구현 시 가장 중요한 고려 사항은 기존 업무의 중단을 최소화하는 것이다.

③ 특히 장기간 광범위하게 사용하던 시스템은 순차적/병행적으로 전환하는 것이 안전하다.

전환 범위에 따른 분류

- 직접적 (Direct)

• 시스템 전체 또는 조직 전체를 동시에 전환한다.

• 전환은 신속하지만 시행 착오와 중단 위험이 높다.

- 순차적(Phased)

• 일부 모듈(또는 부서)부터 차례로 전환 범위를 확대한다.

• 시행 착오와 업무 중단 위험은 낮지만 전환 기간이 길다.

병행 여부에 따른 분류

- 단절적(Abrupt)

• 신 시스템 사용을 전면 중단하고 신 시스템으로 전환한다.

• 새로운 환경 적응 스트레스 및 업무 중단 위험이 높다.

- 병행적(Parallel)

• 신 시스템과 구 시스템이 공존하는 기간을 허용한다.

• 새로운 환경 적응 스트레스 및 업무 중단 위험이 낮다.

7. 프로젝트 이후의 활동

① 프로젝트를 마친 후에는 프로젝트 수행에서 얻을 수 있는 교훈점을 분석하는데 이를 프로젝트 이후 검토(post project review)라고 한다.

② 전환을 마치고 난 후 일정 기간은 하자 보수 등을 통해 시스템 안정화를 지원한다.

③ 구현이 끝난 지 6~18개월 후에는 시스템이 사용자 요구 사항과 비즈니스 니즈를 충족하는지, 목표한 투자 대비 편익이 달성되었는지, 프로젝트 수행 과정은 적절했는지 등에 대한 구현 후 검토(post implementation)를 한다.