Yazılım Test Süreci ve Kalite Kontrol

Kısa cevap: yazılım testi projenin sonunda yapılan tek bir aşama değil, geliştirmeyle birlikte yürüyen üç katmanlı bir süreçtir. Geliştirici kendi yazdığı kodu birim testleriyle, ekip modüllerin birbiriyle konuşmasını entegrasyon testleriyle, siz de işin sahibi olarak kabul testiyle (UAT) doğrularsınız. Sağlıklı bir projede test için ayrılan efor toplam geliştirme süresinin yüzde 20-30 aralığındadır; bunu kısmak projeyi hızlandırmaz, hatayı yalnızca canlı ortama erteler.

Test süreci kaç katmandan oluşur?

Test piramidi diye anılan yapı basit bir mantığa dayanır: en çok testi en ucuz katmana koyarsınız. Alt katmanda saniyeler içinde çalışan yüzlerce birim testi, ortada modüller arası entegrasyon testleri, en tepede az sayıda uçtan uca senaryo bulunur. Piramit ters çevrildiğinde, yani her şey elle tıklanarak test edildiğinde, her yeni sürüm bir öncekinden daha pahalı hale gelir.

• Birim testi: Tek bir fonksiyonun doğru sonucu ürettiğini kontrol eder. Hızlıdır, geliştirici yazar, her kod değişikliğinde otomatik çalışır.
• Entegrasyon testi: Veritabanı, ödeme servisi, kargo API gibi parçaların birlikte çalıştığını doğrular. Entegrasyonu çok olan projelerde en kritik katman budur.
• Uçtan uca (E2E) test: Gerçek bir kullanıcı gibi tarayıcıda adım adım senaryo yürütür: giriş yap, ürünü sepete ekle, ödeme yap. Yavaştır, bu yüzden yalnızca kritik akışlar için yazılır.
• Kabul testi (UAT): Yazılımın istenen işi yaptığını sizin doğruladığınız aşamadır. Teknik değil, iş odaklıdır.
• Regresyon testi: Yeni bir özellik eklenince eskilerin bozulmadığını kontrol eder. Otomasyonun en çok kazandırdığı yer burasıdır.

Otomasyonun asıl getirisi ilk yazımda değil, üçüncü sürümde ortaya çıkar. Elle test edilen bir projede her sürüm öncesi aynı ekranların tekrar tekrar denenmesi gerekir; otomatik testte aynı kontrol saniyeler sürer.

Bir test nasıl görünür?

Aşağıdaki örnek, indirim hesaplayan küçük bir fonksiyonun testidir. Dikkat edilmesi gereken şey testin kendisi değil, testin bir kabul kriterini kod haline getirmesi: kuponun yüzde 50 ile sınırlı olması bir iş kuralıdır ve artık kimse onu yanlışlıkla bozamaz.

export function hesaplaIndirim(tutar: number, kuponYuzde: number) {
  if (tutar <= 0) throw new Error('Tutar sifirdan buyuk olmali');
  const oran = Math.min(Math.max(kuponYuzde, 0), 50); // kupon en fazla %50
  return Math.round(tutar * (1 - oran / 100) * 100) / 100;
}

// Kabul kriteri: kupon %50 ile sinirlanir ve kurus yuvarlamasi kaybolmaz.
describe('hesaplaIndirim', () => {
  it('kuponu %50 ile sinirlar', () => {
    expect(hesaplaIndirim(200, 80)).toBe(100);
  });

  it('kurus yuvarlamasini dogru yapar', () => {
    expect(hesaplaIndirim(19.99, 10)).toBe(17.99);
  });

  it('sifir ve negatif tutari reddeder', () => {
    expect(() => hesaplaIndirim(0, 10)).toThrow();
  });
});

Bu üç satırlık kontrol, projenin ilerleyen aylarında birinin sınırı kaldırması ya da yuvarlamayı değiştirmesi durumunda anında uyarı verir. Kabul kriterlerinin sözleşmeye nasıl yazıldığını yazılım geliştirme sözleşmesi yazısında anlattık.

Manuel test mi, otomasyon mu?

İkisi rakip değil; farklı işleri yapıyorlar. Otomasyon tekrarlayan kontrolleri üstlenir, manuel test ise insanın fark edebileceği şeyleri yakalar: yanlış duran bir buton, anlamsız bir hata mesajı, mobilde kayan bir tablo. Doğru dengeyi kuran soru şudur: bu kontrolü kaç kez tekrarlayacağız?

