Production-dan əvvəl inteqrasiya test checklisti

Qısa cavab

Production-a çıxmazdan əvvəl inteqrasiya səkkiz qrup test keçməlidir: funksional ssenarilər, data və formatlar, xəta halları, dublikat və təkrar göndəriş, həcm və limitlər, təhlükəsizlik, monitorinq və bildirişlər, geri çəkilmə. Hər test üçün gözlənilən nəticə əvvəlcədən yazılır, nəticə isə «keçdi / keçmədi / tətbiq olunmur» kimi qeyd olunur. Biznes sahibi və texniki sahib son nəticəni yazılı təsdiqləyir. Çatbotun dialoqlarını test etmək ayrıca işdir; bu checklist sistemlər arasındakı məlumat axınının özünü yoxlayır.

Niyə checklist lazımdır

İnteqrasiya testləri çox vaxt «işləyir» təsdiqi ilə bitir: developer bir test lead göndərir, CRM-də görür və iş bitmiş sayılır. Problemlər isə canlıda çıxır: adında «ə» hərfi olan müştərinin adı simvollara çevrilir, gecə gələn lead-in tarixi bir gün sürüşür, CRM yenilənəndə lead-lər itir. Bunların heç biri «xoşbəxt yol» testində görünmür.

Checklist testi ağıla gələnlə yox, yazılı siyahı ilə aparmağa məcbur edir və «biz bunu yoxlamışdıqmı?» sualına sonradan cavab verir.

1. Funksional ssenarilər

• Hər biznes ssenarisinin normal halı: lead yaranır, düzgün sahələrlə, düzgün menecerə təyin olunur.
• Alternativ hallar: müştəri artıq mövcuddur, nömrə yoxdur, iki niyyətli müraciət.
• Status dəyişikliyi hər iki istiqamətdə gözlənildiyi kimi gedir.
• Gözlənilən gecikmə: hadisə hədəf sistemdə razılaşdırılmış müddət ərzində görünür.

2. Data və formatlar

• Azərbaycan hərfləri — ə, ş, ç, ğ, ı, ö, ü — ad, ünvan və qeydlərdə düzgün qalır.
• Kiril və latın qarışıq mətn, emoji və uzun mesajlar.
• Telefon formatları: 055…, +99455…, boşluqlu və mötərizəli yazılışlar.
• Tarix və saat: gecə yarısına yaxın hadisə, saat qurşağı fərqi.
• Boş sahələr: mənbədə boş olan sahə hədəfdə düzgün dəyəri silmir.
• Uzun mətn: hədəf sahənin limitindən uzun xülasə kəsilirmi və necə.

Sahə xəritəsinin necə yazıldığını CRM data mapping checklisti yazısında göstərmişik.

3. Xəta halları

• Hədəf sistem cavab vermir: sorğu itmir, təkrar cəhd edilir.
• Vaxt aşımı: təkrar cəhd ikinci qeyd yaratmır.
• Açar səhvdir və ya müddəti bitib: dərhal bildiriş gəlir.
• Məlumat yoxlamadan keçmir (məsələn, məcburi sahə boşdur): sorğu növbəyə düşür və insan görür.
• Limit aşılır (429): sistem gözləyir və sonra davam edir.

Bu davranışların qaydalarını API xətaları və retry qaydaları yazısında izah etmişik.

4. Dublikat və təkrar göndəriş

• Eyni hadisə iki dəfə göndərilir — hədəfdə bir qeyd qalır.
• Eyni müştəri iki kanaldan gəlir — qayda gözlənildiyi kimi işləyir.
• İki tərəfli sinxronizasiyada dəyişiklik geri qayıdıb sonsuz dövrə yaratmır.
• Paralel iki sorğu eyni qeydi yaratmağa çalışır — biri qalır.

Texniki dublikatların səbəblərini sistemlər arasında dublikat məlumat yazısında izah etmişik.

5. Həcm və limitlər

Gözlənilən gündəlik həcmin bir neçə qatı ilə qısa test aparın — məsələn, kampaniya gününü təqlid edərək. Baxılacaq şeylər: gecikmə artırmı, sorğular itirmi, qarşı tərəfin limitinə çatılırmı, növbə nə qədər tez boşalır. Bu test test mühitində aparılır, canlı sistemin qarşısında yox.

6. Təhlükəsizlik

