Sparround

Test plan və test strategiyası

İki sənəd tez-tez qarışdırılır və interviewdə məhz bu fərq soruşulur:

  • Test strategiyası — təşkilat və ya məhsul səviyyəsində uzunmüddətli sənəd. Sual: "biz ümumiyyətlə necə test edirik?" Test səviyyələri, alətlər, mühitlər, avtomatlaşdırma yanaşması, defekt idarəetmə qaydaları. Nadir dəyişir.
  • Test planı — konkret layihə/release üçün sənəd. Sual: "bu release-i kim, nə vaxt, hansı resursla necə test edəcək?" Scope, cədvəl, məsuliyyətlər, entry/exit meyarları, risklər.

Sadə yaddaş qaydası: strategiya = necə (davamlı prinsiplər), plan = kim, nə vaxt, nə qədər (bu dəfə).

Test planının bölməsiNə yazılırNiyə vacibdir
Scope (in / out)Nə test olunur və — xüsusilə — nə test OLUNMURƏn vacib bölmə: gözləntiləri əvvəlcədən uyğunlaşdırır və sonrakı mübahisələri aradan qaldırır
Test yanaşmasıHansı səviyyələr, növlər və texnikalar tətbiq olunacaqKomanda eyni yanaşmanı paylaşır, boşluqlar görünür
Entry criteriaTestə başlamaq üçün nə hazır olmalıdır (build deploy olunub, smoke keçib, test datası var)Yarımçıq build-ə vaxt itirməyin qarşısını alır
Exit criteriaTesti bitmiş saymaq şərtləri (kritik bug 0, planlanan case-lərin 95%-i icra olunub)"Nə vaxt bitir?" sualına obyektiv cavab verir
Mühit və test datasıHansı mühitlər, hansı inteqrasiyalar mock-dur, data haradan gəlirSığortada real ödəniş şlüzü sınana bilmir — bunu əvvəlcədən razılaşdırmaq lazımdır
Risklər və asılılıqlarNə testi bloklaya bilər və planın ehtimalıGecikmə sürpriz olmur — əvvəlcədən bildirilib
Rollar və cədvəlKim nəyə cavabdehdir, hansı tarixlərdəMəsuliyyət boşluqları görünür

IEEE 829 və Agile reallığı. Klassik IEEE 829 test plan şablonu 20+ səhifəlik sənəddir. Bir çox interviewer onun bölmələrini soruşur, amma real Agile komandalarda onu tam yazan demək olar ki, yoxdur — yazılsa da, ikinci sprintdə köhnəlir.

Agile-da işləyən yüngül alternativlər:

  • Bir səhifəlik test plan — scope, yanaşma, risklər, exit criteria; bir A4 səhifə
  • Test strategy on a page — komandanın davamlı razılaşmaları bir yerdə
  • Definition of Done — hər story üçün faktiki exit criteria rolunu oynayır
  • Release test checklist — hər release-də təkrarlanan addımlar
  • Test charter-lər — exploratory sessiyalar üçün

İnterviewdə ideal mövqe: klassik şablonu bilirsən, amma Agile-da nəyin praktik olduğunu da bilirsən. Yalnız birini bilmək zəiflikdir.

Entry/exit criteria interviewdə çox soruşulur, çünki onlar QA-nın obyektivliyini göstərir. Yaxşı exit criteria ölçülə biləndir: "0 kritik və 0 yüksək severity açıq bug, planlanan case-lərin ən azı 95%-i icra olunub, bütün kritik axınların regression-u keçib". Pis exit criteria: "test kifayət qədər aparılıb". İkinci variantı deyəndə sual dərhal gəlir: "kifayət qədəri kim müəyyən edir?"