• Otomatikleştirin: Giriş, ödeme, sipariş oluşturma gibi her sürümde tekrar test edilecek kritik akışları.
• Elle test edin: Tasarım uyumunu, metinleri, yeni geliştirilen ve henüz değişmeye devam eden ekranları.
• Otomatikleştirmeyin: Ayda bir kullanılan, sürekli değişen ve testi yazmanın kendisinden uzun sürdüğü ekranları.
• Unutmayın: Performans ayrı bir test alanıdır; nasıl ölçüldüğünü web sitesi performans testi yazısında anlattık.

Kabul testi (UAT): işin sizin tarafınızdaki kısmı

Projelerin en çok tartışma çıkaran aşaması teslimdir ve sebebi neredeyse her zaman aynıdır: kabul kriterleri baştan yazılmamıştır. UAT, yazılımın hatasız olduğunu değil, anlaşılan işi yaptığını doğrular. Bu aşamayı verimli geçirmenin yolu, test edilecek senaryoları proje başında brief ile birlikte yazmaktır; nasıl hazırlandığını yazılım proje brief hazırlama yazısında bulabilirsiniz.

• Senaryoyla test edin, ekranla değil. "Sipariş ekranını kontrol ettim" değil, "iki ürünle sipariş verdim, kargo ücreti doğru hesaplandı, fatura düştü".
• Gerçek veriyle deneyin. Test verisiyle çalışan sistem, gerçek müşteri adları ve uzun ürün isimleriyle bambaşka davranabilir.
• Hataları tek yerde toplayın. WhatsApp mesajlarına dağılan geri bildirimler kaybolur; tek liste tutun, her maddeye ekran görüntüsü ve adım ekleyin.
• Öncelik verin. Her hata acil değildir; sınıflandırma yapılmazsa ekip önce kolay olanları düzeltir, kritik olan bekler.

Hata önceliklendirme: neyi ne zaman düzeltmeli?

Sağlıklı bir hata listesi üç seviyeden oluşur ve bu seviyeler teslim tarihini belirler. Kritik hatalar canlıya çıkışı durdurur, önemli hatalar ilk hafta içinde kapatılır, kozmetik hatalar bakım listesine düşer. Bu ayrımı yapmayan projeler ya hiç yayına çıkamaz ya da yanlış şeyler düzeltilerek çıkar.

• Kritik (yayını durdurur): Veri kaybı, ödeme alınamaması, giriş yapılamaması, güvenlik açığı.
• Önemli (yayın sonrası ilk hafta): Bir özelliğin yanlış çalışması ama alternatif yolun bulunması.
• Kozmetik (bakım listesi): Hizalama, yazım hatası, ikon farkı gibi işleyişi etkilemeyen konular.

Yayın kararını hata sayısı değil, kalan hataların sınıfı verir. Sıfır hatalı yazılım yoktur; kritik hatası olmayan yazılım vardır.

Test süreci ne kadar sürer, maliyeti ne olur?

Test ayrı bir kalem olarak fiyatlanmaz; geliştirme eforunun içinde yer alır. Pratikte 40 adam-günlük bir projede 8-12 adam-gün test ve düzeltmeye ayrılır. Bu kalemi bütçeden çıkarmak projeyi ucuzlatmaz, yalnızca maliyeti canlı ortama taşır: yayındaki bir hatanın düzeltilmesi, geliştirme sırasında yakalanan aynı hataya göre çok daha pahalıdır çünkü araya veri düzeltme, müşteri iletişimi ve acil sürüm çıkarma girer.

Sonuç

İyi bir test süreci ekstra bir hizmet değil, projenin teslim edilebilir olmasının şartıdır: geliştiriciden gelen otomatik testler, ekipten gelen entegrasyon kontrolleri ve sizin yürüttüğünüz kabul testi. Üçü birden varsa teslim tarihi tartışma konusu olmaz. Projenizde bu süreci nasıl kuracağınızı konuşmak isterseniz özel yazılım hizmetimizi inceleyebilir ya da teklif alabilirsiniz; kapsam çıkarırken test eforunu ayrı bir satır olarak yazıyoruz.