Salesforce CPQ 구현은 단순한 제품 카탈로그에서 복잡한 기업 견적 엔진으로 진화하여 수백만 개의 제품 조합을 처리합니다. 초기 구현은 UI 검증에 초점을 맞추었지만, 현대 B2B 영업 프로세스는 정교한 가격 알고리즘, 실시간 승인 조정 및 문서 생성 워크플로우의 검증을 요구합니다. 이 질문은 중첩된 번들에서 가격 계산 오류로 인해 수익 누수가 발생한 생산 사건에서 발생했으며, 거버너 한계 예외로 인해 중요한 분기 종료 중 대규모 기업 견적이 손상되었습니다.
핵심 과제는 Salesforce의 다중 테넌트 거버너 한계(특히 2000 DML 행 한계 및 50,000 쿼리 행 한계)를 준수하면서 계층적 데이터 구조에서 상태 기반 계산을 검증하는 데 있습니다. 테스트 담당자는 가격 재계산이 부모-자식 번들 관계를 통해 올바르게 전파되고, 승인 프로세스가 동적 기준(할인 비율, 거래 규모, 제품 카테고리)에 따라 라우팅되며, 계약 생성이 자동화된 워크플로우에 의해 트리거될 때 데이터 일관성을 유지하도록 확인해야 합니다. 또한, 관리 패키지 논리와 함께하는 Apex 전후 트리거의 교차점은 수동 테스트 담당자가 백엔드 디버그 로그에 접근하지 않고도 드러내야 하는 보이지 않는 실행 순서 의존성을 만듭니다.
거버너 한계에 대한 경계 값 분석, 승인 워크플로우에 대한 상태 전이 테스트 및 가격 계층에 대한 동등 분할을 사용하는 체계적인 방법론입니다. 테스트 담당자는 거버너 한계의 50%, 90%, 100%에서 테스트 데이터 세트를 구성하여 감소 패턴을 관찰해야 합니다. 가격 검증을 위해, 조합 폭발을 최소화하면서 커버리지를 유지하기 위해 할인 차원(볼륨, 기간, 선불)에 대해 쌍을 이루는 테스트를 구현합니다. 승인 워크플로우 테스트는 특정 역할 계층을 가진 사용자 페르소나를 시뮬레이션하는 어두운 테스트와 무한 루프 또는 라우팅 마감이 없도록 하는 상태 머신 검증이 필요합니다. 문서 생성 테스트는 생성된 PDFs와 원본 견적 데이터 간의 시각적 비교 및 체크섬 검증을 통해 필드 매핑 정확성을 검증해야 합니다.
기업 견적 위기
한 포춘 500 제조 회사는 중첩 선택 구성 요소(엔진, 유압, 인증) 및 지역 가격 행렬을 포함한 복잡한 기계 견적을 자동화하기 위해 Salesforce CPQ를 배포했습니다. UAT 중 영업 사원들은 150개 이상의 견적 항목을 초과하는 중장비 구성을 위해 견적을 생성할 때 간헐적인 "Apex CPU 타임아웃" 오류를 보고했으며, 금융 부서는 프로모션 코드와 결합할 때 번들 수준 할인이 두 번 적용되는 중대한 버그를 발견했습니다. 이로 인해 서명된 계약에서 12%의 수익 누수가 발생했습니다.
해결책 1: 점진적 데이터 로딩 전략
한 가지 접근법은 거버너 한계 예외를 유발하는 정확한 임계값을 식별하기 위해 점진적으로 더 큰 견적 항목 수(50, 100, 150, 200)를 포함한 견적을 수동으로 생성하는 것이었습니다. 이 방법은 정확한 한계 식별을 제공했지만 과도한 수동 데이터 입력 시간(시험 주기당 약 4시간)을 요구했고 관련 개체 전반에 걸쳐 복잡한 수식 필드가 재계산될 때 비선형 성능 영향을 고려하지 못했습니다. 팀이 대량 가져오기 작업 중 생산 데이터 볼륨이 지속적으로 이 임계값을 초과할 것이라는 사실을 깨달은 후, 테스트는 3일 후 중단되었습니다.
해결책 2: 프록시 테스트를 통한 자동 거버너 한계 모니터링
팀은 수동 테스트 실행 중 DML 문장 소비를 추적하기 위해 Salesforce 설정 감사 추적 및 디버그 로그 모니터링 도구를 활용하는 방안을 고려했습니다. 이는 SOQL 쿼리 소비 및 DML 행에 대한 정량적 메트릭을 제공했지만 QA 팀이 생산과 유사한 샌드박스 환경에서 부족한 시스템 관리자 권한이 필요했습니다. 게다가 이 접근법은 기술 메트릭에 초점을 맞추어 비즈니스 결과 검증을 놓칠 수 있었으며, 기술 성능을 최적화하면서 잘못된 가격 계산과 같은 기능 결함을 놓칠 수 있었습니다.
해결책 3: 합성 대량 데이터를 통한 경계 값 분석
선택된 방법론은 경계 값 분석과 합성 데이터 생성을 결합하였습니다. QA 팀은 각기 1,999개 (2000 DML 한계 바로 아래), 2,000개 (한계에서) 및 2,001개 (한계를 초과하는) 항목을 포함하는 특수 테스트 계정을 생성했습니다. 가격 검증을 위해, 그들은 서로 다른 제품 카테고리에서 모든 할인 유형(계층형, 선불, 프로모션)을 결합하는 행렬 테스트를 설계했습니다. 그들은 개발자의 도움을 받아 Salesforce의 "Execute Anonymous" Apex 창을 활용하여 이러한 대규모 데이터 세트를 프로그램적으로 생성한 후, 수동으로 견적 수정, 가격 업데이트 및 승인 제출을 실행하여 이러한 중요 경계에서 시스템 동작을 관찰했습니다. 이 접근법은 수동 검증의 제약 속에서 현실적인 볼륨 테스트의 필요성과 균형을 이루어 기술적 실패(거버너 한계 오류)와 기능적 결함(이중 할인)을 동시에 관찰할 수 있게 하였습니다.
결과
이 방법론은 모든 견적 항목 수정을 위해 상위 견적 기록을 재귀적으로 업데이트하는 Apex 트리거에서 심각한 논리 오류를 발견하였고, 쿼리 소비를 94% 감소시켰습니다. 또한, 가격 행렬 테스트는 동시에 세 가지 할인 규칙이 적용될 때 여러 할인 유형에 대한 "스태킹" 알고리즘이 실패하는 버그를 드러냈으며, 이는 연간 약 230만 달러의 수익 손실로 이어질 수 있는 결함이었습니다. 체계적인 접근법은 모든 향후 CPQ 릴리스의 표준으로 채택되어 이후 1년 동안 생산 사건을 78% 감소시켰습니다.
UI에 나타나지 않지만 거버너 한계를 소비하는 "유령" 트리거 실행을 어떻게 테스트합니까?
많은 후보자들이 보이는 UI 검증에만 집중하고 Salesforce가 직접 사용자 행동과 간접 시스템 업데이트(롤업 요약 재계산 등)에서 Apex 트리거를 실행한다는 사실을 무시합니다. 이를 감지하기 위해서는 테스트 담당자가 "Apex Jobs" 큐를 모니터링하고 UI에 오류가 발생하지 않더라도 개발자 콘솔의 "Execution Overview" 탭을 통해 거버너 한계 소비를 관찰해야 합니다. 특히, 테스트 담당자는 기준 작업(단일 견적 항목 저장)을 실행하고 소비된 CPU 시간과 쿼리 행 수를 기록한 다음 목표 작업을 실행하고 차이를 비교해야 합니다. 설명할 수 없는 significant 증가가 발생하면 배경 트리거 논리를 나타냅니다. 또한 테스트는 사용자가 200개의 레코드(최대 목록 보기 크기)를 선택하고 대량 업데이트를 수행하는 "대량화" 시나리오를 포함해야 하며, 이로 인해 트리거가 비효율적인 루프 내에서 실행되는 대신 컬렉션을 효율적으로 처리하도록 해야 합니다.
시간 의존적인 승인 프로세스를 테스트할 올바른 접근법은 무엇입니까?
후보자들은 종종 Salesforce 승인 프로세스의 시간 의존적 행동(48시간 내 응답이 없을 경우 VP로 승격)이 지역 컴퓨터에서의 시스템 시간을 단순히 변경하더라도 가속화될 수 없다는 사실을 놓칩니다. 올바른 방법론은 "설정 -> 프로세스 자동화 -> 시간 기반 워크플로우" 모니터링 페이지를 활용해 예약된 작업이 올바르게 대기되고 있는지 확인한 다음, Salesforce의 "개발자 콘솔 -> Apex 테스트 실행"을 사용하여 Test.setCreatedDate() 메소드를 이용해 프로그래밍적으로 테스트하거나, 시스템 관리자가 유지 관리 창 동안 샌드박스 환경에서 "조직 시간대"를 임시로 수정하도록 요청하는 것입니다. 순수 수동 테스트의 경우, QA 팀은 Flow 인터뷰의 "일시 중지된 인터뷰" 기록을 확인하고 시간 기반 워크플로우 규칙이 "시간 기반 워크플로우" 큐에 정확한 예약 실행 타임스탬프와 함께 나타나는지 확인하여 시간 경과 없이 구성 논리를 검증해야 합니다.
패키지 업그레이드(예: CPQ 버전 업데이트)가 기존 사용자 정의 사항을 손상시키지 않도록 검증하는 방법은 무엇입니까?
이는 "회귀 고고학" 테스트를 요구합니다. 후보자는 관리 패키지 업그레이드 전의 중요 사용자 여정을 기준으로 설정하고 스크린샷, 필드 값 및 승인 프로세스 상태를 캡처해야 합니다. 업그레이드 후에는 동일한 여정을 실행하면서 "가입자 편집" 지점을 별도로 검토하며, 여기서 사용자 정의 Apex 클래스나 트리거가 관리 패키지 객체와 상호 작용합니다. 핵심 기법은 사용자 정의 필드가 표준 객체에서 관리 패키지 논리를 유발하는 "교차 객체" 업데이트를 테스트하는 것입니다. 이는 업그레이드 시 스키마 변경에 가장 취약한 통합 지점입니다. 테스트 담당자는 Salesforce의 "패키지 업그레이드 내역"과 "스키마 빌더"를 활용하여 업그레이드에 의해 추가된 새로운 필드나 검증 규칙을 식별하고, 기존 사용자 정의 워크플로우에 대해 이러한 새로운 제한 사항을 유발할 데이터 시나리오를 체계적으로 테스트해야 합니다.