Q: Product owner deyir: "Səhifə yavaşdır, test yazın." Nə edirsən?

"Yavaş" ölçülə bilən deyil, ona görə birinci işim tələbi dəqiqləşdirməkdir — və bu suala verilən ən yaxşı cavab məhz sual verməkdir. Soruşacağım şeylər: (1) Kim üçün yavaşdır? Şikayət hansı istifadəçilərdən gəlir — mobil, müəyyən region, konkret səhifə? (2) Nə vaxt yavaşdır? Həmişəmi, yoxsa pik saatlarda (bu, yük problemidir, frontend problemi yox)? (3) Nə qədər yavaş qəbul ediləndir? Hədəf rəqəm nədir? (4) Nə dəyişib? Son release-dən sonra başlayıbsa, bu, regressiyadır və müqayisə nöqtəmiz var. Sonra problemi təsnif edirəm, çünki həlli tamamilə buradan asılıdır: frontend problemi (böyük bundle, optimizasiya olunmamış şəkillər, render bloklayan skriptlər) → Lighthouse CI, budget, RUM datası; backend problemi (yavaş sorğu, N+1, indeks yoxdur) → APM, birbaşa API cavab müddətinin ölçülməsi; yük problemi (yalnız pik saatlarda) → k6 ilə yük testi. Sonda dürüst çərçivə qururam: "test yazmaq" özü problemi həll etmir — ölçmə və diaqnoz lazımdır. Mən ölçməni qura bilərəm və regressiyanın təkrarlanmaması üçün budget qoya bilərəm; optimizasiyanın özü isə komanda işidir. Bu cavab strukturu — sual → təsnifat → uyğun alət — həm burada, həm oxşar suallarda işləyir.

Q: Funksional avtotestlərdən performans haqqında hansı siqnalları çıxara bilərsən?

Funksional suite performans ölçmə aləti deyil, amma erkən xəbərdarlıq sistemi kimi çox dəyərlidir — və bu ayrımı saxlayaraq danışmaq vacibdir. Çıxardığım siqnallar: (1) Suite müddətinin trendi — testlər dəyişməyib, amma suite 12 dəqiqədən 18-ə çıxıbsa, ya infrastruktur, ya məhsul yavaşlayıb; hər ikisi araşdırılmalıdır. Bu trendi mən dashboard-da izləyirəm. (2) Konkret testlərin müddəti — Playwright hesabatı testləri müddətə görə sıralayır; bir testin qəfil iki dəfə uzanması adətən konkret bir səhifənin və ya sorğunun yavaşlaması deməkdir. (3) Timeout-a düşən assertion-lar — əvvəllər 2 saniyədə keçən yoxlama indi 5 saniyə timeout-a dirənirsə, bu, flakiness kimi görünür, amma əslində performans regressiyası ola bilər. Bu, ən çox səhv təsnif edilən haldır. (4) Trace-dəki network timing-ləri — hansı sorğunun uzandığı dəqiq görünür və bu, birbaşa backend komandasına ötürüləcək faktdır. Məhdudiyyəti mütləq deyirəm: bu rəqəmlər CI mühitindən, paralellikdən və şəbəkədən asılıdır, yəni mütləq dəyər kimi istifadə edilə bilməz — yalnız trend və nisbət kimi. Rəsmi ölçü üçün nəzarət olunan mühitdə Lighthouse və ya yük aləti lazımdır. Bu cavab yaxşıdır, çünki mövcud alətdən əlavə dəyər çıxarmağı göstərir — və eyni zamanda həddi aşmır.

Q: k6 ilə JMeter arasında seçim etməli olsan, nəyi əsas götürərdin?

