Sparround

Risk əsaslı testing və prioritetləşdirmə

Testing-in ikinci prinsipi deyir ki, hər şeyi test etmək mümkün deyil. Onda əsas sual belə olur: məhdud vaxtda nəyi test etmək ən çox dəyər verir? Cavab risk əsaslı testing-dir.

Risk = Ehtimal × Təsir

  • Ehtimal (probability) — burada defekt olma şansı nə qədərdir? Kod nə qədər mürəkkəbdir, təzə dəyişilib, yeni developer yazıb, tarixən neçə bug verib.
  • Təsir (impact) — defekt baş verərsə biznes nə itirir? Pul, müştəri, reputasiya, tənzimləyici cərimə, data itkisi.

Bu ikisi ayrı-ayrı ölçülür və bir-birini əvəz etmir: nadir baş verən, amma pul itirən defekt (məs. ikiqat ödəniş) tez-tez baş verən kosmetik defektdən çox prioritetlidir.

Risk səviyyəsiEhtimal × TəsirTest yanaşması
KritikYüksək × YüksəkDetallı test case-lər, bütün neqativ və boundary hallar, hər build-də regression, əlavə exploratory sessiya
YüksəkAşağı × YüksəkƏsas ssenarilər + ən vacib neqativ hallar; release-dən əvvəl mütləq yoxlanılır
OrtaYüksək × AşağıChecklist səviyyəsində yoxlama, dəyişiklik olan sprintlərdə regression
AşağıAşağı × AşağıYalnız smoke; vaxt qalarsa exploratory; scope-dan çıxarıldığı açıq bildirilir

Prioritetləşdirmə üçün praktiki meyarlar (interviewdə bunları ardıcıllıqla saymaq güclü təəssürat yaradır):

  • Pul axını — ödəniş, qiymət hesablanması, endirim, geri qaytarma
  • Dəyişiklik — bu release-də toxunulmuş kod və onun asılılıqları
  • İstifadə tezliyi — analitikaya görə istifadəçilərin 80%-nin keçdiyi yollar
  • Defekt tarixçəsi — keçmişdə ən çox bug verən modullar (defect clustering)
  • Tənzimləyici tələb — sığorta/bank sahəsində məcburi hesabat və audit sahələri
  • Bərpa olunmazlıq — səhvi geri qaytarmaq mümkündürmü? Yanlış SMS geri alınmır, yanlış poliso silinmir

Nəyin test OLUNMADIĞINI bildirmək risk əsaslı testing-in ayrılmaz hissəsidir. Susmaq "hər şey test olunub" mesajı verir və bütün riski QA-nın üzərinə yıxır. Düzgün formul: "Kritik axınlar tam test olunub. X və Y modulları vaxt çatmadığına görə yalnız smoke səviyyəsində yoxlanılıb — risk: orta. Qərar sizindir."

Interviewdə "vaxt azdır, nəyi test edərsən?" sualına verilən ən zəif cavab "ən vacib şeyləri"dir. Güclü cavab meyarları adlandırır və nümunə verir: "Ödəniş və poliso hesablanmasını — pul riski var; sonra bu sprintdə dəyişən kodu; sonra analitikada ən çox istifadə olunan renewal axınını. Kosmetik UI dəyişikliklərini scope-dan çıxarardım və bunu release qeydində yazılı bildirərdim."