Yazılım Testi Nasıl Yapılır? Test Senaryosundan Hata Raporuna Adım Adım Eğitim

Yazılım yayına çıkar, ilk gün bir bayi 501 adetlik sipariş verir ve sistem kabul eder; oysa depoda en fazla 500 adet gönderilebilmektedir. Ya da ay sonunda faturalar yanlış toplanır, ya da kimse telefondan siparişi tamamlayamaz. Bu hataların neredeyse hepsi, yazılımı yazan kişi için "zaten çalışıyor" gibi görünür. Çünkü yazan kişi yazılımı bildiği gibi kullanır; müşteri ise hiç beklemediğiniz biçimde kullanır. Yazılım testi, bu farkı müşteri görmeden önce bulma işidir.

Bu rehberde yazılım testi nasıl yapılır sorusunu, tek bir örnek ekran üzerinden, test türlerinden hata raporuna ve yayın kararına kadar adım adım cevaplıyoruz. Rehberi bir eğitim gibi kurduk: yedi ders var, her derste bir kavramı anlatıyor, örnekle gösteriyor ve sonunda kendi projenizde yapmanız için küçük bir görev veriyoruz. Teknik bir geçmişiniz olmasa da bir yazılım projesini yöneten, sipariş eden ya da kabul eden biri olarak testin nasıl yapıldığını ve nasıl denetleneceğini öğreneceksiniz.

Yazılım Testi Nedir?

Yazılım testi, bir yazılımın beklenen davranışı gösterip göstermediğini önceden belirlenmiş senaryolarla denetleme ve gösteremediği yerleri hata olarak kayda geçirme sürecidir. Amacı, hataları kullanıcıdan önce bulmak ve yayına çıkma kararını veriye dayandırmaktır.

İki terim sık karıştırılır: hata (defect) yazılımda ya da tasarımda bulunan yanlışlıktır; arıza (failure) bu yanlışlığın çalışma sırasında kullanıcının karşısına çıkmasıdır. Test, arızayı kullanıcıdan önce tetikleyip hatayı bulmaktır.

Test hatanın varlığını gösterebilir ama yokluğunu kanıtlayamaz; üstelik her kombinasyonu denemek de mümkün değildir. Bu yüzden iyi test, her şeyi denemek değil, hata bulma ihtimali en yüksek durumları akıllıca seçmektir. Rehberin dersleri bunu öğretir.

Okumanızı öneririz: Özel yazılım geliştirme hizmetimiz

Bu Rehberi Nasıl Kullanmalısınız?

Dersleri sırayla izleyin; her ders bir öncekini kullanır. Tüm örneklerde aynı ekranı test ediyoruz: bir üreticinin bayi portalındaki sipariş ekranı. Kurallar şöyle: bayi, ürün koduyla sipariş verir; bir satırda adet 1 ile 500 arasında olmalıdır; sipariş tutarı en az ₺1.000 olmalıdır; sipariş tutarı ₺10.000 ve üzerindeyse %5 ek indirim uygulanır; pasif bayi sipariş veremez. Tutarlar ve kurallar temsilidir.

Ders 1: Yazılım Test Türleri Nelerdir?

Test türleri, yazılımın hangi katmanının denetlendiğine göre ayrılır: birim testi en küçük kod parçasını, entegrasyon testi parçaların birbiriyle çalışmasını, sistem testi bütün uygulamayı, kabul testi ise yazılımın iş ihtiyacını karşılayıp karşılamadığını denetler. Bunlara bir de işlevsel olmayan testler, yani hız, güvenlik, kullanılabilirlik ve uyumluluk testleri eklenir.

Test piramidi nedir?

Test piramidi, tabanda çok sayıda hızlı ve ucuz birim testi, ortada daha az entegrasyon testi, tepede az sayıda yavaş ve pahalı uçtan uca test bulunması gerektiğini anlatır. Alt katman testleri saniyeler içinde çalışır ve hatanın yerini gösterir; üst katmandaki testler uzun sürer ve nedeni bulmak zordur.

Ders 2: Test Senaryosu ve Test Durumu Nasıl Yazılır?

Test senaryosu, neyin test edileceğini bir cümleyle anlatır; test durumu ise o senaryonun nasıl çalıştırılacağını adım adım, girdi ve beklenen sonuçla yazar. İyi bir test durumu, yazanı tanımayan birinin de aynı sonucu alacağı kadar açıktır.

Örnek: "Bayi, ürün koduyla sipariş verebilmeli" bir senaryodur. Bundan çıkan test durumlarından biri şöyle yazılır:

Üç kurala uyun: beklenen sonucu somut yazın ("doğru çalışmalı" değil, "toplam ₺4.800 olmalı"); bir test durumu tek bir şeyi denetlesin; olumsuz senaryoları da yazın (yanlış kod, boş alan, olmayan ürün). Kullanıcılar yalnızca mutlu yolda yürümez.

Okumanızı öneririz: Yazılım gereksinim analizi nasıl yapılır? Kabul kriterlerinin kaynağı

