Fonksiyonel Test ve Otomatik Test: Temel Fark

“Fonksiyonel test vs otomatik test” karşılaştırması QA’da sık görülür, ancak bu iki kavram birbirinin alternatifi değildir. Fonksiyonel test neyi test ettiğinizi, otomatik test ise testi nasıl çalıştırdığınızı açıklar. Bu ayrımı yapmadan test stratejisi kurmak, yanlış önceliklere ve kırılgan test paketlerine yol açar.

Apidog'u bugün deneyin

Bu rehberde iki kavramı ayrı eksenler olarak ele alacağız ve özellikle API testlerinde nasıl uygulanacağını adım adım netleştireceğiz.

Kategori hatası

Karışıklık iki farklı sorunun cevaplarını karşılaştırmaktan kaynaklanır:

• Fonksiyonel test: Ne test ediyoruz?
• Otomatik test: Testi nasıl çalıştırıyoruz?

Fonksiyonel test, yazılımın beklenen davranışı üretip üretmediğini kontrol eder. Örneğin bir API uç noktasının doğru durum kodunu, doğru yanıt gövdesini ve doğru hata mesajını döndürmesi fonksiyonel bir konudur.

Otomatik test ise bu kontrolün bir insan tarafından manuel yapılması yerine araçlar, komut dosyaları veya CI/CD süreçleriyle çalıştırılmasıdır.

Bu yüzden doğru soru şudur:

“Fonksiyonel test mi otomatik test mi yapmalıyız?” değil,

“Neleri test etmeliyiz ve bunların hangilerini otomatikleştirmeliyiz?”

Fonksiyonel test nedir?

Fonksiyonel test, bir uygulamanın özelliklerinin gereksinimlere göre çalışıp çalışmadığını doğrular. Genellikle kara kutu yaklaşımıyla yapılır: iç kod incelenmez, girişler ve çıktılar kontrol edilir.

Bir API için fonksiyonel test şu kontrolleri kapsar:

• POST /orders gerçekten sipariş oluşturuyor mu?
• Geçersiz payload gönderildiğinde 400 dönüyor mu?
• Yanıt gövdesi beklenen şemayla eşleşiyor mu?
• Hata yanıtları belgelenen formatta mı?
• Yetkisiz isteklerde doğru 401 veya 403 yanıtı geliyor mu?

Basit bir fonksiyonel API kontrolü şu şekilde düşünülebilir:

POST /orders
Content-Type: application/json

{
  "productId": "p_123",
  "quantity": 2
}

Beklenen sonuç:

{
  "id": "ord_001",
  "productId": "p_123",
  "quantity": 2,
  "status": "created"
}

Bu testte kontrol edilecek noktalar:

Status code = 201
response.id exists
response.status = "created"
response.quantity = 2
response schema matches Order schema

Bu kontroller, gerçek yanıtı beklenen yanıtla karşılaştıran API iddialarına dayanır.

Fonksiyonel testin güçlü tarafı, doğrudan kullanıcının önemsediği şeyi doğrulamasıdır: özellik çalışıyor mu?

Ancak tek başına yeterli değildir. Bir uç nokta doğru yanıt döndürebilir ama yüksek trafik altında yavaşlayabilir veya çökebilir. Bu alanı performans testi kapsar.

Fonksiyonel testin gerçek karşılığı “otomatik test” değil, fonksiyonel olmayan testtir:

• Performans testi
• Yük testi
• Güvenlik testi
• Kullanılabilirlik testi

Otomatik test nedir?

Otomatik test, test adımlarının insan tarafından tekrar tekrar çalıştırılması yerine araçlar veya komut dosyalarıyla yürütülmesidir.

Bir testi bir kez tanımlarsınız:

• İstek
• Test verisi
• Beklenen durum kodu
• Beklenen yanıt alanları
• Şema kontrolleri
• Hata koşulları

Sonra bu testleri şu şekillerde çalıştırırsınız:

