FinTech trading platform testing üçün əsas sual “əməliyyat uğurlu oldumu?” deyil, “şəbəkə, provayder və ya proses uğursuz olsa belə, sistem maliyyə baxımından düzgün vəziyyətdə qalacaqmı?” sualıdır. Order, ödəniş, depozit, pul çıxarışı və ya mövqe dəyişikliyi yalnız bir API cavabı deyil: istifadəçi interfeysi, daxili xidmətlər, verilənlər bazası, broker və ya payment provider, market-data axını və back-office arasında gedən çoxmərhələli prosesdir.
Happy path testləri vacibdir, amma ən bahalı insidentlər adətən sərhədlərdə yaranır: istifadəçi düyməni iki dəfə basır, mobil tətbiq timeout-dan sonra yenidən göndərir, provider cavabı gecikir, webhook iki dəfə gəlir və ya sistem gecə yarısı UTC ilə lokal biznes günü arasında keçid edir. Buna görə maliyyə proqram təminatının QA planı idempotentlik, vəziyyət keçidləri, uzlaşdırma, müşahidəolunma və geri dönüş prosedurlarını birlikdə yoxlamalıdır.
POLADO-nun FinTech və trading sistemləri xidməti bu tip inteqrasiya və əməliyyat axınlarının layihələndirilməsi üçün nəzərdə tutulur. Mövcud məhsulda riskli sərhədləri və reliz boşluqlarını qiymətləndirmək üçün texniki dəstək və konsaltinq çərçivəsində audit də həyata keçirmək olar.
Əvvəlcə əməliyyatı və texniki cəhdi ayırın
İdempotent test dizaynının ən vacib prinsipi biznes əməliyyatını onun şəbəkə cəhdlərindən ayırmaqdır. Məsələn, istifadəçinin “10 000 USD depozit et” niyyəti bir biznes əməliyyatıdır. Həmin niyyət timeout, tətbiqin yenidən açılması və ya worker retry səbəbindən üç HTTP sorğusu yarada bilər. Sistemdə bu üç sorğu üç depozit kimi yox, eyni əməliyyatın cəhdləri kimi görünməlidir.
Hər yüksək riskli əməliyyat üçün saxlanılan minimum məlumatı əvvəlcədən müəyyən edin:
- müştəri və ya hesab identifikatoru;
- dəyişməyən əməliyyat identifikatoru və idempotency key;
- məbləğ, valyuta, alət, tərəf, məqsəd və sorğunun normalizasiya olunmuş parametrləri;
- yaradılma vaxtı, biznes vaxtı və mənbə vaxt zonası;
- daxili və xarici istinad identifikatorları;
- hazırkı status, status tarixi və rədd/istisna səbəbi;
- hansı addımın geri qaytarıla, hansının yalnız kompensasiya edilə bildiyi.
İdempotency key təkbaşına kifayət deyil. Eyni açarla başqa məbləğ və ya başqa instrument göndərilərsə, sistem bunu səssiz şəkildə əvvəlki nəticə kimi qaytarmamalıdır. Key, əməliyyatın kanonik parametrlərinə və uyğun scope-a bağlı olmalıdır: məsələn, hesab + əməliyyat növü + açar. Paralel sorğular üçün də unikal indeks və ya atomik “create-or-return” məntiqi lazımdır; əks halda iki worker eyni anda iki yazı yarada bilər.
İdempotentlik testləri: retry uğursuzluq demək deyil
Trading platform QA testing-də retry ssenarisi mütləq mənfi test deyil; o, normal paylanmış sistem davranışıdır. Sorğu göndərilib, amma cavab istifadəçiyə çatmayıbsa, klient əməliyyatın icra olunmadığını bilməyə bilər. Provider də cavabı verməzdən əvvəl əməliyyatı təsdiqləmiş ola bilər. Test komandasının məqsədi “retry bloklandı” demək yox, retry zamanı biznes nəticəsinin bir dəfə yaranmasını sübut etməkdir.
Əsas idempotentlik sınaqları
- Eyni sorğu, eyni açar: paralel və ardıcıl olaraq iki, sonra on sorğu göndərin. Bir maliyyə əməliyyatı, bir xarici submission və proqnozlaşdırıla bilən cavab gözlənilməlidir.
- Cavabdan sonra retry: server əməliyyatı tamamlayır, lakin cavab bağlantısı kəsilir. Yenidən cəhd əvvəlki əməliyyatın vəziyyətini qaytarmalıdır.
- Provider qəbul edir, tətbiq timeout görür: daxili sistem “naməlum” və ya “pending confirmation” vəziyyətinə keçir, avtomatik ikinci debit və ya order yaratmır.
- Eyni açar, fərqli payload: məbləğ, valyuta və ya quantity dəyişdirilərsə, açıq konflikt xətası yaranmalıdır.
- Gecikmiş və təkrarlanan callback: webhook-lar fərqli sıra ilə, iki dəfə və ya günlər sonra gəldikdə vəziyyət maşını geri getməməlidir.
- Worker restart: retry edən proses restart olduqda açar, cəhd sayğacı və xarici istinad itirilməməlidir.
FIX və ya broker inteqrasiyalarında transport səviyyəsində sequence number bərpası tətbiq səviyyəsində order deduplication-un əvəzi deyil. Tətbiq hər bir order intent, client order ID və execution report üçün ayrıca biznes qaydasını yoxlamalıdır. Xüsusilə resend edilmiş mesaj köhnəlmiş qiymət və ya dəyişmiş bazar vəziyyəti ilə artıq qəbulolunmaz ola bilər.
Uzlaşdırma: daxili statusa deyil, sübuta əsaslanın
Payment and transaction reconciliation testing daxili verilənlər bazasındakı “completed” statusunun provayder, broker, bank çıxarışı və ya clearing məlumatı ilə uyğun olduğunu təsdiqləyir. Bu, sadə record-count müqayisəsi deyil. Eyni əməliyyatı fərqli sistemlər fərqli vaxtda, fərqli identifikatorla və fərqli yekunluq səviyyəsində görə bilər.
Praktik olaraq üç görünüşü müqayisə edin: məhsulun əməliyyat reyestri, dəyişməyən daxili ledger/jurnal və xarici providerin export-u və ya API nəticəsi. Hər sətr üçün uyğunlaşdırma qaydası əvvəlcədən yazılmalıdır: primary external reference, məbləğ və valyuta, hesab, əməliyyat növü, event time və qəbul edilən gecikmə pəncərəsi.
Uzlaşdırma testlərində axtarılan fərqlər
- daxildə tamamlanmış, xaricdə tapılmayan əməliyyat;
- xaricdə uğurlu, daxildə pending və ya failed qalan əməliyyat;
- eyni external reference ilə iki daxili yazı;
- valyuta çevirməsi, komissiya, rounding və ya net/gross məbləğ fərqi;
- qismən icra edilmiş order və ya qismən settlement;
- gözlənilən gecikmə pəncərəsindən sonra hələ də açıq qalan əməliyyat;
- əl ilə müdaxilə nəticəsində audit izi olmayan düzəliş.
Test data-set yalnız tam uğurlu nümunələrdən ibarət olmamalıdır. Onun içində orphan callback, duplicate provider record, reversed transaction, partial fill, manual correction və bir neçə gün gecikən settlement olmalıdır. Sınaqdan alınan fərqlər avtomatik “fix” edilməməli, əvvəlcə exception queue-ya düşməli, sahib, prioritet, sübut və qərar tarixi almalıdır.
Bazar məlumatı və account-state üçün failure ssenariləri
Trading məhsullarında qiymət düzgün görünsə də, qərar vaxtında düzgün olmaya bilər. Hər quote və ya candle üçün source timestamp, receive timestamp, instrument mapping və feed status görünməlidir. Testlərdə köhnə price, boş interval, sequence gap, bir providerin gecikməsi və iki provider arasında fərqli qiymət verin. Sonra sistemin davranışını yoxlayın: istifadəçiyə stale xəbərdarlığı göstərirmi, order qəbulunu məhdudlaşdırırmı, yoxsa köhnə məlumatla səssiz şəkildə riskli hesablayır?
Hesab vəziyyəti də order göndərilən anla icra alınan an arasında dəyişə bilər. KYC statusunun məhdudlaşması, margin-in azalması, leverage limitinin yenilənməsi, hesabın dondurulması və ya istifadəçi sessiyasının ləğvi kimi halları sınaqdan keçirin. Server orderi qəbul etməzdən əvvəl, submission-dan dərhal əvvəl və execution report gələndə hansı yoxlamanın aparıldığını açıq şəkildə müəyyən edin. Hər status keçidi audit jurnalında səbəb və actor ilə saxlanmalıdır.
Market-data etibarlılığı ilə bağlı daha dərin arxitektura məsələləri üçün ESFX layihəsi kimi maliyyə analitikası nümunələrinə baxmaq faydalıdır.
Qismən uğursuzluqlar və kompensasiya məntiqi
Bir əməliyyatın bütün addımlarını tək verilənlər bazası transaction-u daxilində saxlamaq çox vaxt mümkün deyil: provider API-si, message queue və bank/broker sistemi sizin transaction sərhədinizdən kənardadır. Buna görə “provider çağırışı uğurlu oldu, amma daxili status yazılmadı” və əks ssenarilər ayrıca test edilməlidir.
Bu axınları aydın status maşını ilə qurun: məsələn, created → validated → submitted → acknowledged → partially_filled/settled → completed; alternativ qollar isə rejected, expired, cancelled, reversal_pending, reconciliation_required ola bilər. “Unknown” statusu uğursuz dizayn deyil; məlumat yetərsizdirsə, yanlış “failed” və ya “completed” yazmaqdan daha dürüstdür. Unknown vəziyyətində sistem təhlükəsiz retry siyasəti, status sorğusu, uzlaşdırma işi və lazım olduqda operator eskalasiyası tətbiq etməlidir.
Transactional outbox pattern-i ilə daxili status dəyişikliyi və göndərilməli event eyni lokal transaction-da yazıla bilər. Amma outbox consumer-inin ən azı bir dəfə işləməsi yenə duplicate event yarada bilər. Buna görə consumer-lər də idempotent olmalı, event ID-ni emal reyestrində saxlamalıdır.
Test mühiti: real riskləri təhlükəsiz simulyasiya edin
Sandbox-un mövcudluğu test mühitinin yetərli olması demək deyil. Provider sandbox bəzən production-dakı latency, rate limit, callback davranışı, settlement gecikməsi və ya səhv kodlarını tam təkrarlamır. Müqavilə və inteqrasiya sərhədlərində kontrollu simulator və fault injection qatına ehtiyac olur.
- provider cavabını gecikdirin, kəsin, 429 və 5xx qaytarın;
- callback-ləri təkrarlayın, sıralamanı dəyişin və signature yoxlamasını pozun;
- queue mesajlarını iki dəfə çatdırın və consumer restart edin;
- database write-dan sonra process-i dayandırın;
- UTC gün dəyişimi, DST keçidi və ay sonu üzrə test edin;
- real müştəri məlumatı əvəzinə maskalanmış və ya sintetik data istifadə edin;
- test hesabları, test instrument-ləri və test provider tenant-ləri üçün aydın təmizləmə planı saxlayın.
Observability və reliz qapıları
Financial software QA yalnız test nəticəsi deyil, production-da sübut toplamaq qabiliyyətidir. Hər əməliyyat üçün correlation ID, idempotency key, daxili ID, provider reference, status keçidi, latency və retry səbəbi axtarıla bilən olmalıdır. Metriklərdə isə duplicate prevention sayı, pending yaşlanması, callback gecikməsi, reconciliation break sayı və məbləği, retry nisbəti, provider üzrə xəta faizi və stale-price hadisələri izlənməlidir. Məbləğləri lazımsız şəkildə log-lamaq və ya həssas məlumatı tracing sisteminə daşımaq olmaz; observability dizaynı privacy və giriş nəzarəti ilə birlikdə qurulmalıdır.
Relizə keçid üçün ölçülə bilən qapılar təyin edin: kritik axınların contract və failure ssenariləri keçibmi, replay testində duplicate yaranmayıbmı, uzlaşdırma fərqləri izah edilirmi, dashboard və alert-lər işləyirmi, rollback sahibinin və qərar meyarının adı bəllidirmi? Rollback həmişə kodun əvvəlki versiyasına qayıtmaq deyil. Schema migration, artıq göndərilmiş əməliyyat və ya providerə yayılan konfiqurasiya üçün forward fix, feature flag, submission pause və kompensasiya prosesi daha təhlükəsiz seçim ola bilər.
Relizdən əvvəl qısa yoxlama siyahısı
- Hər pul və order əməliyyatının biznes identifikatoru və idempotency qaydası varmı?
- Timeout-dan sonra retry eyni biznes nəticəsini qaytarırmı?
- Gecikmiş, təkrarlanan və sırası dəyişmiş callback-lər təhlükəsiz emal olunurmu?
- Daxili jurnal, əməliyyat reyestri və xarici provider məlumatı uzlaşdırılırmı?
- Partial fill, reversal, rejected və unknown vəziyyətləri istifadəçi və operator üçün aydındırmı?
- UTC, lokal vaxt zonası, DST və gün sonu sərhədləri sınaqdan keçirilibmi?
- Əməliyyatın bütün addımlarını correlation ID ilə izləmək mümkündürmü?
- Reliz dayandırma, rollback və incident eskalasiyası üçün real prosedur varmı?
Bu yoxlama siyahısı error-free maliyyə sistemi vəd etmir. Onun məqsədi gözlənilən uğursuzluqları nəzarətli, izah oluna bilən və uzlaşdırıla bilən vəziyyətlərə çevirməkdir. Trading, payments və ya maliyyə analitikası məhsulunuz üçün test arxitekturası, inteqrasiya audit-i və təhlükəsiz reliz planı lazımdırsa, POLADO ilə texniki konsultasiya planlaşdırın.