how test insurance domain application
테스트의 역할 – 보험 도메인 애플리케이션 테스트 방법 :
이 튜토리얼을 통해 보험 도메인 애플리케이션을 테스트하는 방법과 보험 애플리케이션에서 테스트 할 다른 모듈은 무엇인지 배웁니다.
모든 보험 회사는 비즈니스 운영에 도움이되는 다양한 유형의 소프트웨어에 더 많이 의존합니다. 이 소프트웨어 응용 프로그램은 새 정책 작성, 구성원 등록, 정책 관리 등에 도움이됩니다.
추천 도서=> 보험 도메인의 기초를 배우고 싶다면, 이 튜토리얼을 읽을 수 있습니다.
학습 내용 :
- 보험 도메인 개요
- 보험 애플리케이션 테스트의 중요성
- 보험 프레임 워크
- 보험 애플리케이션을 테스트하기위한 다양한 모듈
- 클레임 관리 시스템 테스트
- 보험 도메인 신청 테스트 팁
- 보험 분야의 성능 테스트
- 보험 분야의 자동화 테스트
- 보험 애플리케이션 테스트의 과제
- 보험 애플리케이션 테스트를위한 테스트 시나리오
- 보험 애플리케이션의 샘플 테스트 케이스
- 결론
- 추천 도서
보험 도메인 개요
우리 모두 알다시피 보험 산업 생명 보험, 자동차 보험, 재산 보험, 건강 보험 등과 같은 다양한 분야로 널리 분류됩니다.
반면에 보험 도메인을 다른 도메인과 크게 다르게 만드는 정책 관리, 청구, 인수 등과 같은 복잡한 기능이 있습니다.
소프트웨어 테스팅은 보험 애플리케이션에서 매우 중요한 것입니다. 테스트는 응용 프로그램이 사용에 적합한 지 여부를 입증하고 새 정책을 생성하는 것부터 최종 청구 합의까지 종단 간 흐름을 수행합니다.
모든 보험 회사는 IT 인프라를 유지 관리하고 있으며 애플리케이션이 실시간으로 성공적으로 실행되는지 여부를 확인하기위한 투자도 고려하고 있습니다.
테스트는 애플리케이션의 견고성을 입증하므로 보험 테스트가 가장 중요합니다.
보험 애플리케이션 테스트의 중요성
오늘날 보험 산업은 생명, 자동차, 건강, 재산 등과 같은 다양한 영역에 널리 퍼져 있습니다. 이러한 광범위한 적용 범위를 통해 최종 사용자의 요구에 따라 여러 소프트웨어 또는 제품을 보유하고 있습니다. 때때로, 같은 보험 상품이 한 지역에서는 빠르게 움직이고 같은 나라의 다른 지역에서는 천천히 움직일 가능성이 있습니다.
이러한 큰 변화로 보험 회사는 현지 고객의 요구를 고려하고 필요에 따라 제품을 만듭니다.
이제 테스트는 제품 기능이 궁극적으로 동일한 국가에서 다른 요구 사항이있을 때 복잡한 작업이됩니다. 따라서 보험 제품이 현지 고객 요구 사항에 맞는지 여부를 확인하려면 보험 도메인 응용 프로그램을 테스트해야합니다.
현재의 디지털 세상에서 각 보험 회사는 소프트웨어를 유지 관리하기 위해 서로 다른 기술을 사용하여 비용을 절감하고 고객 만족도를 높이는 데 도움이됩니다. 보험 회사는 또한 고객의 데이터를 안전하게 유지하기 위해 비용을 지출합니다. 따라서 여러 보험 회사는 모바일 애플리케이션을 통해 자신의 발자국을 보여주기 시작했습니다.
보험 프레임 워크
보험 산업은 다음과 같은 다양한 하위 산업으로 크게 나뉩니다. 생명, 자동차, 재산 및 건강 등. 각 하위 산업에는 테스트 할 기능 영역과 모듈이 다릅니다.
다음은 다양한 모듈을 포함하는 샘플 보험 프레임 워크입니다.
(영상 출처 )
보험 애플리케이션을 테스트하기위한 다양한 모듈
각 보험 회사는 정책 관리, 보험, 청구 관리 시스템 등과 같은 다양한 비즈니스 영역에 분산되어 있습니다. 각 영역에는 따라야 할 자체 프로세스와 표준이 있습니다. 이 섹션에서는 보험 애플리케이션을 테스트하는 동안 중요한 몇 가지 중요한 영역에 대해 알아 봅니다.
여기에서는 보험 업계의 다양한 비즈니스 라인과 보험 애플리케이션을 테스트하는 동안 집중해야하는 영역에 대해 언급했습니다. 물론 각 영역에는 중요하고 조직마다 계속 다른 기능이 있습니다.
클레임 관리 시스템 테스트
클레임 관리자 소프트웨어는 보험 회사의 클레임 프로세스를 단순화하며 '클레임 관리 시스템'이라고도합니다. 이러한 클레임 관리 소프트웨어는 클레임 시작부터 최종 클레임 해결까지 워크 플로를 시작합니다.
청구 관리 시스템은 다양한 기술과 도구를 사용하여 회사의 비용을 절감하고 수동 프로세스를 제거하여 수동 오류 등을 줄입니다.
클레임 관리 시스템 테스트에는 다음이 포함됩니다.
- 청구 수명주기
- 클레임 평가
- 청구 처리 및 거래
- 정책 포기 처리
- 성숙도 처리
- 지불금 설정
정책 관리 시스템 테스트 :
이름 자체가 정책 관리를위한 관리 시스템이라고 말합니다. 고객 개인 정보 및 관련 적용 범위 정보는이 정책 관리 시스템에 저장됩니다. 테스트를위한 다양한 기능이 포함되기 때문에 이는 테스트의 중요한 부분으로 간주됩니다.
아래에 몇 가지 기능이 나열되어 있습니다. :
- 정책 워크 플로 또는 정책 수명주기
- 금융 및 비금융 거래
- 문서 관리 및 처리
- 커버리지 변경
- 프리미엄 만기일 알림
- 정책 취소, 갱신
- 고객 개인 정보 수정
- 정책 경과 처리
언더라이팅 모듈 테스트 :
어떤 사람이 보험을 구매하기로 결정하면 신청을 수락하기 전에 그 사람과 관련된 위험을 평가하는 것이 보험업자의 임무입니다. Underwriting은 보험 회사의 위험 평가 프로세스로 회사가 위험을 평가하고 그에 따라 피보험자의 보험료를 결정합니다.
언더라이팅 모듈에는 주로 다음 테스트가 포함됩니다.
- 복잡한 비즈니스 규칙
- 평가 효율성
- 언더라이팅 품질
- 병력 확인
- 운전 이력 확인
새로운 경영학 시험 :
위험 관리는 보험 회사의 성공에 핵심적인 역할을합니다.
테스트 관점에서 테스트하는 동안 다음 사항을 고려해야합니다.
- 고객에게 빠르고 상세한 견적.
- 고객에게 혜택 세부 정보를 제공합니다.
- 경쟁사의 요금 체계 구조를 확인하십시오.
- 일괄 작업 일정 및 실행.
정책 견적 시스템 테스트 :
고객의 요구 사항에 따라 항상 초기 견적을 고객에게 제공해야합니다. 다양한 유형의 고객이 있으며 서로 다른 적용 범위가 필요하므로 정책 견적 시스템 테스트를 거쳐야합니다.
다음은 정책 견적 시스템을 테스트하는 동안 기억해야 할 중요한 사항입니다.
C ++ 용 이클립스 구성 방법
- 견적 생성에 도움이되는 요율 구조를 검증합니다.
- 고객의 요구에 따라 계획을 검증하십시오.
- 정책 유효 날짜를 확인하십시오.
보험 도메인 신청 테스트 팁
이제 몇 가지 예를 통해 보험 애플리케이션 테스트가 얼마나 중요한지 살펴 보겠습니다.
보험 업계에서는 업무를 수행 / 완료 한 후 다음 단계로 넘어가는 각 에이전트 또는 브로커 (여기서는 '사용자'라고 함)에게 부여되는 역할과 권한이 다릅니다. 두 명의 사용자가 동일한 역할 또는 권한을 가지지 않으므로 작업 완료 중에 충돌이 발생합니다.
# 1) 응용 프로그램의 역할 및 권한 :
예를 들어 , 아래의 역할과 책임을 고려해 보겠습니다. 생산 과정에서 역할 / 책임이 잘못되면 보험 회사에 엄청난 혼란이 생길 것입니다.
- 보험 대리인이 고객에게 보험 정책 신청서를 제출합니다.
- 보험업자는 위험을 평가하고 신청을 수락할지 거부할지 결정합니다.
- 위험 및 적용을 수락하면 고객이 요청한 혜택 또는 계획에 따라 정책이 생성됩니다. 보험 회사의 소프트웨어 애플리케이션을 사용하여 정책 생성이 수행됩니다.
이제 위의 프로세스에서 단계 중 하나가 잘못되고 고객이 요청하지 않은 계획으로 정책이 생성되었는지 상상해보십시오. 또는 신청 수락 또는 거부를 위해 보험 대리인에게 액세스 권한이 부여 된 경우? 현실 세계에서 문제가 발생하면 보험 회사는 시장에 대한 믿음을 잃고 사업을 계속하기가 어려워집니다.
이것은 보험 회사에 큰 손실이 될 것이며 시장 기준을 잃을 수도 있습니다. 따라서 소프트웨어 테스트는 보험 애플리케이션 테스트에서 중요한 역할을합니다.
위의 예에서 테스트는 모든 역할과 권한이 적절한 사용자에게 부여되고 종단 간 흐름이 올바르게 수행되는지 확인합니다. 소프트웨어 테스트는 비즈니스의 이상을 방지하는 데 필수적이며 최종 사용자는 보험 제품 또는 보험 소프트웨어 애플리케이션의 최종 품질을 수락합니다.
보험 애플리케이션을 테스트하려면 보험 분야의 전문가 인 숙련 된 테스트 팀이 있어야합니다.
위의 내용은 단순한 예일 뿐이며 청구, 연금, 정책 관리, 견적 시스템, 평가 엔진 등과 같은 다양한 영역에서 응용 프로그램이 올바르게 진행되도록 테스트가 필요한 부분이 있습니다.
# 2) 정보 인터페이스 :
보험 애플리케이션을 테스트하는 동안 정보가 프런트 엔드를 통해 올바르게 업데이트되고 백 엔드 시스템 또는 데이터베이스에 성공적으로 저장되었는지 확인해야합니다. 또한 저장된 정보는 데이터베이스의 프론트 엔드에서 오류없이 가져옵니다.
# 3) 숫자 인자 :
보험은 숫자 게임이며 보험 도메인의 많은 엔터티는 이러한 숫자에 민감합니다.
보험료의 작은 변화는 최종 결과에 큰 차이를 일으킬 수 있습니다. 따라서 모든 소수점을 확인하고 적절한 수학적 계산이 보험 애플리케이션 테스트에서 중요합니다.
# 4) 날짜 요소 :
날짜도 보험 신청에서 매우 중요합니다.
유효 날짜 정책이 발효되는 날짜입니다. 정책을 수정 한 후에도 유효 날짜가 수정되므로 날짜를 신중하게 입력하고 해당 날짜가 정책 계획에 올바르게 반영되었는지 테스트해야합니다.
# 5) 테스트 종단 간 보험 신청 :
보험 신청을 테스트하는 동안 아래 사항을 확인해야합니다. :
- 견적이 생성되고 고객이 해당 견적을 수락합니다.
- 정책 번호는 적절한 계획과 함께 생성됩니다.
- 모든 개인 정보 및 정책 세부 정보는 정책 관리 시스템에서 업데이트됩니다.
- 회원과 그 부양 가족은 해당 정책에 따라 등록됩니다.
- 시스템에서 적절한 커미션이 생성됩니다.
- 브로커는 프런트 엔드 애플리케이션을 통해 고객 정보를 볼 수 있어야합니다.
- 고객은 온라인 포털을 통해 세부 정보를보고 수정할 수 있어야합니다.
# 6) 비즈니스 관점에서 생각 :
보험 사업을 이해하고 종단 간 흐름을 올바르게 테스트하십시오. 한계를 넘어서 생각해야합니다 '상자 밖으로' 결함을 식별합니다.
최종 사용자의 관점에서 생각하고 애플리케이션을 테스트합니다. 한 화면에서 숫자, 날짜, 등록 세부 정보의 변경 사항이 수정되면 다른 화면에서도 그에 따라 반영되므로 테스트하는 동안 매우 세심한주의가 필요합니다.
보험 분야의 성능 테스트
보험 애플리케이션에는 여러 비즈니스 영역이 있으며 각 영역에는 서로 다른 유효성 검사, 체크 포인트, 복잡성 등이 있습니다. 청구 관리, 정책 관리, 회원 또는 브로커 프런트 엔드 애플리케이션에는 최대 트랜잭션 또는 활동이 수행되는 중요한 영역이 있습니다.
따라서 이러한 응용 프로그램의 성능이 가장 중요합니다. 그리고이 튜토리얼을 통해 보험 도메인 애플리케이션을 테스트하는 방법에 대한 더 많은 지식을 얻을 수 있습니다.
복수 클레임 처리, 당일 복수 정책 갱신, 프론트 엔드 신청을 통해 지속적으로 제출되는 중개 신청 등 다양한 활동이 있으므로 서버가 적절하게 응답하는지 테스트하는 것이 중요합니다.
예를 들어, 보험 애플리케이션은 여러 병원에서 한 번에 많은 청구 (예 : 1000)로 테스트해야하며 시스템이 모든 청구를 성공적으로 처리하는지 확인해야합니다.
부하 테스트를 통해 임계 값 제한을 확인할 수 있으며 스트레스 테스트는 시스템이 실패한 트랜잭션의 최대 최대 제한을 보장하고 실패한 지점에서 성공적으로 복구합니다.
다음은 사용할 수있는 다양한 도구 목록입니다. 성능 시험 보험 신청 :
- LoadRunner
- JMeter
- WebLoad
- 실크 공연자
- 합리적인 성능 테스터
보험 분야의 자동화 테스트
자동화 된 소프트웨어 테스트는 보험 부문의 과제 중 하나입니다.
딜로이트는 보고서에서 보험 업계가 심각한 혼란에 직면하고 있으며 기존 비즈니스 모델이 업계에 도전을 줄 수 있다고 강조했습니다. 모든 애플리케이션에 대해 효율적인 테스트를 수행하면 생산시 결함 수를 크게 줄일 수 있습니다.
다음은 보험 애플리케이션 또는 소프트웨어를 자동화하는 3 가지 부분입니다.
- 자동화 프레임 워크 생성
- 비즈니스 테스트 시나리오 작성
- 소프트웨어의 테스트 상태 평가
보험 애플리케이션 테스트 자동화의 주요 이점 :
- 일관성 : 기능 수정 후에도 애플리케이션이 작동하는지 확인하기 위해 지속적인 테스트가 필요합니다. 수동 오류없이 테스트 스위트를 실행하는 자동화 테스트의 도움으로 가능합니다.
- 재사용 성 : 자동화 테스트를 통해 테스트를 재사용 할 수 있고 비용이 절감됩니다.
- 비용을 줄이고 출시 시간을 단축합니다.
- 오토메이션 확장 성이 뛰어나고 유지 관리가 쉽습니다.
보험 애플리케이션 테스트의 과제
보험 응용 프로그램은 복잡하고 중요한 응용 프로그램이며 보험 도메인에서 응용 프로그램 테스트 중에 관련된 다양한 문제가 있습니다.
Android 용 음악 다운로더 상위 10 개
(영상 출처 )
위의 이미지는 몇 가지 문제를 보여줍니다.
이러한 과제를 빠르게 이해하겠습니다.
- 사람들 : 많은 조직이 보험 분야에 대한 지식이있는 테스터가 부족합니다. 도메인 지식은 모든 비즈니스 프로세스를 인식하므로 종단 간 관점에서 매우 중요합니다.
- 프로세스 : 품질 프로세스 및 모범 사례는 프로젝트의 성공적인 구현에 도움이됩니다. 이러한 프로세스와 실행을 무시하면 프로젝트에 막대한 비용이들 수 있습니다. 모범 사례와 프로세스가 부족한 많은 조직이 실패하는 경향이 있습니다.
- 과학 기술: 다양한 도구와 기술은 프로젝트의 전체 비용을 줄이는 데 도움이되며 오늘날의 디지털 세계에서는 모든 프로젝트에서 이러한 도구와 기술을 구현하는 것이 불가능할 수 있습니다. 도구 비용, 기술 또는 도구에 대한 지식 등 다양한 이유가 있습니다.
- 규제 및 규정 준수 : 새로운 기술이 등장함에 따라 보험 산업에 대한 규칙과 규정도 그에 따라 수정됩니다. 어떤 경우에는 애플리케이션의 품질 테스트를 방해 할 수도있는 복잡한 규칙이 있습니다.
- 경쟁: 정시 배송 및 최소 비용은 고객과 고객 만족을 유지하는 핵심 요소입니다. 새로운 기술과 프로젝트 제공과 함께 고객에게 '새롭거나 추가'혜택을 제공하면 시장 경쟁에서 앞서 나갈 수 있습니다.
- 시각: 각 테스트 단계에서 모든 테스트 팀이 애플리케이션을 철저히 테스트 할 수있는 충분한 시간을 확보 할 수 있도록 테스트를위한 정확한 시간에 애플리케이션을 사용할 수 있어야합니다.
보험 애플리케이션 테스트를위한 테스트 시나리오
이 섹션에서는 보험 애플리케이션을 테스트하는 동안 일반적으로 중요한 다양한 종류의 보험 시나리오에 대해 알아 봅니다.
시작하자.
- 고객이 정책 혜택에 성공적으로 등록 할 수 있는지 확인합니다.
- 시스템이 새 보장 또는 계획 추가를 위해 기존 정책을 수정할 수 있는지 확인합니다.
- 시스템이 고객의 개인 정보를 수정하거나 업데이트 할 수 있는지 확인합니다.
- 시스템이 정책을 취소 할 수 있어야합니다.
- 에이전트의 커미션이 올바르게 계산되었는지 확인합니다.
- 지불 할 금액보다 더 많은 금액을 지불 한 경우 추가 금액을 고객에게 되돌려 야합니다.
- 시스템에서 NEFT, 수표 방법 등을 사용하여 결제를 처리 할 수 있는지 확인합니다.
- 무효 변경 프로세스가 성공적으로 완료되었는지 확인하십시오.
- 새 수취인이 시스템에서 성공적으로 업데이트되었는지 확인합니다.
- 정책에 잘못된 라이더 코드를 추가하는 동안 오류 메시지가 표시되는지 확인하십시오.
- Riders가 기존 정책에 성공적으로 추가되었는지 확인합니다.
- 정책에 대한 구성원 등록이 성공적으로 처리되었는지 확인합니다.
- 요금이 정책 계획 및 구조에 따라 생성되었는지 확인합니다.
- 에이전트 시스템에서 생성 된 정책이 견적 시스템에서 자동으로 사용 가능한지 확인하십시오.
- 정책 수정이 성공적으로 처리되었는지 확인하십시오.
- 정책에 대한 적용 범위를 확인하십시오.
- 정책 번호 또는 정책 이름을 사용하여 정책을 검색 할 수 있는지 확인하십시오.
- 고객의 요청에 따라 정책 갱신이 성공적으로 처리되었는지 확인합니다.
- 제안이 관련 정책 계획에 대해 성공적으로 생성되어 보험 계약자에게 전송되었는지 확인합니다.
- 청구가 성공적으로 처리되었는지 확인하십시오.
- 새 계획을 추가하여 정책 유효 날짜가 업데이트되었는지 확인하십시오.
보험 애플리케이션의 샘플 테스트 케이스
에이전트 시스템, 관리 시스템, 커미션 또는 브로커 시스템, 등록 시스템 등과 같은 거의 모든 시스템 또는 응용 프로그램을 다루는 가상 흐름을 기반으로 한 샘플 테스트 케이스를 제공하고 있습니다.
이 흐름은 가상의 기준일뿐입니다.
단계 아니오 | 기술 | 예상 결과 |
---|---|---|
7 단계 | 관리 시스템은 모든 세부 사항을 확인하고 에이전트 커미션을 계산하고 커미션 시스템으로 전달합니다. | 커미션 시스템은 에이전트 / 브로커의 커미션으로 업데이트되어야합니다. |
1 단계 | 고객의 확인시 보험 대리인이 시스템에 초기 제안을 생성 할 수 있는지 확인합니다. | 고객 요청에 따라 초기 제안을 생성해야합니다. |
2 단계 | 초기“Case”가 생성되고 보험 시스템 및 Quoting 시스템으로 이동합니다. | 제안서는 정책을 생성하기 위해 견적 시스템으로 이동해야합니다. |
3 단계 | 고객 요구 사항에 따라 올바른 유효 날짜 및 정책 계획으로 성공적으로 생성 된 정책 | 적절한 위험 계산 후 고객에 대한 정책 번호를 생성해야합니다. |
4 단계 | 보험 계약 및 견적 시스템에서 정책이 관리 시스템으로 전달되는지 확인 | 이제 관리 시스템에 정책 번호 및 관련 계획이 있어야합니다. |
5 단계 | 모든 구성원, 부양 가족 및 해당 세부 정보가 정책 세부 정보와 함께 등록 시스템에서 업데이트되었는지 확인합니다. | 등록 시스템이 정책 세부 정보로 업데이트됩니다. |
6 단계 | 이러한 세부 사항이 관리 시스템에 성공적으로 전달되었는지 확인하십시오. | 이제 관리 시스템에는 관련 정책 및 계획과 함께 보험 계약자의 모든 개인 정보가 있어야합니다. |
8 단계 | 모든 이용 약관과 함께 정책 문서 및 프리미엄 세부 정보가 생성되었는지 확인 | 모든 문서를 생성하여 보험 계약자의 주소로 보내야합니다. |
9 단계 | 정책 등록 후에도 개인 정보가 성공적으로 수정되었는지 확인 | 정책 등록 후 개인 정보가 업데이트되어야합니다. |
10 단계 | 새로운 혜택 또는 계획이 성공적으로 추가 / 제거 / 수정 될 수 있는지 확인 | 새 계획은 기존 정책에서 성공적으로 추가 / 제거 / 업데이트되어야합니다. |
11 단계 | 기존 정책을 수정 한 후 정책의 유효 날짜가 올바르게 업데이트되었는지 확인 | 기존 정책을 수정하면 유효 날짜가 올바르게 업데이트되어야합니다. |
12 단계 | 적절한 확인 후 클레임 요청이 수락되었는지 확인 | 클레임 요청은 성공적으로 수락되고 관련 하위 시스템으로 전송되어야합니다. |
13 단계 | 청구가 성공적으로 처리되고 적절한 수혜자 / 보험 계약자에게 지급되었는지 확인 | 보험 계약자 / 수혜자는 청구 금액을 적립해야합니다. |
14 단계 | 테스트 종료 |
결론
이 자습서에서는 보험의 다양한 영역과 각 영역에서 수행해야하는 테스트 유형에 대해 배웠습니다. 또한 보험의 주요 측면과 보험 도메인 애플리케이션 테스트와 관련된 다양한 용어를 살펴 보았습니다.
시나리오와 샘플 엔드 투 엔드 테스트 케이스가 보험 개념과 다른 애플리케이션의 흐름을 명확하게 이해하는 데 확실히 도움이되기를 바랍니다.
보험 도메인의 테스터입니까? 이 튜토리얼에 흥미로운 것을 추가 하시겠습니까? 아래 댓글란에 자유롭게 의견을 남겨주세요!
추가 권장 읽기 :