Davranış Odaklı Gelişim doğal diller belirsiz olduğunda netliği nasıl geliştirir?


9

Şu anda salatalık gibi BDD test çerçevelerini araştırıyorum ve insanlar dediğinde merak ediyorum

özellik dosyaları basit doğal dilde olduğundan netliği artırır ve net bir görüş sağlar

ama doğal dil, yazılım mühendisliğindeki sorunların çoğunun nedeni değil midir?

Doğal dil belirsizdir ve müşterilerin gereksinimlerinin yanlış anlaşılması ve geliştiricinin anlayışı nedeniyle birçok yazılım projesinin başarısız olmasının nedeni budur. Burada niş yok.

Evet, testleri küçük basit yapılabilir eylemlere bölmek mantıklıdır ve belirli bir netlik düzeyi sağlar, ancak bu bir bütün olarak verimliliği artırır mı?

Not: Uzman değilim ve burada bir görüş belirtmiyorum. Sadece konsepti anlamaya meraklıyım.


1
Çok güzel bir soru. Salatalık teklifinin pratikte işe yaradığı şeyleri hiç görmediğimi söylemeliyim. Doğal dil, testlerin belirlenmesi gibi kesin teknik görevler için uygun değildir.
Andres F.

BDD'nin dili kullanması, işletme için zaten anlamsız olması gereken mevcut işletme alanının dilini yansıtmayı amaçlamaktadır. Wikipedia makalesi, metnin başlarında bunu belirtir.
Martin Spamer

Yanıtlar:


8

Haklısın. BDD, dil belirsizliğiyle ilgili sorunları hiç ortadan kaldırmaz - hiç değil. Diğerlerinin de belirttiği gibi, çevrilen snippet'lerin uygun şekilde tanımlanmasıyla eşleştirilmesi gerekir, ancak bu aynı zamanda altta yatan belirsizlik sorununu da ele almaz.

Şimdi BDD bu sorunu çözmemesine rağmen neden değerli? Bazı nedenler var ve bu liste kesinlikle tam değil.

Belirsizlik çözülmedi

Bu ne BDD lehine ne de ona karşı bir sebep değildir. Ancak bunu kullanıcı öyküleri veya gereksinimleri gibi diğer yaklaşımlarla karşılaştırdığınızda, tüm SW geliştirme yaklaşımları, doğal bir dil formülasyonu ile bir şekilde başladığı için dil belirsizliğinden muzdariptir.

Teknik olarak, dil belirsizliği sorunu lojban gibi yapay dillerle çözülmüştür , ancak daha sonra müşteriniz ve geliştiricileriniz bu dili bilmeyecektir.

Her yerde kullanılan dil

BDD her yerde bulunan bir dil fikriyle el ele gider. Senaryoları tüm müşteriler, testçiler ve geliştiricilerle birlikte belirleyebilmek, BDD'ye diğer yaklaşımlara göre bir avantaj sağlıyor.

Tüm gereksinimleri yazan geleneksel bir ihtiyaç mühendisini düşünün. Bir test cihazı veya müşteri olarak, 300 sayfalık belgeyi gözden geçirme gereksinimleriyle dolu hale getirdikten sonra, orada kullanılan terminolojiden çok daha acil sorunlarınız olacaktır.

Kullanıcı öyküleri bu cephede biraz daha iyi olur, çünkü yaratımlarına tüm paydaşları da dahil ederler. Her yerde kullanılan dil açısından, BDD'nin veya kullanıcı hikayelerinin daha iyi olduğunu söyleyemem - bir sonraki noktada önemli ölçüde farklılık gösterse de.

Testedilebilirlik

BDD'nin önemli bir özelliği spesifikasyonlarınızın gerçekten yürütülebilir olmasıdır (Salatalık veya benzeri). Ne gereksinimler ne de kullanıcı hikayeleri bu özelliği sunmaz. Şahsen benim için BDD'nin ana satış noktası bu.

Geleneksel gereksinimlerden farklı olarak, biz mühendislere çağlar boyunca gereksinimlerinin test edilebilir olması gerektiğini söylüyoruz. Yine de, her proje, hat test cihazlarının bir yerinde belirli bir gereksinimi nasıl test edeceklerine dair hiçbir fikirleri olmadığını fark ettikleri bir durum görür.

Kullanıcı hikayeleri, doğru yapılırsa, emin olmak için test cihazlarını erken oluşturma aşamalarına dahil edin. Ne yazık ki, bu gerçek dünyayla çatışan bir teori örneğidir, burada daha önce hiçbir test cihazının görmediği birçok hikaye gördüm.

Öte yandan BDD size otomatik olarak yürütülebilir bir test senaryosu verir. Hiçbir mazeret ve bunun hiçbir yolu yoktur (otomasyon katmanlarını tamamen görmezden gelmedikçe ve sadece süslü şiir için senaryolar yazmadıkça).

Daha genel olarak, Test First, yazılım geliştirmenin tüm aşamalarında çok faydalı olan bir prensiptir ve BDD, geliştirmenin en dış katmanına uygulanmasıdır (birim düzeyinde f.ex. TDD ile karşılaştırıldığında).

özet

Özetle, BDD sizi doğal dil belirsizliği sorunlarından kurtarmaz. Bununla birlikte, bu sorunu iki önemli noktadan ele almanıza yardımcı olur: Belirsizlikleri azaltmak için her yerde birden fazla dile odaklanmak (tamamen ortadan kaldırmaz, ancak bir ton yardımcı olur!) Ve yürütülebilir yazmanıza zorlayarak özellikleri. İkinci nokta, belirsizlik sorunlarının ele alınmasına yardımcı olmaktadır, çünkü belirsizliklerin aksi takdirde sorun olarak ortaya çıkmaya başladığı nokta budur.


