Test cihazlarının bulacağı kasıtlı böcekleri kodda bırakmak

Bunu firmamızda yapmıyoruz, ancak arkadaşlarımdan biri proje yöneticisinin her geliştiriciden, ürün QA'ya gitmeden hemen önce kasıtlı hatalar eklemesini istediğini söylüyor. Bu nasıl çalışır:

1. Ürün KG'ye gitmeden hemen önce, geliştirme ekibi koddaki rasgele yerlere bazı kasıtlı böcekler ekler. Bu böceklerin son ürünle birlikte gönderilmediğinden emin olmak için orijinal çalışma kodunu uygun şekilde yedeklerler.
2. Test uzmanları da bu konuda bilgilendirilir. Böylece zor testler yapacaklar, çünkü mevcut hatalar olduğunu ve onları bulamamanın bir yetersizlik işareti olarak değerlendirilebileceğini biliyorlar.
3. Bir kasıtlı (kasıtlı veya başka türlü) bir hata bulunursa, geliştirme ekibinin düzeltmesi gerekenler bildirilecektir. Geliştirme ekibi daha sonra, ürünün ikinci seviyedeki QA'ya girmesinden hemen önce kodun ilgili bir bölümüne kasıtlı bir hata daha ekler. Proje yöneticisi bir test cihazının bir geliştirici gibi düşünmesi gerektiğini ve değişikliklerin yapıldığı bölümlerde yeni hatalar beklemesi gerektiğini söyledi.

Peki, bu böyle gider. Bu yaklaşımın aşağıdaki avantajlara sahip olduğunu söylüyorlar.

1. Testçiler her zaman parmaklarının ucunda olacak ve deliler gibi test edecekler. Bu, ayrıca geliştiricilerin bunları düzeltebilmeleri için gizli (kasıtsız) hataları bulmalarına yardımcı olur.
2. Test cihazları böceklerle beslenir. Herhangi bir böcek bulamamak onların moralini etkileyecektir. Onlara kolay bir bulmalarını sağlamak morallerine yardımcı olacaktır.

Bu kasıtlı böceklerden birinin nihai ürünle birlikte gönderildiği senaryoyu görmezden gelirseniz, bu yaklaşımı benimsemeden önce düşünmemiz gereken diğer dezavantajlar nelerdir?

Bazı açıklamalar:

1. Kaynak kontrolde orijinal kodu uygun şekilde yedeklerler.
2. Bir test cihazı kasıtlı hatayı bulduğunda, geliştirme ekibi onu görmezden gelir. Test cihazı kasıtsız (orijinal) bir hata bulursa, geliştirme ekibi öncelikle bunun kasıtlı hatalardan herhangi birinin neden olup olmadığını kontrol eder. Yani, geliştirme ekibi ilk önce bunu orijinal çalışma kodunda tekrarlamaya ve mümkünse düzeltmeye çalışır.
3. QA ve geliştirme ekibi arasındaki ilişki sorunlarını göz ardı edin. Bu soruyu özellikle İşyerinde değil, Programcılar üzerinde sordum . KG ve geliştirme ekibi arasında iyi bir ilişki olduğunu ve çalışma saatlerinden sonra birlikte parti yaptıklarını düşünün. Proje yöneticisi, her iki takımı da desteklemeye hazır olan hoş ve yaşlı bir beyefendidir (Godsend).

Bu kesinlikle çılgınca geliyor. Çok şüpheli bir fayda için çok fazla çaba harcıyor ve uygulama bazı hatalı tesislere dayanıyor gibi görünüyor:

• Her gün test edildiklerini bilmedikleri sürece, KG, çok fazla çalışmayacak (moral için iyi olamaz)

• QA'nın bulabilmesi için yazılımda istemeden ortaya çıkan hataların bulunmadığı

• QA'nın işi böcek bulmaktır - öyle değil; Yazılımın üretim kalitesi olmasını sağlamak

• Kalkınma ve kalite güvencesi arasındaki bu tür zihniyet savaşının şirket için bir şekilde sağlıklı olduğu - öyle değil; tüm çalışanlar birbirlerinin yerine şirket rakiplerine karşı birlikte çalışmalıdır.

Bu korkunç bir fikir ve söz konusu proje yöneticisi insanlar ve motivasyon hakkında hiçbir şey anlamayan bir pislik / salak. Ve bu iş için kötü.

“QA'nın işi:” açıklamamı genişletmek için, QA kesinlikle hem kodlarda hem de test takımlarında hata buluyor olmalı - işlerini yapmanın bir eseri olarak, ancak rolü “bulmalısınız” böcek." Yeni özellikleri dikkate almak ve tüm yüksek test kapsamını sağlamak için test takımlarını güncel tutmalısınız. Bu, hata bulma ile sonuçlanmazsa, test prosedürleri ürün için yeterince karmaşık değildir.

Peki, öğrendiklerime göre:

