Test metrikləri və hesabat
Metriklər QA-nın işini görünən etmək üçündür — özünü haqlı çıxarmaq üçün deyil. Yaxşı metrik bir qərara xidmət edir: release-ə hazırıqmı? Hansı modul diqqət tələb edir? Prosesdə nə pisləşir?
Əsas metriklər və onların oxunuşu:
- Test execution progress — icra olunan / planlanan case-lər (%). Sual: cədvəldə qalırıqmı?
- Pass rate — keçən / icra olunan. Sual: build nə qədər stabildir?
- Defect density — modul üzrə defekt sayı (kod həcminə və ya funksiya sayına nisbətdə). Sual: hansı modul risklidir?
- Defect leakage / escaped defects — production-da tapılan defektlərin ümumi defektlərə nisbəti. Sual: test prosesi nə qədər effektivdir?
- Defect removal efficiency (DRE) — release-dən əvvəl tapılan / (əvvəl + sonra tapılan). Yüksək olması yaxşıdır.
- Reopen rate — yenidən açılan bug-ların payı. Sual: fix keyfiyyəti və ya bug report keyfiyyəti problemi var?
- Average time to fix — bug-ın açılışından bağlanışına qədər. Sual: triage prosesi işləyirmi?
| Vanity metrik (yanıldıcı) | Niyə pisdir | Nə ilə əvəz etməli |
|---|---|---|
| Yazılmış test case sayı | 500 zəif case 50 yaxşı case-dən pisdir; kəmiyyət əhatəni ölçmür və case yazmağa süni stimul yaradır | Requirement/AC əhatəsi: kritik axınların neçə faizi test olunub |
| Tapılan bug sayı (tester üzrə) | Kosmetik bug-lar sayılmağa başlayır; QA-nı erkən qarşısalmadan (shift-left) çəkindirir; komanda daxilində rəqabət yaradır | Escaped defects: production-a neçə defekt düşdü və nə severity ilə |
| Pass rate 100% | Testlərin zəif olması da 100% verir; "hər şey yaşıldır" məlumat daşımır | Pass rate + hansı case-lərin işlədiyi + escaped defect trendi birlikdə |
| Avtomatlaşdırılmış test sayı | Sayı yox, hansı riskin örtülməsi vacibdir; flaky testlər sayını artırır, etibarı azaldır | Kritik axınların avtomat əhatəsi + suite-in stabillik faizi |
| Test icrasına sərf olunan saatlar | Səmərəsizliyi mükafatlandırır — yavaş işləmək yaxşı görünür | Kritik axınlar üzrə əhatə və release-in keyfiyyət nəticəsi |
Kimə nə hesabat verilir — bu, interviewdə nadir soruşulan, amma cavabında dərhal fərqlənməyə imkan verən mövzudur:
- Developer / dev lead — konkret bug-lar, reproduksiya detalları, hansı modulda defekt sıxlığı artıb
- Product Owner — release-ə hazırlıq mənzərəsi: bilinən problemlər, risklər, nə test olunmayıb, qərar tələb edən nöqtələr
- Menecment / stakeholder — trend və nəticə: escaped defect sayı azalır ya artır, kritik axınların vəziyyəti, resurs riskləri
Qızıl qayda: hesabat rəqəm siyahısı deyil, qərara aparan hekayədir. "142 test icra olundu" heç nə demir. "Kritik axınlar tam əhatə olundu, 2 açıq Medium bug var — biri workaround ilə, release GO tövsiyə olunur" — qərar verməyə imkan verir.
Interviewdə tələ sual: "Keçən ay neçə bug tapdın?" Rəqəm deməklə kifayətlənmə. Güclü cavab rəqəmi kontekstlə verir: "Təxminən 40 — amma bu metriki tək istifadə etmirəm. Daha vacib rəqəm odur ki, həmin release-də production-a yalnız 1 Medium defekt düşdü. Bundan başqa, refinement-də verilən suallar sayəsində bir neçə defekt heç yaranmadı — onlar heç bir statistikada görünmür, amma ən dəyərli nəticədir."