Question 1

Severity və priority arasındakı fərq nədir?

Accepted Answer

Üç cümlə ilə cavab ver — bu, sürətli raund üçün ideal uzunluqdur. Severity bug-ın sistemə texniki təsiridir; priority onun nə qədər tez düzəldilməli olmasıdır və bu, biznes qərarıdır. Severity-ni adətən tester, priority-ni PO və ya lead təyin edir. Sonra iki əks nümunə ver — məhz bu, cavabı tam edir: nadir istifadə olunan köhnə səhifədə crash (high severity, low priority) və ana səhifədə şirkət adında hərf səhvi (low severity, high priority). Əlavə bal üçün bir cümlə də de: "İkisi həmişə üst-üstə düşmür — məhz buna görə ayrı sahələr kimi mövcuddur."

Question 2

Bug lifecycle-ı addım-addım danış.

Accepted Answer

Əsas yolu bir nəfəsə say: New → Assigned → In Progress → Fixed → Ready for retest → Verified → Closed. Sonra dərhal alternativ statuslara keç — namizədlərin çoxu burada dayanır və məhz bu, fərqlənmə nöqtəsidir: retest uğursuz olsa Reopened, təkrar bug Duplicate, reproduksiya olunmasa Cannot reproduce, nəzərdə tutulan davranış Not a bug, təxirə salınsa Deferred. Sonda bir praktik nüans əlavə et: "Bug-ı adətən onu açan bağlayır — retest-dən sonra. Və 'Deferred' statusu unudulmamalıdır: ona sahib və tarix təyin olunmalıdır, əks halda bug səssizcə itir." Bu nüans real təcrübə siqnalıdır.

Question 3

Positive və negative testing fərqi nədir? Nümunə ver.

Accepted Answer

Positive testing — sistem düzgün, gözlənilən datada düzgün nəticə verirmi. Negative testing — sistem yanlış datada düzgün şəkildə imtina edirmi: crash yox, 500 xətası yox, aydın və faydalı error mesajı. Nümunə üçün bir sahə seç və hər ikisini göstər: "Sığorta formasında yaş sahəsi 18-65 qəbul edir. Positive: 40 daxil edirəm — qəbul olunur. Negative: boş sahə, 17, 66, -5, 18.5, 'abc', 200 simvolluq mətn, xüsusi simvollar — hər birində aydın validasiya mesajı gözləyirəm." Sonda vacib cümlə: "Praktikada bug-ların çoxu negative ssenarilərdə tapılır, çünki developer əsasən happy path-ı düşünərək kodlayır."

Question 4

Black box, white box və grey box testing — sən hansını edirsən?

Accepted Answer

Əvvəlcə üçünü qısa ayır: black box — daxili kodu bilmədən, yalnız input/output üzrə; white box — kod strukturunu bilərək, adətən developer və unit testlər; grey box — qismən daxili biliklə. Sonra özün haqqında dürüst cavab ver — bu, cavabın ən güclü hissəsidir: "Formal olaraq manual QA black box edir, amma praktikada mən əsasən grey box-dayam: DB strukturunu bilirəm və SQL ilə nəticəni yoxlayıram, API endpoint-lərini bilirəm və Postman ilə birbaşa test edirəm, log-lara baxıram. Bu, bug-ı frontend-də yoxsa backend-də olduğunu dəqiqləşdirməyə imkan verir və bug report-un keyfiyyətini xeyli artırır." Bu cavab həm terminologiyanı, həm real bacarıqları bir yerdə göstərir.

Question 5

Sürətli nəzəriyyə raunduna necə hazırlaşırsan?

Accepted Answer

Hazırlığımın üç qaydası var. Birincisi — formul: hər cavab 2-3 cümlədir: tərif, nə ilə qarışdırılır, bir konkret nümunə. Bu struktur olmadan ya çox qısa, ya da çox uzun danışılır. İkincisi — səsli məşq: sualları oxuyub ucadan cavab verirəm və vaxtı ölçürəm. Beyində "bilmək" ilə 30 saniyəyə səlis danışmaq fərqli bacarıqlardır və yalnız ikincisi interviewdə görünür. Üçüncüsü — nümunələr öz təcrübəmdən: hər əsas anlayış üçün öz işimdən bir nümunə hazır saxlayıram; ümumi kitab nümunəsi əvəzinə real hal danışmaq cavabı dərhal inandırıcı edir. Əlavə edə bilərsən: "Bilmədiyim termin gələrsə, uydurmuram — bunu deyirəm və məntiqi ehtimal irəli sürürəm." Bu, öz-özünə dürüstlük siqnalıdır.