1. Bu bir okul veya iş görüşmesi değil;
2. Test cihazları çocuk değil;
3. Bu bir oyun değil;
4. Şirketin parasını boşa harcar.

KG, yalnızca hataları bulmak için değil , sistemin ne kadar sezgisel olduğu, kullanıcı için öğrenme eğrisi , kullanılabilirlik ve genel olarak erişilebilirlik konusunda endişelenmek için de vardır . Örneğin: "Sistem çirkin mi?", "Kullanıcı rengi kör mü ve malzeme kırmızı ve yeşil mi?" Onlar da şikayet etmeli.

Bir sistemin KG'yi geçmesi için gereken asgari gereksinimler, genellikle bu özellik için bir kullanıcı öyküsünde veya PO'nun sistemin kafasında ne kadar büyülü olmasını istediği konusunda açıklanır.

tl; Dr.

Sadece böcekler değil, test ediciler de bu dar görüşün dışına çıkmalı.

Kötü bir fikir.

Test cihazının bakış açısından: "Çok sıkı test edecekler, çünkü mevcut böceklerin olduğunu ve onları bulamamalarının yetersizlik olarak kabul edilebileceğini biliyorlar." Temelde, devler kodu bubi tutuyor. Sonunda anlamsız olan (böcekler önceden bilindiği için) ancak yine de algılanma şeklini etkileyen iş yapmaktan az sayıda insan. Bubi tuzaklarını bulamadığınız için somut cezalar varsa, daha fazlası. Ve testçilerin böcek bulma konusunda başarılı olduklarını biliyor musunuz? Bu toksik bir çatışma ortamı gibi geliyor; Bir QA, incelemekte oldukları kodun kalitesi yüksek olduğunda mutlu olmalıdır. Her ne kadar böcek tarafından ödenmiş olsalar da ... http://thedailywtf.com/articles/The-Defect-Black-Market

Dev'in bakış açısından: QA'lar orada olduğunu bildiğiniz hataları bulmak için teşvik ediliyor. Bu , gerçek hataların kapıdan dışarı çıkma olasılığını artırabilir ; KG'lar, zamanlarının en azından bir kısmını, gerçekten ince olanları değil, ekilmesi kolay bir böcek türü aramak için harcıyorlar. Ayrıca bir bubi tuzağının kapıdan çıkması için küçük bir şans var.

Bunun neden motivasyon için kötü olduğunu ve genellikle korkunç insan yönetimi olduğunu yukarıdaki cevaplara tamamen katılıyorum. Ancak, bunu yapmamak için sağlam teknik sebepler de olabilir:

Ürün KG'ye gitmeden hemen önce, geliştirme ekibi koddaki rastgele yerlere bazı kasıtlı böcekler ekler. Bu böceklerin son ürünle birlikte gönderilmediğinden emin olmak için orijinal çalışma kodunu uygun şekilde yedeklerler.

1. İlk açıklamada dayanarak, asla gerçekte bu iki geçişte amaçlanan üretim kodu test edin.

2. Bir müşteri değişikliği yapmak için acele etmeye çalışırken, yanlışlıkla 'kasıtlı' bir hatayı salıverilmiş üretim kodunuza dahil etme olasılığını büyük ölçüde artırdığınızı hayal ediyorum. Bir noktada birkaç kırmızı yanağa neden olabilir.

3. Bunun test edicilerinizi geliştiricileriniz gibi düşünmesi için eğittiğini (yani Tom, buraya nasıl bir böcek ekler) muhtemelen Tom'un düşünmediği hataları bulma olasılığını daha düşük hale getirir.

Düzenle

Bu cevabın sadece KG işleminizi test etme konseptinden bahsettiğini ve soruda gösterilen belirli metodolojiyi savunmadığımı açıkça belirtmek istiyorum.

Düzenlemeyi Sonlandır

Testinizin / kontrolünüzün gerçekten çalışıp çalışmadığını kontrol etmek için geçerli bir neden var. Size imalattan bir örnek vereyim, ancak prensip aynı.

Malzemeyi bir makineden beslerken besleyicinin malzemeyi yeterince ileri itmeyebileceği normaldir. Buna "kısa besleme" denir ve bunu önlemek için bir "kısa besleme sensörü" takabiliriz (tipik olarak malzeme tarafından engellenen bir ışın tipi sensör). Bu sensör, tam besleme uzunluğuna ulaştığında malzemenin sonunu algılar. Makine döngüsünün belirli bir noktasında sensörün bloke olduğunu kontrol ederiz ve kontrol başarısız olursa makineyi durdururuz.

Şimdi testin kendisinin nasıl başarısız olabileceğini düşünmelisin. Örneğin, bir miktar kir veya başka bir kalıntı sensörü engelleyebilir ve daima "Tamam" olarak bildirir ve makineyi asla durdurmaz. Ayrıca, sensörün doğası alıcının kiriş çarptığında alıcının açılmasıdır, böylece kurduğunuz sensör türüne bağlı olarak, elektriksel olarak sensör engellenmediğinde bir "ON" girişi elde edersiniz . Bu, eğer kablo kesilirse veya o sensöre güç kesilirse veya giriş başarısız olursa, programınızın mantığı "KAPALI" olarak okunur ve bu "engellenmiş" veya "Tamam" anlamına gelir.

Testin bu başarısızlık modlarını yakalamak için, sensörün gerçekten de döngünün ikinci bir bölümü sırasında engellenmediğinden emin olmak için ikinci bir kontrol ekleriz . Bu şekilde, testin gerçekten de çalıştığını kontrol ederiz (elimizden geldiğince).

Benzer şekilde, bir KG departmanının başarısız olabileceği birçok yol var. Belki de otomatikleştirilmiş testler çalışmadı ve rapor test verilerinin eski bir kopyasına bakıyor. Belki birileri işini doğru yapmıyordur. KG departmanını test etmek makul bir şeydir.

Belli ki dezavantajı, bir "test hatasının" QA departmanında ve bitmiş üründe yapabileceğidir. İmalat endüstrisinde bazen, bazen "Kırmızı Tavşan" olarak adlandırılan bilinen kötü bir parçanın, sürece (genellikle KG'lardan biri tarafından) eklendiği ve bu parçanın işlemden geçtiğini ve ne kadar sürdüğünü ölçtüğü durumlar vardır. parçayı bul ve çıkar. Normalde bu kısım parlak kırmızı (veya turuncu) boyanır, böylece kolayca izlenebilir. Birisi bu test sırasında bu parçayı takip ederken, son ürüne geçme şansı neredeyse sıfırdır. Tabii ki, "sistemin bulabildiğini görmek için" sürecin bilinen bir kötü kısmını atmış birinin apocryphal hikayeleri var.

Dürüst olmak gerekirse, bu davranışa açıkça etik dışı ve pratik olmayan diyebilirim. Başbakan fesih değilse, ciddi bir yeniden eğitim ihtiyacı var.

• Kalite güvencesi kavramını anlamada temel bir eksiklik olduğunu gösterir . Test ediciler, geliştiriciler gibi düşünmemelidir: Son kullanıcılar gibi düşünmelidirler. KG ekiplerinin olmasının nedeni, geliştiricilerin doğası gereği koda çok yakın olması; QA, kodun dev'lerin kaçırdıklarını yakalayabilecekleri yeterli mesafeyi sağlaması gerekiyor.
• QA çabasını boşa harcar . Bu hataların önemsiz olmadıklarını varsayarsak - ne zaman oldukları için aşağıya bakın - bu, QA'nın bilinmeyen şeyleri araştırmak için harcayabilecekleri zamanları ve kaynakları araştırmak için zaman harcadığı anlamına gelir.
• Geliştirici çabasını boşa harcar . Kalite güvencesi milletinin bu önemsiz hataları yakalaması için geliştiricilerin önce bunları yazması gerekir. Bu, sadece hataları kodlamakla kalmayıp, aynı zamanda yazılım gereksinimlerini ve tasarımını göz önünde bulundurarak daha fazla çaba gerektirir.
• Üretimi gereksiz risk altına sokar . Değişikliklerin doğru bir şekilde birleştirilmemesi sadece bir zaman meselesidir.
• Yukarıdakileri yapmazsa, anlamsızdır . Bilinen hataların tümü önemsiz ise, o zaman standart altı çalışanları yakalamazlar: yalnızca hiç iş yapamayan insanları yakalarlar. Bunu yapmanın daha iyi yolları var.
• Çalışma ortamını zehirler . QA test uzmanlarınız profesyoneldir. Onlar için güvenilir olmalıdır olmak aksi şüphelenmek için gerçek bir neden oluncaya kadar profesyonel. Başka türlü şüphelenmek için bir neden olduğunda, bu akıl oyunları yerine uygun bir soruşturma yapılmalıdır. Başka bir şey moral öldürür.

Ciddi anlamda. Başbakan'ın paranoyası bu özel durumda sağlam bir şekilde kurulmuş olsa bile, bu, test işlerini yöneten herhangi biri olmayan biri değil.

Şahsen ben bu yaklaşımdan rahatsız hissediyorum.

Beni ilgilendiren en önemli şey, kasıtlı böcek yerleştirmenin pratikliğidir . Bu bana öngörülebilir herhangi bir şekilde yapmak zor gibi görünüyor.

Herhangi bir kod değişikliği (kasıtlı veya başka şekilde) yan etkileri olma riski vardır. Bu yan etkiler test sırasında ortaya çıkarılabilir, ancak kök nedeninin ne olduğu açık değildir (böceği ekleyen geliştirici için bile) açık olmayabilir. Ne demek istediğimi biliyorsanız (buradaki bağırsaklarımdan konuşuyorum), "güvenli" hissetmez.

Ayrıca, test cihazı gerçekten piyasaya sürülmeyecek olan çok fazla zaman test kodunu boşa harcar. Kasıtlı hatalar giderildikten sonra, bence yine de tam bir test yapılmalıdır. Bütün test noktası bu. Bir şeyler değişir, her şey , ve siz her şeyi yeniden test edersiniz . Tamam, bunun pratikte hiçbir zaman yaşanmadığını biliyorum, ancak bu regresyon testinin konusu.

Yani, genel olarak, ikna değil.

Öte yandan, müşterilerin QA ekiplerinin çalışmalarını doğrulamalarına izin veriyoruz, ki bu muhtemelen ideal değildir. Yine de çok güçlü bir geri besleme döngüsü.

Zaten verilen tüm nedenlerden dolayı kötü bir fikir, ancak böcek tohumlama, farklı bir amaç için yararlı bir araçtır. KG işleminin ne kadar etkili olduğuna dair kaba bir ölçüm elde etmek için kullanabilirsiniz.

En basit durumda, diyelim ki 100 böcek tohumla ve onlar gerçek böceklerin tüm kapsamını temsil ediyorlar (biliyorum, pek mümkün değil ama basitleştiriyorum). Deneyi bozmamak için KG'ye bunu yaptığınızı söylemeyin . QA işleminin sonunda diyelim ki 100 tohumlanmış böceğin 60'ını (ve diğer gerçek böcekleri) buldular. Artık QA'nın böceklerin% 60'ını bulduğunu biliyorsunuz.

Bunu, QA'nın bulduğu gerçek böcek sayısını sayarak ve sahte hata oranını uygulayarak daha da genişletebilirsiniz . Örneğimizde, QA 200 gerçek böcek bulduysa, bunların sadece% 60'ını buldukları sonucuna varabilirsiniz, bu yüzden 133 kalır.

Tabii ki, bu büyük hata çubukları ile sadece geniş bir tahmin. Gerçekçi yazmak, temsili hatalar zordur. Yazdığınız hataların , KG'nın bulması daha kolay olacaktır, çünkü geliştiriciler hata yazmamak için eğitilmiştir. Tek tek hatalar, Unicode hatalar, arabellek taşmaları vb. Gibi bir hata sınıfı taklit etmek daha iyi olabilir.

Bu , geliştirici birim testi, sürekli entegrasyon ve mümkünse özel bir QA ekibini içeren tüm QA sürecine uygulanmalıdır .

Bu bir metriktir ve bir yönetim motivasyon aracı olarak kaçırılmamalıdır.

Kötü bir fikir.

Bu, geliştiricilerin sık sık getirdiği bir tür mantıksal, ikili yaklaşımdır, ancak QE'ler için aşağılayıcıdır. Bu sadece güven eksikliğini gösterir. QE'ler çoğu zaman bu durumlara onlardan fazla girdi olmadan yerleştirilir ve bununla iyi olduklarını varsayır ve aksi takdirde önerilebilecekleri yer değildir.

Bu tür bir düşünce, QE'lerin yalnızca manuel test edici olmalarını ve test edilen gerçek kodu anlama konusunda motive olmamalarını birleştirir.

Ben kıdemli bir QE'yim ve bu, çalıştığım çoğu kuruluşta bilinen bir konudur.

Kötü bir fikir diyebilirim.

Bir: Programcılar kasıtlı hataları kod içine koymak için zaman harcayacak ve iyi sürümü kurtarmak için biraz çaba gösterecekler. Test cihazları muhtemelen ekilen hataya sahip özellikler de dahil olmak üzere her şeyi test etmeli olsa da, bir tane bulduğunda, muhtemelen testin kafasının karıştığını (ve test cihazının kafasının karıştığını değil) doğrulamak için tekrar denemeleri ve tekrar çalıştırmaları gerekecektir. bir şekilde). En azından, testçiler ekilen böcekleri yazmak için zaman harcayacaklar. Daha sonra programcılar yerleştirdikleri hatayı düzeltmek için zaman harcamak zorundadır. Bu, iyi kod yazmaya ve gerçek hataları yazmaya çalışarak harcanabilecek çok fazla çaba.

İki: Test programcılarına ve / veya yönetimin işlerini yapmadıklarını ve çocuk olarak muamele görmeleri gerektiğini düşündükleri test uzmanlarına açık bir mesaj gönderiyor. Bunun moral için iyi olduğunu hayal edemiyorum. Bir programcı olarak, eğer bir program için belirsiz veya çelişkili özellikler verildi, ve onları netleştirmek için bir sürü zaman harcamak zorunda kaldım ve sonra saatlerimi veya günlerini harcadıktan sonra patronum bana şöyle dedi: "Ah, evet, kasıtlı olarak sadece onları okuduğunuzdan emin olmak için özellikler ", sanırım gerçekten sinirlenirdim. Bu düzenli bir şekilde olmuşsa, beni başka bir iş aramam için yeterli olabilir.

