1. SDLC və STLC fərqi
SDLC proqram təminatının hazırlanmasının tam həyat dövrünü əhatə edir. SDLC requirment analiz, feasibility study, design, development, testing, deployment ve maintance den ibarətdir. STLC isə yalnız test proseslərinə yönəlmiş həyat dövrüdür. STLC test planı, test case dizaynı, test icrası və buraxılışa qədər olan test fəaliyyətlərini əhatə edir. SDLC tam layihə həyat dövrü olduğu halda, STLC yalnız onun bir hissəsidir. STLC, SDLC-nin test mərhələsinə daxil edilir. SDLC-də test mərhələsi başlamazdan əvvəl STLC fəaliyyətləri planlaşdırılır. STLC test mühəndislərinin iş prosesini təsvir edir, SDLC isə bütün komandanın işini. STLC test giriş meyarlarına və çıxış meyarlarına diqqət yetirir. SDLC isə ümumi layihə teslim tarixləri və büdcəyə nəzarət edir.
2. Idempotent və non-idempotent API
Idempotent API-də eyni sorğu neçə dəfə göndərilirsə göndərilsin, nəticə dəyişmir. Bu xüsusiyyət serverdə təkrarlanan əməliyyatların zərər verməməsini təmin edir. GET metodu idempotentdir, çünki məlumatı dəfələrlə oxumaq heç bir dəyişiklik yaratmır. PUT metodu da idempotentdir, çünki eyni məlumatı təkrarən göndərmək eyni nəticəni verir. DELETE metodu təkrar çağrıldıqda artıq silinmiş resurs üçün eyni cavabı qaytarır. Non-idempotent API-də hər yeni sorğu fərqli nəticə yarada bilər. POST metodu yeni resurs yaratdığı üçün hər dəfə fərqli identifikator qaytarır. PATCH metodu qismən yeniləmə apardığından təkrar çağrıldıqda fərqli nəticə verə bilər. Idempotent metodlar şəbəkə xətalarında təhlükəsiz şəkildə təkrarlana bilər. Non-idempotent metodlarda təkrarlama gözlənilməz nəticələrə səbəb ola bilər.
3. Access token vs Refresh token
Access token API-lərə müraciət etmək üçün qısa müddətli icazə daşıyıcısıdır. Access token adətən bir neçə dəqiqə və ya bir saat ərzində etibarlı olur. Refresh token isə uzun müddətli, bəzən günlər və ya aylarla etibarlı ola bilən tokendir. Access token bitdikdə refresh token istifadə edərək yeni access token alınır. Refresh token sayəsində istifadəçi təkrar daxil olmadan sessiyasını uzada bilir. Access token tez-tez dəyişdiyi üçün oğurlansa belə zərər müddəti məhduddur. Refresh token təhlükəsiz yerdə, adətən HTTP-only cookie-də saxlanılır. Access token client tərəfdə asanlıqla istifadə edilə bilər, məsələn localStorage-də. Refresh token yalnız token yeniləmə endpointinə göndərilir, başqa API-lərə getmir. Bu iki tokenin ayrılması təhlükəsizlik və istifadə rahatlığı arasında tarazlıq yaradır.
4. 409 error nə zaman olur
409 Conflict error serverdə cari vəziyyətlə sorğu arasında ziddiyyət yarandıqda baş verir. Ən tipik hal təkrar unikal məlumat yaratmağa cəhd edildikdədir, məsələn eyni email ilə istifadəçi qeydiyyatı. Versiya nəzarətində köhnə versiya əsasında yeniləmə etmək də 409 xətası verə bilər. Eyni resursa eyni anda ziddiyyətli əməliyyatlar göndərildikdə bu xəta yaranır. Məsələn, bir istifadəçi eyni vaxtda eyni sənədi yeniləməyə çalışdıqda. Serverdə müəyyən bir şərt (precondition) pozulduqda da 409 qaytarılır. Resursun cari vəziyyəti sorğunun icrasına imkan vermədikdə bu xəta istifadə olunur. Conflict xətası adətən client tərəfdən həll edilməli olan bir problemdir. Server 409 qaytardıqda bədəndə hansı şərtin pozulduğunu izah edə bilər. Bu xətanı düzəltmək üçün sorğu dəyişdirilməli və ya resurs cari vəziyyətə uyğunlaşdırılmalıdır.
5. 401 vs 403
401 Unauthorized istifadəçinin autentifikasiya olunmadığını və ya etibarlı token təqdim etmədiyini bildirir. Bu səhv adətən token olmadıqda, vaxtı keçdikdə və ya səhv formada göndərildikdə baş verir. 401 xətasından sonra client adətən yenidən daxil olmağı (login) tələb edir. 403 Forbidden isə istifadəçinin autentifikasiya olunsa da, tələb olunan resursa icazəsi olmadığını göstərir. 403-də istifadəçi daxil olub, lakin rolu və ya icazələri əməliyyatı yerinə yetirməyə imkan vermir. Məsələn, adi istifadəçi admin səhifəsinə girməyə çalışdıqda 403 alır. 401-də server "sən kimsən?" sualına cavab gözləyir, 403-də isə "sənsən, amma icazən yoxdur". 401 düzəldilə bilən bir autentifikasiya problemini, 403 isə icazə çatışmazlığını ifadə edir. 401 qəbul edildikdə client avtomatik olaraq login ekranına yönləndirilə bilər. 403 qəbul edildikdə isə client sadəcə icazə olmadığını göstərir, yenidən login etmək kömək etməz.
6. Reproducible bug
Reproducible bug eyni addımlar ardıcıllığı ilə hər dəfə təkrarlana bilən xətadır. Bu tip bugların həlli daha asandır, çünki developer xətanı öz mühitində təkrar yarada bilir. Reproducible bug üçün dəqiq addımlar, giriş məlumatları və şərtlər yazılmalıdır. Məsələn, "login olub, profil səhifəsinə keçib, 'şəkil yüklə' düyməsinə basdıqda xəta verir" kimi. Bu buglar adətən unit testlərlə də təkrarlana bilər. Reproducible bug aşkar edildikdə bug report-un "Steps to Reproduce" bölməsi ən vacib hissədir. Bu xətalar regression testlərdə də yoxlanıla bilər. Reproducible olmayan buglarla müqayisədə, bunların prioriteti daha yüksək olur, çünki həlli mümkündür. Bəzən müəyyən konfiqurasiya və ya məlumat bazası vəziyyəti tələb olunur. Reproducible bug fix edildikdən sonra eyni addımlarla təkrar test edilib doğrulama aparılır.
7. Boundary Value Analysis
Boundary Value Analysis test texnikasıdır ki, burada giriş dəyərlərinin hədd qiymətləri test edilir. Bu texnika səhvlərin ən çox hədd qiymətlərdə baş verdiyi prinsipinə əsaslanır. Məsələn, 1-dən 100-ə qədər dəyər qəbul edən bir sahə üçün 0, 1, 100, 101 dəyərləri test edilir. Minimum həddin özü, minimum-1 və minimum+1 test edilir. Maksimum həddin özü, maksimum-1 və maksimum+1 test edilir. Bu yanaşma ilə ən kritik nöqtələr yoxlanmış olur. Boundary Value Analysis həm integer, həm də tarix, vaxt kimi ardıcıl dəyərlər üçün tətbiq olunur. Bu texnika aşırım (off-by-one) səhvlərini aşkar etməkdə çox təsirlidir. Ekvivalentlik bölgüsü ilə birlikdə istifadə edildikdə test coverage artır. Boundary dəyərləri həm keçərli, həm də keçərsiz daxil etməklə hər iki hal test edilir.
8. Maintenance-də nə edirik
Maintenance mərhələsində sistem artıq produksiya mühitində işləyir və real istifadəçilər tərəfindən istifadə olunur. Bu mərhələdə yeni aşkar edilmiş buglar üçün fix-lər yoxlanılır və test edilir. Hər bir bug fix-dən sonra regression testing aparılır ki, köhnə funksiyalar pozulmasın. Performance göstəriciləri mütəmadi olaraq izlənilir və darboğazlar aşkar edilir. İstifadəçilərdən gələn yeni tələblərə əsasən kiçik təkmilləşdirmələr edilir. Təhlükəsizlik yamaları və üçüncü tərəf komponentlərin yeniləmələri tətbiq edilir. Loglar və monitorinq sistemləri vasitəsilə sistemin sağlamlığı yoxlanılır. Yeni əməliyyat sistemi və ya brauzer versiyaları ilə uyğunluq testləri aparılır. Müntəzəm olaraq backup və bərpa testləri həyata keçirilir. Maintenance mərhələsi sistemin bütün ömrü boyu davam edir və ən uzun mərhələdir.
9. Boundary nədir
Boundary giriş dəyərlərinin keçərli diapazonunun minimum və maksimum limitlərini ifadə edir. Hər bir giriş sahəsinin qəbul edə biləcəyi ən kiçik və ən böyük dəyər boundary adlanır. Məsələn, yaş sahəsi 18-65 arası dəyər qəbul edirsə, boundary-lər 18 və 65-dir. Boundary-lərin dərhal kənarındakı dəyərlər (17 və 66) keçərsiz bölgəyə aiddir. Proqram təminatında səhvlər çox vaxt məhz bu hədd qiymətlərdə baş verir. Boundary dəyərləri test edərkən həm aşağı, həm də yuxarı hədd yoxlanılmalıdır. Boundary-lərdən kənar dəyərlərin düzgün rədd edilib-edilmədiyi test edilməlidir. Bu anlayış xüsusilə riyazi hesablamalar, dövrlər və massiv indeksləri üçün vacibdir. Boundary təhlili zamanı hədd dəyərlərin tipi (int, float, string uzunluğu) nəzərə alınır. Proqramın spesifikasiyasında boundary-lər aydın şəkildə müəyyən edilməlidir.
10. Idempotent metodlar
GET metodu idempotentdir, çünki eyni sorğunu təkrar etmək hər dəfə eyni məlumatı qaytarır. PUT metodu bütün resursu əvəz etdiyi üçün idempotent sayılır, eyni məlumatla təkrar göndəriləndə nəticə dəyişmir. DELETE metodu idempotentdir, çünki bir dəfə silinmiş resursu təkrar silmək heç bir dəyişiklik yaratmır. HEAD metodu GET kimi işləyir, ancaq bədənsiz cavab qaytarır, buna görə də idempotentdir. OPTIONS metodu serverin imkanlarını sorğulayır və dəyişiklik etmədiyi üçün idempotentdir. TRACE metodu sorğunun gedişatını izləmək üçündür və heç bir dəyişiklik etmir. Idempotent metodlar şəbəkə xətaları səbəbi ilə təkrarlana bilər. Bu metodlar serverdə yan təsir yaratmadıqları üçün təhlükəsiz hesab olunur. Idempotentlik təkrarlanan əməliyyatların proqramın vəziyyətini korlamayacağını təmin edir. API dizaynında idempotent metodların düzgün işləməsi gözlənilən bir davranışdır.
11. Scrum artifact-ları
Product Backlog Scrum-da məhsula əlavə ediləcək bütün işlərin sıralanmış siyahısıdır. Bu siyahıda feature-lar, bug fix-lər, texniki təkmilləşdirmələr və digər tələblər yer alır. Product Owner prioritetləri müəyyən edir və backlog-u daim təkmilləşdirir. Sprint Backlog isə cari sprint ərzində tamamlanacaq işlərin seçilmiş hissəsidir. Sprint Backlog seçilmiş product backlog elementlərindən və onların həyata keçirilməsi üçün plandan ibarətdir. Increment sprint-in sonunda hazır olan və istifadəyə yararlı məhsul versiyasıdır. Hər sprint bir increment yaradır və bu increment əvvəlki increment-lərin üzərinə qurulur. Increment "Done" kriteriyasına cavab verməli və potensial olaraq buraxıla bilən vəziyyətdə olmalıdır. Sprint Review-da bu increment stakeholder-lərə nümayiş etdirilir. Bu üç artifact Scrum-da şəffaflığı və işin izlənilməsini təmin edir.
12. Burndown chart
Burndown chart sprint ərzində qalan işin miqdarını zamana görə göstərən qrafikdir. Şaquli oxda qalan iş (adətən saat və ya story point), üfüqi oxda isə sprint günləri olur. Burndown chart sprintin gedişatını vizual olaraq izləməyə imkan verir. Bu qrafik həm də komandanın iş tempini (velocity) təhlil etməyə kömək edir. Daily Scrum zamanı burndown chart-a baxaraq sprint hədəfinə çatma ehtimalı qiymətləndirilir. Sprint bitdikdə burndown chart planlaşdırma ilə icra arasında fərqləri göstərir.
13. Regression testing
Regression testing proqrama edilən dəyişikliklərdən sonra köhnə funksiyaların hələ də düzgün işlədiyini yoxlamaqdır. Bu test növü yeni feature və ya bug fix mövcud sistemə zərər vermədiyinə əmin olmaq üçün aparılır. Hər dəfə kod dəyişdikdə əvvəlki işləyən hissələrin pozulma riski yaranır. Regression test dəsti adətən avtomatlaşdırılır, çünki tez-tez təkrarlanmalıdır. Full regression testing bütün test dəstini işə salır, bu da çox vaxt apara bilər. Partial regression testing isə yalnız dəyişiklikdən təsirlənən modulları yoxlayır. Continuous integration sistemləri hər build-dən sonra regression testləri avtomatik işə salır. Regression testlər keçmədikdə, build uğursuz sayılır və düzəliş tələb olunur. Bu testlər proqram təminatının keyfiyyətini qorumaq üçün vacibdir. Regression testlər sayəsində komanda yeni feature-lar əlavə edərkən arxayın ola bilər.
14. Prod-a çıxmadan əvvəl təsir ölçmək
Produksiyaya buraxılmadan əvvəl regression test dəsti tam şəkildə icra edilməlidir. Smoke test əsas funksionallıqların işlək olduğunu təsdiq etmək üçün aparılır. UAT (User Acceptance Testing) real istifadəçilər və ya onları təmsil edən şəxslər tərəfindən həyata keçirilir. Performance test yük altında sistemin cavab müddətini və sabitliyini yoxlayır. Yeni feature-ların mövcud performansa təsiri ölçülməlidir. Təhlükəsizlik testləri (penetration testing) yeni zəifliklərin yaranmadığını yoxlayır. Load test ilə sistemin gözlənilən istifadəçi sayına dözümlülüyü sınanır. Integration test yeni komponentin digər sistemlərlə uyğunluğunu yoxlayır. Dəyişikliklərin təsir təhlili (impact analysis) hansı modulların risk altında olduğunu göstərir. Bütün bu testlər uğurla keçdikdən sonra buraxılış üçün yaşıl işıq yandırılır.
15. Test case texnikaları
Boundary Value Analysis giriş dəyərlərinin hədd qiymətlərini test edən texnikadır. Equivalence Partitioning daxil edilən məlumatları keçərli və keçərsiz qruplara bölərək hər qrupdan bir nümunə seçir. Error Guessing test mühəndisinin təcrübə və intuisiya ilə potensial xətaları təxmin etməsidir. Exploratory Testing əvvəlcədən yazılmış case-lər olmadan, öyrənərək test etmə texnikasıdır.
16. Boundary 2 və 3 value
Two-value boundary testing yalnız minimum və maksimum hədd dəyərlərini test edir. Bu yanaşmada həddin özü (min və max) və həddin bir vahid kənarı (min-1, max+1) olmaqla 4 dəyər test edilir. Three-value boundary testing isə həddin özü, hədd-1 və hədd+1 dəyərlərini test edir. Üç dəyər yanaşmasında minimum üçün min-1, min, min+1; maksimum üçün max-1, max, max+1 test edilir. İki dəyər yanaşması daha az test case tələb edir və daha sürətlidir. Üç dəyər yanaşması daha çox test case tələb edir, lakin daha yüksək keyfiyyət təmin edir. Məsələn, 1-100 intervalı üçün iki dəyər: 0,1,100,101; üç dəyər: 0,1,2,99,100,101. Bir çox layihələrdə iki dəyər yanaşması kifayət sayılır. Kritik sistemlərdə (tibb, aviasiya) üç dəyər yanaşması tələb oluna bilər. Hansı yanaşmanın seçilməsi risk təhlili və vaxt məhdudiyyətlərindən asılıdır.
17. Error Guessing
Error Guessing test mühəndisinin keçmiş təcrübəsinə və proqram haqqında bilgilərinə əsaslanan bir test texnikasıdır. Bu texnikada əvvəlcədən yazılmış formal test case-lər yerinə, mühəndis "burada nə xəta ola bilər?" sualına cavab axtarır. Məsələn, login səhifəsində boş şifrə, çox uzun şifrə, xüsusi simvollar daxil etmək kimi. Təcrübəli test mühəndisləri əvvəlki layihələrdə tez-tez rast gəldikləri xəta nümunələrini bilirlər. Sıfır, boş string, null, mənfi dəyərlər kimi sərhəd qiymətlər tez-tez sınaqdan keçirilir. Həmçinin, istifadəçinin gözlənilməz ardıcıllıqla əməliyyat etməsi də sınaqdan keçirilir. Məsələn, formu göndərməzdən əvvəl səhifəni yeniləmək, və ya geri düyməsini istifadə etmək. Error Guessing texnikası əsasən exploratory testing zamanı tətbiq olunur. Bu texnika formal texnikaların (boundary, equivalence) çatmadığı yerləri tamamlayır. Error Guessing nəticəsində tapılan xətalar çox vaxt real istifadəçilərin də rastlaşacağı xətalar olur.
18. Equivalence Partitioning
Equivalence Partitioning giriş məlumatlarını məntiqi qruplara bölərək hər qrupdan yalnız bir nümunə test etmə texnikasıdır. Bu texnikada eyni qrupdakı bütün dəyərlərin eyni davranışı göstərəcəyi fərz edilir. Keçərli daxil etmələr üçün bir partition, keçərsiz daxil etmələr üçün ayrıca partition-lar yaradılır. Məsələn, 1-100 arası dəyər qəbul edən sahə üçün keçərli partition: 1-100; keçərsiz: <1 və >100. Keçərli partition-dan bir dəyər (məsələn 50) seçib test edirik. Keçərsiz partition-ların hər birindən də bir dəyər seçirik (məsələn 0 və 101). Bu yanaşma test case sayını dramatik şəkildə azaldır, lakin coverage qorunur. Equivalence Partitioning adətən Boundary Value Analysis ilə birlikdə istifadə olunur. Bu texnika xüsusilə çoxlu sayda mümkün daxil etmə dəyərləri olan sahələr üçün effektivdir. Məsələn, aylar (1-12), yaş qrupları, ölkə kodları kimi. Bu yanaşma ilə eyni qrup daxilində bütün dəyərlərin test edilməsinə ehtiyac qalmır.
19. 402
402 Payment Required HTTP status kodu rəsmi olaraq "gələcəkdə istifadə üçün ayrılmış" statusdur və hal-hazırda çox nadir istifadə olunur. Bu kod əslində rəqəmsal ödəniş sistemlərində tələb olunan ödənişin edilmədiyini bildirmək üçün nəzərdə tutulmuşdur. Lakin praktikada heç bir geniş yayılmış API bu kodu standart olaraq istifadə etmir. Bəzi ödəniş şlüzləri öz xüsusi status kodlarından istifadə edir, 402-dən fərqli olaraq. Bu kodun istifadəsi üçün rəsmi RFC specifikasiyası tam olaraq müəyyən edilməmişdir. Nəticədə, developer-lər adətən 402 yerinə 403 və ya 400 seriyalı başqa kodlar seçirlər. Bəzi eksperimental API-lərdə subscription tələb olunduqda 402 qaytarılır. Lakin bu, standart deyil və hər API-də fərqli şəkildə tətbiq oluna bilər. 402 ilə qarşılaşsanız, bu API-nin xüsusi tətbiqidir və sənədləşməyə baxmalısınız. Ümumiyyətlə, 402 praktikada "istifadə olunmayan status kodu" olaraq qalır.
20. 403
403 Forbidden istifadəçinin autentifikasiya olunsa da, tələb olunan resursa çıxış icazəsi olmadığını bildirir. Bu kod serverin istifadəçini tanıdığını, lakin ona lazımi səviyyədə icazə verilmədiyini göstərir. Məsələn, adi istifadəçi admin panelinə girməyə çalışdıqda 403 alır. Başqa bir nümunə: istifadəçi öz profilini oxuya bilər, lakin başqasının profilini oxuya bilməz. 403 bəzən IP ünvanı əsasında giriş məhdudiyyəti olduqda da qaytarılır. Bu kod 401-dən fərqlidir, çünki 401-də autentifikasiya tələb olunur, 403-də isə autentifikasiya olsa belə icazə yoxdur. 403 qəbul edildikdə client adətən heç bir şey edə bilməz, sadəcə xətanı istifadəçiyə göstərir. Yenidən daxil olmaq (login) 403 xətasını həll etmir, çünki problem icazə səviyyəsindədir. API-lərdə 403 bəzən token düzgün olsa belə, rol çatışmadıqda qaytarılır. Təhlükəsizlik baxımından 403 qaytararkən nəyin çatışmadığını çox detallı izah etmək tövsiyə edilmir.
21. CRUD
CRUD proqram təminatında məlumatlar üzərində dörd əsas əməliyyatı ifadə edən akronimdir. Create yeni məlumat yaratmaq əməliyyatıdır və API-də adətən POST metodu ilə həyata keçirilir. Read mövcud məlumatları oxumaq əməliyyatıdır və adətən GET metodu ilə yerinə yetirilir. Update məlumatları dəyişdirmək əməliyyatıdır, PUT (tam yeniləmə) və ya PATCH (qismən yeniləmə) ilə edilir. Delete məlumatları silmək əməliyyatıdır və DELETE metodu ilə həyata keçirilir. Hər bir CRUD əməliyyatı verilənlər bazasında müvafiq SQL əməliyyatlarına (INSERT, SELECT, UPDATE, DELETE) uyğun gəlir. RESTful API dizaynında hər bir resurs üçün bu dörd əməliyyat təmin edilməlidir. CRUD əməliyyatları idempotentlik baxımından fərqlənir: Read, Update, Delete idempotent, Create isə non-idempotentdir. Bu əməliyyatlar əksər tətbiqlərin əsasını təşkil edir. CRUD tam funksional tətbiq yaratmaq üçün kifayət deyil, lakin başlanğıc nöqtəsidir.
22. API vs Unit test
Unit test kodun ən kiçik hissələrini (funksiya, metod, sinif) təkbaşına test edir. Unit testlər adətən developerlər tərəfindən yazılır və development mühitində icra olunur. Bu testlər xarici asılılıqları (verilənlər bazası, şəbəkə) mock edərək təcrid olunmuş şəkildə işləyir. Unit testlər saniyələr və ya millisaniyələr ərzində minlərlə icra oluna bilər. API test isə tam endpoint-ləri, yəni real HTTP sorğu-cavab dövrünü test edir. API testlər real və ya test verilənlər bazası ilə işləyir və şəbəkə kommunikasiyasını əhatə edir. API testlər status kodlarını, response body-ni, header-ləri, autentifikasiyanı yoxlayır. API testlər unit testlərə nisbətən daha yavaşdır, çünki bütün stack-i işə salır. Unit testlər ağ-qutu (white-box) yanaşması, API testlər isə qara-qutu (black-box) yanaşmasıdır. Hər iki test növü tam keyfiyyət təminatı üçün vacibdir və bir-birini tamamlayır.
23. Maintenance
Maintenance proqram təminatının buraxılışdan sonrakı bütün fəaliyyətlərini əhatə edən SDLC mərhələsidir. Bu mərhələdə sistem artıq produksiyadadır və real istifadəçilər tərəfindən istifadə olunur. Maintenance zamanı aşkar edilən bug-lar üçün fix-lər hazırlanır və test edilir. Hər bir dəyişiklikdən sonra regression testing aparılır ki, köhnə funksiyalar pozulmasın. Performans problemləri monitorinq vasitələri ilə izlənilir və optimizasiya edilir. Təhlükəsizlik zəiflikləri aşkar edildikdə təcili yamalar buraxılır. Yeni əməliyyat sistemi, brauzer və ya üçüncü tərəf asılılıq yeniləmələri tətbiq edilir. İstifadəçilərdən gələn geri bildirimlər əsasında kiçik təkmilləşdirmələr edilir. Verilənlər bazasının optimizasiyası və arxivləşdirilməsi kimi tapşırıqlar yerinə yetirilir. Maintenance mərhələsi sistemin istismar müddəti boyu davam edir və ən uzun mərhələdir.
24. Login test case
Positive test case: düzgün email ünvanı və düzgün şifrə ilə login olmaq. Negative test case: düzgün email, yanlış şifrə daxil edib xəta mesajını yoxlamaq. Negative: mövcud olmayan email ilə login cəhd etmək. Negative: email sahəsini boş buraxıb göndərmək və validasiya mesajını yoxlamaq. Negative: şifrə sahəsini boş buraxıb göndərmək. Negative: email sahəsinə yanlış formatda dəyər (məsələn, "test" və ya "test@") daxil etmək. Negative: şifrə sahəsinə minimum uzunluqdan qısa dəyər daxil etmək (əgər məhdudiyyət varsa). Negative: şifrə sahəsinə maksimum uzunluqdan uzun dəyər daxil etmək. Negative: email və şifrəni hər iki sahəni boş buraxıb göndərmək. Boundary: email-in maksimum uzunluğu (255 simvol) daxilində və kənarında dəyərlər test edilməlidir.
25. Test case
Test case test mühəndisinin yazdığı, müəyyən bir funksiyanı yoxlamaq üçün addımlar ardıcıllığıdır. Hər test case-də ID, başlıq, ilkin şərtlər, test addımları, gözlənilən nəticə və faktiki nəticə olmalıdır. İlkin şərtlər testin başlamazdan əvvəl sistemin hansı vəziyyətdə olması lazım olduğunu təsvir edir. Test addımları aydın, ardıcıl və təkrar edilə bilən şəkildə yazılmalıdır. Gözlənilən nəticə dəqiq və ölçülə bilən olmalıdır, məsələn "200 OK status kodu qaytarılır". Test case-lər həm müsbət (positive), həm də mənfi (negative) ssenariləri əhatə etməlidir. Yaxşı test case-lər qısa, anlaşılan və tək bir şeyi yoxlayan olmalıdır. Test case-lər test menecment alətlərində (Jira, TestRail, qTest) saxlanılır. Test case-lər təkrar istifadə edilə bilər və regression test dəstlərinin əsasını təşkil edir. Hər bir test case üçün keçmə/keçməmə kriteriyası aydın şəkildə müəyyən edilməlidir.
26. Bug
Bug proqram təminatının gözlənilən davranışı ilə faktiki davranışı arasındakı uyğunsuzluqdur. Bug istifadəçi təcrübəsini mənfi təsirləyən, funksionallığı pozan və ya sistemin çökməsinə səbəb olan problemdir. Hər bug-un aşkar edilməsi üçün dəqiq addımlar, giriş məlumatları və sistem konfiqurasiyası qeyd olunmalıdır. Bug-lar severity (ciddilik) və priority (prioritet) səviyyələrinə görə təsnif edilir. Severity bug-un texniki təsirini, priority isə biznes baxımından nə qədər tez düzəldilməsi lazım olduğunu göstərir. Bəzi bug-lar həmişə təkrarlana bilən (reproducible), bəziləri isə təsadüfi (intermittent) xarakter daşıyır. Bug report-da əlavə olaraq environment, build versiyası, log-lar və screenshot/video da olmalıdır. Bug həll edildikdən sonra test mühəndisi fix-i doğrulayır və bug-u bağlayır. Bəzən bug "cannot reproduce" və ya "works as designed" səbəbi ilə bağlana bilər. Bug idarəetmə sistemi (Jira, Bugzilla, YouTrack) bütün bug-ların izlənilməsi üçün istifadə olunur.
27. Uyğunsuzluq
Uyğunsuzluq proqram təminatının faktiki davranışı ilə gözlənilən davranışı arasındakı fərqdir. Gözlənilən davranış adətən tələb spesifikasiyası, dizayn sənədi və ya istifadəçi hekayəsində təsvir edilir. Faktiki davranış test icrası zamanı müşahidə edilən real nəticədir. Əgər expected ≠ actual olarsa, bu uyğunsuzluq bir bug olaraq qeydə alınır. Uyğunsuzluq səhv hesablama, səhv mesaj, səhv yönləndirmə, məlumat itkisi və ya performans problemi ola bilər. Bəzən uyğunsuzluq sənədləşmədəki qeyri-dəqiqlikdən qaynaqlana bilər. Həmçinin, gözlənilən nəticənin özü də səhv müəyyən edilmiş ola bilər. Test mühəndisi uyğunsuzluq aşkar etdikdə əvvəlcə tələbi yenidən yoxlamalıdır. Uyğunsuzluğun səbəbi kod xətası, konfiqurasiya xətası, məlumat xətası və ya mühit xətası ola bilər. Hər bir uyğunsuzluq dəqiq sənədləşdirilməli və həll prosesi izlənilməlidir.
28. Pesticide paradox
Pesticide paradox test nəzəriyyəsində deyilir ki, eyni testləri təkrar-təkrar icra etsəniz, zamanla onlar yeni bug tapmağı dayandırır. Bu, eyni pestisidin eyni zərərvericilərə qarşı zamanla təsirini itirməsinə bənzədilir. İlkin mərhələdə yazılmış testlər sistemin ən açıq və asan tapılan buglarını aşkar edir. Lakin eyni test dəstini hər build-də işlətməklə siz yalnız eyni bug-ların təkrar görünmədiyini yoxlayırsınız. Yeni, daha dərin bug-ları tapmaq üçün test dəsti daim yenilənməli və təkmilləşdirilməlidir. Bu paradoksun həlli müntəzəm olaraq yeni test case-lər yazmaq, fərqli texnikalar tətbiq etməkdir. Həmçinin, exploratory testing kimi qeyri-formal yanaşmalar da tətbiq edilməlidir. Regression test dəstlərini təmizləmək (artıq aktuallığını itirmiş case-ləri silmək) də vacibdir. Yeni feature-lar əlavə edildikcə, onlar üçün yeni test case-lər yazılmalıdır. Pesticide paradoxunu yalnız avtomatlaşdırmaya güvənmək gücləndirir, ona görə də əl testlə də nəzarət edilməlidir.
29. API
API (Application Programming Interface) iki proqram sistemi arasında əlaqə qurmağa imkan verən interfeysdir. API vasitəsilə bir proqram digərinin funksiyalarından istifadə edə bilər, daxili təfərrüatları bilmədən. Web API-lər HTTP protokolu üzərində işləyir və adətən REST arxitekturasına əsaslanır. API sorğuları client tərəfindən göndərilir, server isə cavab qaytarır. Sorğu metod (GET, POST, PUT, DELETE), URL, header-lər və bədəndən ibarətdir. Cavab status kodu (200, 404, 500), header-lər və bədəndən (adətən JSON formatında) ibarətdir. API-lər proqram təminatı komponentləri arasında modulluğu və təkrar istifadə edilə bilənliyi təmin edir. Yaxşı API-lər versiyalanır, sənədləşdirilir və backward-compatible saxlanılır. API testlər status kodları, cavab strukturu, autentifikasiya, performans və təhlükəsizliyi yoxlayır. Müasir tətbiqlərin əksəriyyəti frontend-backend əlaqəsi üçün API-lərdən istifadə edir.
30. Regression test
Regression test proqram təminatına edilən dəyişikliklərdən sonra köhnə funksiyaların hələ də düzgün işlədiyini yoxlamaqdır. Bu test növü yeni kodun mövcud sistemi pozmadığını təmin edir. Regression test dəstləri adətən avtomatlaşdırılır, çünki tez-tez təkrarlanmalıdır. Hər yeni build və ya buraxılışdan əvvəl regression testlər icra edilməlidir. Full regression testing bütün test dəstini işə salır, bu da saatlarla, hətta günlərlə vaxt apara bilər. Partial (selective) regression testing isə yalnız dəyişiklikdən təsirlənə biləcək modulları yoxlayır. Continuous integration/continuous deployment (CI/CD) pipeline-larında regression testlər avtomatik işə düşür. Regression testlər keçmədikdə, pipeline dayanır və düzəliş tələb olunur. Hər bir bug fix-dən sonra həmin bug-u yoxlayan test regression dəstinə əlavə edilir. Bu yanaşma eyni bug-un təkrar görünməsinin qarşısını alır (regression prevention).
31. API metodlar
GET metodu serverdən məlumat oxumaq üçün istifadə olunur və heç bir yan təsir yaratmamalıdır. POST metodu serverdə yeni resurs yaratmaq üçün istifadə olunur, idempotent deyil. PUT metodu mövcud resursu tamamilə əvəz etmək üçündür, idempotentdir. PATCH metodu resursun yalnız müəyyən hissələrini yeniləmək üçündür, qismən idempotent ola bilər. DELETE metodu resursu silmək üçündür və idempotentdir. HEAD metodu GET ilə eyni, lakin response bədəni olmadan yalnız header qaytarır. OPTIONS metodu serverin hansı metodları dəstəklədiyini sorğulamaq üçündür. CONNECT metodu proxy vasitəsilə tunel yaratmaq üçün istifadə olunur (nadir). TRACE metodu sorğunun yolunu izləmək üçün debug məqsədli istifadə olunur. Ən çox istifadə olunanlar GET, POST, PUT, PATCH, DELETE-dir, digərləri daha spesifik hallarda işlədilir.
32. Test life cycle
Test life cycle (STLC) test prosesinin planlaşdırmadan buraxılışa qədər olan mərhələlərini təsvir edir. Requirement analysis mərhələsində test mühəndisi tələbləri təhlil edir və test edilə bilənliyini yoxlayır. Test planning mərhələsində test strategiyası, resurslar, vaxt təxmini və risklər müəyyən edilir. Test design mərhələsində test case-lər, test məlumatları və test ssenariləri hazırlanır. Test environment setup mərhələsində test üçün lazım olan hardware, software, şəbəkə konfiqurasiyası qurulur. Test execution mərhələsində test case-lər icra edilir, bug-lar aşkar edilir və report olunur. Test closure mərhələsində test sənədləri tamamlanır, metrikalar toplanır və dərslər qeydə alınır. Hər mərhələnin giriş meyarları (başlamaq üçün nələr hazır olmalı) var. Hər mərhələnin çıxış meyarları (mərhələni bitirmək üçün nələr hazır olmalı) var. STLC SDLC-nin içində yerləşir və adətən development mərhələsi ilə paralel aparılır.
33. QA
QA (Quality Assurance) keyfiyyətin təmin edilməsi prosesidir və məhsulun keyfiyyət standartlarına cavab verməsini təmin edir. QA mühəndisi sırf test etməkdən daha geniş vəzifələrə malikdir, proseslərin özlərini yaxşılaşdırır. QA-nın məqsədi xətaların qarşısını almaqdır (prevention), test isə xətaları tapmaqdır (detection). QA proseslərin, metodologiyaların, standartların və auditin planlaşdırılmasını əhatə edir. QA mühəndisi test strategiyasını müəyyən edir, test planlarını hazırlayır və prosesləri izləyir. Həmçinin, test mühəndislərinin işini koordinasiya edir və onlara dəstək verir. QA metrikalar toplayır, məsələn, bug density, test coverage, passed/failed test nisbəti. QA release prosesini idarə edir və buraxılışın keyfiyyət həddlərini təyin edir. QA həmçinin developer-lərə unit testlərin yazılması və kod keyfiyyəti ilə bağlı təlimlər verir. Yaxşı QA departamenti "keyfiyyəti içinə qurur" (build quality in), sona saxlamır.
34. SDLC mərhələləri
Requirement gathering and analysis mərhələsində stakeholder-lərdən tələblər toplanır və təhlil edilir. Design mərhələsində sistem arxitekturası, verilənlər bazası dizaynı, interfeyslər və komponentlər layihələndirilir. Development (implementation) mərhələsində developer-lər dizayn əsasında kodu yazır və unit testlər edirlər. Testing mərhələsində keyfiyyət təminatı komandası sistemi test edir, bug-ları aşkar edir. Deployment mərhələsində təsdiqlənmiş proqram staging-dən produksiyaya çıxarılır. Maintenance mərhələsində produksiyadakı sistemə dəstək verilir, bug fix-lər və təkmilləşdirmələr edilir. Hər mərhələnin öz giriş və çıxış meyarları var. Ən geniş yayılmış SDLC modelləri Waterfall, Agile, V-model, Iterative, Spiral-dır. Agile metodologiyasında mərhələlər ardıcıl deyil, təkrarlanan (iterative) şəkildə aparılır. Hər bir mərhələ layihənin uğuru üçün vacibdir, lakin vaxt və resurs bölgüsü modelə görə dəyişir.
35. Feature
Feature proqram təminatına əlavə edilən yeni funksionallıq və ya imkandır. Hər bir feature son istifadəçiyə müəyyən bir dəyər təqdim edir və ya biznes problemini həll edir. Məsələn, "şifrəni unutdum" funksiyası, "sosial şəbəkə ilə daxil ol" və ya "sifarişi izlə" bir feature-dır. Feature-lar adətən istifadəçi hekayələri (user stories) şəklində təsvir edilir. Hər feature üçün ayrıca test planı, test case-lər və regression testlər hazırlanır. Feature-lar prioritetlərə əsasən sıralanır və sprints/sürümlərə bölünür. Böyük feature-lar daha kiçik hissələrə bölünərək tədricən buraxıla bilər (feature flag arxasında). Feature test edilərkən həm funksional, həm də qeyri-funksional tələblər yoxlanılır. Yeni feature mövcud sistemlə uyğunluğunu yoxlamaq üçün regression testdən keçməlidir. Feature buraxıldıqdan sonra istifadəçi geri bildirimləri toplanır və gələcək təkmilləşdirmələr üçün təhlil edilir.
36. Test prinsipləri
Testing shows presence of defects: testlərin məqsədi xətaların olduğunu göstərməkdir, xətasız olduğunu sübut edə bilməz. Exhaustive testing is impossible: bütün mümkün giriş və kombinasiyaları test etmək qeyri-mümkündür, risk əsaslı yanaşma lazımdır. Early testing: testlərə erkən başlamaq (tələb və dizayn mərhələsində) xətaları daha ucuz düzəltməyə imkan verir. Defect clustering: xətaların təxminən 80%-i modulların 20%-də toplanır (Pareto prinsipi). Pesticide paradox: eyni testləri təkrar etdikdə yeni xəta tapmaq getdikcə çətinləşir, testləri yeniləmək lazımdır. Testing is context dependent: test yanaşması proqramın tipindən, risk səviyyəsindən və kontekstdən asılı olaraq dəyişir. Absence of errors fallacy: xətalar tapılıb düzəldilsə belə, sistem istifadəçi ehtiyaclarını qarşılamırsa faydasızdır. Bu prinsiplər ISTQB sertifikasiyasının əsasını təşkil edir. Hər bir test mühəndisi bu prinsipləri bilməli və işində tətbiq etməlidir. Bu prinsiplər testin effektivliyini artırmağa və tələlərdən qaçmağa kömək edir.
37. Pesticide paradox izah
Pesticide paradox test nəzəriyyəsinin əsas prinsiplərindən biridir. Bu prinsip deyir ki, eyni test dəstini dəfələrlə icra etsəniz, yeni bug tapmaq ehtimalınız zamanla sıfıra enir. Bunun səbəbi, test dəstinin yalnız müəyyən ssenariləri əhatə etməsidir. Yeni bug-lar isə çox vaxt bu ssenarilərdən kənarda, gözlənilməz yerlərdə gizlənir. Məsələn, login testini həmişə eyni email və şifrə ilə etsəniz, yeni bug tapmazsınız. Ancaq login prosesinə captcha əlavə edilibsə, köhnə test dəsti bunu yoxlamır. Pesticide paradoxunu aradan qaldırmaq üçün test dəstləri mütəmadi yenilənməlidir. Hər sprintdə yeni test case-lər yazılmalı, köhnəlmiş case-lər silinməli və ya dəyişdirilməlidir. Həmçinin, exploratory testing kimi qeyri-formal yanaşmalar da tətbiq edilməlidir. Regression test dəstlərini avtomatlaşdırsanız da, əl ilə yeni ssenarilər əlavə etməlisiniz. Pesticide paradoxu test avtomatlaşdırmasının da "paslanmasına" səbəb olur, buna görə də diqqətli olmaq lazımdır.
38. Test level
Unit testing ən aşağı test səviyyəsidir və tək bir funksiya, metod və ya sinifi test edir. Unit testlər adətən developerlər tərəfindən yazılır və development mühitində icra olunur. Integration testing müxtəlif modulların, siniflərin və ya xidmətlərin birlikdə necə işlədiyini yoxlayır. Integration testlər API-lər, verilənlər bazası əlaqələri və xarici xidmətlərlə inteqrasiyanı test edir. System testing bütün tam inteqrasiya olunmuş sistemi onun tələblərinə qarşı yoxlayır. Sistem testi funksional və qeyri-funksional (performans, təhlükəsizlik, istifadəçi dostluğu) aspektləri əhatə edir. User Acceptance Testing (UAT) real istifadəçilər və ya onları təmsil edən şəxslər tərəfindən aparılır. UAT-də məqsəd sistemin real dünya ssenarilərində istifadəçi ehtiyaclarını qarşılayıb-qarşılamadığını yoxlamaqdır. Hər bir test səviyyəsinin öz alətləri, mühiti və giriş/çıxış meyarları var. Aşağı səviyyələrdə tapılan xətalar daha ucuz düzəldilir, buna görə də unit testlər çox vacibdir.
39. UAT
UAT (User Acceptance Testing) proqram təminatının real istifadəçilər tərəfindən qəbul edilməzdən əvvəl son test mərhələsidir. Bu testdə məqsəd sistemin real dünya ssenarilərində işlədiyini və istifadəçi ehtiyaclarını qarşıladığını yoxlamaqdır. UAT adətən müştəri nümayəndələri, biznes analitiklər və ya son istifadəçilər tərəfindən həyata keçirilir. UAT test case-ləri real biznes prosesləri əsasında, texniki detallardan uzaq şəkildə yazılır. Bu test mərhələsində istifadəçilər sistemi öz gündəlik iş axınlarında sınayırlar. UAT uğurla keçdikdə müştəri rəsmi olaraq sistemi qəbul edir (sign-off). UAT zamanı tapılan bug-lar adətən yüksək prioritetli olur, çünki buraxılış gözləyir. Bəzən UAT "beta testing" adlanır, xüsusilə kütləvi istifadəçilər üçün məhsullarda. UAT mühiti produksiya mühitinə mümkün qədər yaxın olmalıdır. UAT-nin uğursuz olması buraxılışın ləğv edilməsinə və ya təxirə salınmasına səbəb ola bilər.
40. Bank app smoke test
Bank tətbiqində smoke test ən kritik funksiyaların işlək olduğunu yoxlayan qısa test dəstidir. Login funksiyası: istifadəçi düzgün kredit kartı nömrəsi və PIN ilə daxil ola bilirmi. Balans görüntüləmə: daxil olduqdan sonra hesab balansı düzgün göstərilirmi. Pul köçürmə: öz hesabları arasında və ya başqa hesaba pul köçürmək mümkündürmü. Köçürmə tarixçəsi: edilən köçürmə əməliyyatı tarixçədə görünürmü. Logout: istifadəçi sistemdən çıxa bilirmi və çıxdıqdan sonra yenidən daxil olmaq tələb olunurmu. Hesab mövcudluğu: bağlanmış və ya bloklanmış hesabla giriş cəhdi uyğun mesajla rədd edilirmi. Minimum balans: köçürmə zamanı minimum balans qaydası yoxlanılırmı. Bu smoke test dəsti bütün testlər 5-10 dəqiqə ərzində başa çatmalıdır. Smoke test hər yeni build-dən sonra, daha dərin testlərdən əvvəl icra edilir. Smoke test keçməzsə, build "unstable" sayılır və qalan testlər icra edilmir.
41. Variable
Variable proqramlaşdırmada dəyər saxlamaq üçün istifadə edilən adlandırılmış yaddaş sahəsidir. Hər bir variable-ın bir adı (identifier) və məlumat tipi (integer, string, boolean, etc.) olur. Variable-ın dəyəri proqramın icrası zamanı dəyişə bilər (dəyişən). Proqramlaşdırmada variable-lar təyin edilir (assignment) və sonra istifadə olunur (reference). Məsələn, int age = 25; burada "age" variable, 25 isə onun dəyəridir. Test mühəndisləri də variable-lardan test məlumatlarını saxlamaq üçün istifadə edirlər. API testlərində variable-lar environment, collection və ya global səviyyədə təyin edilə bilər. Məsələn, Postman-da {{baseUrl}} variable-ı ilə əsas ünvan saxlanılır. Variable-lar təkrar istifadəni asanlaşdırır və kod/test-ləri daha oxunaqlı edir. Test avtomatlaşdırmasında variable-lar doğru idarə edilmədikdə çox vaxt səhvlərin mənbəyi olur.
42. Boundary value
Boundary value giriş dəyərlərinin etibarlı diapazonunun sərhəd nöqtələridir. Hər bir etibarlı diapazonun minimum və maksimum həddi boundary-lərdir. Boundary dəyərlərdə səhvlərə daha tez-tez rast gəlinir, çünki proqramçılar "off-by-one" xətaları edə bilərlər. Məsələn, 1-100 arası dəyər qəbul edən sahədə boundary-lər 1 və 100-dür. Boundary dəyərlər test edilərkən həddin özü, hədd-1 və hədd+1 dəyərləri yoxlanılır. Bu yanaşma "Boundary Value Analysis" texnikasının əsasını təşkil edir. Boundary dəyərlər yalnız rəqəmsal daxil etmələr üçün deyil, string uzunluğu, tarixlər və vaxtlar üçün də tətbiq olunur. Məsələn, ad sahəsi minimum 2, maksimum 50 simvol qəbul edirsə, 1,2,3,49,50,51 test edilir. Boundary dəyərlər həm keçərli (valid) hədd dəyərləri, həm də keçərsiz (invalid) hədd kənarı dəyərləri əhatə edir. Bu texnika ekvivalentlik bölgüsü ilə birlikdə istifadə edildikdə çox effektlidir.
43. Non-functional test case examples
Performance test case: 1000 eyni vaxtlı istifadəçi login olduqda server cavab müddəti 2 saniyədən çox olmamalıdır. Security test case: SQL injection hücumuna qarşı login sahəsi mühafizə olunmalı, "' OR '1'='1 daxil edildikdə login baş verməməlidir. Usability test case: yeni istifadəçi heç bir təlim olmadan 3 dəqiqə ərzində uğurla hesab yarada bilməlidir. Reliability test case: sistem 7 gün 24 saat fasiləsiz işlədikdə heç bir xəta baş verməməli, CPU istifadəsi 80%-i keçməməlidir. Scalability test case: istifadəçi sayı 1000-dən 10000-ə çıxdıqda, sistem 3 əlavə server əlavə edilməklə normal işləməlidir. Compatibility test case: tətbiq Chrome, Firefox, Safari və Edge-in son 3 versiyasında eyni görünməli və işləməlidir. Maintainability test case: yeni bir feature əlavə etmək üçün developer 2 saatdan az vaxt sərf etməlidir. Portability test case: tətbiq Windows, Linux və macOS-da eyni şəkildə quraşdırılıb işlədilə bilməlidir. Accessibility test case: ekran oxuyucu proqramlar (screen reader) səhifədəki bütün elementləri düzgün oxuya bilməlidir. Compliance test case: tətbiq GDPR tələblərinə uyğun olmalı, istifadəçi məlumatları silinə bilməlidir.
44. Business smoke test
Business smoke test proqramın əsas biznes proseslərini və kritik funksiyalarını yoxlayan minimal test dəstidir. Bu test dəsti xətanın bütün biznes əməliyyatını dayandıra biləcək yerləri əhatə edir. Business smoke test texniki detallardan uzaq, biznes stakeholder-lərin anlayacağı dildə yazılır. Məsələn, e-ticarət tətbiqində: məhsul axtar, səbətə əlavə et, ödəniş et, sifarişi təsdiqlə. Bank tətbiqində: daxil ol, balansı gör, pul köçür, çıxış et. Bu testlər hər yeni buraxılışdan əvvəl, deployment-dan sonra produksiyada da icra edilə bilər. Business smoke test uğursuz olarsa, buraxılış dərhal dayandırılır və geri qaytarılır (rollback). Bu testlər adətən əl ilə icra olunur, çünki biznes proseslər tez-tez dəyişir. Lakin kritik yerlər avtomatlaşdırıla bilər. Business smoke test dəsti qısa olmalı, 5-10 test case-dən çox olmamalıdır. Bu testlər "happy path" ssenarilərini əhatə edir, negative ssenarilər burada yer almır. Business smoke test keçdikdən sonra daha dərin regression testlərə başlanılır.
45. API test cases
Status code test case: etibarlı sorğuya 200 OK, yaradılan resursa 201 Created, tapılmadıqda 404 Not Found qaytarılmalıdır. Response body test case: cavab bədənində gözlənilən bütün sahələr (id, name, email) mövcud olmalı və düzgün tipdə olmalıdır. Response schema test case: cavab JSON schema-ya uyğun olmalı, əlavə və ya çatışmayan sahələr olmamalıdır. Headers test case: cavabda Content-Type: application/json header-i olmalıdır. Authentication test case: token olmadan göndərilən sorğuya 401 Unauthorized qaytarılmalıdır. Authorization test case: token düzgün olsa da, rol icazə vermirsə 403 Forbidden qaytarılmalıdır. Request body validation test case: tələb olunan sahələrdən biri çatışmadıqda 400 Bad Request qaytarılmalıdır. Performance test case: endpoint 1 saniyə ərzində cavab verməlidir (load test altında). Idempotency test case: eyni PUT sorğusunu 5 dəfə göndərdikdə hər dəfə eyni cavab və eyni server vəziyyəti olmalıdır. Error message test case: səhv olduqda cavab bədənində insan tərəfindən oxuna bilən error mesajı olmalıdır.
46. Env vs Collection variable
Environment variable (env var) müəyyən bir test mühitinə (development, staging, production) aid olan dəyərləri saxlayır. Məsələn, development üçün baseUrl = "https://dev.api.example.com", production üçün isə fərqli. Environment variable-lar mühitlər arasında keçid etməyi asanlaşdırır, kod/test case dəyişmədən. Collection variable isə bir collection (test dəsti) daxilində bütün sorğular üçün ortaq olan dəyərləri saxlayır. Məsələn, collection-da müştəri ID-si, default request header-ları, ümumi autentifikasiya tokeni. Collection variable-lar collection-un bütün sorğularında istifadə edilə bilər, environment-dan asılı deyil. Environment variable-lar collection variable-lardan üstünlüyə malikdir (override edir). Əgər eyni adlı variable hər ikidə varsa, environment variable istifadə olunur. Postman, Newman, REST Client kimi alətlərdə bu ikili dəstəklənir. Test məlumatlarını (məsələn, test user email) adətən collection variable-da saxlamaq daha əlverişlidir. Environment dəyişdikdə dəyişməli olan dəyərləri isə environment variable-da saxlamaq lazımdır.
47. Query param vs path param
Path parameter URL-in bir hissəsi kimi, resursun unikal identifikatorunu təyin etmək üçün istifadə olunur. Məsələn, /users/123 URL-də "123" path parameter-dir və istifadəçi ID-sini göstərir. Path parameter-lər məcburidir, çünki onlar olmadan hansı resursa müraciət ediləcəyi bəlli deyil. Query parameter isə URL-in sonunda "?" işarəsindən sonra gəlir və açar-dəyər cütlüyü şəklində olur. Məsələn, /users?page=2&limit=10 URL-də "page" və "limit" query parameter-lərdir. Query parameter-lər ixtiyaridir, filtrasiya, sıralama, səhifələmə və seçmə əməliyyatları üçün istifadə olunur. Path parameter-lər adətən resursun identifikasiyası üçün (GET /users/123 - bir istifadəçi). Query parameter-lər isə resursların siyahısını süzmək üçün (GET /users - bütün istifadəçilər). RESTful API dizaynında path parameter-lər "identifies a resource", query parameter-lər isə "filters or modifies a collection" rolunu oynayır. Hər ikisi də URL-in bir hissəsidir, lakin fərqli məqsədlərə xidmət edir. URL-də path parameter-lər "resource hierarchy"-ni təmsil edir, məsələn /users/123/orders/456.
48. Login non-functional
Login prosesinin qeyri-funksional testlərindən biri cavab müddətidir, normal şəraitdə login 1 saniyədən az olmalıdır. Security testi: brute force hücumuna qarşı sistem qorunmalı, 5 uğursuz cəhddən sonra hesab müvəqqəti bloklanmalıdır. Load testi: 1000 istifadəçi eyni vaxtda login olduqda, server çökməməli və cavab müddəti 3 saniyədən çox olmamalıdır. Stress testi: normal yükün 10 qatı (10,000 istifadəçi) login sorğusu göndərildikdə sistem düzgün xəta mesajı qaytarmalı (çökməməli). Scalability testi: istifadəçi sayı 2 dəfə artdıqda, login prosesi avtomatik miqyaslana bilməlidir (əlavə resurs ayrılmalı). Reliability testi: 24 saat ərzində hər 5 dəqiqədə login edilə bilməli, heç bir uğursuzluq olmamalıdır. Usability testi: login formu mobil cihazda rahat doldurulmalı, düymələr barmaq üçün kifayət qədər böyük olmalıdır. Accessibility testi: ekran oxuyucu proqram email və şifrə sahələrini düzgün tanımalıdır. Compliance testi: login zamanı şifrə açıq mətndə loglanmamalı, GDPR tələblərinə uyğun olmalıdır. Concurrency testi: eyni istifadəçi iki fərqli cihazdan eyni anda login olduqda, sessiyalardan biri sonlandırılmalıdır (və ya xəbərdarlıq verilməlidir).
49. Pesticide paradox işdə
İşdə pesticide paradox ilə qarşılaşdıqda ilk addım test dəstini təhlil etməkdir, hansı ssenarilər hələ test edilməyib. Müntəzəm olaraq (məsələn, hər sprintdə) test case-lərə yeni ssenarilər əlavə etmək lazımdır. Əvvəlki sprintlərdə tapılan bug-ları təhlil edərək, hansı növ ssenarilərin çatışmadığını müəyyən etmək olar. Təcrübəli test mühəndisləri error guessing ilə potensial riskli sahələri müəyyən edib yeni case-lər yazırlar. Exploratory testing sessiyaları təşkil edərək, yazılı case-lərdən kənara çıxmaq lazımdır. Eyni test dəstini avtomatlaşdırıb "işləyir, toxunma" düşüncəsindən qaçmaq lazımdır. Regression test dəstini təmizləmək (köhnəlmiş, artıq tətbiq olunmayan case-ləri silmək) də vacibdir. Yeni test texnikaları tətbiq etmək (məsələn, pairwise testing, state transition) da kömək edir. İş yerində pesticide paradox aylarla eyni regression dəstini işlədən komandalarda daha çox görünür. Həll yolu: test dəstinin code review-ni etmək, çatışmayan hissələri müəyyən edib daim təkmilləşdirməkdir.
50. Exploratory testing
Exploratory testing əvvəlcədən yazılmış test case-lər olmadan, öyrənərək və araşdıraraq test etmə metodudur. Bu yanaşmada test mühəndisi eyni vaxtda öyrənir, dizayn edir və icra edir. Exploratory testing əsasən təcrübəli test mühəndisləri tərəfindən, yüksək riskli və mürəkkəb sahələrdə tətbiq olunur. Bu metod yazılı test case-lərin çatmadığı, gözlənilməz ssenariləri aşkar etmək üçün idealdır. Prod-da riskli yerləri yoxlamaq üçün əla üsuldur, çünki real istifadəçi davranışını simulyasiya edir. Exploratory testing zamanı test mühəndisi "test charter" adlanan bələdçi sənədə sahib ola bilər. Məsələn, "login prosesinin təhlükəsizlik aspektlərini araşdır" kimi bir charter. Bu test növü zamanı test mühəndisi tapdığı bug-ları dərhal sənədləşdirir. Həmçinin, hansı yolları test etdiyini qeyd edir ki, təkrarlana bilsin. Exploratory testing yazılı test case-ləri tamamlayır, onları əvəz etmir. Agile metodologiyalarda exploratory testing çox populyardır, çünki sürətli dəyişikliklərə uyğunlaşa bilir.
51. Non-functional titles
Performance test sistemin müəyyən iş yükü altında nə qədər sürətli cavab verdiyini ölçür. Load test sistemin gözlənilən maksimum istifadəçi sayı altında necə işlədiyini yoxlayır. Stress test sistemi normal həddən çox yükləyərək onun qırılma nöqtəsini tapır. Endurance test (soak test) sistemi uzun müddət (məsələn 24 saat) normal yük altında saxlayaraq yaddaş sızmalarını yoxlayır. Scalability test istifadəçi sayı artdıqda sistemin resurs əlavə edərək miqyaslana biləcəyini yoxlayır. Security test sistemin zəifliklərini, autentifikasiya, icazə, məlumat təhlükəsizliyini yoxlayır. Usability test sistemin nə dərəcədə istifadəçi dostu, intuitiv və öyrənməsi asan olduğunu qiymətləndirir. Compatibility test sistemin müxtəlif brauzerlər, əməliyyat sistemləri, cihazlarda işləməsini yoxlayır. Reliability test sistemin müəyyən zaman ərzində fasiləsiz və xətasız işləmə ehtimalını ölçür. Maintainability test sistemin nə dərəcədə asan dəyişdirilə, təkmilləşdirilə və təmir edilə biləcəyini yoxlayır.
52. QA sprint işi
Sprint planning mərhələsində QA mühəndisi sprintə daxil olan user story-lərin test edilə bilənliyini yoxlayır. Test case yazma: hər bir user story üçün positive, negative, boundary, integration test case-ləri hazırlanır. Test məlumatlarının hazırlanması: test execution üçün lazımi məlumatlar (istifadəçi, məhsul, sifariş) yaradılır. Test execution: developer-lər feature-i təslim etdikdə, QA dərhal test etməyə başlayır. Bug reporting: tapılan hər bir bug detallı şəkildə Jira (və ya başqa alət) vasitəsilə report olunur. Bug verification: developer bug fix etdikdə QA fix-i doğrulayır və bug-u bağlayır. Regression testing: hər bir bug fix və yeni feature-dən sonra regression testlər icra edilir. Sprint review-da QA nə test edildiyini, nəticələri və buraxılışa hazırlığı təqdim edir. Sprint retrospective-də QA proseslərdəki problemləri, test çatışmazlıqlarını gündəmə gətirir. Sprint boyu QA həmçinin automation testlər yazır, test environment-ı idarə edir və sənədləri yeniləyir.
53. Stress test
Stress test sistemi normal iş yükünün həddindən artıq yükləyərək onun qırılma nöqtəsini tapmaq üçün aparılır. Məqsəd sistemin hansı şəraitdə xəta verməyə başladığını və necə bərpa olduğunu görməkdir. Stress test zamanı istifadəçi sayı tədricən artırılır, normal limiti aşana qədər. Məsələn, normal yük 1000 istifadəçidirsə, stress test 2000, 5000, 10000 ilə aparılır. Login stress testi zamanı birdən-birə çox sayda login sorğusu göndərilir. Sistem çökməməli, əksinə "rate limit" və ya "service unavailable" kimi düzgün xəta mesajı qaytarmalıdır. Stress test nəticəsində sistemin maksimum tutumu (capacity) müəyyən edilir. Həmçinin, yaddaş sızmaları (memory leak) aşkar edilə bilər. Stress testdən sonra sistem avtomatik bərpa olma qabiliyyəti də yoxlanılır. Bu test növü Black Friday və ya bilet satışı kimi pik zamanlar üçün vacibdir. Stress test adətən load testing alətləri (JMeter, Gatling, LoadRunner) ilə avtomatlaşdırılır.
54. Severity vs Priority
Severity bug-un proqram təminatına texniki təsirinin dərəcəsidir, yəni nə qədər ciddi bir problem olduğunu göstərir. Məsələn, sistemin çökməsi kritik severity, kiçik UI qüsuru isə aşağı severity sayılır. Priority isə bug-un nə qədər tez düzəldilməli olduğunu göstərən biznes qərarıdır. Severity əsasən test mühəndisi tərəfindən təyin edilir, priority isə product owner və ya biznes tərəfindən. Yüksək severity + yüksək priority: sistem çökür, dərhal fix edilməlidir. Yüksək severity + aşağı priority: nadir hallarda baş verən ciddi bug, lakin növbəti versiyaya qalmalıdır. Aşağı severity + yüksək priority: korporativ login səhifəsində logo səhvdir (kiçik UI, lakin yüksək görünürlük). Aşağı severity + aşağı priority: alətdəki köhnə yazı səhvi, heç vaxt fix olunmaya da bilər. Bəzən yüksək severity bug aşağı priority ola bilər, məsələn köhnə brauzerdə çökmə (istifadəçilərin 0.1%-i). Severity və priority arasında tarazlıq qurmaq test menecmentinin vacib hissəsidir.
55. Smoke vs Sanity
Smoke test geniş, lakin dayaz bir testdir, əsas funksiyaların işlədiyini yoxlayır. Sanity test isə dar, lakin dərin bir testdir, kiçik dəyişiklikdən sonra müəyyən bir modulun işlədiyini yoxlayır. Smoke test hər yeni build-dən sonra, build-in "stability"-sini yoxlamaq üçün edilir. Sanity test isə kiçik bir bug fix və ya kiçik bir feature əlavəsindən sonra edilir. Smoke test adətən ssenarilər şəklində yazılır, məsələn "login ol, məhsul axtar, səbətə əlavə et". Sanity test isə yalnız dəyişdirilən sahəyə yönəlir, məsələn "şifrə dəyişmə funksiyası işləyir". Smoke test daha geniş əhatə dairəsinə malikdir, lakin dərinliyi azdır. Sanity test daha dar əhatəlidir, lakin daha dərindir. Smoke test uğursuz olarsa, build reject edilir, qalan testlərə keçilmir. Sanity test uğursuz olarsa, yalnız həmin dəyişiklik reject edilir. Hər iki test regression test dəstinin alt hissələridir. Smoke test bütün sistemin "smoke" testidir, əgər tüstü çıxırsa, yanğın var deməkdir.
56. STLC-də tester
Test plan mərhələsində tester test strategiyasını, əhatə dairəsini, resursları, vaxt təxminini və riskləri müəyyən edir. Test case development mərhələsində tester tələblərə əsasən test case-lər, test məlumatları və test ssenariləri yazır. Test environment setup mərhələsində tester (bəzən DevOps ilə birlikdə) test mühitinin hazır olduğunu doğrulayır. Test execution mərhələsində tester test case-ləri icra edir, actual nəticələri expected ilə müqayisə edir. Bug reporting mərhələsində tester tapdığı hər bir bug üçün detallı report yaradır (addımlar, log, screenshot). Bug verification mərhələsində developer bug fix etdikdən sonra tester fix-i doğrulayır və bug-u bağlayır. Regression testing mərhələsində tester dəyişikliklərin köhnə funksiyaları pozmadığını yoxlayır. Test closure mərhələsində tester test sənədlərini tamamlayır, metrikaları toplayır və hesabat hazırlayır. STLC boyu tester həmçinin test avtomatlaşdırması, performans testi, təhlükəsizlik testi kimi ixtisaslaşmış testləri də yerinə yetirə bilər. Tester hər mərhələdə developer, product owner, DevOps və digər stakeholder-lərlə əməkdaşlıq edir.
57. Ceremonies
Daily Scrum (stand-up) hər gün eyni vaxtda, maksimum 15 dəqiqə davam edən qısa görüşdür. Hər bir komanda üzvü üç suala cavab verir: dünən nə etdim, bu gün nə edəcəyəm, hansı maneələr var. Sprint Planning sprintin əvvəlində edilir, bu görüşdə product backlog-dan hansı işlərin sprintə alınacağı müəyyən edilir. Sprint Planning iki hissədən ibarətdir: "nə edəcəyik" (product owner liderliyində) və "necə edəcəyik" (developer liderliyində). Sprint Review sprintin sonunda edilir, komanda bitirdiyi işləri stakeholder-lərə nümayiş etdirir. Sprint Review-də əldə edilən feedback əsasında product backlog yenilənir. Sprint Retrospective sprint-in ən sonunda, review-dən sonra edilir. Retrospective-də komanda prosesləri müzakirə edir: nə yaxşı getdi, nə pis getdi, nəyi dəyişdirə bilərik. Backlog Refinement (Grooming) sprint boyu davam edən, product backlog-dakı maddələrin təfərrüatlandırıldığı və təxminləndiyi görüşdür. Bu dörd əsas ceremony Scrum komandalarının açar prosesləridir.
58. System testing
System testing tam inteqrasiya olunmuş proqram təminatını onun spesifikasiyalarına qarşı yoxlayan test səviyyəsidir. Bu test bütün komponentlərin birlikdə düzgün işlədiyini təsdiq edir. System testing zamanı proqram real istifadəçi mühitini simulyasiya edən test mühitində icra olunur. Bu test səviyyəsində funksional tələblər (login, transfer, axtarış) yoxlanılır. Həmçinin, qeyri-funksional tələblər (performans, təhlükəsizlik, usability) də bu mərhələdə test edilir. System testing adətən QA komandası tərəfindən, qara-qutu (black-box) yanaşması ilə aparılır. Bu testə başlamazdan əvvəl unit və integration testlər uğurla keçmiş olmalıdır. System testing end-to-end ssenariləri əhatə edir, məsələn "istifadəçi qeydiyyatdan keçir, login olur, məhsul alır, ödəniş edir". Bu test mərhələsi həftələrlə davam edə bilər, layihənin böyüklüyündən asılı olaraq. System testing uğurla keçdikdən sonra UAT-ə (user acceptance testing) keçilir.
59. System testing-də
System testing zamanı funksional testlər: bütün funksiyaların tələblərə uyğun işlədiyini yoxlayır. Məsələn, istifadəçi qeydiyyatı, login, şifrə sıfırlama, məhsul axtarışı, səbətə əlavə etmə, ödəniş. Integration testlər: sistemin daxili komponentləri arasında (məsələn, frontend-backend) və xarici sistemlərlə (ödəniş şlüzu, SMS gateway) əlaqəni yoxlayır. Database testlər: əməliyyatlardan sonra məlumatların düzgün yazıldığını, yeniləndiyini, silindiyini yoxlayır. UI testlər: istifadəçi interfeysinin bütün brauzerlərdə və cihazlarda düzgün göründüyünü yoxlayır. Performance testlər: sistemin normal və pik yük altında cavab müddətini, resurs istifadəsini ölçür. Security testlər: autentifikasiya, icazə, məlumat təhlükəsizliyi, SQL injection qorunmasını yoxlayır. Usability testlər: sistemin nə dərəcədə istifadəçi dostu, intuitiv olduğunu qiymətləndirir. Compatibility testlər: sistemin müxtəlif əməliyyat sistemləri, brauzerlər, cihaz ölçüləri ilə uyğunluğunu yoxlayır. Reliability testlər: sistemin uzun müddət (məsələn 7 gün) fasiləsiz işləməsini yoxlayır. System testing-də bütün bu aspektlər birlikdə yoxlanılır, çünki real dünyada sistem hər şeyi eyni anda etməlidir.
60. Debug vs Info
Debug log səviyyəsi ən ətraflı məlumatı verir və yalnız development mərhələsində istifadə olunur. Debug log-lar funksiyaların giriş-çıxış parametrlərini, dövrlərin iterasiyalarını, dəyişənlərin qiymətlərini göstərir. Debug log-lar produksiya mühitində adətən söndürülür (disabled), çünki çox yer tutur və performansı aşağı salır. Info log səviyyəsi proqramın normal iş axını haqqında ümumi məlumat verir. Məsələn, "User 123 logged in successfully", "Order 456 created", "Payment processed". Info log-lar həm development, həm də produksiya mühitlərində açıq ola bilər. Info log-lar sistemin sağlamlığını izləmək və audit üçün vacibdir. Debug log-lar developer-lərə xətanı lokal olaraq reproduce etməyə kömək edir. Info log-lar isə əməliyyat (ops) komandasına sistemin nə etdiyini anlamağa kömək edir. Debug produksiyada açılırsa, bu böyük təhlükəsizlik riski ola bilər, çünki həssas məlumatlar görünə bilər. Hər iki səviyyənin məqsədi fərqlidir: debug development üçün, info monitoring üçündür.
61. Warn
Warn log səviyyəsi gözlənilən, lakin potensial problem ola biləcək vəziyyətləri qeyd edir. Bu səviyyə sistemin hələ də işlədiyini, lakin diqqət yetirilməli bir şey olduğunu bildirir. Məsələn, "API response time exceeded 2 seconds" bir warn ola bilər. Həmçinin, "Retrying failed database connection" da bir warn-dır. Warn xəta deyil, çünki sistem avtomatik olaraq bərpa olundu (retry işlədi). Lakin bu, potensial bir xətanın əlaməti ola bilər, buna görə də araşdırılmalıdır. Warn log-lar produksiya mühitində mütləq izlənilməli və həddi aşdıqda alert göndərilməlidir. Məsələn, 5 dəqiqə ərzində 100 warn olarsa, bu problem deməkdir. Developer-lər warn-ları "future error" kimi qəbul etməli və kök səbəbini araşdırmalıdırlar. Warn-lar tez-tez configurasiya problemlərindən, resurs darboğazlarından və ya sərhəd şərtlərindən qaynaqlanır. Yaxşı tətbiqlərdə warn-lar az olur və hər biri bir aksiyon tələb edir.
62. Error
Error log səviyyəsi proqramın icrası zamanı baş verən, lakin sistemin dayanmasına səbəb olmayan xətaları qeyd edir. Bu səviyyə müəyyən bir əməliyyatın uğursuz olduğunu, lakin ümumi sistemin işləməyə davam etdiyini bildirir. Məsələn, "Failed to send email to user 123" bir error-dur, lakin tətbiq çökməyə bilər. Error log-lar produksiya mühitində mütləq izlənilməlidir və adətən həmin anda alert göndərilir. Hər bir error log-un özünəməxsus error kodu, mesajı, stack trace-i və timestamp-i olmalıdır. Error-lar tez-tez istifadəçinin hərəkətindən deyil, sistemin daxili problemlərindən qaynaqlanır. Məsələn, verilənlər bazasına qoşulma uğursuz oldu, lakin tətbiq cached məlumatla işləyə bilər. Error log-lar developer-lər üçün bug-ların əsas mənbəyidir. Hər bir error üçün bug report yaradılmalı və prioritet təyin edilməlidir. Error-lar warn-dan daha ciddidir, çünki artıq xəta baş verib, ancaq fatal deyil. Error-lar toplanaraq təhlil edilməli, ən çox rast gəlinənlər prioritet şəkildə fix edilməlidir.
63. Fatal/Critical
Fatal (və ya Critical) log səviyyəsi sistemin dayanmasına səbəb olan ən ciddi xətalardır. Bu səviyyədə log qeyd edildikdə, tətbiq və ya xidmət özünü dayandırır (crash). Məsələn, "OutOfMemoryError: unable to create new native thread" fatal bir xətadır. Həmçinin, "Failed to load critical configuration file" da fatal ola bilər, çünki tətbiq onsuz işləyə bilməz. Fatal xətalar adətən tətbiqin start-up zamanı və ya həyati resursa çatmaq mümkün olmadıqda baş verir. Bu xətalardan sonra tətbiq avtomatik restart oluna bilər (container orchestration vasitəsilə). Fatal log-lar dərhal operativ komandaya bildiriş göndərməlidir (SMS, telefon, Slack alert). Hər bir fatal xəta üçün dərhal aksiyon planı olmalıdır, çünki xidmət dayanıb. Fatal xətaların kök səbəb analizi prioritet olaraq aparılmalıdır. Bu xətalar adətən infrastruktur (yaddaş, disk, network) və ya kodun kritik hissələri ilə bağlı olur. Fatal xəta baş verdikdə, log-da mümkün qədər çox kontekst (stack trace, thread dump, heap dump) saxlanılmalıdır.
64. Log bug report-da
Log bug report-un ən vacib hissələrindən biridir, çünki problemi sübut edir və developer-ə həll yolu göstərir. Bug report-da log olmadıqda, developer "mənim mühitimdə işləyir" deyə bug-u bağlaya bilər. Log-da xətanın baş verdiyi dəqiq zaman damğası (timestamp) olmalıdır. Eyni zamanda, xətanın mesajı (error message), xəta kodu (error code) və stack trace olmalıdır. Stack trace xətanın hansı fayl və sətirdə baş verdiyini göstərir. Log-da həmçinin sorğu ID-si (request ID) və ya transaction ID olmalıdır ki, əlaqəli log-lar tapılsın. İstifadəçi ID-si varsa, o da log-da ola bilər, amma maskalanmalıdır (GDPR). Log-un bir hissəsi kimi environment (development, staging, production) da göstərilməlidir. Bug report-a log-u düz mətn (plain text) olaraq əlavə etmək, screenshot-dan daha yaxşıdır, çünki axtarıla bilər. Log çox böyükdürsə, yalnız xəta ilə əlaqəli hissə (xəta ətrafındakı 20-30 sətir) əlavə edilməlidir. Bəzi hallarda, log faylının özü deyil, log aggregator sistemində (Splunk, ELK) link paylaşılır.
65. Log-da nə olmalı
Timestamp log-un nə vaxt baş verdiyini göstərən dəqiq vaxt damğası (ISO 8601 formatında, millisaniyə dəqiqliyi ilə) olmalıdır. Error message xətanın qısa, anlaşılan təsviri olmalıdır, məsələn "Database connection timeout". Stack trace xətanın hansı fayl, sinif, metod və sətirdə baş verdiyini göstərən məlumat olmalıdır. Endpoint sorğunun hansı API endpointinə göndərildiyi (URL və HTTP metodu) qeyd olunmalıdır. Request ID hər bir sorğuya verilən unikal identifikator olmalıdır ki, eyni sorğuya aid log-lar birləşdirilə bilsin. User ID (maskalı formada, məsələn, "user_12345") əməliyyatı hansı istifadəçinin etdiyini göstərməlidir. IP ünvanı (anonimləşdirilmiş şəkildə, son oktet silinmiş) sorğunun haradan gəldiyini göstərə bilər. Log səviyyəsi (DEBUG, INFO, WARN, ERROR, FATAL) hər bir log mesajında açıq şəkildə yazılmalıdır. Environment (dev, staging, prod) və ya servis adı (auth-service, payment-service) də qeyd edilməlidir. Session ID varsa, o da log-da ola bilər ki, istifadəçinin bütün əməliyyatları bir yerdə görünsün.
66. Real login problem
User login edə bilmir, səhv şifrə xətası alır, lakin şifrə düzgündür. Səbəb 1: API endpoint-i yanlışdır, məsələn staging-də login endpoint-i dəyişib, amma tətbiq köhnə URL-ə sorğu göndərir. Səbəb 2: Verilənlər bazasında istifadəçi qeydiyyatı zamanı şifrə hash-lənib, lakin login zamanı hash funksiyası fərqli alqoritm işlədir. Səbəb 3: İstifadəçi adında gizli boşluq (whitespace) var, məsələn "john " (sonunda boşluq), lakin login zamanı trim edilmir. Səbəb 4: Şifrənin maksimum uzunluğu qeydiyyatda 50, login-də 20 simvol, uzun şifrə kəsilir. Səbəb 5: Autentifikasiya serveri (SSO) down-dur, lakin tətbiq "yanlış şifrə" mesajı göstərir (yanlış xəta mesajı). Səbəb 6: JWT token expiration time səhv qurulub, token 1 saniyəyə bitir, login elə uğursuz olur. Səbəb 7: Brauzerdə cookie-lər disabled-dir, server session saxlayır, amma cookie göndərilmir. Səbəb 8: CAPTCHA validation bug, CAPTCHA düzgün olsa da həmişə uğursuz olur. Səbəb 9: İki faktorlu autentifikasiya (2FA) səhv konfiqurasiya olunub, SMS gəlir amma sistem qəbul etmir. Səbəb 10: Məlumat bazasında user status "blocked" və ya "inactive"dir, lakin tətbiq bunu "yanlış şifrə" kimi göstərir.
67. Logging
Logging proqram təminatının icrası zamanı baş verən hadisələrin qeydiyyatı prosesidir. Bu hadisələrə xətalar, istifadəçi əməliyyatları, sistem hadisələri, performans metrikaları daxildir. Logging sistemin sağlamlığını izləmək, xətaları tapmaq və təhlil etmək üçün vacibdir. Hər bir proqram komponenti öz log-larını yaradır, adətən fayllara və ya mərkəzləşdirilmiş log sisteminə yazır. Yaxşı logging praktikası: log səviyyələrindən (DEBUG, INFO, WARN, ERROR, FATAL) düzgün istifadə etməkdir. Həmçinin, log-lar strukturlu formatda (JSON) olmalıdır ki, avtomatik işlənə bilsin. Log-lar mərkəzləşdirilmiş sistemə (ELK Stack, Splunk, Loki) göndərilməlidir. Bu sistemlər log-ları indeksləyir, axtarış və vizualizasiya imkanı verir. Logging performansa təsir edir, buna görə də çox log yazmaq sistemi yavaşlada bilər. Həssas məlumatlar (şifrə, token, kredit kartı) log-da yazılmamalıdır. Log-lar müəyyən müddət (məsələn 30 gün) saxlanılır, sonra arxivlənir və ya silinir.
68. Log level-lər
DEBUG log səviyyəsi ən ətraflı məlumatı verir, development zamanı istifadə olunur, produksiyada söndürülür. INFO log səviyyəsi normal əməliyyatlar haqqında ümumi məlumat verir, məsələn "user logged in", "file uploaded". WARN log səviyyəsi potensial problemləri göstərir, sistem hələ işləyir, amma diqqət tələb olunur. ERROR log səviyyəsi müəyyən əməliyyatın uğursuz olduğunu, lakin sistemin işləməyə davam etdiyini bildirir. FATAL (və ya CRITICAL) log səviyyəsi ən ciddi səviyyədir, sistemin dayanmasına səbəb olan xətaları qeyd edir. TRACE daha da ətraflı, DEBUG-dan da dərin, çox nadir istifadə olunur. OFF log səviyyəsi logging-i tamamilə söndürür. Hər bir log səviyyəsinin rəqəm dəyəri var, məsələn DEBUG=100, INFO=200, WARN=300, ERROR=400, FATAL=500. Tətbiq konfiqurasiyasında minimum log səviyyəsi təyin edilir, ondan aşağı səviyyələr yazılmır. Məsələn, səviyyə WARN-ə təyin edilsə, DEBUG və INFO log-ları yazılmaz, ancaq WARN, ERROR, FATAL yazılır. Bu yanaşma performans optimizasiyası üçündür.
69. ERROR vs WARN
ERROR log səviyyəsi artıq baş vermiş, real bir problemi göstərir, məsələn "Failed to save order to database". WARN isə hələ problem olmayan, lakin potensial problem ola biləcək vəziyyətləri göstərir, məsələn "Database connection pool is 90% full". ERROR-da tətbiqin bir funksiyası işləməyə bilər, amma tətbiq ümumilikdə işləyir. WARN-da tətbiqin bütün funksiyaları işləyir, amma yaxın gələcəkdə problem yarana bilər. ERROR log-u görəndə əməliyyat (ops) komandası dərhal müdaxilə edə bilər. WARN log-u isə izlənilməli, lakin dərhal müdaxilə tələb etməyən bir göstəricidir. ERROR tez-tez istifadəçi tərəfindən hiss olunan bir problemə səbəb olur. WARN çox vaxt istifadəçi üçün görünməzdir. Hər ERROR üçün adətən bir bug report yaradılır. WARN üçün isə yalnız həddi aşdıqda alert yaradılır, məsələn 10 WARN/dəqiqə. ERROR daha yüksək prioritetli araşdırma tələb edir. WARN isə planlı şəkildə, məsələn həftəlik əsasda araşdırılır.
70. QA niyə log əlavə edir
QA log əlavə edir ki, developer bug-un kök səbəbini daha tez tapsın və düzəltsin. Log olmadan developer saatlarla problemi reproduce etməyə çalışa bilər. Log xətanın baş verdiyi dəqiq sətri, metodu və parametrləri göstərir ki, developer kodu tez lokallaşdırsın. QA-nın ətraflı addımları olsa belə, log xətanın ətraf mühit şərtlərini (timestamp, request ID, session) təmin edir. Log eyni zamanda xətanın neçə dəfə baş verdiyini, hansı istifadəçiləri təsirlədiyini də göstərir. QA bəzən özü log-da gördüyü ipucu ilə səbəbi təxmin edib bug report-a yaza bilər. Məsələn, "log-da 'NullPointerException at line 123' görürəm, 'user' obyekti null gəlir" kimi. Log əlavə etmək QA ilə developer arasında kommunikasiyanı sürətləndirir, "təkrar yarada bilmirəm" dövrünü qırır. Log bug report-un "canonical" mənbəyidir, onu screenshot-dan üstün edən odur ki, axtarıla bilir. Bəzi şirkətlərdə QA birbaşa log aggregator-dan (Splunk, ELK) link paylaşır. Ən yaxşı halda QA log-u bug report-a yapışdırır, həm də log aggregator-da axtarış linki paylaşır.
71. Log-da nə olmamalı
Log-da heç vaxt istifadəçinin şifrəsi açıq mətndə yazılmamalıdır, bu böyük təhlükəsizlik riskidir. Tokenlər (JWT, API key, session token) də log-da olmamalıdır, çünki oğurlansa həmin token istifadə edilə bilər. Kredit kartı nömrələri, bank hesabı məlumatları, CVV kodu log-da yazılmamalıdır. Şəxsi məlumatlar (şəxsiyyət vəsiqəsi nömrəsi, ünvan, telefon nömrəsi) maskalanmadan log-da olmamalıdır. GDPR, PCI-DSS və digər compliance tələbləri bu məlumatların loglanmasını qadağan edir. Səhiyyə tətbiqlərində (HIPAA) xəstə məlumatları da log-da ola bilməz. Hətta "full stack trace" bəzən həssas məlumat (məsələn, environment variable-lar) ehtiva edə bilər. Buna görə də log-lar istehsala (production) çıxmazdan əvvəl təmizlənməlidir (sanitize). Bəzi məlumatlar (user ID) maskalanmalıdır, məsələn "user_123" deyil, "user_****". Log-da həmçinin internal IP ünvanları, server adları, database connection string-ləri də olmamalıdır. Log-lar mütəmadi audit edilməli, heç bir həssas məlumatın loglanmadığı təsdiqlənməlidir. Əgər log-da həssas məlumat görsəniz, dərhal security komandasına bildirməlisiniz.
72. INFO
INFO log səviyyəsi proqramın normal iş axınında baş verən əhəmiyyətli hadisələri qeyd edir. Bu səviyyə istifadəçi əməliyyatlarını, sistem hadisələrini və biznes proseslərini izləmək üçün istifadə olunur. Məsələn, "User 123 logged in successfully", "Order 456 created", "Payment of $50 processed". INFO log-lar həm development, həm də produksiya mühitlərində aktiv olur. Onlar sistemin sağlamlığını izləmək və audit üçün vacib məlumatlar verir. INFO log-ları olmadan, siz sistemdə nə baş verdiyini bilməzsiniz. Ancaq çox INFO log yazmaq performansa təsir edə bilər, buna görə seçici olmaq lazımdır. Hər bir əhəmiyyətli dövlət dəyişikliyi (state change) üçün INFO log yazılmalıdır. Məsələn, "Order status changed from PENDING to SHIPPED". INFO log-lar həm də operativ komandaya sistemin gözlənildiyi kimi işlədiyinə əminlik verir. Bəzi şirkətlərdə INFO log-lar birbaşa mərkəzləşdirilmiş monitoring sisteminə göndərilir. INFO log-ların həcmi normal şəraitdə sabit olmalıdır, qəfil artım problem əlamətidir.
73. DEBUG
DEBUG log səviyyəsi development zamanı ən ətraflı məlumatı təmin etmək üçün istifadə olunur. DEBUG log-lar funksiyalara giriş və çıxış parametrlərini, dövrlərin hər iterasiyasını, dəyişənlərin qiymətlərini qeyd edir. Məsələn, "Entering calculateTotal with params: items=3, discount=10", "Loop iteration 1, subtotal=50". DEBUG log-lar produksiya mühitində adətən söndürülür (disabled), çünki çox yer tutur və performansı aşağı salır. Ancaq müəyyən bir istifadəçi və ya sorğu üçün dinamik olaraq DEBUG log aça bilən sistemlər də var. DEBUG log-ları açmaq üçün əksər tətbiqlər log səviyyəsini dəyişmək imkanı verir (runtime reconfiguration). DEBUG log-lar olmadan mürəkkəb xətaları local mühitdə reproduce etmək çox çətin olardı. Bu log səviyyəsi adətən developer-lər üçün nəzərdə tutulub, QA və ya ops üçün deyil. Çox detallı olduğu üçün, DEBUG log-ları bir neçə saatlıq işləmədə gigabaytlarla yer tuta bilər. Buna görə də produksiyada DEBUG log-ları yalnız çox qısa müddətə, xüsusi bir problemi araşdırmaq üçün açmaq lazımdır. DEBUG log-ların təhlükəsizlik riski də var, çünki həssas məlumatlar (token, şifrə) bu səviyyədə loglana bilər.
74. 500 error görsə QA
500 Internal Server Error görən QA ilk olaraq eyni sorğunu təkrar göndərməlidir, bəzən müvəqqəti problem ola bilər. Əgər təkrarlanırsa, QA dərhal log sisteminə (Splunk, ELK) daxil olub həmin vaxt intervalında log-ları axtarmalıdır. Log-da stack trace, error message və timestamp olmalıdır, bunları bug report-a əlavə etməlidir. QA daha sonra problemi təcrid etmək üçün eyni sorğunu fərqli məlumatlarla (məsələn, fərqli user ID) test etməlidir. Sorğunu Postman və ya cURL ilə birbaşa API-ə göndərib, frontend-i bypass edə bilər. Bu, xətanın frontend-də yox, backend-də olduğunu təsdiq edir. QA həmçinin environment-ı yoxlamalıdır: development, staging, yoxsa production? Xəta digər environment-larda da varmı? Əgər bug reproduce edilə bilirsə, QA detallı addımlar, giriş məlumatları və log ilə birlikdə bug report yaradır. Bug report-un başlığı "500 Internal Server Error on /api/login" kimi aydın olmalıdır. QA həmçinin severity (adətən yüksək, çünki 500 server xətasıdır) və priority təyin edir. Developer fix göndərdikdə, QA fix-i doğrulayır və regression test edir. 500 xətaları adətən null pointer exception, database connection failure, unhandled exception kimi səbəblərdən olur.
75. Login functional test case-lər
Positive: etibarlı email və şifrə ilə login olmaq, uğurlu cavab (200 OK) və token qaytarılmalıdır. Positive: login olduqdan sonra profil səhifəsinə yönləndirmə düzgün işləməlidir. Negative: etibarlı email, yanlış şifrə daxil edildikdə "Invalid credentials" mesajı və 401 status kodu qaytarılmalıdır. Negative: mövcud olmayan email ilə login cəhd edildikdə eyni "Invalid credentials" mesajı (security best practice). Negative: email sahəsi boş, şifrə dolu olduqda validasiya mesajı ("Email is required") göstərilməlidir. Negative: şifrə sahəsi boş, email dolu olduqda validasiya mesajı ("Password is required") göstərilməlidir. Negative: hər iki sahə boş olduqda hər iki sahə üçün validasiya mesajı göstərilməlidir. Negative: email formatı yanlışdırsa (məsələn, "test", "test@", "test@domain") validasiya mesajı göstərilməlidir. Boundary: email maksimum uzunluq (255 simvol) daxilində və kənarında dəyərlər test edilməlidir. Boundary: şifrə minimum uzunluq (məsələn 8) və maksimum uzunluq (məsələn 64) sərhədləri test edilməlidir.
76. Integration test nədir
Integration test iki və ya daha çox modulun, sinfin, xidmətin birlikdə necə işlədiyini yoxlayan test növüdür. Unit test tək komponenti təcrid edərək test edir, integration test isə onların interfeyslərini test edir. Məsələn, user service-in database ilə əlaqəsini yoxlamaq bir integration testdir. API test də əslində bir növ integration testdir, çünki frontend-backend əlaqəsini yoxlayır. Integration testlər real asılılıqlarla (və ya test doubles ilə) işləyir. Məsələn, verilənlər bazası, mesaj brokeri, xarici API-lər. Bu testlər unit testlərə nisbətən daha yavaşdır, çünki xarici sistemləri işə salır. Integration testlər konfiqurasiya xətalarını, interfeys uyğunsuzluqlarını, şəbəkə problemlərini aşkar edir. Məsələn, "order service payment service-ə düzgün məlumat göndərə bilirmi?" Integration testlər adətən aşağıdakı aspektləri yoxlayır: sorğu formatı, cavab formatı, xəta idarəetməsi, timeout, retry mexanizmləri. Continuous integration pipeline-larında integration testlər unit testlərdən sonra icra olunur. Yaxşı bir test strategiyasında çoxlu unit test, az sayda integration test, daha az end-to-end test olur.
77. Prod like environment
Prod like environment produksiya mühitinə mümkün qədər yaxın olan, lakin real istifadəçilərin olmadığı test mühitidir. Bu mühitdə hardware konfiqurasiyası, şəbəkə quruluşu, verilənlər bazası ölçüsü produksiya ilə eyni olmalıdır. Prod like environment-da real produksiya məlumatları deyil, anonimləşdirilmiş (maskalanmış) məlumatlar istifadə olunur. Bu mühit performans testləri, stress testlər, təhlükəsizlik testləri üçün idealdır. Çünki development mühitində alınan performans nəticələri produksiyanı əks etdirmir. Prod like environment-da üçüncü tərəf xidmətlər (ödəniş, SMS) real deyil, sandbox və ya mock versiyaları istifadə olunur. Lakin bu xidmətlərin cavab müddətləri reala yaxın simulyasiya edilməlidir. Bu mühit adətən staging environment adlanır və buraxılışdan əvvəl son testlər burada aparılır. Prod like environment-ın qurulması və saxlanması baha başa gəlir, lakin böyük layihələr üçün vacibdir. Bu mühit olmadan, produksiyada gözlənilməz performans problemləri, miqyaslama problemləri baş verə bilər. Məsələn, development mühitində hər şey sürətli işləyir, amma produksiyada yavaş işləyir, çünki development DB-də 100 sətir, produksiyada 10 milyon sətir var.
78. Mock vs Stub
Mock test double bir obyektin real davranışını təqlid edir və gözləntiləri yoxlayır (verification). Məsələn, mock email service göndərilən email-in mətnini yoxlaya bilər. Stub isə sadəcə əvvəlcədən proqramlaşdırılmış cavabları qaytarır, heç bir yoxlama etmir (state verification). Stub "cavab ver" məntiqi ilə işləyir, mock isə "necə çağırıldığını yoxla" məntiqi ilə. Məsələn, payment service stub-u həmişə "success" qaytarır, amma mock-u 3 dəfə çağırıldığını yoxlayır. Unit testlərdə adətən mock-lar istifadə olunur ki, metodun düzgün parametrlərlə çağırıldığı təsdiqlənsin. Integration testlərdə stub-lar daha çox istifadə olunur, çünki real asılılıqların yerinə sadə cavablar qaytarmaq kifayətdir. Mock-lar daha "ağıllı"dır, stub-lar daha "sadə"dir. Test double termini həm mock, həm stub, həm də fake (real işləyən, lakin yüngül versiya) üçün ümumi anlayışdır. Məsələn, in-memory database bir fake-dir, real database-i təqlid edir, amma diskə yazmır. Mock-lar adətən test edilən kodun asılılıqlarla necə əlaqə qurduğunu yoxlamaq üçün istifadə olunur. Stub-lar isə sadəcə testin davam etməsi üçün lazım olan minimal cavabları təmin edir.