Software Smoothing Stages table və ya Proqram təminatının Hamarlatma mərhələləri cədvəli.

    Biliklərim əsasında formalaşdırdığım və fikrimcə məhsulu - işi software-dən asılı olan bütün şirkətlərin keçirtməli olduqları test əməliyyatları cədvəli. Bilmirəm, məndən daha öncə kimsə bu və ya digər formada bu cədvəli tərtib edibmi? İstənilən halda, bu cədvəli mən tələbat nəticəsində fikirləşmişəm, yararlanırıq və hər kəsə məsləhət görürəm. Nə isə, keçək izaha.

    Əgər biznesiniz proqram təminatı əsasındadırsa, məhsulunuz bu test mərhələlərindən mütləq şəkildə keçməlidir. "Smooth status" sətri olduğunuz mərhələdən asılı olaraq vəziyyətinizin rəngini göstərir.

    Ən altda olan "found problems" sətrində isə mərhələdən keçdikdə proqram təminatında aşkar etdiyiniz problemlərin sayı qeyd olunmalıdır. Əgər nəticə 0-dan çoxdursa, o problemləri həll edib bütün mərhələlərə yenidən başlamalısınız. Ən son mərhələni  bitirdikdə və hamısında nəticə 0 olarsa, proqram təminatınız tam qüsursuz hesab oluna bilər.

Keçək mərhələlərə:

    1. Not tested - Bu mərhələdə Proqramınızda ümumiyyətlə test olunmamış funksionalın sayı göstərilməlidir. Söhbət adi vizual testlərdən gedir. Məsələn, proqramınız cəmi 5 düymədən ibarətdirsə və onun 4 düyməsini sınayıb 1-ini heç vaxt fərqli əməliyyatlar sırası ilə sınamamısınızsa, burada yazacağınız nəticə 1 olmalıdır

    2. Dirty Code - Proqram təminatınızın kodu istifadə etdiyiniz İDE tərəfindən yoxlanıldıqda çıxan səhvlərin sayı. Kodunuzda spagetti (qarışıq kod) hesab olunacaq hissələrin sayı da buraya aiddir.

    3. Tangible bugs - İstənilən insanın proqramdan istifadə zamanı görə biləcəyi xətalar. 

    4. Not Unit Tested - Burada, söhbət, proqramın Unit testlərdən keçməmiş funksional sayından gedir. Bilməyənlər üçün, Unit test  - proqram təminatını test edən proqram deməkdir. Yəni, az öncəki nümunədə 5 düymədən ibarət olan proqramımız üçün Unit testlər yaradırıq. Və bu yaratdığımız test proqramları (istəsəniz Aİ da deyə bilərsiniz, zatən artıq hər şeyə Aİ deyilir) bu 5 düyməni bir-bir basıb nəticə barədə məlumat toplayırlar. Və bizim Unit testlər əgər yalnız 3 düyməni sınaqdan keçiriblərsə, biz aşağıda nəticə olaraq 2 yazmalıyıq.

    5. Business needs - Load limits   -  Proqram təminatına load limiti yoxlanılmalıdır. Yəni yüklənmə limiti. Məsələn, proqramımız online resursdursa bu resursdan eyni zamanda neçə insanın istifadə edə biləcəyini müəyyən etməlisiniz. Sonra isə biznesin bu proqram təminatını təklif etmək istədiyi istifadəçi sayından həmin bu load limiti çıxmalısınız. Nəticə 0 olmalıdır, mənfi rəqəm olsa daha da yaxşıdır. Lakin nəticə 0-dan çoxdursa, deməli, proqram biznesin tələb etdiyi istifadəçi sayına hazır deyil və bu problem ya profiling (kodun incələnərək təkmilləşdirilməsi) əməliyyatlarını edərək və ya digər resursları artıraraq (məsələn server gücü) aradan qaldırılmalıdır.

    6. Limitsiz server olmur. Axının müəyyən dərəcəsi olur və məsələn, əgər server saniyədə yalnız 5000 istifadəçi üçün işlək ola bilərsə, 5001-ci şəxs istifadəyə başladıqda server sönəcək. Əgər server və daxilindəki proqram təminatı düzgün qurulubsa, sönəndən sonra avtomatik olaraq yenidən işə düşəcək və proqram təminatı istifadəyə yararlı olmağa davam edəcək. Burada məsələ sönməsi ilə yenidən işə düşməsi arasında olan zamandan gedir. Həmin müddətin tam saniyə göstəricisi 0-dan çoxdursa bu problemdir. Yəni, heç bir istifadəçinin "restartın" baş verdiyini hiss etməməsi üçün bu proses 1 saniyədən daha az həyata keçməlidir.

    7. Sizin yaratdığınız proqram təminatı, təbii ki, unikal deyil. Mütləq ki, onun hər hansı formada bənzərləri və ya aid edə biləcəyimiz kateqoriyası mövcuddur. Bu kateqoriyaya uyğun proqram təminatları üçün güvənilir hesab olunan testlər var. Məsələn, saytlar üçün Google-ın PageSpeed İnsights aləti var. Və bizim nümunədə saytın PageSpeed İnsights-dakı səhv sayı 0 olmalıdır.