Gerçek hayatta, en önemsiz kod değişikliklerinin tümü hariç, WILL’ın hataları vardır. Test edicilerden şikayet almak konusunda hiçbir zaman bir sorunum olmadı, çünkü verilen ilk taslak kodları% 100 mükemmeldi. Yeterli bir iş yapmayan tembel test uzmanlarıyla uğraşmak zorunda kaldım, ancak programcılar mükemmel olduğu için böyle olmadı. Bir zamanlar birlikte çalıştığım en iyi test uzmanı, yeni bir yazılım sürümü için 100 hata bulmak için kendine kişisel bir hedef belirlediğini söyledi. Tamam, 100'ün gerçekçi bir sayı olup olmadığı, ürünün ne kadar büyük olduğuna ve değişikliklerin ne kadar kapsamlı olduğuna bağlıdır, ancak bizim durumumuzda neredeyse her zaman bu amacı gerçekleştirmeyi başardı. Bazen bir mesajdaki yanlış yazılmış bir kelimeyi "böcek" olarak adlandırmak gibi işleri uzatmak zorunda kaldı, ama hey, düzeltilmesi gerekiyordu.

Senaryoyu yaz: Bunu yaparsanız, bahse girerim ki er ya da geç programcılar kasıtlı olarak bir böcek ekeceklerdir, test uzmanları o belirli olanı bulamazlar ve programcılar iyi kodu geri koymayı unuturlar. Yani şimdi kasıtlı olarak ekilen bir böcek müşteriye gönderilir.

Bunun kötü bir fikir olduğunu sanmıyorum . İşi daha iyi tahmin edebileceğim birçok şey var:

1. QA'yı mümkün olan her şekilde kaliteden sorumlu tutun. Mesela onların sorumluluğunu da destekleyerek. Bu, gönderilen ürünlerin daha kaliteli olmasını sağlamak için motivasyonlarını arttıracaktır. Üzücü bir kullanıcının neyi açıklamaya çalıştığını anlamaya çalışmak için kendiniz bir yetersizlik (böcek, açık bir şekilde eksik özellik, karşı sezgisel davranış) keşfetmeniz daha az çaba gösterir. Ve bu sorumluluğun bir kısmını geliştiricilere bile vermek, KG'nin işlerini yapabileceklerinin en iyisini yapmalarına yardımcı olmak için motivasyonlarını arttırabilir.

2. Rekabet edebilecek birden fazla KG ekibine sahip olmak. Elbette mantıklı bir ölçüm bulman gerekiyor. Kesinlikle sadece sayı sayısında değil. Teklif edilen aksaklığın ciddiyeti veya iş değeri (paydaşların belirlediği şekilde) faktoringin yardımcı olması gerekir.

KG'nin "yeterince iyi" olup olmadığını söylemek zor. QA'nın “sürekli iyileştirilmesi” için yollar bulmak uzun vadede daha kolay ve muhtemelen daha da iyi.

Yine de, kasıtlı hataları ortaya çıkarırsanız dikkat etmeniz gereken bir sorun var: “Doğru” kodun ilk etapta gerçekten doğru olduğunu nereden biliyorsunuz? 2. Kalite Güvencesi'nden sonra, keşfedilmemiş tüm kasıtlı böcekleri temizlersiniz. Onları sadece farklı bir şekilde kırılmış kodla değiştirmeyeceğinizi veya daha önce erişilemeyen kırılmış davranışları etkinleştiremediğinizi bilmenin bir yolu yoktur (abartılı bir örnek: bazı iletişim kutuları kasıtlı bir hata nedeniyle açılmadı, fakat diyaloğun kendisi bozuldu - sadece bunu öğrenemiyorsunuz çünkü test ediciler bunu göremiyorlardı).

Diğerlerinin de belirttiği gibi, geliştiricilerin yazılım içine hatalar eklemesi gerekmemelidir, ancak test paketinizin yazılımın içine test sürecinin bir parçası olarak hata eklemesi meşru bir stratejidir .

Buna mutasyon testi denir . Fikir kaynak kodunda (mutantlar denir) küçük değişikliklerin oluşturulmasını otomatikleştirmek için yazılım kullanmaktır. Değişiklikler farklı davranışlar yaratacak şekilde tasarlanmıştır, örneğin değişebiliriz

if x < 10:
    print "X is small!"

içine

# we flipped the inequality operator
if x > 10:
    print "X is small!"

ve iyi bir birim testi, mutant kod parçasının artık beklendiği gibi çalışmadığını ve mutantı öldürdüğünü tespit etmelidir . Orijinal kod testi geçtiğinde ve tüm mutantlar (işlevsel olarak eşdeğer olmayan) testi geçemezse, kodunuzun ve testlerinizin güçlü olduğunu bilirsiniz .