Ders 3: Sınır Değer Analizi ve Eşdeğer Sınıflar Nasıl Uygulanır?

Eşdeğer sınıf, yazılımın aynı biçimde davranacağı değerlerin grubudur. Sınır değer analizi ise hataların en çok sınırlarda çıktığı gerçeğinden yola çıkarak, her sınıfın sınırındaki değerleri test eder. İkisini birlikte kullanmak, yüzlerce değeri denemek yerine birkaç akıllı değerle neredeyse aynı güveni verir.

Adet alanının geçerli aralığı 1–500. Bu alan için üç eşdeğer sınıf vardır: 1'den küçük değerler (geçersiz), 1 ile 500 arasındaki değerler (geçerli) ve 500'den büyük değerler (geçersiz). Her sınıftan bir değer seçmek yetmez; çünkü sık yapılan hatalardan biri, "küçüktür" ile "küçük eşittir" arasındaki farkı karıştırmaktır. Bu yüzden sınırları ve onların hemen iki yanındaki değerleri deneriz.

500'den fazla olası değer 8 test durumuna indi. Sipariş tutarı kuralları (en az ₺1.000; ₺10.000 ve üzerinde %5 indirim) için de aynı mantıkla ₺999,99 (reddedilir), ₺1.000,00 (kabul, indirim yok), ₺9.999,99 (indirim yok) ve ₺10.000,00 (indirim ₺500,00; toplam ₺9.500,00) denenir. İndirimin 10.000'in tam kendisinde uygulanıp uygulanmadığını yalnızca ₺10.000,00 değeri gösterir; bu tek değer "10.000 ve üzeri" ile "10.000'den fazla" arasındaki farkı yakalar ve böyle bir sınır hatası canlıda fark edildiğinde doğrudan para farkına dönüşür.

Ders 4: Karar Tablosuyla Kural Kombinasyonları Nasıl Test Edilir?

Karar tablosu, birden fazla koşulun birleşimine göre farklı sonuç veren kuralları, koşul kombinasyonlarını tek tek yazarak eksiksiz test etmeye yarar. Koşul sayısı n ise olası kombinasyon sayısı 2ⁿ'dir; karar tablosu hem hiçbirini unutmamayı hem de aynı sonucu veren kombinasyonları birleştirerek test sayısını azaltmayı sağlar.

Sipariş ekranında üç koşul var: bayi aktif mi, kredi limiti yeterli mi, stok yeterli mi? Üç koşul 2³ = 8 kombinasyon eder. İş kuralı şöyle: pasif bayinin siparişi her durumda reddedilir; limit aşılıyorsa sipariş yönetici onayına gider; limit yeterliyse ama stok yetersizse sipariş beklemeye alınır; üçü de uygunsa sipariş onaylanır.

Sonuca bakarak birleştirelim. 3 ve 4. satırlarda stok durumu sonucu değiştirmiyor; 5, 6, 7 ve 8. satırlarda ise yalnızca bayinin pasif olması belirleyici. Bu durumlar "fark etmez" anlamında bir çizgiyle gösterilir ve tablo dörde iner:

Sekiz kombinasyon dört teste indi; ama birleştirmeden önce sekiz satırı yazmak şarttır, çünkü doğru birleştirip birleştirmediğinizi ancak tam tablo gösterir. Tablonun diğer yararı iş birimine gösterilebilmesidir: "Pasif bayi, limiti ve stoğu ne olursa olsun reddedilir, doğru mu?" sorusu kural yazılıma girmeden sorulabilir.

Ders 5: İyi Bir Hata Raporu Nasıl Yazılır?

İyi bir hata raporu, geliştiricinin sorunu tek okuyuşta anlayıp kendi bilgisayarında yeniden üretebilmesini sağlar. Raporu okuyan kişi hatayı yeniden üretemiyorsa düzeltme başlayamaz; rapor ne kadar net olursa düzeltme o kadar hızlı başlar.

Şiddet ile öncelik aynı şey değil midir?

Değildir. Şiddet, hatanın sistem ve iş üzerindeki etkisinin büyüklüğüdür; öncelik ise hatanın ne zaman düzeltileceğidir. Şiddeti test uzmanı belirler, önceliği ise proje yöneticisi ve iş birimi, kullanıcı sayısını ve yayın takvimini de hesaba katarak belirler. İkisi çoğu zaman aynı yönde olsa da her zaman değil.

Örneğin sipariş toplamının yanlış hesaplanması kritik şiddetli ve acildir; yılda bir kullanılan arşiv raporundaki çökme yüksek şiddetli ama düşük önceliklidir (etkisi büyük, kullanımı seyrek, geçici çözümü var); ana sayfadaki şirket adının yanlış yazılması ise düşük şiddetli ama yüksek önceliklidir (işlevi bozmaz ama herkes görür ve hemen düzeltilir).

Ders 6: Regresyon Testi ve Test Otomasyonu Nedir?

