Görev dışı kritik şeyler için uçtan uca ve entegrasyon testleri buna değer mi?

Uçtan uca ve entegrasyon testlerinin maliyetli olduğu iyi bilinmektedir. Tabii ki işler ters giderse insanların ölebileceği uygulamalar geliştirirsek değerli bir yatırımdır. Bununla birlikte, hataların dünyanın sonu olmadığı uygulamalarda, E2E testlerini ve entegrasyon testlerini tamamen atlamak ve bir şey ters giderse bir yedekleme planı hazırlamak daha ucuz olmaz mı? Tıpkı statik olarak yazılmış bir dili kullanan kullanıcı hikayeleri + birim testleri + manuel testi gibi mi?

Örneğin, bir web mağazası bir siparişi kaybederse, öğeyi ücretsiz olarak + başka bir öğeyi özür olarak gönderebilirler. Son kullanıcı bu şekilde daha mutlu olabilir ve şirket genel olarak para tasarrufu sağlar.

Sanırım sorum şu: Bir entegrasyon testinin ve E2E testinin maliyeti ne kadar ve maliyeti ne kadar? Bunun için bir risk / maliyet hesaplaması yapmanın bir yolu var mı?

E2E ve entegrasyon testlerini uygulamanız ya da uygulamamanız önemli değil, her iki şekilde de bir yedekleme planına ihtiyacınız var . Bir sistemin sadece test edildiğinden hatasız olmasını beklemeyin.

Dolayısıyla, maliyet tahmininizde, E2E testlerini uygulama maliyetini, bir arıza durumunda yedekleme planınızın tahmin ettiği maliyetlerle karşılaştırmazsınız:

• E2E testlerini manuel olarak yapma maliyetleri (her yeni sürümden önce birkaç kez)

vs.

• Otomatik E2E testleri oluşturma (ve bakımını yapma) maliyetleri

Bu E2E testlerini birkaç kez kullanabilmeniz durumunda, genellikle maliyetlerin başabaş noktasına ulaştığı bir dizi test çalışması olacaktır. Hangi E2E testlerini manuel olarak yapacağınızı ve hangisini otomatikleştireceğinizi önceden planlamak istediğinizde uyguladığınız metrik olmalıdır.

YG'nin hemen net olduğu yerlerde kolayca uygulanabilen bazı E2E testleri olabilir, ancak geliştirme ve bakımın birkaç yıl boyunca manuel olarak yapılmasının daha pahalı olabileceği E2E testleri de vardır.

Belki de sezgisel bir şekilde karşı koymak, otomatik test geliştirme testini vs geliştirme süresini azaltabilir. Yani bu bir kazan kazan.

Fikir şu ki, testler bir dizi seviyeye katkıda bulunuyor

1. Sıkı gereksinim toplama ve belirtmeyi zorla

   Bu gelişme hızı üzerinde büyük bir etki yapar. Daha fazla ayrıntı, yanlış anlama, gereksiz özellik vb.

2. Geliştiriciler bir özelliğin ne zaman tamamlandığını bilir

   Testlerin çoğu, bitmiş bir ürünü kontrol eden test ediciler yerine kodun yazılması sırasında geliştiriciler tarafından yapılır. Bu testin otomatikleştirilmesi bu iş yükünü azaltır

3. Yeni özelliklerin getirdiği hatalar anında tespit edildi.

   Bunlar kolayca bir sprint'e mal olabilir ve tespit edilmezse tüm bir özelliğin yeniden yazılmasını gerektirebilir.

4. Daha hızlı yayın döngüsü

   Bu, uçuşta daha az kod anlamına gelir, bu da daha az birleşme anlamına gelir, bu da geliştiriciler için daha az çalışma ve daha az karmaşıklık anlamına gelir

Özellikle bir test çerçevesi kurulumunuz varsa, bu testleri yazmak bu verimliliklerde kaydettiğinizden daha az zaman alır.

Ayrıca, manuel test süresinden tasarruf edersiniz, ayrıca sonunda daha iyi bir ürün elde edersiniz.

Cevabım? Belki de hayır .

EOE testleri çok basit olduklarında iyidir. Temel senaryoları kapsamayı planlıyorsanız, EOE testleriyle avantaj elde etmeyi başarabilirsiniz. Ancak, gerçekten karmaşık ve büyük bir uygulamanız varsa (kritik veya kritik olmayan görev), bu EOE testlerinin bakımı pahalı olacaktır ve buna değer veriyorsa değer vermek için senaryonuzu bilmeniz gerekir.

Birkaç yıl önce Google Test Blogu bu konuyu tartışıyor. Sadece yazara katılıyorum. İyi bir testin hızlı , güvenilir ve izolasyon arızaları olması gerekir, EOE testlerinin size sağlayamayacağı özellikler.

Birçok senaryoyu kapsayan 12 saatten fazla uçtan uca test içeren bir uygulama üzerinde çalıştım . Sonunda bu testleri farklı makinelere dağıtmayı, testlerin başlamasını, yürütülmesini ve bitmesini kontrol ederek, sonuçları toplayıp birleştirmeyi başardık. Test edilen uygulama, monolit bir uygulamadır (test edilmesi ve çalıştırılması daha kolaydır) ve testleri sürdürmek kabus olmuştur.