• Manuel tetiklemeyle
• Zamanlanmış görev olarak
• Her commit veya pull request sonrası
• CI/CD pipeline içinde

Otomatik testin karşılığı manuel testtir.

Otomasyonun değeri şudur:

• Aynı testi her seferinde tutarlı çalıştırır.
• Regresyon testini ucuz hale getirir.
• Her commit’te hızlı geri bildirim sağlar.
• İnsan hatasını azaltır.
• Tekrarlayan kontrolleri test uzmanlarından alır.

Ancak otomasyonun sınırları da vardır:

• Testlerin yazılması gerekir.
• Bakım maliyeti vardır.
• Kırılgan testler pipeline’ı yavaşlatabilir.
• Otomasyon yalnızca kendisine öğretilen beklentileri kontrol eder.
• “Bu deneyim gerçekten iyi mi?” gibi yargısal soruları cevaplayamaz.

Daha detaylı açıklama için otomatik test nedir rehberine bakabilirsiniz.

Özetle:

Otomasyon bir test türü değil, testleri çalıştırma yöntemidir.

Fonksiyonel testi de, performans testini de, güvenlik testini de otomatikleştirebilirsiniz.

İki eksen nasıl birleşir?

Fonksiyonel/manuel, fonksiyonel/otomatik, fonksiyonel olmayan/manuel ve fonksiyonel olmayan/otomatik olmak üzere dört pratik kategori vardır.

	Fonksiyonel	Fonksiyonel Olmayan
Manuel	Bir test uzmanı ödeme akışının doğru çalıştığını kontrol eder	Bir test uzmanı arayüzün kullanılabilirliğini değerlendirir
Otomatik	Bir komut dosyası API uç noktasını çağırır ve yanıtı doğrular	Bir yük testi 500 sanal kullanıcıyla gecikmeyi ölçer

Her hücre geçerlidir.

Örneğin:

• Manuel fonksiyonel test: Yeni bir checkout akışını elle denemek
• Otomatik fonksiyonel test: POST /orders için durum kodu ve yanıt şeması doğrulamak
• Manuel fonksiyonel olmayan test: Kullanıcı arayüzünün anlaşılır olup olmadığını değerlendirmek
• Otomatik fonksiyonel olmayan test: 500 eşzamanlı kullanıcıyla yük testi çalıştırmak

Bu yüzden karar şu şekilde verilmelidir:

1. Hangi davranışları test etmeliyiz?
2. Bunların hangileri otomatikleştirilmeli?
3. Hangileri insan yargısı gerektirdiği için manuel kalmalı?

API testlerinde bu ayrım nasıl uygulanır?

API’ler otomatik fonksiyonel testler için çok uygundur çünkü:

• Açık sözleşmeleri vardır.
• İstek ve yanıtlar yapılandırılmıştır.
• UI render süreci yoktur.
• Yanıtlar net şekilde doğrulanabilir.
• CI/CD içinde kolay çalıştırılabilir.

Pratik bir API test stratejisi şu şekilde kurulabilir:

1. Kritik uç noktaları belirleyin.
2. Her uç nokta için fonksiyonel test senaryoları yazın.
3. Durum kodlarını doğrulayın.
4. Yanıt gövdesindeki zorunlu alanları kontrol edin.
5. JSON şema doğrulaması ekleyin.
6. Hatalı istekler için negatif testler yazın.
7. Testleri senaryolarda gruplayın.
8. Testleri CI/CD pipeline içinde otomatik çalıştırın.
9. Performans ve yük testlerini ayrı zamanlanmış işler olarak ekleyin.
10. Keşif ve ürün doğrulama çalışmalarını manuel bırakın.

Örnek API test kapsamı:

Endpoint: POST /orders

Pozitif test:
- Geçerli payload gönder
- 201 döndüğünü doğrula
- response.id alanının oluştuğunu doğrula
- response.status = "created" olduğunu doğrula
- Yanıt şemasını kontrol et