Regresyon testi, yeni bir değişiklikten sonra eski ve çalışan özelliklerin bozulmadığını denetleyen testtir. Yazılımda sık görülen sürprizlerden biri, bir yerdeki düzeltmenin başka bir yeri bozmasıdır; regresyon testi bunu yayından önce yakalar.

Her değişiklikte tüm testleri elle tekrarlamak zaman alır ve hata riski taşır; bu yüzden sık tekrarlanan testler otomatikleştirilir ve her değişiklikten sonra kendiliğinden çalışır. Ama her şeyi otomatikleştirmek gerekmez: her sürümde yinelenen, net girdi ve beklenen sonucu olan, sık değişmeyen akışlar (indirim hesabı, sınır değerler, giriş ve sipariş akışı) otomasyona uygundur; bir kez yapılacak testler, öznel değerlendirmeler ve tasarımı hâlâ değişen ekranlar elle daha doğrudur.

Keşif testi, önceden yazılmış senaryolar yerine test uzmanının yazılımı merakla kurcalamasıdır ve yazılı senaryoların kaçırdığı hataları bulur. Sağlıklı ekip ikisini birlikte yapar.

Okumanızı öneririz: Proje planı nasıl hazırlanır? Testi takvime koymak

Ders 7: Test Metrikleri ve Yayın Kararı Nasıl Verilir?

"Test bitti mi?" sorusuna "bitti galiba" demek yerine, dört basit metrikle ve önceden belirlenmiş çıkış ölçütleriyle cevap verilir: çalıştırma oranı, geçme oranı, gereksinim kapsamı ve hata yoğunluğu. Aşağıdaki örnekte 26 gereksinimli bir sürümün test sonuçlarını hesaplıyoruz. Rakamlar temsilidir.

Tabloyu okumanın yolu şudur: planlanan testlerin %10'u çalıştırılmamış, çalıştırılanların %11'i başarısız, iki gereksinimin hiç testi yok; henüz yayına hazır değiliz. Hata yoğunluğu hangi modüle daha çok dikkat edileceğini, hata yakalama etkinliği ise hataların ne kadarının müşteriden önce bulunduğunu, yani test sürecinin ne kadar işe yaradığını gösterir.

Yayın için çıkış ölçütü nasıl belirlenir?

Çıkış ölçütü, testin "bitti" sayılması ve yayına çıkış için sağlanması gereken koşulların testten önce yazılı hâle getirilmesidir. Ölçütü sonuç bilindikten sonra belirlemek, sonucu savunmaya dönüşür; önceden belirlemek ise karar verilebilir bir eşik koyar. Aşağıdaki liste bir örnektir; eşikleri kendi riskinize göre belirleyin.

Yazılım Testinde Sık Yapılan Hatalar Nelerdir?

Test hatalarının çoğu, araç eksikliğinden değil, bakış açısı eksikliğinden doğar. En sık görülenler şunlardır:

• Testi en sona bırakmak: Sürenin bittiği yerde test de biter; kısalan ilk şey testtir. Test, gereksinim aşamasında planlanmalı ve geliştirmeyle paralel yürümelidir.
• Yazanın kendi yazdığını test etmesi: Geliştirici kendi aklına gelen durumları dener; başkasının aklına gelecek durumlar sınanmamış kalır. Birim testi geliştiricinin, sistem ve kabul testleri başkasının işi olmalıdır.
• Yalnızca mutlu yolu denemek: Boş alan, yanlış girdi, bağlantı kopması ve aynı butona iki kez basmak gibi olumsuz durumlar atlanır; müşteri ise tam olarak bunlara denk gelir.
• Beklenen sonucu yazmamak: Beklenen sonucu önceden bilinmeyen bir testte her sonuç "doğru" görünür.
• Test ortamında gerçek müşteri verisi kullanmak: Gerçek ad, telefon ve adresler test ortamında erişilebilir hâle geldiğinde bir veri güvenliği ve KVKK sorunu doğar. Test ortamında örnek ya da anonimleştirilmiş veri kullanın.

Okumanızı öneririz: Özel Yazılım Nasıl Yaptırılır? Firma Seçimi, Teklif, Sözleşme ve Ödeme Planı Rehberi

Okumanızı öneririz: API güvenliği nasıl sağlanır? Kimlik, yetki, token ve hız sınırı rehberi

İnovabil ile Yazılım Testi

İnovabil olarak test adımını geliştirmenin sonunda bir kontrol olarak değil, projenin başından itibaren planlanan bir adım olarak ele alıyoruz. Gereksinim aşamasında yazdığımız kabul kriterleri test senaryolarının temelini oluşturuyor. Yazılımı gerçek iş senaryolarıyla; farklı roller, cihazlar ve uç durumlar dahil test ediyor, senaryo bazlı fonksiyon testlerine performans ve güvenlik kontrollerini ekliyoruz. Kabul testlerini sizinle birlikte yapıyor ve çıktı olarak test senaryolarını ve kabul onayını teslim ediyoruz.

Yazılım projenizin nasıl test edileceğini ve kabul ölçütlerini birkaç cümleyle anlatın; size özel bir test planı çerçevesi hazırlayalım.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular