2.3. Adım Adım Metodoloji: V-Model ve STLC Fazları

Bir önceki bölümde terzinin provasını konuştuk. Şimdi o provayı mühendisliğin evrensel diliyle masaya yatıralım.

2.3.1. V-Model: Geliştirme ve Testin Kusursuz Simetrisi

Geleneksel yazılım süreçlerinde en büyük yanılgı, yazılımcının işi tamamen bitirip sistemi bir “kara kutu” gibi test ekibinin önüne atmasıdır. V-Model, bu hatayı ortadan kaldıran harika bir mimari prensip sunar:

“Geliştirme sürecindeki her bir planlama ve inşa adımının, tam karşısında onu denetleyen simetrik bir test seviyesi vardır.”

V harfinin sol kanadı yukarıdan aşağıya doğru projeyi parçalara ayırıp detaylandırır (tasarım ve kodlama). Taban noktası kodlamadır. V harfinin sağ kanadı ise aşağıdan yukarıya doğru o parçaları birleştirip bütüne ulaşır (test seviyeleri).

Geliştirme Aşaması (Sol Kanat – İnşa)	Karşılık Gelen Test Seviyesi (Sağ Kanat – Denetim)	Ne Yapılır? (Odak ve Kapsam)	Kim Yapar?
İş İhtiyaçları Analizi (BRD / User Stories) Müşterinin ne istediği yazılır.	Kabul Testleri (Acceptance Testing / UAT) Sistem iş ihtiyacını gerçekten çözüyor mu?	Gerçek kullanıcı senaryoları koşulur; ürün sahibi son onayı verir.	Son Kullanıcı, Ürün Sahibi (PO)
Sistem Mimarisi Tasarımı Uygulamanın genel omurgası çizilir.	Sistem Testleri (System Testing) Sistem bir bütün olarak eksiksiz çalışıyor mu?	Uçtan uca tüm fonksiyonlar, güvenlik, hız ve veri akışı denetlenir.	QA / Test Mühendisi (Ana Karargâh)
Yüksek Seviye Mimari (HLD) Modüllerin ve servislerin bağlantıları planlanır.	Entegrasyon Testleri (Integration Testing) Parçalar birbiriyle doğru konuşuyor mu?	Farklı servislerin ve veritabanının birbirine doğru veri iletip iletmediği test edilir.	Geliştiriciler & Test Mühendisleri
Düşük Seviye Tasarım (LLD) Tek tek fonksiyonların formülleri tasarlanır.	Birim Testleri (Unit Testing) En küçük kod hücresi doğru hesaplıyor mu?	Dış dünya taklit edilerek sadece tekil bir fonksiyon test edilir.	Yazılım Geliştirici (Developer)
⬇️ KODLAMA (V’nin En Dibi)	⬆️ Sağ Kanat Başlar	Burada kod yazılır ve testler tabandan tavana doğru yürütülür.	Yazılım Geliştirici

Bu 4 Test Seviyesini Günlük Hayat Mantığıyla Anlayalım:

1. Birim Testleri (Unit Testing): Bir otomobil fabrikasını düşün. Birim test; arabanın motorundaki tek bir bujinin veya fren pedalındaki tek bir vidanın tornada doğru diş açısıyla üretilip üretilmediğini tek başına denetlemektir. Dış dünya (örneğin akü veya tekerlek) henüz ortada yoktur; bujiye laboratuvarda elektrik verilip kıvılcım çıkarıp çıkarmadığına bakılır. (Yazılımda dış bağımlılıkların geçici sahte kopyalarla taklit edilmesine Mocking / Stubbing denir).

2. Entegrasyon Testleri (Integration Testing): Motor bloğu ile vites kutusunu tezgâhta birbirine bağlarsın. Vitesi 1’e taktığında motorun dişlisi beklenen açıyla dönüyor mu? İki bağımsız parçanın birleşim noktası test edilir. Yazılımda ise: “Sepet servisi ödeme servisine toplam tutarı kuruşu kuruşuna doğru iletiyor mu?” sorusu yanıtlanır.

