Soru Tarihçesi
Fintech uygulamalarının yaygınlaşması ve sıkı düzenleyici gereklilikler ile modern QA ekipleri, kontrol edilemeyen veya tam olarak incelenemeyen siyah kutu üçüncü taraf entegrasyonları ile giderek daha fazla yüzleşmektedir. Bu soru, test uzmanlarının sonunda geçici aksaklıklar veya dış KYC sağlayıcılarında bakım pencereleri olarak kanıtlanan "kritik hataları" araştırmak için günler harcadığı gerçek dünya senaryolarından ortaya çıkmıştır. Bu zorluk, tam yığın görünürlüğe sahip monolitik uygulamalardan, sorumluluk sınırlarının belirsizleştiği dağıtık mimarilere geçişi vurgulamaktadır.
Sorun
Manuel test uzmanlarının üçüncü taraf hizmet günlüklerine, altyapı durumuna veya algoritmik karar verme süreçlerine görünürlüğü yoktur, ancak yine de uygulama işlevselliğini sertifikalandırmak zorundadırlar. Kararsız davranış sergileyen dış hizmetler—stohastik zaman aşımı, tutarsız API yanıt formatları veya olasılıksal red mantığı gibi—hata izleme sistemlerinde yüksek bir yanlış pozitif oranı oluşturur. Bu belirsizlik, paydaşların QA bulgularına olan güvenini erozyona uğratır ve bu da gerçek entegrasyon hatalarını maskeleyerek uygulamanın dengesiz hale getirilmesine yol açabilecek gereksiz kod değişikliklerine neden olabilir.
Çözüm
İstek parmak izi alma, sentetik işlem izleme ve kontrollü test verisi doğrulamasını birleştiren sistematik bir izolasyon protokolü uygulayın. Öncelikle, tüm çıkış isteklerini benzersiz korelasyon kimlikleri ile yakalayarak ve zaman damgası ekleyerek hatalardaki zamansal desenleri belirleyin. İkincisi, bilinen iyi ve kötü kontrol belgeleri kullanarak bir temel oluşturun ve uygulama mantığı ile dış hizmetin değişken faktör olup olmadığını belirleyin. Son olarak, belirleyici yanıtları simüle etmek için proxy araçları veya kumanya ortamları kullanarak, uygulamanın dış dalgalanmalara rağmen başarı ve hata durumlarını doğru bir şekilde işleyip işlemediğini doğrulayın.
Bir dijital cüzdan projesinin son sprintinde, ekip doğrulama akışında mükemmel geçerli devlet tarafından verilmiş ID belgelerinin ara sıra reddedilmesiyle karşılaştı. Dış KYC sağlayıcısının paneli %99,9 çalışma süresi gösterirken, test kayıtlarının yaklaşık %30'u genel "doğrulama reddedildi" mesajlarıyla başarısız oldu. Ürün sahibi acil düzeltmeler talep etti ve sorunun görüntü ön işleme mantığımızda olduğunu varsaydı, oysa dış sağlayıcı AI modellerinin kararlı olduğunu ısrarla savundu.
Bir yaklaşım, ekran görüntüleri ve zaman damgaları ile üçüncü taraf sağlayıcının destek ekibine hemen yükseltmekti. Bu, standart yükseltme protokollerini takip etse de, sağlayıcı genellikle günlükleri incelemek için 48-72 saat gerektiriyordu ve geçmiş deneyimler, kanıt olmadan hatayı nadiren kabul ettiklerini gösterdi. Bu yaklaşım, sorunun kod tabanımızda var olmayabileceği bir problem için serinin geç kalmasına neden olma riskini taşırken, geliştiriciler aslında doğru çalışan görüntü sıkıştırma algoritmalarını izlemek için zaman kaybediyordu.
Başka bir seçenek, KYC yanıtlarını simüle etmek ve işleme mantığımızın sağlam olduğunu kanıtlamak için WireMock kullanarak tam bir sahte sunucu inşa etmekti. Bu, uygulamanın kabul/reddet yanıtlarını doğru bir şekilde işleyip işlemediğini kesin bir şekilde gösterecekti, ancak gerçek dünya entegrasyon sorunlarını—şebeke gecikmesi artışları, SSL sertifika uyumsuzlukları veya sahte ve gerçek hizmet arasındaki ince veri formatı farklılıkları—yakalamakta başarısız olacaktı. Ayrıca, sağlayıcı API şemasını değiştirdiğinde bu sahtenin sürekli güncellemeler gerektirmesi, sprint sırasında ekip tarafından sürdürülemeyen bir bakım yükü oluşturacaktı.
Seçilen çözüm, istek parmak izi almayı ve bir sağlık kontrolü paneli uygulamaktı. Test derlemelerini, milisaniye hassasiyeti ile tam istek yükleri, yanıt süreleri ve HTTP durum kodlarını günlüğe kaydedecek şekilde aletledik. Ardından, başarısızlık zaman damgalarını sağlayıcının resmi durum sayfasıyla (gerçekten belirli bölgelerde ara ara bozulma gösteriyordu) ilişkilendirdik ve %100 geçme garantili belgelerin "kontrol grubu" ile test ettik. Bu, başarısızlıkların belirli zaman dilimlerinde kümelendiğini ve tüm belge türlerini eşit şekilde etkilediğini kanıtladı, bu da dış hizmet istikrarsızlığına kesin olarak işaret etti, uygulama hatalarına değil.
Sonuç, yanlış hata raporlarında %90'lık bir azalma ve test ortamında bir "devre kesici" uyarısının uygulanması oldu. KYC hizmetinin yanıt süresi 2 saniyeyi aştığında veya belirli hata kodları döndüğünde, test panosu artık dış hizmet bozulmasını gösteren sarı bir uyarı pankartı gösteriyordu. Bu, test uzmanlarının çevresel gürültü ile gerçek hataları ayırt etmesine olanak tanıdı ve sürüm, gizemli engeller yerine belgelenmiş bilinen sorunlarla programlandığı gibi ilerledi.
Üçüncü taraf hizmeti her API çağrısı için ücret alırken ve sıkı bir hız sınırlaması varsa test kapsamını nasıl korursunuz?
Çözüm, WireMock veya Postman sahte sunucular gibi araçlar kullanarak kayıt-ve-oynat stratejisini uygulamaktır. Başlangıçtaki "kayıt aşamasında" bir kumanya ortamında, başarı, red ve zaman aşımını içeren çeşitli senaryolar için gerçek yanıtları yakalayın. Sonraki regresyon döngüleri için, uygulama yapılandırmasını sahte sunucunuza işaret edecek şekilde değiştirin ve bu kayıtlı yanıtları belirleyici bir şekilde tekrar oynatın. Bu yaklaşım, yanıt gövdesi ayrıştırılması ve HTTP durum kodlarının işlenmesi gibi entegrasyon mantığı için test kapsamını korurken, maliyetleri ve hız sınırlaması kısıtlamalarını ortadan kaldırır. Başlangıçta kaçırılan önemli detay, gerçek hizmet ile periyodik "canlı ateş" testleri yapmanız gerektiğidir; bu, API sözleşme değişikliklerini tespit etmek için gereklidir ve bunlar, minimum test verisi ile off-peak saatlerde planlanmalıdır.
Kötü test ve kötü bağımlılık arasındaki temel fark nedir ve bu ayrım hata raporlamanızı nasıl değiştirmelidir?
Kötü bir test, yarış koşulları veya yanlış kurulum/temizleme rutinleri gibi deterministik olmayan test kodu nedeniyle tutarsız sonuçlar üretirken, kötü bir bağımlılık tutarsız sonuçlar üretir çünkü dış hizmetin dalgalanmasıdır, tutarlı test girdilerine rağmen. Hata raporlarınızda, dış bağımlılıklar şüpheli olduğunda, her zaman çevresel telemetri ekleyin: korelasyon kimlikleri, kesin zaman damgaları ile zaman dilimi, yanıt gecikmesi ölçümleri ve gönderilen veri yükleri. Başlangıç seviyesindeki kişiler genellikle "KYC kontrolü bazen başarısız oluyor" gibi belirsiz raporlar yazarlar, bu da geliştiricilerin tahmin yapmasına zorlar. Bunun yerine, başarısızlıkların sağlayıcının bakım pencereleri ile ilişkilendirildiğini veya belirli yük eşiklerinde meydana geldiğini gösteren bir zaman serisi analizi sağlayın ve QA'nın araştırma titizliğini belgeleyin ve mühendislik saatlerini tasarruf edin.
Üçüncü taraf hizmeti stabil ve tahmin edilebilir olduğunda zaman aşımı ve hatalı yanıtlar gibi kenar durumlarını nasıl test edersiniz?
Uygulamanız ile dış hizmet arasında trafiği manuel olarak değiştirmek için Fiddler veya Charles Proxy gibi proxy kesme araçları kullanın. İstek başarılı olduktan sonra yanıtı yakalamak için bir durak noktası yapılandırın, ardından hatalı verileri eklemek, yanıt gecikmesini artırmak veya HTTP 500 hatalarını simüle etmek için JSON'u manuel olarak düzenleyin. Özellikle zaman aşımı testi için, ağları yavaş simüle etmek veya uygulamanın zaman aşımı eşiklerini aşan yapay gecikmeler eklemek için Charles Proxy'nin yavaşlatma özelliklerini kullanın. Adayların gözden kaçırdığı kritik teknik, uygulamanızın yeniden deneme mantığı ve devre kesicilerin doğru bir şekilde aktive olduğunu doğrulamaktır—sadece mutlu yolu test etmek yetersizdir. Kullanılan tam proxy ayarlarını ve yanıt modifikasyonlarını belgeleyin, böylece geliştiriciler karmaşık proxy yapılandırmasını anlamak zorunda kalmadan senaryoyu yeniden üretirler.