Negatif test:
- Eksik productId gönder
- 400 döndüğünü doğrula
- error.message alanının dolu olduğunu doğrula

Yetki testi:
- Token olmadan istek gönder
- 401 döndüğünü doğrula

Bu kontroller test senaryoları olarak yazılabilir ve test senaryolarında gruplanabilir.

Ardından bu senaryolar CI/CD içinde her değişiklikte çalıştırılır.

Manuel çaba ise şu işlere ayrılmalıdır:

• Keşif testi
• Uç durumların incelenmesi
• API’nin gerçek problemi çözüp çözmediğinin değerlendirilmesi
• Kullanıcı deneyimi ve ürün doğrulaması

Bu ayrım, doğrulama ile teknik kontrol arasındaki farkı da netleştirir.

Neleri otomatikleştirmeli, neleri manuel bırakmalı?

Her fonksiyonel testi otomatikleştirmek doğru değildir. Otomasyon seçici yapılmalıdır.

Otomatikleştirin: tekrarlayan ve kararlı kontroller

Her commit’te çalıştırmak istediğiniz kontroller otomasyon için iyi adaydır.

Örnekler:

• Login endpoint’i
• Sipariş oluşturma
• Ödeme başlatma
• Kullanıcı oluşturma
• Kritik veri okuma uç noktaları
• Regresyon kontrolleri

Eğer bir test uzun süre tekrar tekrar çalışacaksa, otomasyon maliyeti zamanla geri kazanılır.

Otomatikleştirin: yüksek değerli akışlar

Arızası ciddi sonuç doğuracak akışlar öncelikli olmalıdır.

Örnekler:

• Kimlik doğrulama
• Ödeme
• Yetkilendirme
• Sipariş yönetimi
• Fatura oluşturma
• Kritik entegrasyonlar

Bu testleri manuel bırakmak, yoğun teslimat dönemlerinde atlanma riskini artırır.

Otomatikleştirmeyin: nadir çalıştırılan kontroller

Bir testi yalnızca bir veya iki kez çalıştıracaksanız, otomasyon maliyeti genellikle değmez.

Örnek:

Sadece tek seferlik migration sonrası kontrol edilecek geçici endpoint

Bu durumda manuel kontrol daha ucuz olabilir.

Otomatikleştirmeyin: sürekli değişen özellikler

Henüz şekillenmemiş bir özellik için erken otomasyon, sürekli bakım yükü oluşturur.

Önce davranışın oturmasını bekleyin. Ardından kararlı gereksinimler üzerinden testleri otomatikleştirin.

Manuel bırakın: keşif testi

Otomatik testler yalnızca tanımlanmış beklentileri kontrol eder. İnsan test uzmanları ise beklenmeyen davranışları bulabilir.

Keşif testinde şu sorular sorulur:

• Bu API farklı sırayla çağrılırsa ne olur?
• Eksik veya beklenmeyen alanlar gönderilirse sistem nasıl davranır?
• Hata mesajları geliştirici için yeterince açık mı?
• Yanıt formatı gerçek kullanım için pratik mi?

Bu tür kontroller insan sezgisi gerektirir.

Manuel bırakın: yargıya dayalı kontroller

Bazı sorular assert ile cevaplanamaz:

• Hata mesajı gerçekten yardımcı mı?
• API tasarımı anlaşılır mı?
• İş akışı tutarlı mı?
• Geliştirici deneyimi iyi mi?
• Bu özellik kullanıcının gerçek problemini çözüyor mu?

Bu noktada otomasyon destek olur, ancak karar insan tarafından verilmelidir.

Uygulanabilir test stratejisi

Sağlıklı bir API test stratejisi şu yapıyı kullanabilir:

1. Otomatik fonksiyonel testler
   - Kritik endpoint kontrolleri
   - Status code doğrulamaları
   - Response body kontrolleri
   - Schema validation
   - Negatif testler

2. Otomatik fonksiyonel olmayan testler
   - Yük testi
   - Performans testi
   - Gecikme ölçümü

