Programcılardan birim testi talep etmeli miyim? [kapalı]

Çok sayıda BT projesi satın aldığımız bir yerde çalışıyorum. Şu anda gelecekteki projelerin talepleri için sistem gereksinimleri için bir standart üretiyoruz. Bu süreçte tedarikçilerimizden otomatik birim testi talep edip edemeyeceğimizi tartışıyoruz.

Kodun kalitesini ve istikrarını belgelemek için doğru otomatik birim testlerinin yapıldığına inanıyorum. Diğer herkes, birim testinin yalnızca tedarikçiyi ilgilendiren isteğe bağlı bir yöntem olduğunu düşünüyor gibi görünmektedir. Bu nedenle, otomatik birim testi, sürekli test, kapsam raporu, birim testi muayenesi ya da hiçbir şekilde talepte bulunmayacağız. Bu politikayı çok sinir bozucu buluyorum.

Burada tamamen çizgimin dışında mıyım?

Lütfen görüşlerin herhangi biri için bana argümanlar sunun.

Kesin olarak, uygun otomatik birim testinin, kodun kalitesini ve istikrarını belgelemenin tek yolu olduğuna inanıyorum.

Mesele şu ki , insanlara zorlayarak uygun otomatik birim testi yaptırmayacaksınız (ya da en azından nadiren) . Boktan testler yapmanın ve projelerin maliyetini artırmanın iyi bir yolu.

Şahsen kaliteyi içeren bir talebe veya SLA'ya bakardım; Nasıl başarıldığına bakılmaksızın. 10 yıl önce en iyi ünite testleri nadirdi. 10 yıl içinde, kaliteyi sağlayacak daha iyi yöntemlere sahip olduğumuzda tedarikçilerinizi kelepçelemek istemezsiniz, ancak eski politikanız eski yöntemleri kullanmalarını gerektirir.

Şahsen, sizin durumunuzda bunun yerine kabul testleri açısından düşünmeniz gerektiğini düşünüyorum:

• Size verilen kara bir kutunuz var ve belli bir şekilde davranmasını bekliyorsunuz.
• Yapana kadar ödemezsiniz.
• Görmeniz gereken davranışı uygulayan birim testleri yazın ve başarısız olurlarsa düzeltmeleri gerekir.

Ayrıca bunun bir güven meselesi olduğuna dikkat edin. Tedarikçinize güvenmiyorsanız, kaynak kodunu almanız, kontrol etmeniz ve derlemeniz gerekir. Bundan daha az olan her şey, en azından bazılarına güvendiğiniz anlamına gelir .

Kesin olarak, uygun otomatik birim testinin, kodun kalitesini ve istikrarını belgelemenin tek yolu olduğuna inanıyorum.

Bu düşüncenin ne kadar yaygın olduğu beni şaşırtıyor. Otomatik, evet. Birim testi (yalnız), hayır. Otomatik yazılım testinde tek başına birim testlerinden çok daha fazlası var. Peki ya entegrasyon, sistem, fonksiyonel, QA? Bazı nedenlerden dolayı insanlar "Tamam, uygun birim testlerimiz var. Testler yapıldı, cuma akşamı olun!" Diye düşünmeye meyillidir . . Birim testi sadece başlangıçtır.

Neyse, konuya geri dönelim. Başkaları ile herhangi bir kimseye bir şeyi zorlamanın muhtemelen arzulananların karşısına sonuç vereceğini söyleyerek katılıyorum. Takımın nasıl çalıştığını asla bilemezsiniz, belki de milyon dolarlık test departmanına sahipler ve asla tek ünite testi yazmadılar.

İlk işimde 0 birim testinin yapıldığı bir yerde çalıştım (biz daha çok ya da daha az ciddi şeylere atılan bir sürü genç olduk). İster inanın ister inanmayın, işe yaradı. Tabii, hiç kimse bu hatanın neden düzelttiğine veya bu düzeltmenin neyin kırıldığına emin değildi, ama işe yaradı. Kesinlikle rastgele bir hatanın ortaya çıkacağı zamanlar oldu, amabeyzbol sopası ve dairenizin yanma riskibazı ekstra saatler harikalar yaratabilir. Belki tedarikçileriniz benzer teknikler kullanıyordur ?

