Salesforce CPQ uygulamaları, basit ürün kataloglarından milyonlarca ürün kombinasyonunu işleyen karmaşık kurumsal teklif motorlarına evrim geçirdi. Erken uygulamalar, UI doğrulamasına odaklanırken, modern B2B satış süreçleri karmaşık fiyatlandırma algoritmalarının, gerçek zamanlı onay orkestrasyonunun ve belge oluşturma iş akışlarının doğrulanmasını gerektiriyor. Bu soru, iç içe geçmiş paketlerdeki fiyatlandırma hatalarının, kritik çeyrek sonu kapanışları sırasında büyük kurumsal tekliflerin bozulmasına neden olduğu üretim olaylarından kaynaklandı.
Kritik zorluk, Salesforce'un çok kiracılı yönetici sınırlarını (özellikle 2000 DML satır sınırı ve 50,000 sorgu satır sınırı) dikkate alarak hiyerarşik veri yapıları arasında durumlu hesaplamaların doğrulanmasında yatıyor. Testçiler, fiyatlandırma yeniden hesaplamalarının ana-çocuk paket ilişkileri aracılığıyla doğru bir şekilde yayıldığını, onay süreçlerinin dinamik kriterlere (indirim yüzdesi, anlaşma boyutu, ürün kategorileri) göre yönlendirildiğini ve sözleşme oluşturmanın otomatik iş akışları aracılığıyla tetiklendiğinde veri tutarlılığını sürdürdüğünü doğrulamalıdır. Ayrıca, Apex tetikleyicilerinin yönetilen paket mantığı ile kesişimi, manuel testçilerin arka uç hata ayıklama günlüklerine erişimi olmadan yüzeye çıkarması gereken görünmeyen yürütme sırası bağımlılıkları yaratır.
Yönetici sınırları için sınır değer analizi, onay iş akışları için durum geçiş testi ve fiyatlandırma katmanları için eşdeğer bölümlendirme uygulayan sistematik bir metodoloji. Testçiler, bozulma desenlerini gözlemlemek için yönetici sınırlarının %50'si, %90'ı ve %100'ü seviyelerinde test veri setleri oluşturmalıdır. Fiyatlandırma doğrulaması için, kombinatoryal patlamayı en aza indirmek için indirim boyutları (hacim, vade, peşin) üzerinden çiftli test uygulayın. Onay iş akışı testi, belirli rol hiyerarşileri ile kullanıcı persona simülasyonu olarak karanlık test gerektirir ve sonsuz döngüler veya yönlendirme çıkmazları olmadığını sağlamak için durum makinesi doğrulaması gerektirir. Belge oluşturma testleri, oluşturulan PDF'lerin kaynak teklif verileri ile karşılaştırılarak alan eşleştirme doğruluğunu görsel karşılaştırma ve kontrol toplamı doğrulaması ile doğrulamalıdır.
Kurumsal Teklif Krizi
Bir Fortune 500 üretim şirketi, iç içe geçmiş isteğe bağlı bileşenleri (motorlar, hidrolikler, sertifikalar) ve bölgesel fiyatlandırma matrislerini içeren karmaşık makineler için otomatik teklif oluşturma amacıyla Salesforce CPQ'yu devreye aldı. UAT sırasında, satış temsilcileri 150 satır öğesini aşan ağır ekipman yapılandırmaları için teklif oluştururken aralıklı "Apex CPU zaman aşımı" hataları bildirdi ve finans, kampanya kodlarıyla birleştirildiğinde paket seviyesindeki indirimlerin iki kez uygulandığı kritik bir hata keşfetti ve bu da imzalı sözleşmelerde %12'lik bir gelir kaybına yol açtı.
Çözüm 1: Artan Veri Yükleme Stratejisi
Bir yaklaşım, yönetici sınırları ihlallerini tespit etmek için giderek daha büyük satır sayıları (50, 100, 150, 200) ile teklifler oluşturarak tam eşiği tanımlamak oldu. Bu yöntem kesin sınır tanımlaması sağladı ancak aşırı manuel veri girişi süresi gerektirdi (her test döngüsü için yaklaşık 4 saat) ve karmaşık formül alanlarının ilgili nesneler arasında yeniden hesaplamalarının doğrusal olmayan performans etkisini hesaba katmadı. Takım, üretim veri hacimlerinin bu eşikleri aşacağının farkına vardığında üç gün sonra testi bırakmak zorunda kaldı.
Çözüm 2: Proxy Testi ile Otomatik Yönetici Sınır İzleme
Ekip, manuel test yürütümü sırasında DML ifadesi tüketimini izlemek için Salesforce Ayar Denetim Kaydı ve Hata Ayıklama Günlüğü izleme araçlarını kullanmayı düşünüyordu. Bu, SOQL sorgu tüketimi ve DML satırları hakkında nicel ölçümler sağlasa da, QA ekibinin üretim benzeri kumanda ortamında eksik olan Sistem Yöneticisi ayrıcalıkları gerektiriyordu. Ayrıca, bu yaklaşım teknik ölçümlere odaklanıyor ve iş sonuçlarının doğrulanmasını potansiyel olarak göz ardı ediyordu, böylece teknik performansı optimize ederken yanlış fiyatlandırma hesaplamaları gibi işlevsel hataları kaçırıyordu.
Çözüm 3: Sentetik Toplu Veri ile Sınır Değer Analizi
Seçilen metodoloji, sınır değer analizini sentetik veri oluşturma ile birleştirdi. QA, tam olarak 1,999 satır öğesi (2000 DML sınırının hemen altında), 2,000 öğe (sınırda) ve 2,001 öğe (sınırı aşan) içeren özel test hesapları oluşturdu. Fiyatlandırma doğrulaması için, farklı ürün kategorileri arasında her indirim türünü (katmanlı, peşin, promosyonel) birleştiren matris testleri tasarladılar. Bu büyük veri setlerini programlı olarak oluşturmak için Salesforce'un "Execute Anonymous" apex penceresini (geliştirici yardımıyla) kullandılar ve ardından teklif değişikliklerini, fiyat güncellemelerini ve onay göndermelerini elle yürütmeyi gözlemlediler. Bu yaklaşım, manuel doğrulamanın kısıtlamaları ile gerçekçi hacim testi ihtiyacı arasında dengeli bir çözüm sağladı, testçilerin hem teknik hataları (idare sınırı hataları) hem de işlevsel kusurları (ikili indirimler) aynı anda gözlemlemesine olanak tanıdı.
Sonuç
Bu metodoloji, bir Apex tetikleyicisinin her satır öğesi değişikliğinde ana teklif kayıtlarını özyinelemeli olarak güncelleyen kritik bir mantık hatasını ortaya çıkardı ve bu da SOQL tüketimini %94 oranında azaltmıştır. Ayrıca, fiyatlandırma matris testi, üçten fazla indirim kuralının aynı anda uygulandığında yığılma algoritmasının başarısız olduğunu ortaya çıkardı; bu da tahmini yıllık 2.3 milyon dolarlık bir gelir kaybına neden olabilecek bir hataydı. Sistematik yaklaşım, tüm gelecekteki CPQ sürümleri için standart olarak kabul edildi ve sonraki yıl içinde üretim olaylarını %78 oranında azalttı.
UI'de görünmeyen ancak yönetici sınırlarını tüketen "hayalet" tetikleyici yürütmelerini nasıl test edersiniz?
Birçok aday, yalnızca görünür UI doğrulamasına odaklanarak, Salesforce'un doğrudan kullanıcı eylemleri ve dolaylı sistem güncellemeleri (toplama özet yeniden hesaplamaları gibi) üzerinde Apex tetikleyicilerini çalıştırdığını göz ardı eder. Bunları tespit etmek için, testçiler "Apex İşleri" kuyruğunu izlemeli ve hata görünmediğinde bile Geliştirici Konsolu'nun "Yürütme Genel Bakış" sekmesi aracılığıyla yönetici sınırı tüketimini gözlemlemelidir. Özellikle, testçiler temel bir işlemi (tek bir teklif satırını kaydetmek) yürütmeli, CPU zamanı ve harcanan sorgu satırlarını not etmeli, ardından hedef işlemi yürütmeli ve farkı karşılaştırmalıdır. Açıklanamayan önemli bir artış, arka plandaki tetikleyici mantığını gösterir. Ayrıca, kullanıcıların 200 kaydı (maksimum liste görünüm boyutu) seçip toplu güncellemeler gerçekleştirdiği "toplulaştırma" senaryolarını içeren testler de yapılmalıdır, böylece tetikleyicilerin toplu işlemlerle verimli bir şekilde başa çıkmasını sağlanmalı, verimsiz döngüler içinde yürütülmeleri engellenmelidir.
Zaman bağımlı onay süreçlerini beklemek yerine nasıl test edersiniz?
Adaylar, zaman bağımlı eylemlere (48 saat içinde yanıt verilmezse VP'ye yükselt) sahip Salesforce onay süreçlerinin, yerel makinelerde sistem zamanını değiştirerek hızlandırılamayacağını çoğunlukla gözden kaçırır. Doğru metodoloji, planlı eylemlerin doğru bir şekilde kuyruklandığını doğrulamak için "Ayarlar -> Süreç Otomasyonu -> Zamanlı İş Akışı" izleme sayfasını kullanmak, ardından Salesforce'un "Geliştirici Konsolu -> Apex Test Yürütme" ile Test.setCreatedDate() yöntemini (programlı test yapılıyorsa) kullanmak veya sistem yöneticilerinden bakım pencereleri sırasında kumanda ortamlarında "Organizasyon Zaman Dilimi"'ni geçici olarak değiştirmelerini istemek gerekir. Tamamen manuel test için, QA, Akış görüşmelerinde "Duraklatılmış Görüşme" kayıtlarını doğrulamalı ve zaman bağımlı iş akışı kurallarının doğru planlanmış yürütme zaman damgaları ile "Zamanlı İş Akışı" kuyruğunda göründüğünü doğrulamalıdır, böylece somut zaman geçişi gerektirmeden yapılandırma mantığını doğrulamalıdır.
Yönetilen paket yükseltmelerinin (örneğin CPQ sürüm güncellemeleri) mevcut özelleştirmeleri bozmadığını nasıl doğrularsınız?
Bu, "gerileme arkeolojisi" testini gerektirir. Adaylar, yönetilen paket yükseltmesinden önce kritik kullanıcı yolculuklarının bir temelini oluşturarak ekran görüntüleri, alan değerleri ve onay süreçlerinin durumlarını yakalamalıdır. Yükseltmeden sonra, aynı yolculukları yürütmeli ve özellikle "abonelik düzenlemesi" noktalarını — yönetilen paket nesneleri ile etkileşime giren özel Apex sınıfları veya tetikleyicilerin olduğu alanlar — test etmelidirler. Anahtar teknik, özel alanların standart nesnelerdeki güncellemeleri tetiklediği "çapraz nesne" güncellemelerini test etmektir, çünkü bu entegrasyon noktaları yükseltmelerde şematik değişikliklere en hassas olanlardır. Testçiler, Salesforce'un "Paket Yükseltme Tarihçesi" ve "Şema Oluşturucu" özelliklerini kullanarak yükseltme ile eklenen yeni alanları veya geçerlilik kurallarını belirlemeli, ardından mevcut özel iş akışlarına karşı bu yeni kısıtlamaları tetikleyen veri senaryolarını sistematik olarak test etmelidir.