Makale Özeti

Yazılım test süreçleri; yazılım üreten şirketlerde yavaş yavaş olgunlaşmaya başladı ve test mühendisi istihdamları günden güne artıyor. Dolayısı ile; Test Mühendisliği Nedir? Test Departmanı Ne İş Yapar? Test Mühendisi Kimdir? Test Psikolojisi Nedir? Ne Kadar Test Edilmeli? gibi sorulara cevap vermeden önce şirketler tarafından benimsenmesi ve hatta Test Departmanlarının Duvarına Asmaları Gereken prensipler vardır. Basitçe bu prensinplere göz atalım...

Makale

Yazılım test süreçleri; yazılım üreten şirketlerde yavaş yavaş olgunlaşmaya başladı ve test mühendisi istihdamları günden güne artıyor. Dolayısı ile; Test Mühendisliği Nedir? Test Departmanı Ne İş Yapar? Test Mühendisi Kimdir? Test Psikolojisi Nedir? Ne Kadar Test Edilmeli? gibi sorulara cevap vermeden önce şirketler tarafından benimsenmesi ve hatta Test Departmanlarının Duvarına Asmaları Gereken prensipler vardır.

  1. ISTQB Test Prensipleri (International Software Testing Qualifications Board)
  2. Bertrand Meyer Test Prensipleri

ISTQB Test Prensipleri

Prensip 1: Testler hataların varlığını gösterir.

Yazılım testleri hataların var olduğunu gösterir fakat hiç bir hata kalmayacağını garanti etmez. Test yapılması, yazılımda gizli kalmış hataların bulunma riskini azaltır fakat %100 bir doğruya bizi ulaştırmaz.

Prensip 2: Yazılım ürünün komple test edilmesi mümkün değildir.

Hangi test tekniği kullanılırsa kullanılsın yazılımdaki tüm detayları test etmek mümkün değildir. Bu tarz test yerine, risk analizleri ve öncelikler verilerek testler gerçekleştirilmelidir.

Prensip 3: Erken test edin (Early testing).

Yazılım geliştirme süreci ne olursa olsun, test aktivitesine mümkün olan en erken zamanda başlanmalıdır. Oluşan bir hatanın analiz sürecinde bulunmasının maliyeti 1 birim ise ürün sahaya verildikten sonra maliyet 100’lerce birimdir.

Prensip 4: Hataların kümelenmesi (Defect clustering).

Hatalar, yazılımın belirli bölümlerinde kümelenebilir. Hataların çoğunu veya en önemli operasyonel hataları, az sayıda modül kapsıyor olabilir.

Prensip 5: DNT-Tarım ilacı paradoksu (Pesticide paradox).

Tekrarlayan aynı tipteki test aktiviteleri, yazılımda benzer hataların bulunmasına ve yeni hataların gizli kalmasına neden olurlar. Dolayısıyla, test koşulları (test case) sürekli yenilenmeli ve revize edilmelidir. Amacımız bataklıkta sivrisinek avlamak değil, bataklığı kurutmak olmalıdır.

Prensip 6: Testler içerik ve konu bağımlıdır.

Yazılımın modül içeriğine veya kullanım alanlarına bakılarak farklı tipte veya derinlikte test aktiviteleri uygulanmalıdır.

Prensip 7: Hatalar %100 giderilemez.

Test aktiviteleri esnasında hataların bulunması, yazılımın hatalardan %100 arındırıldığı veya kalite standartları anlamında son kullanıcının ihtiyaçlarının %100 kapsandığı anlamına gelmez.

Bertrand Meyer Test Prensipleri

Prensip 1: Test tanımı.

Testler yazılım ürünlerinde hata bulmak için yapılırlar.

Prensip 2: Test ve spesifikasyon ayrımı.

Testler spesifikasyonların yerine geçmezler.

Prensip 3: Regresyon Testleri (Regression/Gerileme Testleri)

Bulunan her hata için ayrı bir test yazılmalı ve test kütüphanesine eklenmelidir. Çünkü bir hatanın giderilmesi yazılım ürününün başka bir fonksiyonunu bozmuş olabilir. Maalesef sektördeki en önemli problemlerden birisidir.

Prensip 4: Test geçmesi veya kalması üzerine yapılan kriterlerin kontrat niteliğinde olması.

Geçme ve kalma kriterleri sürecin parçası olmalı ve bir kontrat niteliği taşımalıdır. Test; kime göre, neye göre, geçti veya kaldı bilinmelidir.

Prensip 5: Manuel ve otomatik testler.

Test sisteminizde ham manuel hem de otomatik testler (test otomasyonu) yer almalıdır.

Prensip 6: Test stratejileri deneysel değerlendirilebilmelidir.

Test stratejileri tekrar edebilir ve metriklerle değerlendirilebilir test süreçlerini ihtiva etmelidir.

Prensip 7: Değerlendirme kriteri.

Testler sonucunda çıkan en önemli değerlendirme kriterlerinden birisi zaman frekansları bazında ortaya çıkan hata sayısıdır.

www.denizkilinc.com