Question 1

BDD haqqında nə düşünürsən? Cucumber istifadə etmisənmi?

Accepted Answer

Cavabımı ayrımla başlayıram, çünki sualın özündə tez-tez qarışdırılan iki şey var: BDD əməkdaşlıq praktikasıdır, Cucumber isə alət. Bir-birindən asılı deyillər — BDD-ni Cucumber olmadan etmək olar, Cucumber istifadə edib BDD etməmək də olar (və təəssüf ki, ən çox rast gəlinən hal budur). BDD-nin əsl dəyəri three amigos söhbətindədir: biznes, developer və QA tələbi nümunələrlə birgə müzakirə edir. Mən bu praktikanı Cucumber olmadan da tətbiq edirəm — refinement-də konkret nümunələr üzərindən danışmaq ("kupon iki dəfə tətbiq olunsa nə olur?") sprintin sonunda tapılacaq anlaşılmazlıqları əvvəldə həll edir. Bu, mənim üçün BDD-nin ən faydalı hissəsidir. Cucumber-ə gəldikdə, mövqeyim şərtlidir: yalnız Gherkin-i qeyri-texniki tərəf həqiqətən oxuyursa dəyər verir. Əks halda ikiqat saxlanma, idarəolunmaz step definition kolleksiyası və çətinləşən debugging — heç bir qarşılıq olmadan. Playwright-da describe + aydın test adı + test.step() demək olar ki, eyni oxunaqlılığı bir qat az abstraksiya ilə verir. [Təcrübən yoxdursa dürüst ol:] "Layihədə Cucumber ilə işləməmişəm, amma sintaksisi bilirəm və playwright-bdd ilə tanışam. Prinsipləri isə istifadə edirəm — nümunə əsaslı müzakirə mənim iş üsulumun bir hissəsidir." Bu, uydurulmuş təcrübədən qat-qat güclüdür, çünki bir follow-up sualla açılmır.

Question 2

Layihədə Cucumber var, komanda ondan şikayətlənir. Nə edərdin?

Accepted Answer

Dərhal "silək" deməzdim — mövcud sistemi dəyişməyin öz xərci var və şikayətin arxasındakı problem hər zaman aydın olmur. Əvvəlcə diaqnoz: (1) .feature fayllarına QA-dan başqa kim baxır? Git tarixçəsinə baxmaq bunu obyektiv göstərir — son 6 ayda ssenariləri kim redaktə edib? Biznes tərəfin heç bir izi yoxdursa, Gherkin qatı artıq öz məqsədinə xidmət etmir. (2) Şikayət nədən gedir — Gherkin-in özündən, yoxsa pis yazılmış step definition-lardan? Bunlar tamamilə fərqli problemlərdir. Problem Gherkin qatının özündədirsə (heç kim oxumur): mərhələli çıxış təklif edərdim — yeni testlər adi Playwright-da yazılır, köhnələr toxunulanda köçürülür. Böyük "hər şeyi bir dəfəyə miqrasiya" layihəsi adətən yarımçıq qalır və vəziyyəti daha da pisləşdirir: indi iki fərqli yanaşma var. Problem realizasiyadadırsa (Gherkin-i biznes oxuyur, amma iş ağırdır): qatı saxlayıb keyfiyyəti düzəldərdim — step definition-ları təmizləmək və birləşdirmək, texniki addımları ("I click the button with id...") biznes dilinə qaldırmaq, @cucumber/cucumber-dən playwright-bdd-yə keçmək (paralellik, fixture-lər və trace geri qayıdır — çox vaxt şikayətin əsl səbəbi məhz bunların olmamasıdır). Qərarı təkbaşına verməzdim: biznes tərəflə də danışardım — bəlkə onlar ssenarilərə dəyər verir, sadəcə heç kim bunu QA-ya deməyib. Bu addım vacibdir, çünki qatı silmək geri qaytarılması bahalı qərardır.

Question 3

Product owner "testlərimizi Gherkin-də yazın ki, mən də oxuya bilim" deyir. Cavabın?

Accepted Answer