Yönetiminizin bir sözleşmede uygun birim test için ödemeye razı olacağından çok şüpheliyim. Uygun birim testi, test ettikleri kod kadar ucuzdur, ancak son kullanıcıya eşit derecede değerli görülmeyecekleri için algılanan değeri çok az verir. Hiçbir kalite geliştirme firması geliştirme çabalarını diğer parçalara göre daha düşük bir maliyetle birim testlerine harcamayı istemeyecektir, çünkü iş için zarar vermezler, aynı süreyi dolmadan 2 sözleşme daha bulabilirler. birim test şartları.

Talep edilen birim testleri, alınan tekliflerinizi makul olmayan bir seviyeye yükseltir ve muhtemelen daha düşük bir fiyat almak için yapılan ilk imtiyaz olacaktır.

Ünite testleri yaptırmamanın maliyeti, kodu kendiniz ne kadar uzatacağınıza / destekleyeceğinize bağlıdır. Kalite hakkında bir fikir edinmek için kodun bölümlerini incelemeye almak da önemlidir.

Eğer projeleri yalnızca satın alıyorsanız, onları 3. parti bir kütüphane gibi kullanabilirsiniz ve bunları değiştireceğinize inanmıyorsanız, o zaman gerçekten işe yaradığı sürece düşük kaliteli kod riski daha düşüktür.

Nihayetinde bunlar iş kararlarıdır, ancak kararı kimin verdiğinin teknik değerlemenin de farkında olduğundan emin olmanız gerekir. Yönetime açıklamanız gerekiyorsa, kullanılmış bir araba almak gibi bir şey olduğunu açıklayın. Sonuçta buna değip değmeyeceğine karar vermek alıcıya kalmış, ancak bir tamirciye götürmek iyi bir fikir, bu yüzden limon alamayacağınızı biliyorsunuz.

Tüm birim testlerinin kopyaları / raporları da dahil olmak üzere, ne istersen talep edebilirsin.

Testleri veya en azından test spesifikasyonlarını kendiniz bile yazabilirsiniz.

Sizin görüşünüze katılıyorum, bunun çok iyi bir kod kalitesi ölçüsü olduğudur. Bir tedarikçi bu talebi reddederse alarm zilleri çalacaktır, neden yapmak istemezler - düşük kalite standartlarına sahipler ve kısayollar alıyorlar?

Projenize otomatik ünite testi, sürekli test, kapsama alanı raporları ve ünite testlerinin denetlenmesi konusunda kesinlikle haklısınız.

Bununla birlikte, talep gerektiren şeyler, diğerlerinin de ayrıntılı anlattığı gibi, istediğiniz sonuçları elde etmeyecektir.

Zorluğunuz insanları açıklamak ve ikna etmek - çok daha zor beceriler!

Başlangıçta yönetim ile başlayıp, uzmanların ve test uzmanlarının test ve yoldaki kazanımlarını açıklayarak açıklardım. Lütfen, 'PROPER birim testlerini yazıyorum' (sizinki harflerden büyük harf kullanın) gibi ifadelerin ardındaki duyguyu iletmemeye dikkat edin. Kelimeleri 'bağırmak' istemezsiniz (TÜM CAPS’in ima ettiği gibi) insanları doğru çözümü seçmeleri için ikna etmek ve ikna etmek istersiniz.

Sonuçta, eğer bu metodolojileri tanıtamazsanız ve nerede olduklarını kucaklarsanız, artı onlar hakkında tutkuluysanız (ki bu iyidir!) Bu şeylere değer veren birçokları olduğu gibi farklı bir şirkete gideceğim ve sizi gemide ağırlamaktan mutluluk duyarız. Sadece görüşmelerde onlar hakkında önünüzde olduğunuzdan emin olun, böylece tutkularınızın nerede yattığını ve uygun olup olmadığınızı bilirler.

Birisine otomatik test yapmak zorlanırsa, Joachim Sauer ve @Telastyn'in yorumlarında belirtildiği gibi arzu ettiğiniz sonuçları başaramazsınız. Bir çok insan için otomatikleştirilmiş birim testi, düşüncelerinde büyük bir değişikliktir. Çünkü birçok insan çalışan kod yazıyor, ancak test edilemez. Veritabanını, iş kurallarını, nesneleri vb. Sorgulayan tüm mantığın arkasındaki kodda olduğu bir ASP.NET web sayfası yazabilirim. Sayfa çalışacak mı? Evet. Otomatik birim testi kullanılarak test edilebilir mi? Kesinlikle hayır. Bir tedarikçi otomatik birim testine sahip değilse, birim testlerini doğru şekilde nasıl yazacağını öğrenmek ve bunu öğrenmenin bir sonucu olarak, daha kolay bir şekilde test edilebilir hale getirmek için kodlarını yeniden yazın veya yeniden faktörlendirin. Muhtemelen bu masrafları size geçirecekler.