Fikri beğendim. "Huzur içinde daha fazla ter, savaşta daha az kanar" diyen General Patton mıydı?

Kasıtlı böcek koyarak testçilerin "zamanını boşa harcıyorlar". Ancak bu aynı zamanda onların daha çok çalışmasını sağlar, yani İstenmeyen hataları bulmak için daha iyi bir iş çıkarırlar. (Ve "orjinal" in bir kopyasına sahipsin, böylece yaptığın şeyle yaşamak zorunda değilsin.)

İstenmeyen hataların bulunması, uzun vadede kasıtlı olanlarla başa çıkmanın maliyeti konusunda sizi daha fazla üzecektir.

Ayrıca, testçilerinizin ne kadar iyi olduğu hakkında bir fikir edinebilirsiniz.

Ödül veya cezanın kendi yararına değil, hedeflediğiniz davranıştan dolayı bir dayanağı yoktur. Ve bazen istenmeyen sonuçlar doğar. QA ekibinin gevşemesini engellemek ya da bazı yöneticilerin, gerçekten işe yaramadığını fark etmeden bir şeye gerçekten katkıda bulunduğunu hissetmesini sağlamaktır.

Olumlu Sonuç - QA ekibi hataları bulmak için çok çalışıyor. Kim bilir, belki bunu bir meydan okuma olarak görürler. Dostça bir oyun. Ya da sadece izleniyorlar çünkü yapıyorlar (Hawthorne Effect?).

Olumsuz Sonuç - Daha fazla çalışmayabilir ve hatayı yine de bulamayabilirler. QA bunu küçük ve çekingen olarak görüyor. Şimdi, hiper-böcek bulma sürücüsüne giriyorlar ve her türlü niteleme problemini geri veriyorlar. Ekran görüntüsü alıp bir pdf dosyasına dönüştürdüğümde ve% 500'de görüntülediğimde bu yazı tipi düzgün çalışmıyor.

Etki Yok - Sesin bana böyle gelmesi fark yaratmıyor, peki neden rahatsız ediyorsun? Zaman kaybetme ve insanları rahatsız etme riskini alıyorsun.

Hepimiz bunun% 90'ın işe yaramayacağına katılıyoruz. Bu diğer% 10'lara pek de iyi gelmiyor. Kendiniz için bir şeyler test edin. Müşteriler, kasıtlı kod hatalarına sahip bir sürümden daha memnun mu? Diğer alanlarda çalışanların moralini ve üretkenliğini etkiler mi? Ciro artışı? Bize sen söyle.