Bu, əla xəbərdir — real oxucu var, yəni Gherkin-in ən vacib şərti ödənilir. Amma dərhal razılaşmazdan əvvəl bir neçə şeyi dəqiqləşdirərdim, çünki "oxumaq istəyirəm" ilə "davamlı olaraq oxuyacağam" fərqli şeylərdir. Soruşacağım suallar: (1) Hansı testləri oxumaq istəyirsiniz? Bütün suite-i, yoxsa kritik biznes axınlarını? API müqaviləsi testlərini Gherkin-də yazmaq heç kimə fayda vermir. (2) Nə üçün oxumaq istəyirsiniz — hansı sualın cavabını axtarırsınız? Bəzən əsl ehtiyac "hansı funksionallıq əhatə olunub?" sualıdır və bunun daha ucuz cavabı var. (3) Ssenariləri özünüz yazacaqsınızmı və ya review edəcəksinizmi? Bu, ən vacib sualdır: BDD-nin dəyəri məhz burada yaranır. Sonra alternativləri təqdim edərdim, çünki Gherkin tək variant deyil: (a) HTML/Allure hesabatında testlərin adları — aydın yazılıbsa ("a valid coupon reduces the total"), oxunaqlı siyahı verir və heç bir əlavə xərc yoxdur; (b) test.step() ilə addımların hesabatda görünməsi; (c) tam Gherkin — əgər PO ssenariləri yazmaqda/review etməkdə iştirak edəcəksə. Çox vaxt söhbətin nəticəsi (a) olur və hər iki tərəf razı qalır. PO həqiqətən yazma prosesinə qoşulmaq istəyirsə, o zaman Gherkin-i pilot kimi bir feature-də sınayardım — bütün suite-i bir dəfəyə çevirmək əvəzinə. Bu cavab yaxşıdır, çünki istəyi rədd etmir, arxasındakı ehtiyacı tapır və ölçülü addım təklif edir.

Question 4

Yaxşı Gherkin ssenarisini pisdən nə fərqləndirir?

Accepted Answer

Bir cümləlik meyar: yaxşı ssenari user-in NƏ əldə etdiyini deyir, UI-ın bunu NECƏ etdiyini yox. Pis ssenari — imperativ, UI skripti: "When I click the button with id 'apply-btn' / And I wait 3 seconds / Then the element '.total' should contain '90'". Problemləri: biznes bunu oxumur (yəni Gherkin qatının varlıq səbəbi yoxdur), UI dəyişəndə ssenari sınır (halbuki davranış dəyişməyib), və .feature faylı sənəd yox, kod olur. Yaxşı ssenari — deklarativ, biznes dilində: "When I apply the coupon 'QA10' / Then the cart total should be '90.00 AZN'". UI-ın necə qurulduğu step definition-ın daxili işidir. Digər meyarlarım: (1) bir ssenari — bir davranış, 15 addımlıq ssenari adətən bir neçə testin bir yerə yığılmasıdır; (2) Background yalnız ortaq kontekst üçün — bütün hazırlığı ora yığmaq ssenarini oxunmaz edir; (3) Scenario Outline oxşar variasiyalar üçün — üç oxşar ssenari kopyalamaqdansa cədvəl daha aydındır; (4) texniki detal (ID, selector, timeout) heç vaxt ssenaridə görünmür; (5) ssenari adı nəticəni bildirir — "Coupon test 1" deyil. Sonda mühüm bir müşahidə əlavə edərdim: bu meyarların əksəriyyəti Gherkin-ə xas deyil — adi test adları və test.step() üçün də eynilə keçərlidir. "User niyyəti səviyyəsində danış, texniki detalı gizlə" prinsipi alətdən asılı olmayan yaxşı test dizaynıdır.

Şərait	Cucumber dəyər verir?	Səbəb
Biznes analitik ssenariləri özü yazır və review edir	Bəli	Ünsiyyət qazancı əlavə qatın xərcini ödəyir
Tənzimlənən sahə: tələb ↔ test izlənilməlidir	Bəli	Ssenarilər auditə uyğun sənəd rolunu oynayır
Yalnız QA komandası .feature fayllarına baxır	Xeyr	Bütün xərc, heç bir ünsiyyət qazancı
Texniki testlər: API müqaviləsi, error kodları	Xeyr	Gherkin texniki detalı ifadə etmək üçün əlverişsizdir
Kiçik komanda, sürətli iterasiya	Adətən xeyr	Əlavə qat sürəti azaldır, oxucu isə yoxdur
Mürəkkəb biznes qaydaları, çoxlu variasiya	Bəlkə	Scenario Outline cədvəlləri ilə qaydalar aydın görünür

BDD/Cucumber: nə vaxt dəyər verir, nə vaxt yox

📚 Mənbələr və sənədlər