Agile artefaktları və QA-nın rolu
Agile komandada QA-nın işi "kod hazır olanda test etmək" deyil. Ən böyük dəyəri sprintin əvvəlində yaradır — story hələ yazılarkən. Bunun üçün Agile artefaktlarını yaxşı bilmək lazımdır.
User story — funksionallığın istifadəçi baxımından təsviri: "Müştəri kimi, polisomu onlayn yeniləmək istəyirəm ki, filiala getməyə ehtiyac qalmasın."
Acceptance criteria (AC) — story-nin "hazır" sayılması üçün ödənməli olan konkret, yoxlanıla bilən şərtlər. QA üçün AC test case-lərin əsasıdır: hər AC ən azı bir test case doğurur. AC yazmaq PO-nun işidir, amma onları yoxlanıla bilən etmək QA-nın işidir.
AC formatları: sadə siyahı və ya Gherkin (Given / When / Then) — sonuncu xüsusilə şərt-nəticə məntiqi üçün əlverişlidir.
| Anlayış | Nə deməkdir | QA-nın rolu |
|---|---|---|
| Definition of Ready (DoR) | Story-nin sprintə götürülməyə hazır olması şərtləri (AC var, dizayn var, asılılıqlar aydındır, qiymətləndirilib) | AC-lərin yoxlanıla bilən olduğunu təsdiqləyir; test datası və mühit hazırlığını qaldırır |
| Definition of Done (DoD) | Story-nin bitmiş sayılması şərtləri (kod review olunub, testlər keçib, sənədləşdirilib, deploy olunub) | "Test olunub və açıq Critical/High bug yoxdur" şərtinin DoD-da olmasını təmin edir |
| Backlog refinement | Gələcək story-lərin dəqiqləşdirildiyi və qiymətləndirildiyi görüş | **QA-nın ən dəyərli görüşü**: qeyri-müəyyənlikləri, edge case-ləri və error axınlarını burada qaldırır |
| Sprint planning | Sprintə nə götürüləcəyinin qərarı | Test effortunu qiymətləndirir; hər şeyin son günə yığılmamasını təmin edir |
| Daily standup | Gündəlik 15 dəqiqəlik sinxronizasiya | Blocker-ləri **dərhal** bildirir (build yoxdur, mühit sınıb, data yoxdur) |
| Sprint review / demo | Görülən işin stakeholder-lərə göstərilməsi | Demonun uğurla keçəcəyinə əmin olur; bilinən məhdudiyyətləri əvvəlcədən bildirir |
| Retrospective | Prosesin nəyin işlədiyi/işləmədiyinin müzakirəsi | Keyfiyyət problemlərinin kök səbəbini prosesə çevirir (məs. "AC-lər gec hazır olur") |
Shift-left praktikada nə deməkdir? Şüar deyil, konkret davranışlar toplusudur:
- Refinement-də story-yə sual vermək və cavabları ticket-ə yazmaq
- AC-lərə error və edge halları əlavə etdirmək ("ödəniş uğursuz olsa nə olur?")
- Kod yazılmamışdan əvvəl test case/checklist hazırlamaq və developer ilə paylaşmaq — developer həmin halları özü nəzərə alır
- Developer-lə birgə yoxlama ("bunu mənə 5 dəqiqəyə göstər") — bug tracker-ə düşmədən düzəlir
- Story bitən kimi test etmək, sprintin sonunu gözləməmək
Ən güclü nəticə: shift-left ilə tapılan bug sayı azalır, çünki bug-ların bir hissəsi ümumiyyətlə yaranmır. Bu, metriklə ölçüləndə çaşdırıcı görünə bilər — buna görə "az bug tapdım" nəticəsini həmişə kontekstlə izah etmək lazımdır.
Interviewdə "Agile-da QA-nın rolu nədir?" sualına "sprint sonunda test edirəm" cavabı junior səviyyəsini işarələyir. Middle cavabı timeline verir: refinement (sual və AC) → planning (effort) → sprint boyu (story bitən kimi test) → demo → retro (proses). Ən güclü əlavə: "Mənim uğur meyarım tapdığım bug sayı deyil — production-a düşən bug sayıdır."
📚 Mənbələr və sənədlər
- Scrum Guiderəsmiscrumguides.org