Reqresiya — bu nədir, niyə yaranır və necə test etməli

İnkişafda reqresiya nədir

Reqresiya — əvvəlki versiyada işləyən funksionallığın dəyişiklik edildikdən sonra işləməməsi vəziyyətidir. Dəyişiklik hər hansı ola bilər: səhvin düzəldilməsi, yeni funksiyanın əlavə edilməsi, refaktorinq, kitabxananın yenilənməsi və ya hətta konfiqurasiyanın dəyişdirilməsi. Reqresiya sabitliyin əsas düşmənidir: hər dəyişiklik artıq yoxlanılmış və buraxılmış bir şeyi pozmaq riski daşıyır.

Termin test sahəsindən gəlir: reqresiya testi — hər dəyişiklikdən sonra mövcud testlərin təkrar icrasıdır. Əgər əvvəllər keçən test uğursuz olarsa — bu reqresiya deməkdir. Geniş mənada reqresiya təkcə testin uğursuzluğu deyil, həm də istifadəçi və ya QA tərəfindən aşkarlanan hər hansı davranış pisləşməsidir. Tricentis State of Testing 2023 məlumatlarına görə, reqresiyalar istehsalatda tapılan bütün səhvlərin 35–45%-ni təşkil edir.

Adi səhvdən reqresiya zaman konteksti ilə fərqlənir: səhv həmişə mövcud ola bilərdi, reqresiya isə həmişə dəyişikliyin nəticəsidir. Bu vacib fərqdir, çünki reqresiyanın səbəbini axtarmaq dəyişikliklərin təhlili ilə başlayır: “işləyirdi” ilə “işləməyi dayandırdı” arasında nə dəyişdirildi. Git bisect — reqresiyaya səbəb olan commit-i tapmaq üçün standart vasitə.

Reqresiya növləri və nümunələr

Yerli reqresiya — A modulundakı dəyişiklik eyni A modulunda funksionallığı pozur. Nümunə: proqramçı sıralama funksiyasını yenidən yazır və o, boş massivi düzgün emal etməyi dayandırır. Yerli reqresiya aşkarlamaq və düzəltmək üçün ən asandır, çünki səbəb və nəticə yaxındır.

Uzaq reqresiya — A modulundakı dəyişiklik birbaşa kodla bağlı olmayan, lakin məlumat və ya zamanla bağlı olan B modulunda funksionallığı pozur. Nümunə: “İstifadəçilər” modulunda verilənlər bazası sxeminin dəyişdirilməsi eyni cədvəldən istifadə edən “Analitika” modulunda hesabatı pozur. Uzaq reqresiyalar ən məkrlidir: proqramçı onun dəyişikliyinin başqa modula təsir edəcəyini güman etmir.

Yan təsir reqresiyası — yan təsirin dəyişdirilməsi (loglama, keşləmə, bildiriş göndərmə) gözlənilən davranışı pozur. Nümunə: proqramçı işi sürətləndirmək üçün keşləmə əlavə etdi, lakin köhnəlmiş keş səbəbindən istifadəçilər köhnəlmiş məlumatları görür. Yan təsir reqresiyalarını avtomatik testlərlə yaxalamaq çətindir, çünki yan təsirlər çox vaxt testlərlə əhatə olunmur.

Performans reqresiyası — kod funksional olaraq düzgün işləməyə davam edir, lakin əvvəlkindən daha yavaşdır. Nümunə: yeni şifrələmə alqoritmi eyni nəticələri verir, lakin icra müddəti 2 ms-dən 200 ms-ə yüksəldi. Performans reqresiyaları adi vahid testləri ilə aşkarlanmır — benchmark və profilinq tələb olunur.

Reqresiyalar niyə yaranır

Birinci səbəb — kodun bağlılığı (coupling). Modullar bir-birindən nə qədər çox asılıdırsa, birindəki dəyişikliyin digərində reqresiyaya səbəb olma ehtimalı bir o qədər yüksəkdir. Klassik anti-nümunələr: God Object (hər şeyi edən obyekt), Shotgun Surgery (birinin dəyişməsi onlarca yerdə düzəliş tələb edir), Circular Dependency. Coupling-in azaldılması — memarlığın vəzifəsidir: SOLID prinsipləri, Dependency Injection, heksagonal memarlıq.

İkinci səbəb — dəyişdirilən funksionallıq üçün testlərin olmaması. Kod testlərlə əhatə olunmayıbsa, proqramçı reqresiya haqqında yalnız QA və ya istifadəçilərdən öyrənir. Google Testing Blog məlumatlarına görə, test əhatəsi >75% olan layihələrdə reqresiyalar əhatəsi <25% olan layihələrlə müqayisədə 5 dəfə azdır. TDD (Test-Driven Development) testlərin koddan əvvəl yazılmasını təmin edir, “zaman olanda” yox.

Üçüncü səbəb — insan faktoru. Proqramçı qonşu funksionallığın mövcudluğundan xəbərsizdir, bütün asılılıqları başa düşmür və ya sadəcə tələsir. Səbəb — qeyri-kafi kod bazası bilik paylaşımı. Həll yolları: digər modulların proqramçılarının iştirakı ilə code review, pair programming, memarlıq sənədləri. Layihənin Bus faktoru sənədləşdirilmiş memarlıq qərarlarının sayı ilə tərs mütənasibdir.

