Uçtan Uca Test (E2E Testi), bir sistemin veya ürünün başından sonuna kadar eksiksiz bir kullanıcı iş akışını doğrular ve bu süreçte yer alan tüm sistem, servis ve entegrasyonların birlikte doğru şekilde çalıştığını test eder. Bileşenleri birbirinden bağımsız olarak test etmek yerine, gerçek bir kullanıcının deneyimine mümkün olduğunca yakın şekilde tüm zincirin doğru çalıştığını doğrular. Bu kapsamda girişler, çıkışlar, veri akışları ve sistemler arasındaki tüm etkileşimler bir bütün olarak değerlendirilir.
E2E testinin kapsamı bilinçli olarak geniş tutulur. Tek bir E2E testi; kullanıcı arayüzü (UI), API, veritabanı, üçüncü taraf ödeme işlemcisi ve e-posta bildirim servisi gibi farklı katmanları kapsayabilir. Böylece her bir katman ayrı ayrı test edilmek yerine, tüm katmanlar birbirine bağlı tek bir işlem akışının parçası olarak çalıştırılır ve sistemin uçtan uca işlevselliği doğrulanır.
Uçtan Uca Test Neden Önemlidir?
Birim (unit) testlerinin başarıyla tamamlanmış olması, yazılımın bir bütün olarak doğru çalıştığını göstermez. Entegrasyon testlerinin başarıyla geçilmesi de tek başına yeterli değildir. Bu testler, sistemin bileşenlerinin kendi başlarına veya belirli entegrasyonlar kapsamında doğru çalıştığını gösterir. Ancak bu testler; söz konusu bileşenlerin gerçek çalışma koşullarında, doğru işlem sıralaması içerisinde ve aralarında gerçek veriler aktarılırken birlikte sorunsuz çalışıp çalışmadığını gösteremez.
Örneğin; kullanıcı giriş (login) akışı başarıyla test edilmiş, ödeme API'si doğrulanmış ve veritabanına veri yazma işlemi sorunsuz gerçekleşmiş olabilir. Buna rağmen ödeme/alışveriş işleminin tamamı başarısız olabilir. Bunun nedeni, kimlik doğrulama servisi ile sipariş yönetim sistemi arasında oturum belirtecinin (session token) doğru şekilde iletilmemesi olabilir. Birim testlerinin hiçbiri bu tür sistemler arası uçtan uca veri akışı problemini tespit etmeye yönelik olmayabilir.
Uçtan uca test (E2E), tam olarak bu boşluğu kapatır. Çünkü E2E testi; sistemin tüm bileşenlerinin, servislerinin ve entegrasyonlarının gerçek bir kullanıcı senaryosundaki işlem akışı boyunca birlikte çalışmasını doğrular. Bu nedenle bir E2E testindeki başarısızlık, gerçek kullanım senaryosunda kullanıcının işlemi gerçekleştiremeyeceği anlamına gelir. Çoğu durumda, sistemin kullanıcı açısından gerçekten çalışıp çalışmadığını gösteren en önemli sonuç da budur.
Şekil 1. Bir ödeme/alışveriş işleminin tamamlanması, altı farklı sisteme dokunan bir işlem akışını içerir. Test senaryosu yalnızca kullanıcı arayüzü ekranında sonlanıyorsa, doğrulanan tek şey ön yüzün (front-end) ilgili sayfayı doğru şekilde görüntüleyebildiğidir; sistemin geri kalan bileşenlerinin doğru çalıştığı doğrulanmış olmaz.
Uçtan Uca Test Nasıl Çalışır?
Uçtan uca test (E2E), birim veya entegrasyon testlerine kıyasla daha fazla hazırlık ve kurulum gerektirir. Bu nedenle ekipler tarafından çoğu zaman yeterince uygulanmaz. Tipik bir E2E test döngüsü aşağıdaki adımlardan oluşur:
- Kritik kullanıcı iş akışlarını belirleyin.Her iş akışının E2E testiyle doğrulanması gerekmez. Hata oluştuğunda ciddi sonuçlara yol açabilecek kritik akışlara odaklanılmalıdır. Örneğin; ödeme/alışveriş işlemleri, kullanıcı girişi, hesap oluşturma, veri gönderimi ve kritik işlemler.
- Test kapsamında yer alan sistemleri ve bileşenleri haritalayın.Her iş akışının hangi servis, API, veritabanı, üçüncü taraf araç ve çalışma ortamlarıyla etkileşimde bulunduğu belirlenmeli ve dokümante edilmelidir. Bu aşama, ekiplerin sistem içerisinde gerçekte kaç farklı bağımlılığın bulunduğunu ortaya çıkarmasını sağlar.
- Test verilerini hazırlayın.E2E testleri, üretim (production) ortamındaki verileri etkilemeyecek veya kirletmeyecek şekilde gerçekçi test verilerine ihtiyaç duyar. Test ortamlarının gerçek çalışma ortamını mümkün olduğunca doğru şekilde yansıtması gerekir; aksi durumda elde edilen test sonuçları yanıltıcı olabilir.
- Test senaryolarını oluşturun ve çalıştırın.Testler, gerçek bir kullanıcının gerçekleştireceği işlemleri simüle eder. Bunlar; ekrana tıklama, veri girişi, formların gönderilmesi, arka planda çalışan süreçlerin tetiklenmesi ve beklenen sonuçların oluşması için gerekli sürelerin beklenmesi gibi işlemleri kapsar.
- Sonuçları doğrulayın.Doğrulamalar (assertions) yalnızca kullanıcı arayüzünün verdiği tepkiyi değil, işlemin sonunda oluşması gereken gerçek sistem durumunu kontrol eder. Örneğin; veritabanına kayıt başarıyla yazıldı mı? İşlem onay e-postası tetiklendi mi?
- Hataları raporlayın ve nedenlerini analiz edin.E2E testlerinde hata kaynağını belirlemek, birim testlerine kıyasla daha zordur. Bunun nedeni, hatanın sistem zincirindeki herhangi bir bileşenden, servis veya entegrasyondan kaynaklanabilmesidir. Bu nedenle kök neden analizi (root cause analysis) daha kapsamlı bir inceleme gerektirir.
Şekil 2. Altı aşamalı test döngüsü. 1. ve 5. adımlar, test paketinin oluşturulmasının ve sürdürülmesinin gerçekten gerekli ve değerli olup olmadığını belirler; diğer adımlar ise testlerin uygulanmasına odaklanır.
Uçtan Uca Test ile Fonksiyonel Test ve Entegrasyon Testi Arasındaki Farklar
Bu üç test yaklaşımının amaçları belirli ölçüde örtüşse de kapsamları, sorumluluk alanları ve sistem içerisindeki problemlerin hangi seviyede ortaya çıkarıldıkları açısından birbirlerinden farklıdır.
Bunlar birbirinin alternatifi değildir; birbirini tamamlayan test katmanlarıdır. E2E (uçtan uca) testi bu test yapısının en üst katmanında yer alır ve kendisinden, alt katmanların gerçekleştirmesi gereken testleri üstlenmesi beklenmemelidir.
Bunlar birbirinin alternatifi değildir; birbirini tamamlayan test katmanlarıdır. E2E (uçtan uca) testi bu test yapısının en üst katmanında yer alır ve kendisinden, alt katmanların gerçekleştirmesi gereken testleri üstlenmesi beklenmemelidir.
Uçtan Uca Test Örnekleri
E-ticaret ödeme/alışveriş süreci. Bir müşteri ürünü arar, ürünü alışveriş sepetine ekler, indirim kodunu uygular, ödeme bilgilerini girer ve sipariş onayını alır. E2E testi; stok rezervasyonunun oluşturulmasını, ödeme ağ geçidinden (payment gateway) gelen yanıtı, sipariş kaydının oluşturulmasını ve sipariş onay e-postasının gönderilmesini doğrular.
Bankacılıkta parola sıfırlama. Kullanıcı parola sıfırlama talebinde bulunur, bir e-posta alır, e-postadaki bağlantıya tıklar, yeni parolasını belirler ve ardından sisteme giriş yapar. Test; sıfırlama belirtecinin (token) doğru şekilde oluşturulmasını ve süresinin dolmasını, kimlik doğrulama (authentication) servisindeki kullanıcı bilgilerinin güncellenmesini ve eski oturumun geçersiz hale getirilmesini doğrular.
Sağlık hizmetlerinde hasta kabul süreci. Hasta kayıt işlemini tamamlar, sigorta belgelerini sisteme yükler ve randevu onayı alır. Test; hasta portalından randevu planlama sistemine ve kayıt/veritabanı sistemine aktarılan verilerin herhangi bir kayıp veya bozulma olmadan doğru şekilde iletilmesini doğrular.
Sigorta hasar dosyası başvurusu. Sigortalı bir hasar dosyası oluşturur, ilgili belgeleri yükler ve bir başvuru referans numarası alır. Test; hasar dosyasına ait verilerin sigortalama (underwriting) sistemine doğru şekilde yönlendirilmesini, bir alındı/onay bildiriminin tetiklenmesini ve uygun denetim kaydının (audit trail) oluşturulmasını doğrular.
ERP siparişten tahsilata (Order-to-Cash) süreci. Satış siparişi oluşturulur, stok durumu kontrol edilir, siparişin karşılanma/tedarik süreci başlatılır, sevkiyat onaylanır ve fatura oluşturulur. Kurumsal yazılımlardaki daha karmaşık iş akışlarından biridir; çünkü sürecin herhangi bir aşamasında meydana gelen bir hata, gelirin muhasebeleştirilmesi sürecinin ilerlemesini durdurabilir.
Mobil uygulamada hesap oluşturma ve kurulum. Yeni kullanıcı uygulamayı yükler, kayıt işlemini gerçekleştirir, OTP (Tek Kullanımlık Parola) ile kimlik doğrulamasını tamamlar ve profilini oluşturur. Test; kayıt servisini, OTP'nin iletilmesini, profil verilerinin sisteme doğru şekilde yazılmasını ve her adım sonrasında mobil uygulamanın durumunu kontrol eder.
Uçtan Uca Testlerde Yaygın Karşılaşılan Sorunlar
Kırılgan (brittle) testler. Belirli kullanıcı arayüzü (UI) seçicilerine (selector) bağlı olarak oluşturulan test paketleri, ön yüz (frontend) üzerinde yapılan her değişiklikte çalışamaz hale gelebilir. Özellikle kapsamlı bir arayüz yenilemesi veya tasarım değişikliği gerçekleştiren ekipler bu sorunla sıklıkla karşılaşır.
Kararsız (unstable) test ortamları. Test ortamı üretim (production) ortamını güvenilir ve tutarlı bir şekilde yansıtmıyorsa, testlerde ortaya çıkan hatalar anlamlı bir sonuç olmaktan çıkar ve gürültü (noise) haline gelir. Bunun sonucunda ekipler test sonuçlarına olan güvenini kaybederek test paketlerini daha az çalıştırmaya başlar.
Test verilerinin yönetimi. Uygun bir test verisi yönetim stratejisi bulunmadığında, testler birbirleriyle çakışabilir veya güvenilirliği olmayan sonuçlar üretebilir. Bu nedenle test verilerinin izole, tutarlı, tekrarlanabilir ve kontrollü şekilde yönetilmesi gerekir.
Yavaş test yürütme. Üç saat süren bir test paketi, sürekli entegrasyon ve sürekli teslimat (CI/CD) süreçlerine uygun değildir. Ekipler bu tür testleri atlayabilir veya çok seyrek çalıştırabilir. Bu da E2E testlerinin temel amacını büyük ölçüde ortadan kaldırır.
Üçüncü taraf bağımlılıkları. Ödeme ağ geçitleri, kimlik doğrulama servisleri ve harici API'ler, ekibin doğrudan kontrolü dışında gerçekleşen hata senaryoları oluşturabilir. Bu tür bağımlılıklar mocking (sahte servis kullanımı), contract testing (sözleşme testi) veya kapsamın net şekilde sınırlandırılması yoluyla yönetilmelidir.
Belirsiz sorumluluk. Testler birden fazla ekip tarafından geliştirilen veya yönetilen sistemleri kapsadığında, ortaya çıkan hataların sorumluluğunu üstlenmek konusunda belirsizlik oluşabilir. Bunun sonucunda testler çalıştırılmayabilir ve tespit edilen problemler giderilmeyebilir.
Yetersiz hata teşhisi. Başarısız olan bir E2E testi, uzun sistem zincirinin bir noktasında bir sorun olduğunu gösterir; ancak problemin tam olarak nereden kaynaklandığını tek başına ortaya koymaz. Yeterli loglama ve izleme (logging & monitoring) mekanizmaları bulunmadığında, kök nedeni belirlemek gerekenden çok daha uzun sürebilir.
Bu sorunların ilki, test paketlerinin büyük bölümünü kullanılamaz hâle getiren temel problemdir ve nedeni prosedürlerden ziyade yapısaldır. DOM'a (Document Object Model) sıkı şekilde bağlı olarak oluşturulan bir test paketi, DOM'un sahip olduğu tüm kırılganlıkları doğrudan devralır. Bu nedenle, ne kadar titiz bir test süreci veya disiplinli bir uygulama yaklaşımı benimsenirse benimsensin, sorunun temelindeki yapısal kırılganlık ortadan kaldırılamaz.
Otomasyon, Uçtan Uca Test Sürecini Nasıl Değiştirir?
Otomasyon, E2E testlerinin tekrarlanabilir hâle gelmesini, daha hızlı yürütülmesini ve CI/CD (Sürekli Entegrasyon/Sürekli Teslimat) süreçleri içerisinde çalıştırılabilmesini sağlar. Otomasyonun sağladığı temel avantajlar bunlardır.
Ancak otomasyon, kötü tasarlanmış bir test senaryosunu düzeltmez. Kapsamı veya amacı doğru belirlenmemiş bir testin otomatikleştirilmesi, yine kapsamı veya amacı doğru belirlenmemiş bir test ortaya çıkarır. Benzer şekilde otomasyon; test ortamı, test verilerinin yönetimi veya sorumlulukların net olmaması gibi temel problemleri de tek başına çözmez.
Otomasyonun en büyük farkı yarattığı alanlar:
- Regresyon testlerinin otomatik çalıştırılması: Her derleme (build) sonrasında regresyon test paketlerinin herhangi bir manuel müdahaleye gerek kalmadan otomatik olarak çalıştırılması.
- Platformlar arası test yürütme: Testlerin farklı web tarayıcıları, cihazlar ve işletim sistemleri üzerinde çalıştırılması.
- Paralel test yürütme: Birden fazla test senaryosunun aynı anda çalıştırılarak toplam test süresinin önemli ölçüde azaltılması.
- Tutarlı ve tekrarlanabilir sonuçlar: Testlerin, testi kimin çalıştırdığına bağlı olarak değişmeyen, standartlaştırılmış ve güvenilir sonuçlar üretmesi.
- Olgun bir test otomasyonu yaklaşımı; UI otomasyonu, API seviyesinde doğrulama, kullanıcı arayüzünün (UI) doğruluğunu kontrol etmeye yönelik görsel kontroller ve CI/CD pipeline entegrasyonunu bir arada kullanır. Model tabanlı test (model-based testing), test senaryolarının otomatik olarak oluşturulması ve sürdürülmesi için kullanılan yaklaşımlardan biridir. Bu yaklaşım özellikle, manuel test bakımının darboğaz hâline geldiği büyük ve karmaşık uygulamalarda önem kazanır.
- Keysight'ın Automation Intelligence (Eggplant Test) çözümü de bu yaklaşımla çalışır: Uygulamanın bir modeli, testin izleyeceği işlem yollarını (paths) oluşturur; bilgisayarlı görü (computer vision) ise kullanıcı arayüzüyle etkileşimi yönetir. Böylece aynı test akışı, DOM'u hiç açığa çıkarmayan sistemlerde bile çalıştırılabilir.
- Otomasyon, neyin test edileceğine karar verme sürecinin yerini almaz. Otomasyon, daha önce verilmiş test kararlarını uygular ve yürütür.
Uçtan Uca Test Yaklaşımı Nasıl Seçilir?
Kapsama alanı (Coverage). Test yaklaşımı, kullanıcı iş akışında yer alan tüm bileşenlere erişebiliyor mu? Kullanıcı arayüzü (UI), API'ler, veritabanları ve üçüncü taraf servisler kapsama dahil mi? Eğer test yalnızca ön yüze (frontend) erişebiliyorsa, bu tam kapsamlı bir E2E çözümü değildir.
Bakım kolaylığı (Maintainability). Her kullanıcı arayüzü değişikliğinde bozulan test scriptleri, mühendislik ekibinin zamanına sürekli bir maliyet yükler. Bu nedenle model tabanlı test üretimi, görsel otomasyon veya testleri UI yapısından bağımsız hâle getiren soyutlama (abstraction) gibi yöntemlerle testlerin güncel tutulma maliyetini azaltan yaklaşımlar tercih edilmelidir.
Platformlar arası test yürütme (Cross-platform execution). Yazılımınız farklı web tarayıcıları, cihazlar ve işletim sistemleri üzerinde kullanılıyorsa, testlerin de bu farklı platformları kapsaması gerekir.
Ortamlar arasında orkestrasyon (Orchestration across environments). Bir web tarayıcısı, masaüstü istemcisi, arka uçtaki bir veritabanı tablosu ve çevresel bir cihazı (peripheral device) kapsayan bir iş akışının, elle birbirine bağlanmış dört ayrı script olarak değil, tek ve koordineli bir akış olarak çalıştırılması gerekir. Test araçlarının en çok zorlandığı noktalardan biri budur. Aynı zamanda, test paketinin iş akışının tamamına erişebilmesi ile yalnızca erişilmesi kolay bölümlerini test edebilmesi arasındaki temel farkı oluşturur.
CI/CD entegrasyonu. Bir derleme (build) sonrasında tetiklenemeyen testler, pratikte çalıştırılmayacak testlerdir. Bu nedenle kullandığınız test aracının Jenkins, GitHub Actions, Azure DevOps veya kullandığınız diğer CI/CD araçlarıyla ne kadar uyumlu olduğunu değerlendirin.
Raporlama (Reporting). Bir test başarısız olduğunda, hatanın nerede ve neden oluştuğunu ne kadar hızlı tespit edebiliyorsunuz? E2E hata ayıklama sürecinin (debugging) en zor kısmı, kök neden analizidir (root cause analysis).
Ölçeklenebilirlik (Scalability). Yirmi testi yönetmek kolaydır; ancak iki bin testi yönetmek aynı şey değildir. Test otomasyon altyapısını seçerken, ileride ölçek büyüdüğünde ortaya çıkabilecek yönetim ve bakım gereksinimlerini göz önünde bulundurmak gerekir.
Yönetişim ve izlenebilirlik (Governance and traceability). Finans, sağlık ve havacılık/uzay gibi sektörlerde test sonuçlarının çoğu zaman gereksinimlerle ilişkilendirilmesi, izlenebilir olması ve denetime (audit) hazır şekilde sunulabilmesi gerekir. Her test aracı bu gereksinimleri aynı ölçüde desteklemez.
Sonuçların rakamsal karşılığı: JetBlue, Flightkeys UI sistemlerinde test yürütme süresinin %93 oranında azaldığını bildirmiştir. Böylece üç hafta süren manuel test süreci tek bir güne indirilmiştir. FUJIFILM Software ise geleneksel manuel test yöntemleriyle karşılaştırıldığında, tüm test sürecindeki insan-saat ihtiyacında %92 oranında azalma sağlandığını bildirmiştir.
Bu yaklaşımın tüm ayrıntılarına uçtan uca test yetkinliği sayfasından ulaşabilirsiniz.
Uçtan Uca Test SSS (Sıkça Sorulan Sorular)
1-Uçtan uca test ile entegrasyon testi arasındaki fark nedir?
Entegrasyon testi, iki veya daha fazla bileşenin birbiriyle doğru şekilde iletişim kurduğunu kontrol eder. Uçtan uca test (E2E) ise kullanıcı arayüzü (UI), API'ler, veritabanları ve harici servisler dahil olmak üzere, kullanıcı iş akışında yer alan tüm sistemler üzerinden uçtan uca bir kullanıcı yolculuğunu doğrular. Entegrasyon testi, genel test yapısının yalnızca bir alt kümesidir. Uçtan uca test ise kullanıcının bakış açısından sistemin tamamını değerlendirir.
2-Uçtan uca testlerin çalıştırılması ne kadar sürer?
Bu süre, test paketinin büyüklüğüne ve testlerin paralel olarak çalıştırılıp çalıştırılmadığına bağlıdır. Ancak kurumsal uygulamalardaki kapsamlı test paketlerinin çalıştırılması genellikle 30 dakika ile birkaç saat arasında sürebilir. Ekipler genellikle her derleme (build) sonrasında daha kısa bir smoke test paketi çalıştırırken, kapsamlı test paketini belirli bir programa göre veya sürüm yayınlanmadan önce çalıştırır.
3-Uçtan uca testlerden kim sorumlu olmalıdır?
Uçtan uca testlerin büyük bölümü QA mühendisleri ve SDET'ler (Software Development Engineers in Test) tarafından geliştirilir ve sürdürülür. Ancak test başarısızlıklarının sorumluluğu paylaşılmalıdır. Örneğin bir test, arka uç API'sinde yapılan bir değişiklik nedeniyle başarısız oluyorsa, sorumluluk QA ekibine değil, arka uç (backend) ekibine aittir. Bu nedenle tek bir sorumlu belirlemekten ziyade, ekipler arasındaki net devir ve sorumluluk protokolleri daha önemlidir.
4-Uçtan uca testler bir CI/CD pipeline'ında çalıştırılabilir mi?
Evet, doğru yapılandırmayla çalıştırılabilir. Buradaki temel kısıt testlerin çalışma süresidir. Her commit sonrasında hedeflenmiş bir smoke test paketi çalıştırılabilir; kapsamlı regresyon test paketi ise belirli bir programa göre veya sürüm öncesinde çalıştırılabilir. Ayrıca testlerin farklı makinelerde paralel olarak yürütülmesi, toplam test süresinin azaltılmasını sağlar.
5-Uçtan uca testlerde hangi araçlar kullanılır?
Selenium, Cypress ve Playwright, web uygulamalarında yaygın olarak kullanılan DOM tabanlı test araçlarıdır. Keysight Eggplant Test gibi model tabanlı ve bilgisayarlı görü (computer vision) kullanan platformlar ise aynı kullanıcı iş akışlarını test etmenin yanı sıra, DOM sunmayan sistemleri de kapsayabilir. Bunlara Citrix ortamları, mainframe terminalleri, gömülü cihazlar ve paket yazılımlar (packaged software) dahildir.
6-DOM'u olmayan veya kaynak koduna erişimin kısıtlı olduğu sistemlerde uçtan uca test yapılabilir mi?
Evet; ancak selector tabanlı test araçlarıyla değil. Citrix oturumları, mainframe terminalleri, kiosklar, POS (Point of Sale) donanımları ve gömülü arayüzler, sorgulanabilecek bir nesne modeli (object model) sunmaz. Bu sistemlerin test edilmesi, doğrudan görüntülenen ekranın görüntü tanıma (image recognition) ve OCR (Optical Character Recognition) kullanılarak kontrol edilmesini gerektirir. Bu yaklaşım, uygulamada herhangi bir değişiklik yapmadan bu tür sistemlere erişerek test gerçekleştirebilmenin temel yöntemidir.
7-Kaç tane uçtan uca testiniz olmalıdır?
Düşündüğünüzden daha az. Test piramidinde uçtan uca testlerin en üst seviyede yer almasının bir nedeni vardır: Bu testler yavaştır, bakımı maliyetlidir ve hata teşhisi zordur. Bu nedenle, başarısız olması durumunda gerçek ve önemli sonuçlara yol açabilecek kritik kullanıcı iş akışlarını kapsamak gerekir. Diğer testleri ise entegrasyon ve birim testleri seviyesine taşımak daha doğru bir yaklaşımdır.
8-Uçtan uca test ile kullanıcı kabul testi (UAT) arasındaki fark nedir?
Uçtan uca test, sistemin teknik yazılım yığınının (technical stack) tüm katmanları boyunca doğru şekilde çalıştığını doğrular. Kullanıcı kabul testi (UAT – User Acceptance Testing) ise sistemin işletmenin/ticari birimin talep ettiği gereksinimleri karşılayıp karşılamadığını doğrular ve genellikle QA ekibi yerine iş birimi kullanıcıları tarafından gerçekleştirilir.
Kısaca: Biri sistemin teknik olarak doğru çalıştığını, diğeri ise iş gereksinimlerini karşılayıp karşılamadığını kontrol eder.
Buradan Çıkarılacak Sonuç
Uçtan uca test, kullanıcının başarısız olacağı bir durumda başarısızlık gösteren tek test katmanıdır. Bu durum, E2E testlerini sahip olduğunuz en değerli test paketi hâline getirir. Ancak aynı zamanda, bu testlerin sürdürülebilirliğini en zor hâle getiren faktör de kapsamlarının geniş olmasıdır. Çünkü bu geniş kapsam, E2E testlerini yavaş, kırılgan ve hata teşhisi zor testler hâline getirebilir.
Bu problemlerin büyük bölümü prosedürel olmaktan ziyade mimari niteliktedir. DOM'a sıkı şekilde bağlı bir test paketi, DOM'un sahip olduğu tüm kırılganlıkları doğrudan devralır. Bu nedenle, ne kadar disiplinli bir test süreci uygulanırsa uygulansın, temel mimari yapıdan kaynaklanan bu kırılganlık ortadan kaldırılamaz.
Bu yaklaşımın orkestrasyon (orchestration) boyutu; cihazlar, platformlar ve veritabanları arasında tek bir kullanıcı iş akışının, elle birbirine bağlanmış ayrı scriptler yerine tek ve koordineli bir akış olarak çalıştırılmasını ifade eder. Bu konu, Keysight Eggplant ile Uçtan Uca Test (End-to-End Testing with Keysight Eggplant) çözüm dokümanında ayrıntılı olarak ele alınmaktadır. Keysight da kurumsal düzeyde orkestrasyonun; cihazlar, platformlar ve veritabanları arasındaki iş akışlarını koordine ederek testlerin izole scriptler yerine kesintisiz bir uçtan uca süreç olarak yürütülmesini sağladığını belirtmektedir.