bu harika bir cevap. Bu soruyu sorduktan sonra bu konuda biraz araştırma yaptım ve puanlarınızın çoğuna katılmalıyım. Salatalık veya herhangi bir BDD aracı gibi araçların kullanımıyla ilgili büyük bir sorun, geliştiricinin BDD fikrini zen düzeyinde anlamamasıdır. . İşte Elizabeth Keogh'un ilginç bir makalesi.
Raghuram8892

4

Bir şey “doğal dilde” yazıldığında, bu birkaç anlama gelebilir:

  • Bu kelimenin tam anlamıyla İngilizcedir. İngilizce çok belirsiz ve kesin olmayan bir dil olduğundan, bu giriş modu yazılım geliştirme bağlamında tatmin edici değildir.

  • Bu İngilizcedir, ancak ilgili terimler tam olarak tanımlanmıştır. Bu dil yasal belgelerde veya matematiksel metinlerde kullanılır.

  • Bu resmi bir dildir, ancak dil, doğal dil sözleşmelerinden sonra çok yakından modellenmiştir. Bu, tüm programlama dillerini bir dereceye kadar açıklar. Resmi dil ne kadar İngilizceye benziyorsa, eğitimsiz okuyucular için anlaşılması o kadar kolay olur. : Bu hedef programlama dilleri kayda değer örnekleri COBOL ve SQL dahil select id, name from persons where age > 18hemen göze çarpmaktadır. Bu dillerin dezavantajı, çalışma kodunu yazmak için resmi dili anlamanız gerektiğidir . Ayrıca, bu diller genellikle çok ayrıntılıdır.

DDD, projenin etki alanını tanımlamak için her yerde bulunan bir dil kullandığını önerir . Bu esas olarak durum 2'dir: Doğal dil içinde tam olarak iletişim kurabilmeniz için ilgili terimleri tanımlayın.

Salatalık, durum 3'tür: normal İngilizceye çok yakın okuma niyeti olan resmi bir dil. Daha doğrusu: Salatalık, gereksinimleri / testleri ifade etmek için kullanılabilecek basit bir biçimsel dil tanımlamanızı sağlayan bir çerçevedir. Buradaki nokta, aynı belgenin doğal dil gereksinimlerini ve otomatik olarak yürütülebilir testleri temsil etmesidir, bu nedenle ikisi her zaman senkronize olacaktır. Bir salatalık senaryosunu okuyabilir ve tüm bunların nasıl çalıştığını anlamak zorunda kalmadan gereksiniminizi doğru bir şekilde ifade ettiğini doğrulayabilirsiniz.

Salatalık, belgeyi doğal dilin bilinen snippet'leriyle eşleştirerek çalışır. Bu snippet'lerin önce tanımlanması gerekir. Salatalık'ta bir senaryo yazmak için mevcut snippet'lerin farkında olmanız gerekir - yazılım aklınızı okumaz. Bu snippet'ler de olası sorunların kaynağıdır: Metin snippet'inin davranışını uyguladığınızda, kodunuz snippet metninin önerdiğinden biraz farklı olabilir. Aynı pasaj birçok kez kullanılıyorsa, bu bir sorun değildir. Salatalık bu nedenle, daha küçük koşullar, eylemler ve sonuçlardan oluşan iş kurallarını tanımlamak için çok uygundur. Her snippet yalnızca bir veya iki kez kullanılacaksa diğer test çerçeveleri daha iyi olabilir, örneğin her test senaryosu için kurulum benzersizdir.


Ayrıntılı bilgi için teşekkürler. Salatalık biraz durum 2 ve vaka 3 arasındaki gri alanda olduğunu hissediyorum. Onun SQL aslında aksine "Özgür İrade" bir tür olamaz ve sıkı resmi sözdizimi ile sopa olamaz. Sınırlı bilgime göre, salatalık senaryosu için "Verilen", "Ne zaman" anahtar kelimelerinden sonra herhangi bir metin biçimine izin vermiyor mu? Bu kadar basit olabilir, ancak İngilizce ana dili olmayan bir ülkedeyim ve insanların kesin snippet'ler vermesi büyük olasılıktır.
Raghuram8892

1
Evet, istediğiniz her şeyi Given/ When/ karakterinden sonra koyabilirsiniz Then, ancak a) siz ve ekibiniz bunun tam olarak ne anlama geldiğini tanımlarsınız ve b) eşleştiricilerdeki anlamı kodda , yani biçimsel bir dil olarak tanımlarsınız .
Jörg W Mittag

0

@ Raghuram8892, Verilen / Ne Zaman / Sonra / Ve anahtar kelimelerinden sonraki metin "snippet" ile eşleşmelidir, aksi takdirde adım tanımsız veya "beklemede" olarak başarısız olur. Bu şekilde, kare 3'e girer.

"İngilizce", Salatalık ve dili ile ilgili olarak, Gherkin uluslararası kullanım için tasarlanmıştır. Şu cucumber --i18n helpanda desteklenen dillerin listesini cucumber --i18n $CODEgörmek ve belirli bir dil kodunun anahtar kelimelerini görmek için komutu çağırabilirsiniz . Örneğin, cucumber --i18n eoEsperanto için anahtar kelimeler verir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.