Meselenin gerçekleri, tedarikçinin size bir ürün veriyor olması, bir .dll veya bir windows uygulaması olması ve zamanın% 99'unun çalışmasını beklemenizdir. Tabii burada ve orada böcekler var, ancak çoğunlukla çalışması gerekiyor. Bu, özellikle tedarikçi işinizi korumak istiyorsa, makul bir beklentidir. Eğer kara bir kutuysa, nasıl işe yaradıklarının önemi yoktur, bir insan test dalgasını ya da rastgele tuşlara basan maymunlarla dolu bir odayı kullanabilirlerdi. Çalıştığı sürece. Ancak, nasıl kullanılacağı konusunda size başka bir tür belge sağlamaları gerekecektir.

Ancak, size kaynak kodunu verdilerse değiştirebilmeniz için birim testlerini beklerdim. Birim testleri sağlamayan bir şirketle çalışmam. Yaptığın bir değişikliğin her şeyi hortumlamadığını başka nasıl bilebilirsin?

Birim testi, bu tedarikçinin geliştirme döngüsü boyunca riskleri nasıl ele aldığının bir göstergesidir. Birim testlerini kullananlar, değeri azaltma riskini ve bu testlerin kalitesini ne kadar riskin yönetildiğinin bir göstergesidir.

Bununla birlikte, birim testler, projenin üstesinden gelmeye çalıştığı risk seviyesini tanımlamaz. Ayrıca, kötü programlama uygulamalarının getirdiği risklerin azaltılmasında hiçbir rol oynamaz.

Bu nedenle, sağlam test uygulamaları olan ancak yüksek riskli kod yazmaya devam ederken, sıfır test yapan ancak düşük riskli kod yazan başka bir tedarikçiniz olabilir. İki tedarikçi aynı ürünü teklif ederse, düşük riskli tedarikçiyle gitmek en iyisidir.

Bu ancak, bu tedarikçiyle ilgili kişilerin kişilikleri ve yetenekleri hakkında röportaj yapmak, danışmanlık yapmak ve öğrenmekle ölçülebilir.

Özel yazılımı satın almayla ilgili bu yazıyı oldukça faydalı buldum: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

Sormaları önerdikleri bir numaralı soru, tedarikçinin testler yazıp yazmadığıdır.

Birim testlerini talep eden diğerleriyle kabul etmek, test uğruna testlere yol açacaktır; ne istediğine çok karşı olan bir şey.

Tedarikçilerinizi inceleme sürecinde; test etme bu sürecin sadece bir parçası olduğu için onlara geliştirme sürecinin ne olduğunu sorun .

Otomatik bir yapım süreci var mı? Bazı yönetim paradigmalarını takip ediyorlar mı? Düzgün eğitilmiş test uzmanlarına ve bağımsız bir kalite güvence ekibine sahipler mi? Belgelendirme standartları nasıl?

Bunlar, süreçlerinin genel kalitesini ve ardından ürettikleri şeyin kalitesini değerlendirmenize yardımcı olacaktır.

Bana öyle geliyor ki bu şartı dahil etmenin pratikte bir faydası olmayacaktı, çünkü uygulamak imkansız olacak.

Gerçek testler için kod talep edebilir veya gerçek testlerin gerçekleştirilip gerçekleştirilmediğine ilişkin bir rapor isteyebilirsiniz. Eğer tescilli bir proje ise, satıcı muhtemelen tedarik etmek istemeyecektir, çünkü kodun detaylarını büyük ölçüde düşündürür ve düşük seviye uygulama detaylarını sağlamak için yapılmakta ve bunların nasıl yapılacağını anlatmaktadır. Meslekler. Bir noktada, bazı güven olması gerekiyor.

Bunu yapmazsanız, sizi havaya uçurabilirler ancak sadece bir ünite test paketi çalıştırıyor seçeneğinin yanındaki kutuyu işaretleyerek gereklilikleri derler ve çalışırlarsa veya benzer bir yarılanırsa geçen tek bir test yazarak gereksinimi yerine getirirler çaba.