Reqresiya testi və onun rolu

Reqresiya testi — köhnə funksionallığın pozulub-pozulmadığını yoxlamaq üçün hər dəyişiklikdən sonra mövcud testlərin təkrar icrası prosesidir. Bu, yeni dəyişikliyin mövcud kodun işini pozmadığına zəmanət verməyin yeganə yoludur. Reqresiya testi olmadan hər buraxılış lotereyadır: proqramçı heç nəyi pozmadığına ümid edir, lakin bunu təsdiqləyə bilməz.

Əl ilə reqresiya testi — ən bahalı və səmərəsiz yanaşmadır. Layihə böyüdükcə reqresiya test ssenarilərinin sayı xətti, onların əl ilə icra müddəti isə eksponensial olaraq artır. 2–3 illik inkişafdan sonra reqresiyanın əl ilə icrası 2–3 həftə çəkə bilər ki, bu da tez-tez buraxılışları qeyri-mümkün edir. Yeganə çıxış yolu avtomatlaşdırmadır.

Avtomatlaşdırılmış reqresiya testi test piramidasına görə səviyyələrə bölünür:

• Vahid testləri — sürətli, təcrid olunmuş, ayrı-ayrı funksiya və metodları əhatə edir
• İnteqrasiya testləri — modullar, VB, xarici xidmətlər arasında qarşılıqlı əlaqəni yoxlayır
• E2E testləri — UI və ya API vasitəsilə tam istifadəçi ssenarilərini yoxlayır
• Snapshot testləri — komponentin cari çıxışını etalonla müqayisə edir

Google Testing Blog məlumatlarına görə, optimal nisbət: 70% vahid testləri, 20% inteqrasiya, 10% E2E. Bu nisbətdən kənarlaşma reqresiya testinin effektivliyini azaldır: E2E testlərinin çoxluğu pipeline-i yavaşladır, vahid testlərinin çatışmazlığı mikro-səhvləri nəzərdən qaçırır.

Reqresiya testinin avtomatlaşdırma strategiyaları

Birinci strategiya — Full Regression. Layihənin bütün testləri işə salınır. Ən etibarlı, lakin ən yavaş yanaşma. Kiçik layihələr üçün uyğundur (10 000 testə qədər, icra müddəti <30 dəqiqə). Böyük layihələr üçün tam reqresiya saatlarla çəkə bilər ki, bu da CI/CD pipeline-ini qeyri-praktik edir.

İkinci strategiya — Selective Regression. Yalnız dəyişdirilmiş kodla əlaqəli testlər işə salınır. Əlaqələri müəyyən etmək üçün kodun asılılıq qrafından istifadə olunur. Alətlər: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression icra müddətinin 60–80%-nə qənaət edir, lakin dəqiq asılılıq qrafının qurulmasını tələb edir — səhvlər buraxılmış reqresiyalara səbəb olur.

Üçüncü strategiya — Prioritized Regression. Bütün testlər prioritetə görə sıralanır: critical path (ən vacib istifadəçi ssenariləri), high risk (səhv tarixçəsi olan kod), changed code (dəyişiklikdən təsirlənən kod). Əvvəlcə ən prioritet testlər işə salınır — keçərsə, proqramçı sürətli rəy alır. Vaxt məhdudiyyətli icra: 10 dəqiqə ərzində kritik testlər yoxlanılır, qalanları — fonda.

Layihədə reqresiyaların qarşısını necə almaq olar

Birinci və ən vacib addım — test yazmaq mədəniyyəti. Hər dəyişiklik dəyişikliyin işlədiyini yoxlayan test və heç nəyin pozulmadığını yoxlayan test ilə müşayiət olunmalıdır. TDD (Test-Driven Development) ən yaxşı nəticələri verir: proqramçı əvvəlcə uğursuz test, sonra onu keçən kod yazır. Bu, testin koddan əvvəl mövcud olmasını təmin edir.

İkinci addım — testlərin məcburi icrası ilə CI/CD pipeline-i. Bütün testlər keçməyənə qədər Pull request birləşdirilə bilməz. Təciliyə görə testləri “atlamaq” olmaz — təcili dəyişikliklər sürətləndirilmiş, lakin məcburi test dəstindən keçir. Google DevOps Research məlumatlarına görə, məcburi CI/CD olan komandaların istehsalatda reqresiyaları 3 dəfə azdır.

Üçüncü addım — istehsalatda monitorinq. Hətta ən yaxşı testlər reqresiyalardan 100% qorunmağa zəmanət vermir. Observability alətləri (Sentry, Datadog, New Relic) hər yerləşdirmədən sonra əsas metrikaları izləməlidir: error rate, latency, throughput. Həddi aşdıqda avtomatik geri qaytarma (rollback) — reqresiya istehsalata düşərsə təhlükəsizlik yastığıdır.

Dördüncü addım — reqresiya düşüncəsi ilə code review. Rəyçi sual verməlidir: “Bu dəyişiklikdən hansı digər modullar poza bilər?”. Kodun düzgün olduğunu yoxlamaq kifayət deyil — onun qonşu funksionallığı pozmadığını yoxlamaq lazımdır. Code review üçün yoxlama siyahısı “qonşu modullarda reqresiyaların yoxlanılması” bəndini ehtiva etməlidir.