Çoğu zaman, sonuçlarından hataları yakalamak yerine testleri sürdürüyorduk. Uçtan uca testte bir hatanın kökenini keşfetmek çok zaman alır. Ayrıca bir çok "yanlış-negatif" testle ve sorunu anlamak ve düzeltmek için birkaç kez uğraştık: Java Uygulaması yükleme sorunları, sayfada bulunmayan beklenen öğe (artı otomasyon hızı ile ilgili diğer sorunlar), sadece veritabanı bellek testinde kullanılır (çünkü orijinal sorgu veritabanına özel kod kullandığından).

Bütün bunlar insanların ayakta kalmasını ve çalışmasını gerektirir. Sonunda bazı EOE testlerini silmeye ve birçok birim / entegrasyon testiyle değiştirmeye başlıyoruz.

Bu yüzden, muhafazakar tavsiyem Google'dan test piramidini kullanmaktır:

İyi bir ilk tahmin olarak, Google genellikle 70/20/10 ayrımı önerir:% 70 birim testleri,% 20 entegrasyon testleri ve% 10 uçtan uca testler. Kesin karışım her takım için farklı olacaktır, ancak genel olarak bu piramit şeklini korumalıdır.

Deneyimlerime göre, uygulamanın kritikliğine bakılmaksızın E2E testi her zaman ihtiyatlı. Her zaman en kötü durum senaryosu açısından düşünüyorum, eğer işler armut şeklinde olursa, yönetimin önünde ayakta durup yaklaşımınızı haklı çıkarır mısınız? Değilse, yaklaşımınızı değiştirmeniz gerekir. Birçok kuruluş testin önemini ve kaynaklarını en aza indirir, ancak işler ters gittiğinde herkesin suçlanacak birini aradığından ve testi sınırlama kararı aldıysanız veya bu tavsiyeyi verdiğinizden emin olabilirsiniz. hat.

Yazılım geliştirme çoğu zaman örgütsel politikaları gözetmeyi gerektirir.

"Uçtan uca ve entegrasyon testlerinin maliyetli olduğu iyi biliniyor."

Sanırım bu iddiaya katılmıyorum.

İlk olarak, E2E testleri son kullanıcılar için önemlidir ve karmaşık sistemleri test etmek için en etkili / en düşük maliyet seçenekleri olabilir. Örneğin, birisi bir araba satın aldığında çoğu kişi onu parçalara ayırmaz ve karbonhidrat, şanzıman, tekerlekleri ayrı ayrı test etmeye başlamaz. Bunun yerine, bir test sürüşü için alırlar.

İkinci olarak, takım açısından E2E, ürünün iç evrimini yavaşlatma eğiliminde değildir ve daha uzun süre dayanır. Bunu düşünürseniz, çoğu ürünün gerçek fonksiyonel yüzeyi nadiren çok fazla değişir, ancak dahili olarak her türlü gelişmeye maruz kalabilir. Sonuç olarak, test aleti hazır ve çalışır durumda olduğunda, genellikle çok iyi sürer. Örnek olarak, araba benzetmesine geri dönersek. Aynı "sürüş için al" test durumu, Tesla'da olduğu gibi Ford Model T'de de işe yarayacaktır. Yuvarlanan yollara, rüzgar tünellerine, kaçak test kurulumlarına vb. Yapılan yatırımlar gibi, dahili bileşen testlerinden kaçının ömrü boyunca bu kadar iyi bir yatırım getirisi olurdu?

İlk kurulumda olsa ve her şeyi denemek ve test etmek için kullanılıyorsa, E2E testinin daha pahalı / uygunsuz olduğu yerler. Pragmatik olarak, bu tuzaktan kaçınmanın en iyi yolunun aşağıdakileri test etmeyi otomatikleştiren öncelikler olduğunu düşünüyorum:

1. Otomatikleştirilmesi kolaydır ve çalışmaya devam etmek için çok fazla bakıma ihtiyaç duymaz.
2. Tutarlı, yeterli, manuel test süreçlerini uygulamak için en fazla zamanı tüketin.
3. Ürün kırılmış olarak serbest bırakılırsa, sizi veya patronunuzu aptal gibi gösterme riski.

Uygun olduğunu düşündüğünüz E2E dahil her türlü test yöntemini kullanın. Yine de bunlara odaklanın.

Entegrasyon testlerinin maliyetini en iyi durumun maliyetiyle gerçekten karşılaştıramazsınız bir hatanın yalnızca tek bir siparişi etkilediği senaryosunun . Mantıksal bir hatanın çok sayıda emri etkilemesi muhtemeldir. Hata söyleyin, hiçbir ödemenin alınmadığı anlamına gelir - bunun herhangi bir işletme için feci etkileri olabilir.

E2E testinin olmaması nedeniyle gerçekçi bir şekilde üretimde ortaya çıkabilecek en kötü durum hatasının ne olduğunu sormalısınız . Ve Murphys yasasını hatırlayın.

Bu sorunun kurumsal web uygulamaları ile ilgili olduğunu varsayıyorum.

Orta düzeyde kritik şeyler için önerim:

• Arka ucun beklendiği gibi çalıştığından emin olarak arka uç API'larınız için otomatik test gerçekleştirin. Bu testler bir API uygulanırken geliştiriciler tarafından yazılmalıdır.
• Otomatik UI testlerini önemsemeyin, yani ön uç testini manuel olarak yapın.

Çoğu testin API düzeyinde veya bileşen düzeyinde olması gerektiğini düşünüyorum. Yalnızca bazı dahili işlevleri yürüten birim testleri umursamıyorum.