Alət seçimi sualında düzgün refleks kontekstdən başlamaqdır — "k6 daha yaxşıdır" cavabı zəifdir. Soruşduqlarım: komandanın mövcud bacarıqları hansıdır? Testlər CI-da işləyəcəkmi, yoxsa əl ilə? Nəticələr harada saxlanacaq? Mövcud yük testləri varmı? Bundan sonra müqayisəm: k6 — skriptlər JS-dədir, yəni bizim komanda üçün öyrənmə xərci demək olar ki, sıfırdır; skriptlər adi kod kimi git-də saxlanılır və review olunur; CLI-first olduğu üçün CI-a təbii qoşulur; nəticə hədləri (thresholds) konfiqin bir hissəsidir, yəni SLA maşınla yoxlanan qaydaya çevrilir. JMeter — GUI ilə işləmək qeyri-proqramçılar üçün asandır; plagin ekosistemi çox genişdir (ekzotik protokollar: JDBC, JMS, LDAP); enterprise mühitlərdə artıq qurulmuş infrastruktur və təcrübə ola bilər; XML konfiqləri isə git-də review etmək üçün əlverişsizdir. Mənim default seçimim k6 olardı — JS/TS stack-də işlədiyim üçün skriptlər eyni dildə yazılır, kod kimi saxlanılır və CI-a asan girir. Amma JMeter-in artıq qurulduğu və komandanın onu bildiyi bir yerdə yalnız "daha müasirdir" deyə miqrasiya təklif etmərəm — mövcud işləyən infrastrukturu dəyişməyin öz xərci var. Bu son cümlə cavabı praqmatik göstərir və interview-da məhz bu qiymətləndirilir.

Question 1

Performans testi ilə təcrübən varmı? QA-nın bu sahədəki rolu nədir?

Accepted Answer

Dürüst və struktrulu cavab veriləcək sualdır — burada təcrübəni şişirtmək təhlükəlidir, çünki bir follow-up sualla açılır. Mənim çərçivəm: "Mən performans mühəndisi deyiləm, amma sahəni başa düşürəm və QA olaraq dörd konkret şey edirəm." (1) Tələbi ölçülə bilən edirəm — "sürətli olsun" tələbini qəbul etmirəm; "axtarış nəticəsi p95 < 1.5s, 500 eyni vaxtlı istifadəçidə" formasına salıram. Bu, çox vaxt ən dəyərli töhfədir, çünki ölçülməyən tələb heç vaxt yoxlanmır. (2) Frontend tərəfini pipeline-a qoşuram — Lighthouse CI ilə LCP/CLS/INP üçün budget; hədd keçiləndə PR bloklanır. Bu, performans regressiyasını funksional bug kimi tutur. (3) Funksional suite-dən siqnal alıram — suite müddətinin qəfil artması çox vaxt məhsulun yavaşlamasının erkən əlamətidir; bunu araşdırıram. (4) Yük testində iştirak edirəm — k6 ilə sadə ssenari yaza bilirəm (JS olduğu üçün əlverişlidir), amma ciddi yük modeli, infrastruktur profilləşdirməsi və nəticələrin dərin analizi üçün performans mütəxəssisi ilə işləyirəm. Sərhədi açıq demək zəiflik deyil — əksinə, öz səlahiyyət sahəsini bilmək güclü siqnaldır.

Question 2

Product owner deyir: "Səhifə yavaşdır, test yazın." Nə edirsən?

Accepted Answer

"Yavaş" ölçülə bilən deyil, ona görə birinci işim tələbi dəqiqləşdirməkdir — və bu suala verilən ən yaxşı cavab məhz sual verməkdir. Soruşacağım şeylər: (1) Kim üçün yavaşdır? Şikayət hansı istifadəçilərdən gəlir — mobil, müəyyən region, konkret səhifə? (2) Nə vaxt yavaşdır? Həmişəmi, yoxsa pik saatlarda (bu, yük problemidir, frontend problemi yox)? (3) Nə qədər yavaş qəbul ediləndir? Hədəf rəqəm nədir? (4) Nə dəyişib? Son release-dən sonra başlayıbsa, bu, regressiyadır və müqayisə nöqtəmiz var. Sonra problemi təsnif edirəm, çünki həlli tamamilə buradan asılıdır: frontend problemi (böyük bundle, optimizasiya olunmamış şəkillər, render bloklayan skriptlər) → Lighthouse CI, budget, RUM datası; backend problemi (yavaş sorğu, N+1, indeks yoxdur) → APM, birbaşa API cavab müddətinin ölçülməsi; yük problemi (yalnız pik saatlarda) → k6 ilə yük testi. Sonda dürüst çərçivə qururam: "test yazmaq" özü problemi həll etmir — ölçmə və diaqnoz lazımdır. Mən ölçməni qura bilərəm və regressiyanın təkrarlanmaması üçün budget qoya bilərəm; optimizasiyanın özü isə komanda işidir. Bu cavab strukturu — sual → təsnifat → uyğun alət — həm burada, həm oxşar suallarda işləyir.

Question 3

Funksional avtotestlərdən performans haqqında hansı siqnalları çıxara bilərsən?

