Bu bölmə QA mühəndisi müsahibələrində ən çox verilən sualları və ideal cavablarını əhatə edir.
1. ƏSAS ANLAYIŞLAR
S: QA ilə Testing arasındakı fərq nədir?
C: QA (Quality Assurance) proses yönümlüdür – bug-ların baş verməsinin qarşısını almaq üçün prosesləri yaxşılaşdırır. Testing isə məhsul yönümlüdür – mövcud bug-ları tapmağa çalışır. Sadə dillə: QA niyə bug baş verir sualını cavablandırır, Testing isə bug varmı sualını.
S: SDLC ilə STLC fərqi nədir?
C: SDLC (Software Development Life Cycle) bütün proqram hazırlama prosesini – tələb, dizayn, kod, test, deploy, maintenance mərhələlərini əhatə edir. STLC (Software Testing Life Cycle) isə yalnız test hissəsini – requirement analysis, test planning, test case development, environment setup, execution, closure mərhələlərini əhatə edir. Agile-da hər sprint-də paralel gedirlər.
S: Verification vs Validation nədir?
C: Verification: 'Məhsulu düzgün hazırlayırıqmı?' – sənədlər, kod, dizayn tələblərə uyğundurmu? Validation: 'Düzgün məhsulu hazırlayırıqmı?' – məhsul istifadəçinin real ehtiyaclarını ödəyirmi? Mnemonic: Verification = spec-ə uyğun, Validation = user-ə uyğun.
S: Severity vs Priority fərqi nədir? Nümunə ver.
C: Severity bug-un sistemə texniki təsir dərəcəsidir. Priority isə bug-un nə qədər tez fix edilməli olduğudur. Nümunə 1: Logo yanlış rəngdədir. Severity: Low (texniki baxımdan kiçik problem). Priority: High (müştəri görür, brend zədələnir). Nümunə 2: Admin panel crash edir. Severity: Critical. Priority: Medium (son istifadəçiyə birbaşa təsiri yoxdur).
S: Bug Life Cycle-ı izah et.
C: New: tester bug tapır → Assigned: menecer developer-ə verir → Open: developer baxır → Fixed: düzəldildi → Retest: tester yenidən yoxlayır → Closed (fix düzgündürsə) / Reopen (hələ də var). Deferred statusu da var – bug sonraya saxlanılır.
2. TEST NÖVLƏRI
S: Smoke Testing nədir?
C: Smoke Testing – hər yeni build-dən sonra kritik funksiyaların işlədiyini yoxlayan sürətli test (10-30 dəqiqə). 'Build Verification Testing' da deyilir. Əgər smoke test keçərsə, QA komandası tam testə davam edir. Keçməzsə, build development-ə qaytarılır.
S: Sanity Testing nədir, Smoke-dan fərqi nədir?
C: Sanity Testing – kiçik dəyişiklikdən sonra dəyişikliyin düzgün işlədiyini yoxlayan dar, dərin testdir. Smoke: geniş, səthi (bütün kritik funksiyalar). Sanity: dar, dərin (yalnız dəyişiklik edilən hissə). Smoke acceptance testing alt növü, Sanity isə regression alt növü.
S: Regression Testing nədir və nə zaman lazımdır?
C: Regression Testing – yeni dəyişikliklərin köhnə funksionallıqları pozmadığını yoxlayır. Lazımdır: yeni feature əlavə edildikdə, bug fix sonrası, refactoring-dən sonra, hər release öncəsi. Pesticide paradox: eyni testləri təkrarlarsan yeni bug tapmaq çətinləşir – həll: müntəzəm yeni test case-lər əlavə etmək.
S: Black Box, White Box, Grey Box fərqi nədir?
C: Black Box: kodun daxilini bilmirsən, yalnız input/output, QA Engineer edir. White Box: daxili kodu bilirsən, hər branch test edilir, Developer/SDET edir. Grey Box: qismən bilgi (DB şeması, API), hibrid yanaşma, QA + Developer birlikdə edir. İstifadə: Black box = system test, White box = unit test, Grey box = integration test.
3. API TESTİNG
S: 401 vs 403 fərqi nədir?
C: 401 Unauthorized: autentikasiya problemi. Token yoxdur, bitib, yanlışdır. Həll: yenidən login et. 403 Forbidden: avtorizasiya problemi. Token var, amma bu resursa icazə yoxdur. Həll: rol dəyiş. Sadə izah: 401 = 'Sən kimsən bilmirəm', 403 = 'Sən kimsən bilirəm, amma bura girə bilməzsən'.
S: İdempotent API nədir?
C: İdempotent API – eyni sorğunu dəfələrlə göndərdikdə sistemin vəziyyəti dəyişmir. GET, PUT, DELETE idempotentdir. POST idempotent deyil – hər göndərişdə yeni resurs yaranır. Bank əməliyyatlarında kritikdir: şəbəkə kəsilib sorğu təkrar göndərilirsə, ikinci dəfə pul çıxmamalıdır.
S: POST vs PUT vs PATCH fərqi nədir?
C: POST: yeni resurs yaradır, idempotent deyil (hər dəfə yeni qeyd). PUT: mövcud resursu tam əvəz edir, idempotent (bütün sahələri göndərməlisən). PATCH: qismən yeniləmə, yalnız dəyişdiriləcək sahəni göndər. Nümunə: User-in yalnız telefon nömrəsini dəyişmək üçün PATCH istifadə et – bütün user məlumatını göndərməyə gərək yoxdur.
S: HTTP 409 Conflict nədir? Nümunə ver.
C: HTTP 409 – sorğu resursun cari vəziyyəti ilə ziddiyyət təşkil edir. Nümunə 1: Eyni email ilə ikinci dəfə qeydiyyat. Nümunə 2: Çatdırılmış sifarişi ləğv etməyə çalışmaq. Nümunə 3: Optimistic locking – iki nəfər eyni məlumatı eyni anda dəyişdirməyə çalışır.
S: Access Token vs Refresh Token nədir?
C: Access Token: qısa ömürlü (15 dəq – 1 saat), API-yə hər sorğuda Authorization: Bearer header-ında göndərilir. Refresh Token: uzun ömürlü (günlər, həftələr), access token bitdikdə yeni access token almaq üçün istifadə edilir, HTTP-only cookie-də saxlanır. Niyə ikisi? Access token oğurlananda az zərər olsun deyə qısa ömürlüdür.
S: REST vs SOAP fərqi nədir?
C: REST: JSON/XML, sürətli, yüngül, web/mobile app üçün ideal. SOAP: yalnız XML, ağır, ciddi standartlar, enterprise/banking sistemlər üçün. REST daha populyardır çünki sürətli, developer-dostu və çevik. SOAP isə WS-Security ilə güclü built-in təhlükəsizlik təklif edir.
4. TEST DESİGN
S: Equivalence Partitioning nədir?
C: Giriş dəyərlərini ekvivalent siniflərə bölürük. Hər sinifdən bir dəyər test etmək kifayətdir. Məsələn, 18-60 yaş arası etibarlı sahə: siniflər – etibarsız (≤17), etibarlı (18-60), etibarsız (≥61). Test dəyərləri: 17, 30, 61. Bu yanaşma test case sayını azaldır.
S: Boundary Value Analysis nədir?
C: Sərhədlərdə xəta olma ehtimalı daha yüksəkdir. 18-60 aralığı üçün test dəyərləri: 17 (etibarsız), 18 (etibarlı min), 19 (etibarlı), 59 (etibarlı), 60 (etibarlı max), 61 (etibarsız). BVA adətən EP ilə birlikdə istifadə edilir.
S: Test Pyramid nədir?
C: Mike Cohn-un modeli. Üç səviyyə: Unit Test (80%) – tək funksiya, sürətli, ucuz, mock istifadə edir. Integration Test (15%) – modullar arası, DB, API. E2E Test (5%) – tam sistem, real brauzer, yavaş, bahalı. Anti-pattern: 'Ice cream cone' – E2E sayı unit-dən çox, yavaş və kövrək sistem yaranır.
S: Pesticide Paradox nədir?
C: Eyni test case-ləri təkrarlasan, yeni bug tapmaq çətinləşir – böcəklər pestisidə müqavimət kimi. Həll yolları: müntəzəm yeni test case-lər əlavə etmək, exploratory testing aparmaq, fərqli test data istifadə etmək, mutation testing tətbiq etmək.
5. AGILE / SCRUM
S: Scrum-da QA-nın rolu nədir?
C: Sprint Planning-də: user story seçmək, effort estimation etmək, acceptance criteria müəyyən etmək. Sprint-də: developer-lərə unit test-də kömək, story tamamlandıqda test etmək, defect log etmək. Daily Scrum: əncam, plan, maneə bildirmək. Sprint Review: test nəticələrini demo etmək. Retrospective: proses haqqında rəy bildirmək.
S: DoR vs DoD nədir?
C: Definition of Ready (DoR): user story-nin sprint-ə daxil edilməyə hazır olması kriteriyaları – story yazılıb, acceptance criteria var, story point var, dependency yoxdur. Definition of Done (DoD): user story-nin 'tamam' sayılması üçün kriteriyalar – kod yazılıb, unit test keçir, code review olub, QA test edib, deploy olunub.
S: Velocity nədir?
C: Komandanın bir sprint-də ortalama bitirdiyi story point sayı. Son 3 sprint-in ortalaması alınır. Sprint planning-də gələcək sprint-i planlamaq üçün istifadə edilir. Vacib: velocity komandalar arası müqayisə edilə bilməz – hər komandanın story point-i fərqlidir.
6. TEST SƏNƏDLƏŞMƏSİ VƏ LOGGING
S: Log levels-ləri izah et.
C: DEBUG: detallı texniki məlumat, development üçün. INFO: normal sistem fəaliyyəti (user login etdi). WARN: risk var amma sistem işləyir (retry cəhdi). ERROR: xəta baş verdi, sistem işlər (ödəniş servisi 500 verdi). FATAL: sistem ciddi zədələndi (application crash). QA bug report-a ERROR və FATAL-ları əlavə etməlidir.
S: Bug report-da log necə istifadə olunur?
C: Bug report-da: addımları icra edərkən eyni vaxtda log-u izlə. Bug baş verdikdə log-dan error mesajını, stack trace-i, timestamp-i kopyala. Bug report-a əlavə et: bu, developer-ə səbəbi tapmaqda kömək edir. Sensitive data (şifrə, kart) log-da görünürsə bu ayrı bir security bug-dır.
S: RTM nədir?
C: Requirement Traceability Matrix – hər bir tələbin müvafiq test case-lərlə əlaqəsini göstərən cədvəl. Məsələn: REQ-001 → TC-001, TC-002, TC-003. Test coverage-ı izləmək, hansı tələbin test edilib-edilmədiyini görmək üçün istifadə edilir. STLC-nin Requirement Analysis mərhələsinin output-u.
7. FƏLSƏFƏ VƏ ƏSAS PRİNSİPLƏR
S: 7 Testing Prinsipi nədir?
C: 1. Testing hər yerdə bug olduğunu sübut edir, yoxluğunu yox. 2. Exhaustive testing mümkün deyil. 3. Early testing – tez başla. 4. Defect clustering – bug-lar bir yerdə toplanır. 5. Pesticide paradox – eyni testlər yeni bug tapmaz. 6. Testing context-dependent – hər sistem üçün fərqli. 7. Absence of errors fallacy – bug yoxdur ≠ yaxşı məhsul.
S: Exploratory Testing nədir?
C: Formal test case olmadan, öyrənərək test etmək. Tester sezgisindən və təcrübəsindən istifadə edir. Xüsusilə: az sənədli sistemlər, kreativ ssenarilər, son dəqiqə testlər üçün faydalı. Session-based: vaxt məhdud tutulur (məs: 90 dəqiqə), yalnız charter (istiqamət) verilir.
S: Positive vs Negative testing nədir?
C: Positive testing: sistemi düzgün, gözlənilən input ilə test edirsən. Məsələn: düzgün email + şifrə ilə login. Negative testing: yanlış, qeyri-standart input ilə sistemin düzgün xəta verməsini yoxlayırsın. Məsələn: boş email, çox uzun şifrə, xüsusi simvollar. Hər ikisi vacibdir!
S: Test case yazarkən nəyə diqqət etməliyik?
C: Qısa, aydın başlıq. Dəqiq precondition-lar. Addımların ardıcıllığı. Bir test case – bir məqsəd. Expected result dəqiq yazılmalı. Müstəqil olmalı – başqa test case-dən asılı olmamalı. Test data daxil edilməli. Həm pozitiv, həm neqativ ssenarilər əhatə edilməli.
8. PRATİK SUALLAR
S: Login səhifəsini necə test edərdin?
C: Positive: düzgün email+şifrə → dashboard-a keçid. Negative: yanlış şifrə → error mesajı. Boş email/şifrə → validation. Çox uzun string → limit yoxlaması. SQL injection: ' OR '1'='1. XSS: <script>alert(1)</script>. Şifrəni çox dəfə yanlış daxil et → account lock. Şifrəni unut funksiyası. Remember me checkbox. Session management – tab bağla, aç, session qalırmı?
S: API üçün test case-lər necə yazılır?
C: Hər HTTP metodu üçün test: GET – 200 və düzgün data, GET yanlış ID – 404. POST – 201 yaradıldı, POST eyni data – 409. PUT – 200 tam yeniləndi. DELETE – 204. Autentikasiya: token olmadan – 401. Başqa rolun resursu – 403. Edge cases: boş body, yanlış JSON format – 400. Performance: response time < 2s.
S: Hansı bug report alətlərini bilirsən?
C: Jira – ən geniş istifadə edilən, Agile integration güclü. Redmine – open source. TestRail – xüsusi test management. Azure DevOps – Microsoft ekosistemi. Bugzilla – köhnə, amma hələ istifadə edilir. Zephyr – Jira üçün test management plugin. Hər birinin güclü və zəif tərəfləri var – kontekstə görə seçim edilir.
S: Bir bug tapanda ilk nə edirsən?
C: 1. Reproduce et – bug həqiqətən baş verirmi? 2. Reproducibility yoxla – hər dəfə olurmu, bəzən olurmu? 3. Isolation et – minimum addımlarla reproduce et. 4. Mühiti yoxla – yalnız bu environment-dəmi? 5. Log al – konsol, network, server log. 6. Screenshot/video çək. 7. Severity/Priority müəyyən et. 8. Bug report yaz – aydın, dəqiq, addım-addım.
"Problem bug-lar deyil, problem onları kifayət qədər tez tapmamağımızdır."
— Cem Kaner
Geniş izah
Ətraflı praktik bələdçi
Kontekst və məqsəd
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu QA üçün sadəcə termin deyil, real release qərarlarına təsir edən praktik yoxlama sahəsidir. MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu üzrə manual QA, test prosesi və real layihə praktikası üçün Azərbaycan dilində geniş izah. Bu mövzunu düzgün anlamaq test engineer-ə requirement-ləri daha aydın oxumağa, riskləri daha tez görməyə və developer komandası ilə daha konkret danışmağa kömək edir.
Bu yazıda mövzunu həm istifadəçi davranışı, həm texniki risk, həm də test sənədləşməsi tərəfindən izah edirik. Məqsəd yalnız tərif vermək deyil; məqsəd bu mövzunu real layihədə necə tətbiq etməyi göstərməkdir.
Nəyi yoxlamaq lazımdır
Əvvəlcə test ediləcək funksiyanın biznes məqsədi başa düşülməlidir. İstifadəçi bu funksiyanı niyə istifadə edir, hansı məlumatı daxil edir, hansı nəticəni gözləyir və səhv baş verəndə sistem necə reaksiya verməlidir? QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI üçün scope yazanda happy path, negative path, edge case və recovery behavior ayrıca qeyd olunmalıdır.
Əgər mövzu API testing kateqoriyasına aiddirsə, UI yoxlaması ilə kifayətlənmək olmaz. Lazım olan yerdə API cavabı, database nəticəsi, permission səviyyəsi, log mesajı və browser davranışı da yoxlanmalıdır. Bu yanaşma test coverage-i daha real edir.
Test datası və mühitlər
Düzgün test datası olmadan yaxşı QA nəticəsi almaq çətindir. Valid data, invalid data, boş dəyərlər, minimum və maksimum limitlər, duplicate məlumat, expired session, deaktiv istifadəçi və fərqli role-lar əvvəlcədən hazırlanmalıdır.
Environment də eyni dərəcədə vacibdir. Development, staging və production-like mühitlər fərqli data, fərqli permission və fərqli inteqrasiya vəziyyətinə malik ola bilər. Test nəticəsi yazılanda mühit, build versiyası və istifadə olunan data mütləq qeyd edilməlidir.
İcra yanaşması
İcra zamanı əvvəlcə əsas flow yoxlanılır, sonra riskli variantlara keçilir. QA addımları elə yazmalıdır ki, developer həmin problemi eyni şəraitdə təkrar yarada bilsin. Hər addım konkret olmalı, gözlənilən nəticə ilə faktiki nəticə ayrı göstərilməlidir.
Yaxşı yanaşma belədir: əvvəlcə smoke səviyyəsində kritik davranışı yoxla, sonra regression təsirini qiymətləndir, daha sonra boundary, permission, network və data consistency ssenarilərini genişləndir. Bu ardıcıllıq vaxtı qoruyur və ən riskli defektlərin daha tez tapılmasına kömək edir.
Tipik defektlər
Bu mövzuda ən çox rast gəlinən defektlər validation mesajlarının qeyri-dəqiq olması, statusun səhv dəyişməsi, UI ilə backend nəticəsinin uyğun gəlməməsi, role-based access problemleri, data-nın səhv saxlanması və error handling-in zəif olmasıdır.
QA həm də istifadəçinin gözlənilməz davranışını düşünməlidir: iki dəfə klik, səhifəni refresh etmək, geri düyməsi, zəif internet, expired token, boş forma, çox uzun mətn və xüsusi simvollar. Bu hallar sadə happy path testində görünməyən problemləri üzə çıxarır.
Sübut və reportlama
Bug report yazılanda sübut əsasdır. Screenshot, screen recording, console error, network response, request payload, response body, SQL nəticəsi və log timestamp-i developer üçün çox dəyərlidir. Report qısa olsa da, səbəbi tapmağa kömək etməlidir.
Report-da impact də yazılmalıdır. Problem istifadəçini bloklayırmı, data itkisinə səbəb olurmu, security riski yaradırmı, yoxsa yalnız vizual uyğunsuzluqdur? Severity texniki təsiri, priority isə biznes təciliyini göstərməlidir.
Praktik checklist
Praktik checklist: requirement oxundu və anlaşılmaz hissələr soruşuldu; əsas user flow test edildi; negative case-lər yoxlandı; boundary və boş dəyərlər sınandı; uyğun yerlərdə API və database yoxlaması aparıldı; console/network error-ları izlənildi; bug report üçün sübut toplandı; regression təsiri qiymətləndirildi.
Final sign-off-dan əvvəl açıq critical və major bug qalmamalıdır. Əgər risk qalırsa, QA bunu gizlətməməli, release note və ya risk summary formasında komandaya bildirməlidir.
QA üçün nəticə
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu üzrə güclü QA işi təkrarlana bilən, sübuta əsaslanan və real product riskinə bağlı olmalıdır. Məqsəd çox test yazmaq deyil, düzgün yerdə düzgün yoxlama aparmaqdır. Bu yanaşma release-ləri daha etibarlı edir və QA-nı komanda üçün qərarvermə tərəfdaşına çevirir.
Expanded guide
Detailed practical guide
Context and purpose
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI is not just a definition for QA; it is a practical area that affects release confidence and product risk. MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu üzrə manual QA, test prosesi və real layihə praktikası üçün Azərbaycan dilində geniş izah. A QA engineer should understand how this topic appears in requirements, user behavior, implementation details, and defect reports.
The goal of this guide is to make the topic usable in real work. Instead of memorizing the term, QA should know how to test it, how to collect evidence, and how to explain the risk to developers and product owners.
What to verify
Start with the business purpose of the feature. Identify the main user flow, alternative flows, permissions, data states, and expected system behavior. For QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI, scope should include happy path, negative path, edge cases, recovery behavior, and regression impact.
When the topic touches API testing, do not stop at the UI. Check API responses, saved data, browser behavior, logs, permissions, and environment-specific behavior when they are relevant. That gives the team stronger coverage and fewer blind spots.
Test data and environments
Good test data is the foundation of strong QA. Prepare valid records, invalid records, empty values, duplicates, boundary values, long strings, special characters, disabled users, expired sessions, and different roles.
Environment details matter as well. Development, staging, and production-like environments may have different integrations, data quality, feature flags, and permissions. Every meaningful result should mention environment, build version, user role, and test data.
Execution approach
Execution should move from the critical flow to the risky variations. Write steps so another person can reproduce the same result. Expected result and actual result should be separate, concrete, and easy to compare.
A practical order is: smoke-check the core behavior, analyze regression impact, expand into boundary and permission scenarios, then validate API, database, logs, and UI consistency where needed. This protects time while still finding important defects early.
Common defects
Common defects include unclear validation messages, incorrect status changes, broken permissions, weak error handling, data not saved correctly, UI and backend mismatch, duplicate actions, and inconsistent loading states.
QA should also think about unexpected user behavior: double click, refresh, back button, slow network, expired token, empty form, very long input, special characters, and interrupted sessions. These cases reveal issues that happy-path testing often misses.
Evidence and reporting
Evidence makes a bug report useful. Add screenshots, screen recordings, console errors, network responses, request payloads, response bodies, SQL evidence, timestamps, and logs when they help explain the issue.
A strong report also explains impact. Does the issue block the user, risk data loss, create a security concern, or damage trust visually? Severity should describe technical impact, while priority should describe business urgency.
Practical checklist
Practical checklist: requirements reviewed; unclear points clarified; main flow tested; negative cases covered; boundary and empty values checked; API and database validated where relevant; console and network errors reviewed; evidence collected; regression impact assessed.
Before sign-off, no critical or major issue should remain unexplained. If a risk is accepted, QA should make it visible in a release note, test summary, or risk comment so the team makes a conscious decision.
QA takeaway
Strong QA for QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI is repeatable, evidence-based, and connected to real product risk. The aim is not to write more tests for the sake of volume; the aim is to test the right behavior with the right data and communicate the result clearly.
Geniş açıklama
Detaylı pratik rehber
Bağlam ve amaç
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI QA için sadece bir tanım değildir; release güvenini ve product riskini etkileyen pratik bir alandır. MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu üzrə manual QA, test prosesi və real layihə praktikası üçün Azərbaycan dilində geniş izah. QA engineer bu konuyu requirement, kullanıcı davranışı, teknik uygulama ve bug report bağlamında anlamalıdır.
Bu rehberin amacı terimi ezberletmek değil, gerçek projede nasıl test edileceğini göstermektir. QA neyi kontrol edeceğini, hangi kanıtı toplayacağını ve riski ekibe nasıl anlatacağını bilmelidir.
Neyi kontrol etmek gerekir
Önce feature'ın iş amacını anlamak gerekir. Ana user flow, alternatif flow'lar, permission'lar, data state'leri ve beklenen sistem davranışı belirlenmelidir. QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI için scope happy path, negative path, edge case, recovery behavior ve regression impact içermelidir.
API testing alanına dokunan konularda sadece UI kontrolü yeterli değildir. Gerektiğinde API response, kaydedilen data, browser behavior, log, permission ve environment farkları da kontrol edilmelidir.
Test datası ve ortamlar
Güçlü QA için doğru test datası şarttır. Valid record, invalid record, boş değer, duplicate data, boundary value, uzun metin, özel karakter, disabled user, expired session ve farklı roller hazırlanmalıdır.
Environment bilgisi de önemlidir. Development, staging ve production-like ortamlar farklı integration, data kalitesi, feature flag ve permission değerlerine sahip olabilir. Test sonucu yazılırken environment, build version, user role ve test data belirtilmelidir.
Uygulama yaklaşımı
Test execution kritik flow ile başlamalı, sonra riskli varyasyonlara geçmelidir. Adımlar başka bir kişinin aynı sonucu reproduce edebileceği kadar net yazılmalıdır. Expected result ve actual result ayrı gösterilmelidir.
Pratik sıra şudur: core behavior için smoke check, regression impact analizi, boundary ve permission senaryoları, sonra gerekli yerlerde API, database, log ve UI consistency kontrolü.
Tipik defectler
Tipik defect'ler: belirsiz validation mesajları, yanlış status değişimi, permission hatası, zayıf error handling, datanın yanlış kaydedilmesi, UI/backend uyumsuzluğu, duplicate action ve tutarsız loading state.
QA beklenmeyen kullanıcı davranışlarını da düşünmelidir: double click, refresh, back button, yavaş internet, expired token, boş form, çok uzun input, özel karakter ve yarım kalmış session.
Kanıt ve raporlama
Bug report kanıtla güçlü olur. Screenshot, screen recording, console error, network response, request payload, response body, SQL evidence, timestamp ve log bilgisi developer için değerlidir.
Report impact de anlatmalıdır. Problem kullanıcıyı blokluyor mu, data loss riski var mı, security concern yaratıyor mu, yoksa visual trust problemi mi? Severity teknik etkiyi, priority biznes aciliyeti gösterir.
Pratik checklist
Pratik checklist: requirement okundu; belirsiz noktalar soruldu; main flow test edildi; negative case'ler kapsandı; boundary ve empty value kontrol edildi; gerekli yerlerde API/database doğrulandı; console/network error'ları izlendi; kanıt toplandı; regression impact değerlendirildi.
Final sign-off öncesinde açık critical veya major issue açıklamasız kalmamalıdır. Risk kabul ediliyorsa QA bunu release note, test summary veya risk comment ile görünür yapmalıdır.
QA için sonuç
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI için güçlü QA işi tekrarlanabilir, kanıta dayalı ve gerçek product riskiyle bağlantılı olmalıdır. Amaç sadece çok test yazmak değil; doğru davranışı doğru data ile test etmek ve sonucu anlaşılır anlatmaktır.
Расширенное руководство
Подробное практическое руководство
Контекст и цель
QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI — это не просто термин для QA, а практическая область, которая влияет на уверенность в релизе и product risk. MÜSAHİBƏ SUALARI VƏ CAVABLARI mövzusu üzrə manual QA, test prosesi və real layihə praktikası üçün Azərbaycan dilində geniş izah. QA engineer должен понимать, как эта тема проявляется в требованиях, поведении пользователя, реализации и defect reports.
Цель этого руководства — показать, как применять тему в реальной работе. QA должен знать, что проверять, какие доказательства собирать и как объяснять риск developers и product owners.
Что проверять
Сначала нужно понять бизнес-цель функции. Определите main user flow, альтернативные flow, permissions, data states и ожидаемое поведение системы. Для QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI scope должен включать happy path, negative path, edge cases, recovery behavior и regression impact.
Если тема связана с API testing, нельзя ограничиваться UI. При необходимости проверяйте API responses, saved data, browser behavior, logs, permissions и различия между environments.
Тестовые данные и среды
Хорошие test data — основа сильного QA. Подготовьте valid records, invalid records, empty values, duplicates, boundary values, long strings, special characters, disabled users, expired sessions и разные roles.
Environment также важен. Development, staging и production-like среды могут отличаться integrations, data quality, feature flags и permissions. В результате теста стоит указывать environment, build version, user role и test data.
Подход к выполнению
Execution должен идти от critical flow к рискованным вариантам. Шаги нужно писать так, чтобы другой человек мог воспроизвести результат. Expected result и actual result должны быть отдельными и конкретными.
Практичный порядок: smoke-check core behavior, анализ regression impact, расширение на boundary и permission scenarios, затем проверка API, database, logs и UI consistency там, где это нужно.
Типовые дефекты
Типовые defects: неясные validation messages, неправильные status changes, broken permissions, слабый error handling, data сохраняется неверно, UI/backend mismatch, duplicate actions и inconsistent loading states.
QA должен учитывать неожиданное поведение пользователя: double click, refresh, back button, slow network, expired token, empty form, very long input, special characters и interrupted sessions.
Доказательства и отчёт
Bug report становится полезным благодаря evidence. Добавляйте screenshots, screen recordings, console errors, network responses, request payloads, response bodies, SQL evidence, timestamps и logs, если они помогают понять проблему.
Хороший report также объясняет impact. Issue блокирует пользователя, создаёт риск data loss, security concern или визуально снижает trust? Severity описывает технический эффект, priority — бизнес-срочность.
Практический checklist
Практический checklist: requirements reviewed; unclear points clarified; main flow tested; negative cases covered; boundary and empty values checked; API/database validated where relevant; console/network errors reviewed; evidence collected; regression impact assessed.
Перед sign-off не должно оставаться необъяснённых critical или major issues. Если риск принимается, QA должен сделать его видимым через release note, test summary или risk comment.
Вывод для QA
Сильный QA для QA Handbook: MÜSAHİBƏ SUALARI VƏ CAVABLARI — repeatable, evidence-based и связан с реальным product risk. Цель не в количестве тестов, а в правильной проверке правильного поведения с правильными данными и понятной коммуникацией результата.