• Test və canlı açarlar ayrıdır, açarlar kodda deyil.
• İnteqrasiya hesabının yalnız lazım olan icazələri var.
• Webhook ünvanı imza və ya açar olmadan sorğu qəbul etmir.
• Jurnalda lazımsız şəxsi məlumat yoxdur.
• AI aləti yalnız icazə verilmiş ünvanlara müraciət edir.

7. Monitorinq və bildirişlər

Production-a çıxmazdan əvvəl bildirişlərin özü test olunur: süni xəta yaradın və bildirişin düzgün adama, düzgün kanalda gəldiyini yoxlayın. Monitorinq paneli və ya hesabat inteqrasiyanın vəziyyətini göstərməlidir: son uğurlu göndəriş nə vaxt olub, növbədə neçə sorğu var, son bir saatda neçə xəta olub.

8. Geri çəkilmə

Ən çox unudulan test: inteqrasiyanı söndürmək necə olur? Geri çəkilmə planı test olunmalıdır — inteqrasiya bir düymə və ya bir ayar ilə dayandırılır, bu müddətdə məlumat itmir (növbədə qalır və ya əl ilə işlənir), sonra yenidən açılanda növbə düzgün işlənir. Test olunmamış geri çəkilmə planı qəza zamanı işləməyə bilər.

Nəticəni necə qeyd etmək

1. 1TestNə yoxlanılır, hansı data ilə.
2. 2Gözlənilən nəticəƏvvəlcədən yazılır, testdən sonra yox.
3. 3Faktiki nəticəKeçdi, keçmədi, tətbiq olunmur — sübut ilə (ekran görüntüsü, jurnal qeydi).
4. 4QərarKeçməyən test üçün: düzəliş, risk qəbulu (səbəbi ilə) və ya canlıya çıxışın təxirə salınması.
5. 5İmzaBiznes və texniki sahiblərin yazılı təsdiqi.

İllüstrativ nümunə

Bu, illüstrativ nümunədir. Sığorta agentliyinin çatdan CRM-ə inteqrasiyası funksional testləri keçir. Data qrupunda isə iki problem çıxır: «Şəmsiyyə» adı CRM-də hərfləri pozulmuş halda görünür, gecə 23:50-də yaranan lead-in tarixi ertəsi günə düşür. Geri çəkilmə testində məlum olur ki, inteqrasiyanı söndürmək üçün developer lazımdır.

Üç düzəliş edilir: kodlaşdırma, saat qurşağı və paneldə inteqrasiyanı dayandırma ayarı. Yalnız bundan sonra checklist imzalanır və canlıya çıxılır.

Tipik səhvlər

• Yalnız bir «xoşbəxt yol» testi.
• Gözlənilən nəticəni testdən sonra yazmaq.
• Azərbaycan hərflərini və saat qurşağını yoxlamamaq.
• Bildirişləri test etməmək.
• Geri çəkilmə planını test etməmək.

Məhdudiyyətlər

Ən dolğun checklist də canlının bütün hallarını əhatə etmir. Ona görə canlıya çıxışdan sonra ilk həftə gücləndirilmiş monitorinq və gündəlik nümunə yoxlaması lazımdır. Test mühiti canlıdan fərqlidirsə, test nəticəsi də fərqli ola bilər — test mühitinin necə qurulduğunu sandbox və test mühiti yazısında izah etmişik.

Vexvon ilə inteqrasiyada

Vexvon ilə inteqrasiyada kanallar canlıya keçməzdən əvvəl test söhbətləri ilə yoxlanılır, sayt widget-inin test söhbətləri hesabatlara düşmür, zəng marşrutu isə simulyasiya ilə sınanır. Webhook və şirkət API-ləri üçün test checklistini — hansı ssenarilər, hansı xəta halları və qəbul meyarları — inteqrasiya planında birlikdə yazırıq. Ətraflı: inteqrasiyalar.

Növbəti addım

Növbəti inteqrasiyanız üçün səkkiz qrupu cədvələ köçürün və hər qrupa ən azı iki test yazın, gözlənilən nəticə ilə birlikdə. Çatbot dialoqlarının testini isə çatbot test siyahısı yazısında ayrıca izah etmişik. Digər yazılar enterprise inteqrasiya bölməsindədir; checklistinizi demo zamanı birlikdə nəzərdən keçirə bilərik.