페이퍼요약 - 은행/금융 분야에 애자일 테스팅 적용이 적절한가 by Robson

제목: 은행/금융 분야에 애자일 테스팅 적용이 적절한가(Agile Testing and the Banking/Finance Domain…should we do it?)

저자: Sharon Robson, Software Education Associates Ltd, 미국

문서유형: 페이퍼(총 7페이지), 2008년

 

 

은행/금융 분야 시스템에 애자일 테스팅 어프로치 적용이 적절한지에 대하여 다룬 자료

---

 

은행/금융 분야 시스템의 주요 특징

다양한 유형의 은행/금융 애플리케이션이 존재하지만 아래 그림은 일반적인 은행/금융 분야의 시스템(the generic Banking/Finance system)을 표현하고 있으며 다음과 같은 특징을 가진다.

• Multi-tier Functionality 또는 a complex system of systems: 시스템 기능이 여러 계층으로 구성. 대규모 통합(integration)이 필요
• Bespoke Development: 내부 IT 그룹이나 아웃소싱에 의한 맞춤 개발된 시스템
• Lacking Documentation: 이론적으로 시스템 문서화가 잘 되어 있어야 맞지만 종종 업데이트가 안되거나 무수한 매수/합병/인수를 거치는 동안 문서가 손실됨
• Many Interfaces: 은행 대 은행, 은행 대 지점, 은행 대 웹 사용자 같은 많은 인터페이스가 존재
• Distributed systems: 웹 인터페이스(a Web Interface)를 포함하여 많은 형태의 사용자 인터페이스를 가지는 분산 시스템. 서로 다른 비즈니스 요구와 시스템 접근 방법을 가지는 많은 사용자가 존재
• Complex Transactions 또는 Complex Business Logic(Client and Server): 데이터 레벨과 사용자 인터페이스(UI) 레벨의 트랜잭션이 복잡하여 종종 업무 로직(business logic)이 클라이언트단, 서버단, 서비스 계층(Service Layer)이나 비즈니스 로직 계층(Business Logic Layer)에도 적용됨
• Secure Transactions(Batch and Real-time): 시스템을 거치는 대부분의 활동(배치, 실시간)이 보안이 보장되는 안전 트랙잭션을 요구
• Auditable: 엄청난 양의 비즈니스 규칙(Business Rules)을 반드시 유지하고 관리/감독해야 함. 광범위한 규제(regulation) 및 감사(auditing) 기능 요구. 은행시스템의 핵심 컴포넌트 중 하나인 보고(Reporting)는 감사와 규제 준수를 실현하는 방법으로 종종 사용됨
• Document Management: 효과적인 문서 관리는 중요 데이터를 보존하는데 핵심적이며, 대개 비즈니스 규칙 구현과 보고/감사 요구사항(reporting and auditing requirements)을 지원하도록 구현된다.
• Back Up/Recovery/Disaster Recovery: 인프라구조 레벨에서 은행/금융 시스템은 견고한 백업 절차, 재난 복구 시스템, 높은 가용성(availability) 요구사항을 가진다.
• Massive Storage Systems: 대용량 저장 시스템. 신속한 트랜잭션(speedy transactions)과 빠른 데이터 이전(rapid data transfer)을 요구
• Disparate Use Cases: 은행/금융 분야에서 자주 일어나는 병합이나 인수 후에 다수의 이종 레가시 시스템(disparate legacy systems)과 통합이 요구됨(인프라구조의 복잡성을 가중시키는 요인)

 

은행/금융 시스템 특징별 애자일 테스팅의 적합성 여부

 

은행/금융 시스템의 특징	애자일 테스팅 어프로치에 적합한가?
여러 계층의 기능(Multi-tier functionality)	Yes.
대규모 통합이 요구되는 시스템의 시스템(Systems of Systems)	Yes or No. 테스팅에서 요구하는 엄격함(정형성) 정도에 따라 달라짐
맞춤형 개발(Bespoke Development)	Yes.
문서의 부재/결여(Lacking Documentation)	Yes.
많은 인터페이스(Many Interfaces)	Yes - 사용자 시나리오가 잘 정의되어 있는 경우
분산 시스템(Distributed Systems)	Yes.
이종의 사용자 케이스(Disparate Use Cases)	Yes - 사용자 시나리오가 잘 정의되었고 합의된 경우
복잡한 트랜잭션(Complex Transactions)	Yes - 자동화된 단위 및 통합 테스트의 경우
안전한 배치/실시간 트랜잭션(Secure Transactions - Batch and Real-time)	Yes - 테스트가 자동화 된 경우
신속한 트랜잭션(Speedy Transactions)	Yes - 자동화된 단위 및 통합 테스트의 경우
복잡한 업무 로직(Complex Business Logic - Client and Server)	Yes - 자동화된 단위 및 통합 테스트의 경우
감사 가능(Auditable)	적용되는 테스팅 표준에 따라 달라짐 No - 가벼운 문서화가 감사 요구에 부적절 Yes - 단위 및 통합 테스트가 자동화되고 추적 및 소스 컨트롤에 따라 통제가 가능한 경우
문서관리(Document Management)	Yes or No. 테스팅에서 요구하는 엄격함(정형성) 정도에 따라 달라짐
백업/복구/재난복구(Back Up/Recovery/Disaster Recovery)	No - 완전하고 구조적인 테스트 커버리지가 반드시 제공되어야 함
대용량 저장 시스템(Massive Storage Systems)	No - 완전하고 구조적인 테스트 커버리지가 반드시 제공되어야 함

 

결론

 

은행/금융 분야 시스템에 동적이고 시장 출시까지의 시간이 빠른 애자일 테스팅 방법이 효과적인 부분도 있고 또한 해당 산업의 규제나 감사 요구사항 같은 전통적인 구조적 테스팅 방법이 요구되는 부분도 있으므로, 개발과 테스팅에 있어 양쪽 방법을 적절하게 혼합한 하이브리드 접근 방법(“hybrid” approach)도 고려해 볼 수 있음