Accepted Answer

Funksional suite performans ölçmə aləti deyil, amma erkən xəbərdarlıq sistemi kimi çox dəyərlidir — və bu ayrımı saxlayaraq danışmaq vacibdir. Çıxardığım siqnallar: (1) Suite müddətinin trendi — testlər dəyişməyib, amma suite 12 dəqiqədən 18-ə çıxıbsa, ya infrastruktur, ya məhsul yavaşlayıb; hər ikisi araşdırılmalıdır. Bu trendi mən dashboard-da izləyirəm. (2) Konkret testlərin müddəti — Playwright hesabatı testləri müddətə görə sıralayır; bir testin qəfil iki dəfə uzanması adətən konkret bir səhifənin və ya sorğunun yavaşlaması deməkdir. (3) Timeout-a düşən assertion-lar — əvvəllər 2 saniyədə keçən yoxlama indi 5 saniyə timeout-a dirənirsə, bu, flakiness kimi görünür, amma əslində performans regressiyası ola bilər. Bu, ən çox səhv təsnif edilən haldır. (4) Trace-dəki network timing-ləri — hansı sorğunun uzandığı dəqiq görünür və bu, birbaşa backend komandasına ötürüləcək faktdır. Məhdudiyyəti mütləq deyirəm: bu rəqəmlər CI mühitindən, paralellikdən və şəbəkədən asılıdır, yəni mütləq dəyər kimi istifadə edilə bilməz — yalnız trend və nisbət kimi. Rəsmi ölçü üçün nəzarət olunan mühitdə Lighthouse və ya yük aləti lazımdır. Bu cavab yaxşıdır, çünki mövcud alətdən əlavə dəyər çıxarmağı göstərir — və eyni zamanda həddi aşmır.

Question 4

k6 ilə JMeter arasında seçim etməli olsan, nəyi əsas götürərdin?

Accepted Answer

Alət seçimi sualında düzgün refleks kontekstdən başlamaqdır — "k6 daha yaxşıdır" cavabı zəifdir. Soruşduqlarım: komandanın mövcud bacarıqları hansıdır? Testlər CI-da işləyəcəkmi, yoxsa əl ilə? Nəticələr harada saxlanacaq? Mövcud yük testləri varmı? Bundan sonra müqayisəm: k6 — skriptlər JS-dədir, yəni bizim komanda üçün öyrənmə xərci demək olar ki, sıfırdır; skriptlər adi kod kimi git-də saxlanılır və review olunur; CLI-first olduğu üçün CI-a təbii qoşulur; nəticə hədləri (thresholds) konfiqin bir hissəsidir, yəni SLA maşınla yoxlanan qaydaya çevrilir. JMeter — GUI ilə işləmək qeyri-proqramçılar üçün asandır; plagin ekosistemi çox genişdir (ekzotik protokollar: JDBC, JMS, LDAP); enterprise mühitlərdə artıq qurulmuş infrastruktur və təcrübə ola bilər; XML konfiqləri isə git-də review etmək üçün əlverişsizdir. Mənim default seçimim k6 olardı — JS/TS stack-də işlədiyim üçün skriptlər eyni dildə yazılır, kod kimi saxlanılır və CI-a asan girir. Amma JMeter-in artıq qurulduğu və komandanın onu bildiyi bir yerdə yalnız "daha müasirdir" deyə miqrasiya təklif etmərəm — mövcud işləyən infrastrukturu dəyişməyin öz xərci var. Bu son cümlə cavabı praqmatik göstərir və interview-da məhz bu qiymətləndirilir.

Sual	UI testi cavab verə bilir?	Düzgün alət
Səhifə tək istifadəçi üçün nə qədər tez açılır?	Qismən — indikativ ölçü kimi	Lighthouse CI (daha dəqiq və müqayisə oluna bilən)
500 eyni vaxtlı istifadəçidə sistem dayanırmı?	Xeyr	k6 / JMeter — protokol səviyyəli yük
LCP son release-dən sonra pisləşibmi?	Qismən	Lighthouse CI + performance budget
24 saatlıq yükdə yaddaş sızması varmı?	Xeyr	Soak test + serverin monitorinqi (APM)
Düymə basıldıqdan sonra UI donurmu?	Bəli — funksional test bunu tutur	Playwright (assertion timeout-u siqnal verir)

Performans testinin əsasları

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