Bu yüzden otomatik birim testleri övgüye değer bir uygulama olsa da, dış satıcılardan ısrar etmenin pratik olduğunu düşünmüyorum.

Birçok insanın belirttiği gibi, satıcıları bir sözleşmeyi yerine getirmeleri için birim testleri (veya daha iyisi, otomatik birim ve entegrasyon testlerinin bir kombinasyonu) yazmaya zorlamak büyük olasılıkla yüksek kaliteli sonuçlar vermeyecektir. Öte yandan, otomatik testlerin, kod kalitesini sağlamak için şu anda kullanımda olan en iyi yöntem olduğunu kabul ediyorum.

Ünite testleri ile yazılan kodun, ilk önce yazılan ve ünite testleri eklenmiş olan koddan daha kolay tutulması gerektiğini düşünüyorum . Modülerliği ve minimum bağımlılıkları zorlar. Entegrasyon testleri, kodun doğruluğunu doğrulamak için de gereklidir, ancak kodun yazıldığı gibi kalitesi üzerinde aynı etkiye sahip değildir. Temelde, otomatik entegrasyon testleri gerçeklerden sonra eklenebilir, ancak ünite testleri orijinal kodla yazıldığında en fazla etkiye sahiptir.

Durumunuzla ilgili tavsiyem, birim testleriyle kod yazmayı tercih eden satıcıları aramak ve birleşik testlerle kod yazmaya meyilli olmayan satıcıları seçmektir. Eğer yönetim bunun bedelini ödeyecekse, sözleşmeye otomatik testler uygulayın, ancak SADECE TİCARİ BİRİM TESTLERİ İLE YAZMA KODUNA KULLANILIRsa.

Önce öncelikleri açıklayalım ...

Müşteri olarak rolünüzde asıl endişeniz birim testi değil.

Sizin için yazılım üreten tedarikçileri kullanıyorsanız, o zaman bir yöntem ya da başka bir yöntem kullanıyorlarsa endişelenmemelisiniz. Sizin riskiniz, hedeflerinize ulaşmanıza yardımcı olacak bir tür çözüm elde etmektir. İlgilenmeniz gereken tek şey, bu çözümün kabul edilebilir olup olmadığıdır. Bu yüzden istediğinizi aldığınızdan emin olmak için sizin sorumluluğunuzda olduğu gibi kabul testine sahibiz . Müşterinin kabulü çok önemlidir, para şirketinizin cebinden tedarikçinin cebine aktarılır.

Birim testlerini teslim edilebilir bir gereklilik olarak talep edebilirsiniz, ancak bunlarla ilgili devralınan birkaç sorun vardır, en ciddi olanı metrikleri belirlemek için önceden kesin bir yol olmamasıdır:

• Kabul edilebilir birim test miktarı nedir?

10 test yapılmalı mı? 100 test nasıl? 1000 teste ne dersiniz? Aslında, başlangıçta kaç teste ihtiyacınız olacağını belirlemek oldukça zordur. Asıl sayı gerçekten tespit edilemez ... durma problemi gibi ... ama biz bu problemi çözmüyoruz.

Sadece ünite testlerine sahip bir yazılım istersiniz, böylece geliştirmeye devam edebilirsiniz. Ünite testleri henüz ne kırdığınızı söylemez, ancak kodun bir regresyon hatası olduğunu size söylemek için çok uygundur.

• Kabul edilebilir bir kod kapsamı düzeyi nedir?

"% 100, elbette!" düşünecektin. Ne yazık ki bu metrik yanıltıcıdır; % 100 kod kapsamınız olsa bile, işlerin beklendiği gibi çalıştığından emin misiniz ? % 100 kapsama sahip olmak mümkündür ancak yapılamaz.

Yapmanız gereken gerçekten keşif testi, yani işleri kırmada gerçekten iyi olan birini bulmak ve test etmelerine izin vermek. Hiçbir geliştiricinin bile düşünmediği hataları bulmak.

Ayrıca, bazı gerekli performans kesmeleriniz varsa ve test edilmesi zor tasarım desenleri kullanıyorsanız (favori arama motorunuzda "singleton" ve "tdd" yi arayın ve bazı örnekler bulacaksınız),% 100 bazen saf birim testleriyle elde edilemez.

Gönderilen yazılımın çalışmasını istiyorsunuz ve şartname belgesi çalışacağı tek garantinizdir.

Daha yüksek test seviyesine ihtiyacınız olacak