3. Manuel fonksiyonel testler
   - Keşif testi
   - Yeni özelliklerin ilk doğrulaması
   - Edge case araştırması

4. Manuel fonksiyonel olmayan testler
   - Kullanılabilirlik değerlendirmesi
   - API tasarımı incelemesi
   - Geliştirici deneyimi kontrolü

Bu yaklaşım iki riski azaltır:

• Her şeyi manuel yapıp yavaş geri bildirim almak
• Her şeyi otomatikleştirip kırılgan ve pahalı bir test paketi oluşturmak

Amaç, kritik ve tekrarlayan kontrolleri otomatikleştirmek; insan yargısı gerektiren alanları manuel bırakmaktır.

Apidog’da otomatik fonksiyonel API testleri oluşturma

Apidog, komut dosyası yazmadan otomatik fonksiyonel API testleri oluşturmak için kullanılabilir.

Temel iş akışı şöyledir:

1. API uç noktasını tanımlayın.
2. İstek parametrelerini ve body alanlarını ekleyin.
3. Beklenen durum kodunu belirleyin.
4. Yanıt gövdesi için alan kontrolleri ekleyin.
5. Şema doğrulaması tanımlayın.
6. Gerekirse yanıt süresi kontrolü ekleyin.
7. İlgili istekleri test senaryosunda gruplayın.
8. Senaryoyu manuel, zamanlanmış veya CI içinde çalıştırın.
9. Başarısız doğrulamaları rapor üzerinden inceleyin.

Örnek doğrulama mantığı:

GET /users/{id}

Beklenen:
- Status code = 200
- response.id exists
- response.email is string
- response.createdAt is datetime
- response.role in ["admin", "user"]

Aynı çalışma alanında yük testleri de çalıştırılabildiği için, otomatik fonksiyonel testlerle birlikte otomatik fonksiyonel olmayan testleri de yönetebilirsiniz.

Mevcut bir API için otomatik fonksiyonel test paketi oluşturmaya başlamak isterseniz Apidog’u indirin.

Sıkça sorulan sorular

Otomatik test bir fonksiyonel test türü müdür?

Hayır. Otomatik test, testleri çalıştırma yöntemidir. Fonksiyonel test ise neyin test edildiğini açıklar. Bir test hem fonksiyonel hem otomatik olabilir.

Fonksiyonel test otomatikleştirilebilir mi?

Evet. Özellikle API’lerde fonksiyonel testler genellikle otomatikleştirilmelidir. Durum kodu, yanıt gövdesi, şema ve hata formatı kontrolleri otomasyona uygundur.

Fonksiyonel testin gerçek zıttı nedir?

Fonksiyonel olmayan testtir. Performans, yük, güvenlik ve kullanılabilirlik testleri fonksiyonel olmayan test kapsamına girer.

Her fonksiyonel test otomatikleştirilmeli mi?

Hayır. Kararlı, tekrarlayan ve yüksek değerli kontroller otomatikleştirilmelidir. Keşif testi ve yargıya dayalı doğrulamalar manuel kalmalıdır.

Bir ekip nereden başlamalı?

API ekipleri için iyi başlangıç noktası otomatik fonksiyonel API testleridir. Önce kritik uç noktaları kapsayın, ardından performans/yük testleri ve manuel keşif testleriyle kapsamı genişletin.

Otomatik test manuel test uzmanlarının yerini alır mı?

Hayır. Otomasyon, tekrarlayan kontrolleri devralır. Test uzmanları ise keşif testi, uç durum analizi ve ürünün gerçekten iyi çalışıp çalışmadığını değerlendirme gibi daha yüksek değerli işlere odaklanır.

Aynı test hem fonksiyonel hem otomatik olabilir mi?

Evet. Çoğu API testi tam olarak böyledir. Örneğin bir uç noktayı çağırıp yanıtın doğru durum kodu ve şemayla döndüğünü doğrulayan test, otomatik fonksiyonel testtir.