Bir diğerinin kalite güvencesi (QA) için tamamen yinelenen bir sistem oluşturmak kötü bir uygulama mıdır?

İş yerinde oldukça karmaşık bir sistemimiz var. Bu sistemi System_A olarak adlandıralım. KG ekibimiz, System_A'yı test etmek için bu sistemi System_B olarak adlandırmak üzere başka bir sistem oluşturdu.

System_B'nin kullanım şekli aşağıdaki gibidir. Girişler (System_B'nin kendisi kullanılarak), IN üretiyoruz, bu girişleri System_B üzerinden geri işliyor ve O_B çıktıları üretiyoruz. Yani süreç şu şekildedir:

System_B(IN) -> O_B.

Daha sonra aynısını System_A'nın kendi çıktılarını üretmesi için yapıyoruz, O_A:

System_A(IN) -> O_A.

Herhangi bir zamanda, O_B'nin beklenen çıktı olduğu ve O_A'nın gözlemlenen / gerçek çıktı olduğu varsayılır. O ima şu: O_B “altın” kaynak (gerçek). Ancak, bir sorun kombinasyonuyla karşılaştık.

• O_A yanlış, O_B doğru
• O_A doğru, O_B doğru
• O_A yanlış, O_B yanlış
• O_A doğru, O_B yanlış

O_B'nin her zaman haklı olduğu varsayılırsa (veya ne beklenirse) neyin doğru olduğunu kim belirler? O_B'nin insan muayenesi ve analizi ile bazen (veya sıklıkla) yanlış olduğu ortaya çıkıyor. İşler bu süreci kullanarak KG'yi geçecek ve gerçek kullanıcılar şikayet edecek ve sonuçta O_B'nin yanlış olduğunu bulmaya geri dönüyoruz.

Soru şudur: Gerçek sistemi test etmek için bir "test sistemi" oluşturmak kötü bir uygulama mıdır?

• Kaygan yamaç ne olacak? O halde, "test sistemini" test etmek için başka bir sisteme ihtiyacımız olduğunu iddia edemez miyiz?
• Geliştiricilerin artık en azından 2 kod tabanını öğrenmeleri gerektiğinden, maliyet kesinlikle engelleyicidir, belki de Sistem_B'nin karmaşıklığı Sistem_A'dan daha büyüktür. System_B'nin kuruluş için ne kadar iyi veya kötü olduğunu nasıl ölçebiliriz?
• System_B oluşturmak için orijinal "zorlayıcı" nedenlerden biri, testi otomatikleştirmekti. Şimdi tam otomatik olduğumuz için çok gurur duyuyoruz (çünkü System_B, çıktıyı üretmek için kendini kullanma sürecini önyüklemek için girdi üretiyor). Ama bence daha çok zarar verdik ve daha karmaşık bir şekilde, tartışılmaz bir şekilde getirdik. KG'nin işi tamamen otomatik mi olacak? Bu sebep paralel bir sistem oluşturmayı haklı çıkarmak için yeterli mi?
• Asıl endişem bu, hepimiz System_B'nin yanlış olduğunu bilsek de (oldukça sık). System_B girdiyi işlemede o kadar iyiyse ve çıktısı altın kaynağı ise, System_A'yı neden System_B ile değiştirmiyorsunuz? Buna göre, işte hiç kimse tatmin edici bir cevap veremez.

Bu konuda herhangi bir rehberlik takdir edilmektedir.

• O_A yanlış, O_B doğru

Düzeltme A

• O_A doğru, O_B yanlış

Düzeltme B

• O_A doğru, O_B doğru

İnşallah onlar da katılıyorlar.

• O_A yanlış, O_B yanlış

Umarım kabul etmezler, bu yüzden bu konuda bir şeyler yapmayı bilirsiniz.

Hiçbir süreç her şeyi yakalayamaz. Elbette, kodunuzu iki katına çıkardınız ancak O (2n) 'de 2 gibi düşünün. Otomatik KG, entegrasyon testlerine kadar harika bir şey. Manuel test, inovasyonun sürüklenmesidir. Özellikle tam bir test gerektiren çapraz kesim değişikliklerinde. Ayrıca, farklı programcıların aynı şeyi uygulamasına sahip olacağınızdan, yarışmasını sağlayabilirsiniz.

Farklı hatalar alma olasılığını arttırmak farklı insanlar olmalıdır. Sistem A'dan başlayarak sistem B'nin oluşturulmasını önermiyorum. Size tek şey regresyon testidir. Aynı şeyi, O_A'nın eski kopyalarını yenileriyle karşılaştırmak için kaydederek de alabilirsiniz.

Soru şudur: Gerçek sistemi test etmek için bir "test sistemi" oluşturmak kötü bir uygulama mıdır?

Eğer öyleyse, tüm testler kötüdür.

• Kaygan yamaç ne olacak? O halde, "test sistemini" test etmek için başka bir sisteme ihtiyacımız olduğunu iddia edemez miyiz?

Evet, bunu tartışabiliriz. Bu 3. sistemi sistem_A olarak adlandıracağız. : P

• Geliştiricilerin artık en azından 2 kod tabanını öğrenmeleri gerektiğinden, maliyet kesinlikle engelleyicidir, belki de Sistem_B'nin karmaşıklığı Sistem_A'dan daha büyüktür. System_B'nin kuruluş için ne kadar iyi veya kötü olduğunu nasıl ölçebiliriz?