Şartname belgeniz bir şekilde doğrulanmalı. Her noktanın, tedarikçileriniz için açık hedefleri ve kabul kriterleri olanlarla geçmesi gerekir. İyi işleyen bir KG organizasyonu (veya eğer bütçeniz ve sınırlı bir kapsamda iseniz harika bir testçi) bu kabul kriterlerini kontrol etmek için test durumlarını sağlayacaktır. Ayrıca bu kabul kriterlerini doğrulamak için birine ihtiyacınız var.

Hedeflerinizi doğrulamanın birkaç yolu vardır ve eğer biri bana herhangi bir aklı başında kalite, performans ve verimlilik hedefi belirleyemeyeceğinizi söylerse, sırasıyla keşif, performans ve kullanılabilirlik testleri ile ilgili büyük ve ağır kitaplarla kafama vuracağım. Amaçları aşmak kolay olabilir, ancak bilgi ve iletişim gerçekçi hedefler belirlemenize yardımcı olacaktır.

Avukat değilim, ancak çoğu proje sözleşmesi (temelde proje için tüm şartnamelerin annesidir ) okudum, genellikle kaç hata kabul edilebilir sayılacağını belirleyen bir kusur oranı kriterine sahibim. Böcekler genellikle şiddet dereceleri ile belirlenir, QA tarafından bulunan şov durdurulan böcekler düşük toleranslara sahipken, küçük lekeler yüksek toleranslara sahiptir. Gerçek projelerde, yazılımın 0 kusurlu olmasını talep etmek zordur. Son teslim tarihleri ​​genellikle bu uygulamaya son verir. Bu durumda, kapsamı pazarlık etmeye başlamalısınız.

Gördüğüm en çok sağlanan yazılımlar genellikle birim testleriyle teslim edilmiyor. Tedarikçilerin bunu sağlayacak kadar profesyonel olması gerektiğini savunabilirsiniz, ancak birim testlerinin size sunulmasını istemelerinin temel nedeni, regresyon hataları elde etmediğinizden ve yeniden yapılanmayı etkinleştirdiğinizden emin olmaktır. Sıkı teslim tarihlerine ilişkin projelerle gerçek hayatta hem tedarikçi hem de müşteri kapsamı düşürecek ve birim testleri genellikle pencereden dışarı çıkacak ve gerekli teslimat listesinden çıkarılacaktır.

Yüksek profilli açık kaynaklı yazılımların birim testleriyle sunulması biraz üzücü ama profesyonel bir yazılım geliştiricisi olamaz, değil mi?

Peki ne zaman müşteri olarak birim testlerine dikkat edeceğim?

Ben iddia ediyorum sadece , olur zaman gerçekten umurumda birim test teslim edilebilir yazılım coarsest yapmaya yapabilirsiniz test kendisi için tek başına bir program olarak yürütülecek olan kendi kendine yeten bileşen birim test edilir ise ise . Sınıf kütüphaneleri, birim testleri ile birlikte sunulabilen bir tür ürün olacaktır.

Satıcıların birim testleri yazmadığını nereden biliyorsunuz?

Belki yönetim ve satıcı bir toplantı yaptı ve satıcı dedi, kod X $ maliyeti ve birim testleri Y $ maliyeti. Penny pinching yönetimi sadece kodu istediğimizi söyledi.

Satıcı yine de (kalite nedeniyle) birim testleri yazmaya ve sadece (rekabet avantajı nedeniyle) sizinle paylaşmamaya karar verdi.

Şimdi yazılımda bazı önemli ayarlamalar yapmanız gerekir. Kurallara sahip olduğunuzdan, kendiniz yapabilir veya rekabetçi bir şekilde işe alabilirsiniz (orijinal satıcıya mutlaka değil). Ancak birim testleri satın almadığınız için, orijinal satıcı herhangi bir rakip için daha ucuz bir fiyata benzer kalitede işler yapabilecek.

Birim testlerini kullanmamalarına rağmen çok başarılı olan birçok proje var. Sadece linux çekirdeğine bakın, normal bir projede bulabileceğinizin ötesinde bir karmaşıklığa sahip devasa bir proje ve hala çalışıyor. Sonuç iyi bir yazılımsa, nasıl elde ettiklerini umursamamanız gerekir.

Hayır, tam ve otomatik test birimleri talep etmeniz gerekmez. Size uygun test stratejisi belgeleri sağlamaları daha önemlidir. Bu şekilde iyi gidiyoruz.