3. Sistem Testleri (System Testing): Motor, şasi, tekerlekler, camlar, direksiyon birleştirilir. Karşımızda tam teşekküllü bir araba vardır. Araba piste çıkarılır: Direksiyonu çevirince tekerlek dönüyor mu, klima soğutuyor mu, araç 100 km hıza kaç saniyede çıkıyor (performans), kapıları kilitleniyor mu (güvenlik)? Burası Test Mühendisinin (QA) kalbidir.

4. Kullanıcı Kabul Testleri (UAT – User Acceptance Testing): Arabayı satın alacak olan taksi şoförüne veya aileye teslim edersin: “Bagaj bebek arabasını alıyor mu, koltuklar uzun yolda rahat mı?” Teknik olarak kusursuz olan araba, kullanıcının gerçek hayat ihtiyacını karşılıyor mu sorusunun yanıtlandığı son onay kapısıdır.

2.3.2. STLC (Yazılım Test Yaşam Döngüsü) Adımları

Bir test mühendisi projeye nasıl başlar, gün içinde ne yapar ve işi nasıl teslim eder? İşte bu yol haritasına STLC (Software Testing Life Cycle) denir.

Her aşamaya başlayabilmek için gereken şartlara Giriş Kriteri (Entry Criteria), o aşamayı başarıyla bitirip diğerine geçebilmek için gereken çıktılara ise Çıkış Kriteri (Exit Criteria) denir.

Faz 1: Gereksinim Analizi (Requirement Analysis)

• Ne Yapılır? Test mühendisi, analistlerin yazdığı dokümanları okur. “Bu kural test edilebilir mi?”, “Neresi eksik veya belirsiz bırakılmış?” sorularını sorar. Şüpheli her noktayı not eder.

• Giriş Kriteri: Analiz dokümanı veya kullanıcı hikâyelerinin (User Story) yayınlanması.

• Çıkış Kriteri: Analiste sorulacak sorular listesi ve hangi gereksinimin hangi testle doğrulanacağını takip eden İzlenebilirlik Matrisi (RTM – Traceability Matrix) taslağı.

Faz 2: Test Planlama (Test Planning)

• Ne Yapılır? Test lideri veya kıdemli test uzmanları stratejiyi belirler: Neleri test edeceğiz (kapsam içi), neleri test etmeyeceğiz (kapsam dışı), kaç kişilik ekibe ve hangi araçlara ihtiyacımız var, risklerimiz neler?

• Giriş Kriteri: Netleşmiş ve analiz edilmiş gereksinimler.

• Çıkış Kriteri: Onaylanmış Test Planı Dokümanı, takvim ve bütçe/efor tahmini.

Faz 3: Test Senaryosu Tasarımı (Test Case Development)

• Ne Yapılır? Test adımları tek tek kağıda dökülür: Önkoşullar, uygulanacak adımlar, girilecek test verileri ve sistemden beklenen sonuç (Expected Result) detaylandırılır.

• Giriş Kriteri: Onaylı Test Planı ve netleşmiş gereksinimler.

• Çıkış Kriteri: Ekip tarafından gözden geçirilip onaylanmış Test Senaryoları (Test Cases) ve testte kullanılacak hazır veriler (ör. geçerli kredi kartı numaraları, test kullanıcıları).

Faz 4: Test Ortamı Kurulumu (Test Environment Setup)

• Ne Yapılır? Testlerin koşulacağı dijital laboratuvar hazırlanır: Test sunucuları ayağa kaldırılır, test veritabanı bağlanır, mobil cihazlar hazırlanır. Geliştiricilerden gelen yazılım paketi ortama yüklenir. Sistemin en temel fonksiyonlarının ayakta olup olmadığını anlamak için hızlı bir Duman Testi (Smoke Test) yapılır.

• Giriş Kriteri: Yazılımcılardan gelen test edilebilir ilk yazılım paketi (Build).

• Çıkış Kriteri: Sağlıklı ve ayakta olduğu Duman Testi ile kanıtlanmış stabil test ortamı.

Faz 5: Test Koşumu ve Kusur Yönetimi (Test Execution)

