Cevap.

Manuel entegrasyon testi, çeşitli modüller, hizmetler veya dış sistemler arasındaki etkileşimlerin otomatik betikler olmaksızın manuel olarak kontrol edilmesi sürecidir.

Soru Tarihi:

BT ürünlerinin gelişiminin başında tüm sistemler monolitik olarak oluşturuluyordu, ancak şirketin ölçeği ve dış hizmetlerin sayısındaki artış ile entegre testler güncel hale geldi. Test mühendisleri, verilerin ve eylemlerin sistemler arasında doğru bir şekilde geçip geçmediğini — örneğin, başarılı bir ödemenin hem faturalama hem de muhasebe sisteminde yansıyıp yansımadığını nasıl doğrulayacaklarını sorgulamaya başladılar.

Sorun:

En büyük zorluk, tam işlevsel bir ortamın olmaması: entegrasyonlar dış hizmetlere, kararsız API'lere veya harici kısıtlamalara bağlı olabilir. Ayrıca, her entegrasyon noktasında manuel test yapmak çok zaman alıcı olabilir ve adım sıralamasında hata yapılması veya önemli bir kaskad etkisinin gözden kaçırılması kolaydır.

Çözüm:

Testin tekrarlanabilirliğini sağlamak için "sahte" (mock/stub) test ortamları kullanın.
Test senaryolarını yapılandırın, mesajlar, günlükler, durumlar için adım adım kontroller yazın.
Öncelikle sınır durumlarını, zaman aşımını, entegrasyon çağrılarını tekrar denemeyi, sistemin hatalara tepkisini kontrol edin.

Anahtar özellikler:

Entegre edilen her iki tarafın iş mantığını anlamanın gerekliliği.
Asenkronluğun ve durum aktarımındaki hataların dikkate alınması.
Kısmi arızalara karşı dayanıklılık desteği.

Kandırmaca Soruları.

Test çiftleri (test doubles) nedir ve manuel entegrasyon testlerinde neden gereklidir?

Test çiftleri, entegrasyon bileşenlerinin taklitleridir (örneğin, mock, stub, fake). Manuel testin gerektirdiği durumlar, gerçek dış sistemin erişilemez olduğu veya çağrılarının maliyetli olduğu senaryoları çalıştırmaktır.

Eğer test senaryoları sadece happy path'i kapsıyorsa, entegrasyonun test edilmiş sayılabilir mi?

Hayır. Kesinlikle kenar durumlarını test etmek gerekmektedir: bağlantı hataları, hatalı veri formatları, zaman aşımı, beklenmeyen yanıtlar.

Sadece veri gönderim/alımını kontrol etmek yeterli mi yoksa başka bir şey gerekir mi?

Verilerin İÇERİĞİNİ kontrol etmek, verilerin dönüşümünü ve sistemin farklı hatalar karşısındaki davranışını kontrol etmek önemlidir.

Tipik Hatalar ve Antipatternler

Sadece "kendi" sistem kısmıyla çalışmak, partner tarafındaki davranışı kontrol etmemek.
Olumsuz senaryoları göz ardı etmek.
Günlükleri analiz etmemek veya entegrasyon hatalarının geçmişini tutmamak.

Hayattan Bir Örnek

Olumsuz Durum

Test mühendisi, CRM ile faturalama sistemi arasındaki entegrasyonu yalnızca başarılı sipariş ekleme açısından test eder. Senkronizasyon hatasını ve işlem kaybını kontrol etmez.

Artıları:

Temel senaryoların hızlıca karşılanması.

Eksileri:

Entegrasyon hatası, yalnızca gerçek verilerle ortaya çıkacaktır.

Olumlu Durum

Test mühendisi, internet bağlantısını kapatma ve açma senaryoları ile geçersiz jetonların yerleştirilmesi gibi bir dizi test oluşturur. Her iki tarafın günlüklerini doğrular.