Yazılım testi, bir uygulamanın planlandığı gibi çalışıp çalışmadığını sistematik olarak doğrulama sürecidir. Kod canlıya çıkmadan önce hataları, eksik senaryoları ve performans sorunlarını yakalamanın tek güvenilir yolu budur; test edilmemiş yazılım, kullanıcıya çıktığında test edilmiş demektir — sadece kontrolsüz şekilde.
İlgili içerik: App Store Optimization (ASO) Nedir? Mobil Uygulama Güvenliğini Nasıl Sağlayabiliriz?
Yazılım Testi Neden Atlanmamalı
Test edilmemiş bir özellik, üretimde ilk kullanıcıyla karşılaştığında bozulur — genelde en kötü zamanda. Test, projeyi zamanında ve bütçe içinde bitirmenin de bir parçası: geç bulunan bir hata, erken bulunandan çok daha pahalıya mal olur. AppFellas'ta her proje canlıya çıkmadan bu adımlardan geçer; bu, özel yazılım sürecimizin ayrılmaz bir parçası.
Test Türleri
Birim Testi (Unit Testing)
Kodun en küçük parçasını (tek bir fonksiyon veya sınıf) izole şekilde test eder. Diğer testlerin temelini oluşturur; hızlı çalışır, sık tekrarlanır.
Entegrasyon Testi
Ayrı ayrı test edilmiş birimlerin bir araya geldiğinde doğru çalışıp çalışmadığını kontrol eder. Örneğin ödeme modülü ile sipariş modülünün birlikte doğru sonuç üretip üretmediği bu aşamada görülür.
Regresyon Testi
Yeni bir özellik eklendiğinde veya mevcut kod değiştiğinde, daha önce çalışan bir şeyin bozulmadığından emin olmak için yapılır.
Smoke Testing (Duman Testi)
Yeni bir sürümün daha ayrıntılı testlere hazır olup olmadığını hızlıca kontrol eder. Temel akışlar (giriş yapma, ana sayfa açılması) çalışmıyorsa detaylı teste geçilmez.
Alfa ve Beta Testi
Alfa testi, yazılım müşteriye sunulmadan önce genelde kalite güvence ekibi tarafından yapılır. Beta testi ise sınırlı sayıda gerçek kullanıcıyla, gerçek ortamda yapılır — geri bildirimler yayın öncesi son düzeltmelere yön verir.
Sistem ve Performans Testi
Sistem testi, ürünün hedeflenen tüm ortamlarda (farklı işletim sistemi, tarayıcı, cihaz) beklendiği gibi çalıştığını doğrular. Performans testi ise yükün arttığı durumda (çok kullanıcı, çok istek) hızın ve kararlılığın ne kadar düştüğünü ölçer.
| Test Türü | Amacı | Ne Zaman Yapılır |
|---|---|---|
| Birim testi | Tek bir fonksiyonu doğrulama | Kod yazılırken, sürekli |
| Entegrasyon testi | Modüllerin birlikte çalışmasını doğrulama | Modüller birleştiğinde |
| Regresyon testi | Yeni değişikliğin eskisini bozmadığını doğrulama | Her yeni sürümde |
| Smoke testi | Sürümün detaylı teste hazır olup olmadığını kontrol | Yeni derleme sonrası |
| Beta testi | Gerçek kullanıcı geri bildirimi almak | Yayın öncesi |
| Performans testi | Yük altında hız ve kararlılığı ölçme | Yayın öncesi ve büyüme dönemlerinde |
Test Case Nasıl Hazırlanır
Test case, belirli bir senaryoda beklenen sonucun ne olduğunu yazılı hale getirir: hangi adım atılacak, hangi veri girilecek, sonuç ne olmalı. İyi bir test case belirsizlik bırakmaz — başka biri aynı adımları izlediğinde aynı sonucu almalı. Hata bulunduğunda test case numarası ve adımı raporlanarak geliştiriciye iletilir.
İlgili içerik: Mobil Uygulama Tasarımında Kullanıcı Deneyimi Nasıl Olmalı? Mobil Uygulama Analitiği Nedir?
AppFellas
Fikrinizi konuşalım.
Ücretsiz keşif görüşmesinde projenizi, bütçenizi ve zaman çizelgenizi netleştirelim.
Otomatik Test Araçları
Tekrar eden testleri elle yapmak zaman kaybı; bu yüzden otomasyon araçları devreye girer. Test yazılır, sonra her sürümde otomatik çalıştırılır ve beklenen sonuçla karşılaştırılır — geliştiricinin müdahalesine gerek kalmaz.
- Selenium: Tarayıcı tabanlı web uygulamaları için açık kaynak, tekrarlayan testlerde tercih edilir.
- Playwright / Cypress: Modern web uygulamaları için daha yeni, hızlı kurulan test araçları.
- JMeter / LoadRunner: Yük ve performans testleri için kullanılır.
- Appium: Mobil uygulamalar (iOS/Android) için otomasyon sağlar.
- EggPlant: Arayüz (UI) tabanlı mobil testlere olanak tanır.
Manuel mi Otomatik mi?
İkisi birbirinin yerine geçmez. Yeni ve sık değişen özellikler için manuel test daha esnek; aynı senaryonun defalarca tekrarlandığı regresyon testleri için otomasyon zaman kazandırır. Çoğu ekip ikisini bir arada kullanır: kritik akışları otomatikleştirip yeni geliştirilen kısımları manuel test eder.
Hata İzleme ve Raporlama
Bulunan her hata, beklenen ile gerçek sonuç arasındaki farkı net şekilde anlatan bir raporla geliştiriciye iletilmeli: hangi adımda, hangi veriyle, hangi sonuç alındı. Raporlama aracı şirketten şirkete değişir (Jira, Trello, hatta basit bir tablo); önemli olan her hatanın takip edilip kapatıldığının görülebilmesi.
Sık Yapılan Hata
En sık görülen hata, testi projenin sonuna bırakmak. Geliştirme bittikten sonra ayrılan "test haftası", genelde bulunan hataların çoğunu düzeltmeye yetmez. Testi geliştirmeyle paralel yürütmek — her özellik bittiğinde küçük bir kontrol yapmak — hem daha az hata bırakır hem de son haftadaki paniği önler. İkinci sık hata ise sadece "mutlu senaryo"yu test etmek: kullanıcının doğru şeyi doğru sırayla yaptığı durumu. Gerçek kullanıcılar formu yanlış doldurur, bağlantıyı keser, geri döner — test bu durumları da kapsamalı.
Sık sorulan sorular
Yazılım testi neden bu kadar önemli?
Çünkü hatayı canlıya çıkmadan önce yakalamak, kullanıcı üretimde karşılaştıktan sonra düzeltmekten çok daha ucuz ve hızlıdır. Test edilmemiş yazılım risklidir.
Manuel test mi otomatik test mi daha iyi?
İkisi de gerekli. Yeni ve sık değişen özellikler için manuel test daha esnek; tekrar eden regresyon testleri için otomasyon zaman kazandırır.
Hangi test türü ne zaman kullanılır?
Birim testi kod yazılırken sürekli, entegrasyon testi modüller birleştiğinde, regresyon testi her yeni sürümde, performans testi ise yayın öncesi ve büyüme dönemlerinde yapılır.
Test case nasıl yazılır?
Hangi adımın atılacağı, hangi verinin girileceği ve beklenen sonucun ne olduğu net şekilde yazılır. İyi bir test case, başka biri uyguladığında da aynı sonucu verecek kadar açık olmalı.