• Ne Yapılır? Tasarlanan senaryolar canlı gibi çalışan test ortamında tek tek işletilir. Beklenen sonuç ile ekranda gerçekleşen fiili sonuç karşılaştırılır. Ekranda bir hata varsa ekran görüntüsü ve loglarla hata takip sistemine (Jira) kusur kaydı açılır. Yazılımcı hatayı çözüp yeni paket gönderdiğinde iki kritik test uygulanır:

  • Yeniden Test (Re-test): Yalnızca bozulan o spesifik düğmenin veya hatanın düzelip düzelmediğini kontrol etmek.

  • Regresyon Testi (Regression Testing): Yapılan o düzeltmenin, sistemin önceden tıkır tıkır çalışan başka bir yerini yanlışlıkla bozup bozmadığını kontrol etmek.

• Giriş Kriteri: Kararlı test ortamı ve hazır senaryolar.

• Çıkış Kriteri: Koşulmuş testlerin sonuç raporları, çözülmüş ve doğrulanmış hata kayıtları.

Faz 6: Test Kapanışı ve Raporlama (Test Closure)

• Ne Yapılır? Test maratonunun karnesi çıkarılır: Kaç senaryo koşuldu, kaçı başarılı oldu, sistemde kritik açık hata kaldı mı? Proje paydaşlarına resmi kalite onayı (Sign-Off) verilir. Ekip toplanır ve bir sonraki projede nelerin daha iyi yapılabileceğini konuşur (Alınan Dersler – Lessons Learned).

• Giriş Kriteri: Planlanan tüm test koşumlarının tamamlanması, canlıya çıkışı engelleyecek kritik hatanın kalmaması.

• Çıkış Kriteri: Resmi Test Özet Raporu (Test Summary Report) ve canlıya geçiş onayı.

4. “Bir de Şöyle Düşün” (Kutu İçeriği)

💡 Bir de Şöyle Düşün: Re-test mi, Regresyon mu? (Ceket Düğmesi Analojisi)

Bu iki kavramı mülakatlarda ayırt edemeyen adaylar anında elenir. Aralarındaki farkı hiç unutmayacağın bir örnekle aklına kazıyalım:

Ceketinin 3. düğmesi kopmuştu. Terziye götürdün, terzi düğmeyi yeniden dikti.

• Re-test (Yeniden Test): Terziden ceketi aldığında elinle sadece o 3. düğmeyi tutup çekmendir. Düğme sağlam dikilmiş mi, ilikten geçiyor mu? Sadece düzeltilen arızanın giderilip giderilmediğini denetlersin.

• Regresyon Testi (Regression): Terzi o düğmeyi dikerken dikiş iğnesiyle yanlışlıkla ceketin astarını büzmüş veya hemen yanındaki 2. düğmenin ipini gevşetmiş olabilir mi? Aynanın karşısına geçip ceketin tüm düğmelerini kapatıp kollarına bakmandır. Yapılan bir tamiratın, sağlam olan diğer yerleri bozup bozmadığını kontrol etmektir.

5. Mini Alıştırma

Senaryo: Bir bankanın mobil uygulamasında “Para Transferi” ekranında EFT yaparken tutar alanına kuruş girildiğinde sistemin donduğu fark edildi ve geliştiriciye bildirildi. Geliştirici kodu düzeltti ve test ortamına yeni paketi yükledi.

Soru: Test Mühendisi olarak eline gelen bu yeni pakette önce hangi testi, ardından hangi testi koşmalısın?

• A) Önce Regresyon Testi koşup tüm uygulamayı baştan sona test ederim, sonra Re-test yaparım.

• B) Önce Re-test koşarak kuruşlu EFT işleminin düzelip düzelmediğine bakarım; düzeldiyse ardından kuruşsuz normal transferlerin ve havale işlemlerinin bozulup bozulmadığını görmek için Regresyon Testi yaparım.

Doğru Yanıt: B Seçeneği.

Mantıksal sıra her zaman önce Re-test‘tir. Eğer düzeltildiği iddia edilen kuruşlu EFT hatası hâlâ devam ediyorsa paketi anında reddedersin; boşuna saatlerce Regresyon Testi koşarak zaman kaybetmezsin. Hatanın çözüldüğünü Re-test ile kanıtladıktan sonra, bu değişikliğin komşu fonksiyonları bozup bozmadığını anlamak için Regresyon Testi‘ne geçersin.