Geliştiricilerin testleri kendileri yazmaları ve çalıştırmaları beklenen bir dünyadan geliyorsanız, bu "test" "QA" silosunu korkutup kafamı karıştırıyorsunuz, bu yüzden bu açıdan cevap vermeye çalışacağım. Bir yana, kalifiye QA mühendisleri, benim açımdan, (@ SparK'ın cevabında iyi tanımlandığı gibi), yazılımın kullanıcı hikayelerini tam olarak karşıladığından ve genel olarak "kaliteye" sahip olduğundan emin olmak için daha büyük meselelere odaklanmalıdır. yazılımın amaçlandığı alan) böcek avına değil.

Beni buraya çeken şey, @ JamesMcleod'un soruya yaptığı yorumlardaki "hata enjeksiyonundan" bahsetmesi. Aslında geliştiricilerin sisteme nasıl böcek enjekte edebileceğini düşünmelerini sağlamak, savunma kavramını derinlemesine hedeflemek için harika bir fikir olduğunu düşünüyorum. Hiçbir sistemi kontrolsüz bir şekilde yıkmayacak kadar net bir eylem yapılmamalıdır (işlemlerin kolayca yapılabileceği şekilde kaydedilmeden), herhangi bir veri bozulmasına yol açmamalı veya kendi başına bir güvenlik açığına maruz kalmamalıdır.

Her bir bileşenin geliştiricisinin kasıtlı kusurlar yaratması, diğer bileşenlerin sahipleriyle ilgilenmesi ve genel olarak yazılımı hakkında daha olumsuz bir zihniyete girmesi, yazılımın sağlamlığını artırmak için muhtemelen çok şey yapabilir. Hemen faydası bile önemli olabilir - böyle bir yeni kusur türünün (şimdiye kadar denenmemiş) her enjeksiyonunda, geliştiricinin derhal bir bayrakla belirlenecek yeni bir testle ele almasını isterdim. Böceğin, kod tabanında kısa bir süre rahatsız edilmeden yaşamasına izin verin ve daha sonra teslimattan önce (ve kusur kaldırıldı), test takımını daha kapsamlı hale getirecek düzenli bir sınava dönüşmeye başlayın.

İlgili bir seçenek, diğer bileşenlerin bununla nasıl başa çıktığını incelemek için belirli bileşenlerdeki özellikleri bilerek kapatmak için özellik bayraklarının kullanılmasıdır. Obama ekibi tarafından 2012 seçimlerinde kullanılacak yazılım altyapısının bu denli kapsamlı testini anlatan “İlk Yanıtlayıcılardan Öğrenme: Sistemleriniz Ne Zaman Çalışmalı” başlıklı ücretsiz kitabı / makaleyi okumanızı da şiddetle tavsiye ediyorum .

Diğerlerinin de söylediği gibi, sadece hataları bulmak için KG'nin işi değil. Daha ileri gidip teknik olarak onların işi olmadığını söylerdim. Geliştiriciler kendi kodlarını hatasız tutmaktan sorumlu olmalıdır. Test süitleri yeni bir kod oluşturulmadan önce çalıştırılmalı ve test süitleri başarısız olursa, ilk etapta asla QA olmamalıdır. Kasıtlı olarak hata tanımak, test süitlerinizi kesinlikle geçemeyeceğiniz anlamına gelir, öyleyse neden kodunuz QA'ya gidiyor?

KG'nin işi, başvuruyu, uyguladığı kullanıcı hikayelerine göre doğrulamaktır. Akışı, Kullanıcı Arabirimini vb. Test etmeli ve kullanıcının mümkün olan her şeyi mümkün olan en kullanışlı ve erişilebilir şekilde yapmasını sağlamalıdır. Bunu yaparken, elbette, hataların üzerine tökezleyebilirler, ama yaptıklarının değil, yaptıklarının yan etkisi. QA’nın Kalite Güvencesi anlamına geldiğini, hatasız Güvence anlamına geldiğini unutmayın.

Bu mutlaka göründüğü kadar delice değil. Bu senin motivasyonuna bağlı. Test ekibini yenmek için bir sopa arıyorsanız, bu delilik olurdu . Diğer taraftan, yazılım geliştirmedeki en zor şeylerden biri, test yaklaşımınızın ne kadar etkili olduğunu bilmektir.

Bu nedenle, doğru bir şekilde yapılandırırsanız, bu tekniği, göndereceğiniz üründe kaç tane asıl böcek kaldığını tahmin etmek için kullanabilirsiniz. Bu yüzden test yapınıza yapay olarak 100 böcek yerleştirdiğinizi ve test edicilerin 50 tanesini bulduğunu hayal edin. Öyleyse, 50 tohumsuz böcek buldukları takdirde, belki de bulabilecekleri 50 tane kaldığına dair kesin bir ihtimal olduğu sonucuna varabilirsiniz.

Tabii ki, bu birçok sorunla dolu. Bu istatistiklere göre gemi olup olmadığına karar verebilirsiniz, ancak gerçek hayatta çok kötü bir konu veya bin küçük tahriş bulabilirsiniz.

Yine de - bilgi güçtür ve bu teknik olmadan kod tabanınızın kalitesi hakkında daha az fikriniz vardır. Saygılı ve doğru nedenlerle uygulayabiliyorsanız, "Neden olmasın?" Derdim.

Henüz kimsenin bahsetmediği bir şey var: mutasyon testi .

Otomatik bir aracın kaynak kodunuzu aldığı ve kasıtlı olarak içine hatalar yerleştirdiği yerdir. (Örneğin, rastgele seçilen bir ifadeyi silin, bir VE'yi bir VEYA olarak değiştirin veya.

Bütün testler geçerse, iki olasılık vardır:

• Değiştirilen şey hiçbir şey yapmaz. Başka bir deyişle, ölü kodunuz var.
• Değişiklik, test takımınızın yakalamadığı bir hata verdi. Daha fazla teste ihtiyacın var.

Teklifinizden farklı olarak yukarıda tarif ettiğim her şeyin otomatik olduğunu unutmayın . Geliştiricilerin zamanından el ile anlamsız böcekleri sokmakla zaman harcamazsınız. Ve test edicilerin bilinen hataları bulma zamanını boşa harcamıyorsunuz. Kullandığınız tek şey, çok daha ucuz olan makine zamanı. (Makineler aynı testi 20.000 kez yapmaktan sıkılmazlar. İnsanlar bir süre sonra bakmayı keser!)

Otomatik mutasyon testinin bahsettiğiniz manuel senaryodan çok, daha iyi bir yaklaşım olduğunu öneriyorum.

Bir geliştiriciden hataları manuel olarak eklemesini istemeniz durumunda, alacağınız hatanın muhtemelen insanların yapabilecekleri yanlışlıkla yapılan hataları temsil etmediğini unutmayın . (Örneğin, muhtemel bir yarış koşulu olduğunu farketmediyseniz, kasten birini eklemeniz de mümkün değildir.) Otomatik bir aracın daha objektif olmayı başarıp başarmadığı elbette görülüyor.

Genel olarak kötü bir fikir olsa da (diğer cevaplar nedenini tam olarak açıklıyor), üretim koduna kasıtlı olarak böcekleri kontrollü, geçici bir şekilde enjekte etmenin mantıklı olabileceği birkaç özel durum var.

Test kodunu yeniden değerlendirdiğinizde - test kodunun üretim koduyla aynı detayı göstermesini hak ettiğinizde - test kodunun bulması gereken hataları bulup bulmadığını bilmek isteyebilirsiniz.

Testlerin hala çalışıp çalışmadığını doğrulamak için kasıtlı olarak üretim kodunu kırabilirsiniz.

Bunun mümkün olduğu birden fazla seviye var:

• Bazı ünite testini henüz yeni kontrol eden bir geliştirici, ünite testinin hala bulması gereken şeyi bulduğunu doğrulamak için üretim kodunu bozabilir.
• Bir miktar kabul testini henüz yeniden incelemiş olan bir test cihazı, kabul testinin hala neyi doğrulaması gerektiğini doğruladığını doğrulamak için üretim kodunu bozabilir.
• Arabirim yeterince sağlam ve yeterince sağlamsa (ör. Protokol temelli), şirket bilinen hatalı ürün sürümlerinin bir bölümünü tutmak isteyebilir ve testi regresyon testine tabi tutmak için bunlara karşı testler yapmak isteyebilir.

Bu şeylerin mantıklı olup olmadığı bağlıdır. Eğer bir geliştiriciysem ve bir hatayı enjekte etmek bir dakika sürüyorsa, birim testini test edin, hatayı giderin - öyleyse neden olmasın. Ancak editörüme, döngüme ve sürüm kontrol sistemime, yanlışlıkla hata yapmam / teslim etmem / iade etmem / kontrol etmemem kadar iyi bir kontrol altında olmalıyım. Aynısı test cihazı ve kabul testi için de geçerlidir.

Bir örgütün bilinen hatalı ürün sürümlerinin süitlerini tutmasının mantıklı olup olmadığı ve regresyon testi bu teste bağlıdır. Bir çevrimiçi mağaza için yapmazdım. Otomotivde gömülü, havacılıkta gömülü, bankacılık kartlarında veya ödemeli TV kartlarında olurdum.

Bunun ne kadar büyük bir çaba harcadığı testlerin üretim kodundan ne kadar ayrıldığına bağlıdır. Testler üretim kodundan ne kadar fazla ayrılırsa, bunu yapmak o kadar az çaba harcar, testler üretim koduyla ne kadar uyumlu olursa o kadar fazla çaba harcar.

Sebebi şudur: Testleriniz ve üretim kodunuz birbirine uyumlu olduğunda, üretim kodunu değiştirmek, testlerin sık sık değiştirilmesini gerektirir ve bu, testler ile hatalı üretim örnekleri arasındaki bağımlılığı kırar. Ardından hatalı üretim numunelerini de muhafaza etmeniz gerekir. Nadir durumlarda bile, bu bir çabaya değebilir ve sürüm kontrol sisteminin akıllı kullanımı kadar alay etmek de bu çabayı önemli ölçüde azaltabilir, ancak yetenekli geliştiricilerden çok daha fazlasını gerektirir.

Üretim kodu kasıtlı enjekte arızaların kavramı adı sabotaj enjekte hata olarak adlandırılır, sabotajcımız .

Doğrudan depodan test edilmesi gereken kodu almayan bir testçi bunu yanlış yapıyor. (1)

A geliştirici kontrol bilinen-hatalı kod içine depo yanlış yapıyor. (2)

Dolayısıyla, bu aşamada, bu planın, geliştirme ve testlerin nasıl yapılması gerektiğine dair çok temel önceleri ihlal etmeden, bir veya iki taraf olmadan da çalışmasının bir yolu yoktur.

(1) Çünkü hangi sürümü test ettiğinizi belgelemeniz gerekiyor. Git karma ya da SVN revizyon numarası ile etiketlenmiş bir sürüm, "Joe'nun bana verdiği kod" u test edebileceğiniz bir şey değildir.

(2) Çünkü, başarısızlık bekleyen bir test sürücüsünün dışında yapmıyorsunuz .

Bu, devs, test ediciler ve yönetime hemen anlam vermesi gereken mümkün olan en kısa "asansör perdesi" girişimidir.

QA'ya gönderdiğiniz HER YAPI'ya kasıtlı olarak böcek enjekte edilmesini öneriyorum.

Diyelim ki, zaman zaman, yılda bir kez, gizli bir "KG denetimi" yapabilirsin. "Test edilmiş ve çalışan" bir kod tabanı alın ve Todo listenizden olabildiğince küçük yeni özellikler alın. Onları "senden biraz daha özensiz" uygularsın. En son durumları düşünün, yazın, ancak kodunuzu hesaba katması için düzeltmeyin. QA'ya gönder.

Yazdığınızdan daha fazla çalışma dışı durum hatası buluyorlarsa, kesinlikle denetlemesi gereken QA'nız değildir ... ;-)