Nerf silahlarıyla oynamak için bize ödeme yapan mutlu müşteri sayısına göre. Manuel test maliyetini kendiniz kurtardınız. Her hata yakalandığında kullanışlılığı kanıtlanacak bir şey yarattınız. Böceğin erken maliyeti, geç rapor edilen hatalardan çok daha az yakalandı.

• System_B oluşturmak için orijinal "zorlayıcı" nedenlerden biri, testi otomatikleştirmekti. Şimdi tam otomatik olduğumuz için çok gurur duyuyoruz (çünkü System_B, çıktıyı üretmek için kendini kullanma sürecini önyüklemek için girdi üretiyor). Ama bence daha çok zarar verdik ve daha karmaşık bir şekilde, tartışılmaz bir şekilde getirdik. KG'nin işi tamamen otomatik mi olacak? Bu sebep paralel bir sistem oluşturmayı haklı çıkarmak için yeterli mi?

System_B'nin karmaşıklığı System_A'dan harika bir şekilde izole edilmiştir. System_B var olduğu için System_A'ya özellik eklemek daha zor değil. Bu daha kolaydır çünkü System_B onlara hızlı gitmeleri için güven verir.

• Asıl endişem bu, hepimiz System_B'nin yanlış olduğunu bilsek de (oldukça sık). System_B girdiyi işlemede o kadar iyiyse ve çıktısı altın kaynağı ise, System_A'yı neden System_B ile değiştirmiyorsunuz? Buna göre, işte hiç kimse tatmin edici bir cevap veremez.

Bu bir yazım hatası mı? System_B genellikle yanlıştır, bu nedenle System_A'nın yerine kullanmak istediğiniz altın standart mıdır?

System_A'nın genellikle yanlış olduğunu düşündüğünüzü varsayacağım. Hangisinin en sık yanlış olduğu gerçekten önemli değil. Hangisi yanlışsa işe ihtiyaç duyan kişidir. Bu sistemler doğru ve yanlış karar vermez, geliştiriciler karar verir. Testin yaptığı, bir şeyin doğru olmadığı anlamına gelen bir anlaşmazlık yaratmaktır. Geliştiriciler bunun ne olduğunu anlıyor. Unutmayın, burada üretilen hiçbir altın standardı yoktur. Sadece anlaşma veya anlaşmazlık var. Anlaşmazlık, işin yapılması gerektiğini gerektirir. Bu çalışmanın bir kısmı nerede olduğunu bulmak.

Üretimde müşteriler tarafından kullanılan bir sisteminiz olduğunda, hata düzeltmelerini ve yeni işlevleri doğrulamak için bir KG sistemine sahip olmak mutlak bir zorunluluktur. Kalite açısından, üretim sisteminin bir kopyası olabildiğince yakın olmalıdır. Bu şekilde, üretim sisteminin ve KG sisteminin aynı olduğundan emin olursanız, biri üzerinde çalışan diğeri üzerinde çalışmalıdır. Durum böyle değilse, sistemler aynı değildir, girişler aynı değildir ve / veya çıkışlar yanlış yorumlanmıştır.

Sisteminiz kritik öneme sahipse ve 7/24 kullanılabilir olması gerekiyorsa, bu iki katına çıkar. Daha sonra lüksü bir KG sistemine sahip olmayacak şekilde karşılayamazsınız, çünkü üretim sistemindeki kesinti süresini kesinlikle en aza indirmelisiniz. Ve eğer 7/24 bir sistemse, üretim sisteminin tam kopyası çok, çok güçlü bir öneridir.

Şimdi, bu yaklaşımın bariz dezavantajı maliyettir. Donanım maliyetlerini ikiye katlar, dağıtım ve bakım maliyetlerini artırır. Ayrıca, sistemlerin birlikte çalıştığı verilerdeki fark nedeniyle farklı sonuçların oluşma olasılığını en aza indirgemek için üretim sisteminden KG'ye sürekli veri çoğaltması uygulanmalıdır.

Bazı denge genellikle KG sisteminin bazı bileşenlerini üretim sistemine göre küçülterek bulunabilir, böylece işlevselliklerin çoğu düzgün bir şekilde test edilebilir. Bunlar genellikle gereksiz sunucular, sunucuların boyutu veya iş istasyonu sayısıdır. Ancak, benim deneyimime göre bazı hatalar her zaman tam olarak küçültülmüş kısımda bulunur ve daha sonra üretim sisteminde izin verilen minimum kesinti süresini korurken sorunu yeniden oluşturmak ve düzeltmeyi uygulamak bir kabus olur.

Bir sistemi test ettiğinizde, beklenen sonucunuzun ne olduğunu bilmeniz gerekir.

Bir sistemin bu beklenen sonucu üretmesi ile ilgili sorun açıkça 'bu sistemi nasıl test ederim'

Yine de, insanların beklenen sonuçları üretmek için elektronik tablo kullandıklarını görmek normal değildir.

Günün sonunda, sistemin gereksinimlerini yorumlamak ve beklenen sonucu manuel olarak üretmek için gerçekten bir insana ihtiyacınız var. Bir sisteminiz varsa ve sadece farklılıkları kontrol ediyorsanız, testinizi atlıyorsunuz demektir.