Question 1

Performance testing növlərini sadala və fərqlərini izah et.

Accepted Answer

Hər növü bir sual + bir nümunə ilə ver, bu, quru siyahıdan daha yaxşı yadda qalır. Load — "gözlənilən yükdə tələb olunan sürəti saxlayırıqmı?" (məs. eyni anda 500 istifadəçi). Stress — "harada sınırıq və NECƏ sınırıq?" — sınma anında aydın error verilməsi, data korlanmaması vacibdir. Spike — "qəfil yük artımından sonra tez bərpa olunuruqmu?" (məs. reklam kampaniyası və ya ilin sonu poliso yeniləmə piki). Endurance/soak — "saatlarla işləyəndə yaddaş sızması varmı?" Volume — "1 milyon qeydli bazada axtarış nə qədər çəkir?" Scalability — "server əlavə etsək, sistem uyğun şəkildə güclənirmi?" Sığorta kontekstindən nümunə vermək cavabı canlı edir: ilin sonu renewal piki spike testing üçün klassik ssenaridir.

Question 2

Manual QA kimi performance sahəsində nə edə bilirsən?

Accepted Answer

Cavabı iki hissəyə böl — nə edirəm və nə vaxt mütəxəssis cəlb edirəm — bu struktur həm bacarığı, həm də hədləri bilməyi göstərir. Edə bildiklərim: DevTools Network ilə tək istifadəçi cavab müddətini ölçürəm və keçən release ilə müqayisə edirəm (performance regression çox vaxt belə tapılır); böyük data ilə test edirəm — 5 yox, 500 polisosu olan hesabla; throttling ilə yavaş şəbəkədə loading state, timeout və ikiqat submit davranışını yoxlayıram; Network tabında lazımsız təkrar sorğuları görürəm (məs. hər hərfdə API çağırışı — debounce yoxdur). Mütəxəssis cəlb edirəm: real eyni vaxtlı yük, p95 hədəflərinin yoxlanması, endurance testi — bunlar JMeter/k6, ayrıca mühit və server monitorinqi tələb edir. Sonda əlavə et: "Refinement-də 'tez olmalıdır' ifadəsini rəqəmə çevirtdirmək də mənim işimdir."

Question 3

Bir səhifə keçən release-də 1 saniyəyə, indi 4 saniyəyə açılır. Nə edirsən?

Accepted Answer

Bunu performance regression bug-ı kimi qeyd edirəm — "mənə yavaş gəlir" kimi yox. Addımlarım: (1) təkrarlanmanı təsdiqləyirəm — boş cache ilə bir neçə dəfə ölçürəm, eyni mühitdə, eyni test hesabı ilə; başqa cihaz/şəbəkədə də yoxlayıram ki, lokal problem olmasın. (2) lokallaşdırıram — DevTools Network-də hansı sorğunun vaxt apardığına baxıram: bir API çağırışı yavaşdır, yoxsa 60 ayrı sorğu gedir (N+1)? Frontend render, yoxsa backend cavabı? (3) kontekst toplayıram — bu release-də həmin sahədə nə dəyişdi, data həcmi artıbmı, mühitdə paralel iş varmı. (4) report edirəm — əvvəlki və indiki rəqəmlər, HAR faylı, hansı sorğunun günahkar olduğu, istifadəçi təsiri. Bu strukturla verilən bug demək olar ki, heç vaxt "reproduce olunmur" deyə qaytarılmır.

Question 4

PO deyir: "Load testing üçün büdcəmiz yoxdur, sən əl ilə yoxla." Necə cavab verirsən?

Accepted Answer

"Yaxşı" demirəm — bu, yerinə yetirilə bilməyən vədə çevrilir və problem production-da üzə çıxanda məsuliyyət mənim üzərimə düşür. Amma sadəcə "mümkün deyil" də demirəm. Cavabım üç hissəlidir. Birincisi, dürüstlük: "Əl ilə real yük yaratmaq mümkün deyil — 20 tab açmaq nə təkrarlana bilən, nə də ölçülə biləndir. Bunu edə bilərəm, amma nəticəsi heç nə sübut etməyəcək." İkincisi, nə edə biləcəyim: tək istifadəçi ölçmələri, böyük data ilə test, yavaş şəbəkə ssenariləri, keçən release ilə müqayisə — bunlar problemlərin bir hissəsini tutur və pulsuzdur. Üçüncüsü, qalan riski görünən etmək: "Eyni vaxtlı yük altındakı davranış test olunmamış qalır. İlin sonu renewal piki bizim ən riskli dövrümüzdür. Təklifim: bu riski test planında yazılı qeyd edək, ops ilə monitorinq və alert razılaşdıraq, load testi növbəti kvartala planlaşdıraq." Risk qəbul oluna bilər — amma bilməyərəkdən yox, bilərəkdən qəbul olunmalıdır.

Metrik	Nə deməkdir	Nəyə diqqət etməli
Response time	Sorğunun göndərilməsindən cavabın alınmasına qədər keçən vaxt	Ortalama yanıldıcıdır — p95 / p99 (95-ci və 99-cu persentil) daha dürüst mənzərə verir
Throughput	Vahid vaxtda emal olunan sorğu sayı (RPS/TPS)	Yük artdıqca throughput artmırsa, sistem doyma nöqtəsinə çatıb
Error rate	Uğursuz sorğuların faizi	Yük altında 500 və timeout sayının artması — ən aydın sınma siqnalı
Concurrent users	Eyni anda aktiv istifadəçi sayı	Rəqəm analitikadan götürülməlidir — təxmin yox, real pik data
Resurs istifadəsi	CPU, yaddaş, disk, DB bağlantıları	Endurance testində yaddaşın davamlı artması memory leak deməkdir

Manual QA üçün performance testing əsasları

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