Hesabatlar və metrikalar
Hesabatın məqsədi "gözəl şəkil" deyil — qərar verməyə kömək etməkdir. Fərqli auditoriyanın fərqli sualı var:
- Developer (PR-da): "Mənim dəyişikliyim nəyi sındırdı və niyə?" → sürətli, birbaşa link, trace/screenshot
- QA (triage zamanı): "Bu real bug-dır, yoxsa flaky?" → tarixçə, retry statusu, artefaktlar
- Team lead / menecer: "Keyfiyyət yaxşılaşırmı?" → trendlər, escaped defects, suite sağlamlığı
Reporter-lər:
html— Playwright-ın daxili hesabatı; interaktiv, trace-ə birbaşa keçid verir. Gündəlik iş üçün ən yaxşısı və çox layihə üçün TAM KİFAYƏTDİRlist/dot— konsol çıxışı (CI log-larında oxumaq üçün)junit— XML; CI sistemlərinin (Jenkins, GitLab, Azure DevOps) test nəticələrini öz interfeysində göstərməsi üçünblob+merge-reports— sharding zamanı ayrı maşınların nəticələrini bir hesabatda birləşdirmək üçün; sharding istifadə edirsənsə bu, mütləqdir- Allure — ayrıca ekosistem: tarixçə və trendlər, test case-lərin requirement-lərə bağlanması, addımlar, əlavələr, severity. Böyük komandalarda və hesabatlılıq tələb olunan mühitlərdə dəyərlidir; kiçik layihədə əlavə infrastruktur yüküdür (serverdə saxlanma, generasiya addımı)
Metrikalar — bu mövzunun interview üçün ən dəyərli hissəsi. Qayda: yaxşı metrik qərara aparır; vanity metrik yalnız hesabatda gözəl görünür.
Dəyərli metrikalar:
- Escaped defects — production-a keçən bug sayı. Ən vacib metrik, çünki suite-in ƏSAS məqsədinə birbaşa cavab verir. Hər escaped defect üçün sual: "niyə testlərimiz bunu tutmadı?" — cavab yeni test və ya yeni yanaşma verir
- Flaky rate — retry ilə keçən testlərin faizi. Hədəf <1%; 5%-dən yuxarı olduqda komanda qırmızıya inanmağı dayandırır və suite-in bütün dəyəri sıfırlanır
- Suite müddəti və PR feedback vaxtı — developer nə qədər gözləyir. 10 dəqiqədən uzun PR pipeline-ı yan keçmə mədəniyyəti yaradır
- Pass rate trendi — mütləq rəqəm yox, TREND vacibdir
- Test saxlanma xərci — feature dəyişikliyinə görə neçə test düzəltmək lazım gəldi (kövrək dizaynın göstəricisi)
Vanity metrikalar (ehtiyatlı ol):
- Test sayı — 500 zəif test 50 güclü testdən pisdir; həm də saxlanma xərcini artırır
- Kod coverage % — test kodunun ƏHATƏSİNİ ölçür, DƏYƏRİNİ yox: assertion-suz test də coverage verir
- Avtomatlaşdırma faizi — "test case-lərin 80%-i avtomatlaşdırılıb" heç nə demir, çünki case-lərin özü müxtəlif dəyərdədir
- Pass rate 100% — həmişə yaşıl suite şübhəlidir: ya testlər zəifdir, ya heç nə yoxlamır
| Metrik | Hansı suala cavab verir | Hansı qərara aparır |
|---|---|---|
| Escaped defects | Suite öz əsas işini görürmü? | Hər buraxılan bug üçün yeni test/yanaşma; əhatə boşluqlarının aşkarı |
| Flaky rate | Qırmızı nəticəyə inanmaq olarmı? | >1% olduqda flaky düzəlişinə sprint vaxtı ayrılması |
| PR feedback vaxtı | Testlər developer axınını bloklayırmı? | Suite-in təbəqələnməsi, sharding, API-yə köçürmə |
| Test sayı | — (heç nəyə) | Heç nəyə; artması nə yaxşı, nə pis xəbərdir |
| Kod coverage % | Kodun nə qədəri işə düşür? | Yalnız BOŞLUQ axtarışında faydalıdır; hədəf kimi qoyulanda zərərlidir |
İnterview-da mütləq gələn sual: "Avtomatlaşdırmanın uğurunu necə ölçürsən?" Zəif cavab: "coverage və test sayı". Güclü cavab: "Əvvəlcə soruşuram — kimin üçün və hansı qərar üçün ölçürük?" Sonra: escaped defects (suite işləyirmi?), flaky rate (inanmaq olarmı?), feedback vaxtı (bloklayırmı?). Və vanity metrikaları özün tənqid et — bu, mövzuya dərindən baxdığını göstərir.
📚 Mənbələr və sənədlər
- Reporter-lərrəsmiplaywright.dev