Buton Çalışıyor Ama Sayfa Açılmıyor: Fonksiyonel ve Fonksiyonel Olmayan Testlerin Ötesi
Yazılım geliştirme süreçleri artık çok hızlı. Eskisi gibi "Kod tamamen bitsin, sonra test ekibine fırlatırız, onlar bir bakar" lüksümüz kalmadı. Bugün kaliteli bir ürün ortaya koymak istiyorsak, testi projenin ilk gününden itibaren mimarinin bir parçası yapmak zorundayız.
Peki ama bir yazılıma test gözlüğüyle bakarken neleri gözden kaçırıyoruz? Sektörde genellikle teoride kalan ama pratikte çuvalladığımız test türlerine ve doğru bilinen yanlışlara yakından bakalım.
1. Fonksiyonel Testler (Functional Testing): Sistem Gerçekten İstenen İşi mi Yapıyor?
En temelden başlayalım. Fonksiyonel test dediğimiz şey, sistemin iş kurallarına ve gereksinimlere uyup uymadığını kontrol etmektir. Yani kısaca: Sistem kendisinden beklenen işi yapıyor mu?
Burada gözden kaçırmamamız gereken üç kritik nokta var:
Fonksiyonel Tamlık (Functional Completeness): Tasarımda veya analizde konuşulan her yeteneğin kodda bir karşılığı var mı? Yani özellikler eksiksiz mi?
Fonksiyonel Doğruluk (Functional Correctness): Sisteme A girdisini verdiğimizde, içerideki mantık hata yapmadan bize tam ve beklenen B sonucunu üretebiliyor mu?
Gerçek Kullanıcı Senaryoları (İşlevsel Uygunluk): Kullanıcılar uygulamayı hiçbir zaman bizim hayal ettiğimiz o doğrusal çizgide kullanmaz. Gerçek hayat senaryolarını simüle edip, yazılımın asıl amaca ve kullanıcı deneyimine ne kadar hizmet ettiğini görmemiz gerekiyor.
Bloglarda veya yazılarda sıkça görürsünüz; Sınır Değer Analizi (Boundary Value Analysis - BVA) veya Eşdeğerlik Paylarına Ayırma (Equivalence Partitioning) fonksiyonel testlerin bir alt türü gibi anlatılır. Bu tamamen yanlış. Bunlar birer test türü değil, o testleri yazarken tıkanmamak ve doğru girdileri seçmek için kullandığımız kara kutu (black-box) test teknikleridir.
2. Fonksiyonel Olmayan Testler (Non-Functional Testing): Sistem "Nasıl" Çalışıyor?
Fonksiyonel testlerde butonun çalışıp çalışmadığına bakarız. Fonksiyonel olmayan testlerde ise o butona basıldıktan sonra yaşanan deneyimin kalitesine odaklanırız. Bir uygulamanın tüm özellikleri kusursuz çalışabilir; ancak "Ödeme Yap" butonuna basıldığında sayfa 15 saniye dönüyorsa, o ürün kullanıcı gözünde bitmiştir.
Kullanıcıyı doğrudan içeride tutan ya da kaçıran kritik başlıklar şunlar:
Performans ve Yük Testi (Performance & Load Testing): Sistem ani ziyaretçi akınlarında (örneğin bir kampanya döneminde) eziliyor mu, yoksa kararlı kalabiliyor mu?
Güvenlik Testi (Security Testing): Sistemin arkasında veri sızıntılarına veya kötü niyetli saldırılara açık kapı kaldı mı?
Kullanılabilirlik Testi (Usability Testing): Arayüz ne kadar sezgisel? Kullanıcı aradığı butonu bulmak için ekrana işkence gibi bakmak zorunda kalıyor mu?
Uyumluluk Testi (Compatibility Testing): Uygulama sizin bilgisayarınızda harika görünüyor olabilir, peki ya farklı bir tarayıcıda veya eski bir telefonda?
Bakım Kolaylığı ve Taşınabilirlik (Maintainability & Portability): Yazılan kodun arkası ne kadar temiz? Yarın yeni bir özellik eklemek istediğimizde tüm sistem jenga taşları gibi yıkılacak mı ya da sunucu değiştirmek istediğimizde yazılım ne kadar kolay taşınabiliyor?
3. Gözden Kaçan Diğer İki Konu: Kodun İçi ve Değişiklikler
Resmi tamamlamak için madalyonun diğer yüzüne, yani kodun mutfağına ve projede bir şeyler değiştiğinde ne olduğuna bakmalıyız.
Yapısal Testler (White-Box / Structural Testing)
Burada dış davranışla işimiz yok. Doğrudan koda, mimarisine ve mantığına bakıyoruz. Yazılan testlerin kod satırlarının, döngülerin ve koşulların (if-else bloklarının) ne kadarının kapsandığını (Code Coverage) ölçüyoruz. Genelde geliştiricilerin yazdığı birim (unit) testlerle bu adımı güvenceye alırız.
Değişikliklerin Yarattığı Yan Etkiler
Yazılım yaşayan bir yapı; sürekli güncelleniyor, bug’lar çözülüyor. Tam bu aşamada şu iki ayrımı iyi bilmek gerekiyor:
Onay Testi (Confirmation Testing / Re-testing): Bir hata çözüldü dendiğinde, gidip sadece o hatanın gerçekten kapanıp kapanmadığını kontrol etmektir.
Regresyon Testi (Regression Testing): "Hata çözüldü ama içeride başka bir yeri bozdu mu?" sorusunun cevabıdır. Sisteme yeni bir şey eklendiğinde veya bir yer düzeltildiğinde, eski çalışan özelliklerin hala ayakta olduğundan emin olmak için geniş kapsamlı bir tarama yaparız.
Hangi Testi Ne Zaman Yapmalıyız? (Shift-Left Yaklaşımı)
Eski usul projelerde "Önce kodlama tamamen biter, sonra test başlar, en son canlıya çıkmadan performansına bakılır" gibi bir sıralama vardı. Bu artık intihar etmekle eşdeğer. Modern süreçlerde Shift-Left (Sola Kaydırma) dediğimiz mantığı uyguluyoruz. Yani testi sürecin olabildiğince en başına, yani soluna çekiyoruz.
Daha Kod Yazılmadan (Erken Aşama): Gereksinimler ve analiz konuşulurken performans kriterleri, güvenlik açıkları ve fonksiyonel senaryolar planlanmalı.
Geliştirme Yapılırken: Kod yazıldığı an birim testleri ve yapısal kontroller yapılmalı.
Teslimattan Hemen Önce: Yeni özelliklerin fonksiyonel doğrulaması yapılmalı, regresyon testleri çalıştırılmalı ve sistemin yük altında ezilmemesi için performans testleri (ideali CI/CD süreçleriyle otomatik olarak) koşturulmalıdır.
Özetle; Kaliteli bir yazılım sadece kodun doğru çalışmasından ibaret değildir; fonksiyonel doğruluk ile harika bir performansın birleşimidir. Sürekli entegrasyon (CI/CD) ve DevOps dünyasında, akıllıca planlanmış dengeli bir test stratejisi maliyetleri düşürür, ekibin refahını artırır ve en önemlisi son kullanıcının ürüne güvenmesini sağlar.