Sual ("X ilə Y-in fərqi?")	Model cavab
Severity vs Priority	Severity — bug-ın sistemə texniki təsiri; priority — nə qədər tez düzəldilməli olması. Severity-ni tester, priority-ni PO/lead təyin edir. Nümunə: nadir istifadə olunan səhifədə crash — high severity, low priority; ana səhifədə şirkət adında hərf səhvi — low severity, high priority.
Verification vs Validation	Verification — məhsulu düzgün qururuqmu (spesifikasiyaya uyğunluq, review və static yoxlamalar). Validation — düzgün məhsulu qururuqmu (real user ehtiyacına cavab verirmi, dynamic test və UAT). Nümunə: requirement review verification-dır, UAT validation-dır.
Smoke vs Sanity	Smoke — geniş və dayaz: build ümumiyyətlə işləkdirmi, test etməyə dəyərmi. Sanity — dar və dərin: konkret dəyişiklik və ya fix məntiqli işləyirmi. Smoke build-i qəbul etmək qərarı üçün, sanity kiçik dəyişiklikdən sonra.
Re-testing vs Regression	Re-testing — konkret bug-ın düzəldiyini eyni addımlarla yoxlamaq. Regression — həmin dəyişikliyin başqa işləyən sahələri sındırmadığını yoxlamaq. Re-testing hər fix-dən sonra, regression isə release-dən əvvəl və əhəmiyyətli dəyişikliklərdən sonra.
Black box vs White box vs Grey box	Black box — daxili kodu bilmədən, yalnız input/output üzrə (manual QA-nın əsas yanaşması). White box — kod strukturunu bilərək (adətən developer, unit test). Grey box — qismən daxili bilik ilə: DB strukturunu, API-ni və ya arxitekturanı bilib UI-dan test etmək — manual QA praktikada çox vaxt məhz buradadır.
Positive vs Negative testing	Positive — sistem düzgün datada gözlənilən nəticəni verirmi. Negative — sistem yanlış datada düzgün şəkildə imtina edirmi (crash yox, aydın error mesajı). Nümunə: email sahəsinə düzgün email — positive; "user@@mail" və ya boş sahə — negative.
Error vs Defect vs Failure	Error — insanın etdiyi səhv (developer spesifikasiyanı yanlış oxuyur). Defect/bug — həmin səhvin koda düşmüş nəticəsi. Failure — defektin icra zamanı görünən təzahürü (istifadəçi yanlış məbləği görür). Zəncir: error → defect → failure.
Test case vs Test scenario vs Checklist	Test scenario — nəyi test edəcəyimizin yüksək səviyyəli təsviri ("poliso yenilənməsi"). Test case — həmin ssenarinin addım-addım, gözlənilən nəticəli konkret variantı. Checklist — yoxlanılacaqların qısa siyahısı, addımsız; sürətli komandalarda test case-in yüngül əvəzidir.
Alpha vs Beta testing	Alpha — şirkət daxilində, nəzarət olunan mühitdə, daxili istifadəçilər tərəfindən. Beta — real istifadəçilər tərəfindən öz real mühitlərində, release-dən əvvəl. Hər ikisi acceptance testing növüdür.
Load vs Stress testing	Load — gözlənilən normal yük altında sistem tələb olunan cavab müddətini saxlayırmı. Stress — sistemi sınma nöqtəsinə qədər yükləyib həddi tapmaq və necə sındığına baxmaq (aydın error verirmi, yoxsa data korlanır).

Tək anlayış sualı	Model cavab
Bug lifecycle-ı danış	New → Assigned → In Progress → Fixed → Ready for retest → Verified → Closed. Alternativ yollar: retest uğursuz olsa Reopened; bug təkrar olsa Duplicate; reproduksiya olunmasa Cannot reproduce; nəzərdə tutulan davranış olsa Not a bug; sonraya saxlanılsa Deferred. Vacib nüans: bug-ı adətən onu açan bağlayır.
Testing-in 7 prinsipi	Testing defektlərin varlığını göstərir (yoxluğunu yox); exhaustive testing mümkün deyil; early testing; defect clustering; pesticide paradox; testing kontekstdən asılıdır; absence-of-errors fallacy. Sürətli raundda hamısını sadalayıb birini nümunə ilə açmaq kifayətdir.
Boundary Value Analysis nədir?	Bug-ların əksəriyyəti sərhədlərdə yaşadığı üçün sərhəd dəyərlərini və onların hər iki tərəfini test edən texnikadır. 18-65 aralığı üçün: 17, 18, 19 və 64, 65, 66. Adətən Equivalence Partitioning ilə birlikdə istifadə olunur.
Requirement Traceability Matrix nədir?	Hər requirement-i onu yoxlayan test case-lərlə (və tapılan defektlərlə) əlaqələndirən cədvəldir. Məqsəd: heç bir requirement-in test olunmadan qalmadığını göstərmək və dəyişiklik olanda təsir dairəsini tez müəyyən etmək.
Exit criteria nədir?	Testi bitmiş saymaq üçün əvvəlcədən razılaşdırılmış, ölçülə bilən şərtlər: açıq Critical/High bug yoxdur, planlanan case-lərin ≥95%-i icra olunub, kritik axınların regression-u keçib. Onların əsas faydası "nə vaxt bitir?" sualını subyektiv hissdən çıxarmaqdır.
Shift-left nə deməkdir?	Test fəaliyyətlərinin SDLC-nin daha erkən fazalarına çəkilməsi: QA refinement-dən qoşulur, requirement-ləri review edir, AC-lərin yoxlanıla bilən olmasını təmin edir. Səbəbi sadədir — erkən tapılan defekt dəfələrlə ucuz başa gəlir.
Test olunmuş halda bug production-a düşərsə, bu kimin günahıdır?	Bu, günah sualı deyil — komanda nəticəsidir. Testing bütün defektlərin yoxluğunu sübut edə bilməz (1-ci prinsip). Doğru reaksiya: təsiri qiymətləndirmək, hotfix-i yoxlamaq, sonra blameless kök səbəb analizi — bu ssenari niyə scope-a düşməyib və hansı proses dəyişikliyi onu gələcəkdə tutar.

Sürətli nəzəriyyə sualları