Analistler için 7 Temel Test Prensibi

Analistler, testler sırasında aslında çok temel hatalar yaparlar. Kötü olan (hayatta da böyledir) bu bir hata olarak görülmez ve doğru yaptığımızı düşünürüz. İşte bu duruma bir çözüm niteliğinde olan aşağıdaki 7 prensip, bir kağıda basılarak masaların en güzel gözüken yerlerinde yer almalıdır. Bu prensiplerden çıkarılacak çok fazla ders vardır. Analistler olarak, yazılım testine olan yanlış bakış açımızı değiştirebilmemiz için bu kurallar sürekli aklımızın bir köşesinde olmalıdır.

Test, yazılımda hata olduğunu gösterir/kanıtlar.

Tek başına bu cümleyi okuduğumuzda, “bu nasıl bir prensip?” diyebilirsiniz. Zaten testi, hata bulmak için yapıyoruz değil mi?

Bu cümleyi bir de anlamını değiştirmeden tersten yeniden kuralım. “Test, yazılımda hata olmadığını göstermez”. Aslında anlamı baya değişti değil mi? Ama asıl dikkat etmemiz gereken nokta işte bu. Eğer, test sonuç raporlarınızda tüm defectler çözülmüş gözüküyorsa, bu hataların bittiğini değil, “henüz bulunmamış hatalar” olduğunu gösterir.

Testlere, geliştirme sürecinin en başında başlanması gerekir.

Testlere, mümkün olan en erken zamanda başlanması gerekir. Peki bu erken zaman aslında hangi zaman? Yazılım bittiğinde mi? Yoksa yazılımın belli bir kısmı bittiğinde mi? Yazılımcı kendi testleri yaptıktan sonra mı? Hepsine cevap HAYIR! En doğru zaman gereksinim analizi safhasıdır. Analist, çıkardığı iş ve sistem gereksinimlerini en önce okuyarak test etmelidir. Gereksinimlerin proje ile ilgili herşeyi içerdiği ve gereksinim tanımına uygun olarak yazıldığı kontrol edilmelidir. Eğer bir bugfix gerekiyorsa önce burada yapılmalıdır.

Hatalar, yazılımın belli bölgelerinde yoğunlaşır.

Evet bu bildiğimiz Pareto. Burada da geçerli. Burada bahsetmeyeceğiz ama merak edenler proje yönetiminde kullanılan “Ishikawa Diagram” tekniğine bakabilirler. Buradaki olay, analistin, bazen tecrübesini de kullanarak, nerelerde daha çok hata çıkabileceğini tahmin etmesidir. Bu nokta bulununca artık çok uzaklara gitmeye gerek yok. Bu hatanın etrafında dolaşarak çok sayıda hatayı daha kısa zamanda bulabiliriz.

Böcek ilacı paradoksu

Bazı böcek türleri, kendilerine karşı sürekli aynı böcek ilacı kullanıldığında, artık buna bağışıklık kazanır ve ilaç etkisini yitirir. Yazılım testi de böyledir. Ama bir yazılım, teste karşı nasıl bağışıklık kazanabilir ki? Şöyle; yazılımda çıkan hatalar her düzeltildiğinde, sürekli aynı testler tekrar edilirse, belki aynı hataların tekrar etmediğini görebilirsiniz, ancak yapılan değişiklikler sonucu başka hatalar da çıkacaktır. Yazılım, eski test caselerimize bu şekilde bağışıklık kazanacaktır. İşte bu yüzden, her bugfixten sonra test caselerimizi güncellemeliyiz.

Bir yazılımı %100 test etmek imkansızdır.

Onlarca buton, textbox, combobox bulunan bir ekranda, her şeyi test edebilmeniz için denenmesi gereken kombinasyon sayısı kaçtır hiç hesapladınız mı? Kaç olduğunu bulmaya gerek yok. Kısacası imkansızdır. Test’in temelinde risk vardır. Testi, riski en aza indirmek için yaparız. Bu yüzden bu kombinasyonların tümünü test etmek yerine, güzel bir risk analizi ile riski çok aza indirecek testler yaparız. Yani, doğru test stratejileri ile, az test, çok bug.

Yazılım testi, yazılımın içeriğine bağımlı olarak değişkenlik gösterir.

Bu aslında çok basit bir prensip. Testlerimiz sırasında zaten uyguluyoruzdur. Açıklamak gerekirse, bir Windows uygulaması ile web uygulamasını aynı şekilde test edemezsiniz. Benzer olarak, bir hava savunma yazılımı ile E-Ticaret sitesini aynı şekilde test edemezsiniz. Yazılımın içeriğine göre uygun test stratejileri uygulanmalıdır.

Hiç hata olmadığı yanılgısı.

Bu aslında ilk prensiple öz kardeş olan bir prensip. Bir yazılımın tüm test caselerimizden başarılı olarak geçmesi, yazılımda hata olmadığını göstermez. Başka bir deyişle, tüm hataları çözmek, ürünün piyasaya sürülebileceği anlamına da gelmez. Çünkü, yapılan testin de doğru bir şekilde yapılıp yapılmadığının teyit edilmesi gerekir.

Reklamlar

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.