BDD, programcılar tarafından yazılabilir mi?


24

Sembolik “O Zaman Verildi” senaryoları ile Davranış Odaklı Gelişim sözdizimi, son zamanlarda yazılım işlevsellik değerlendirmesi için bir sınır nesnesi olarak kullanılması muhtemel kullanımları nedeniyle oldukça karmaşık olmuştur .

Gherkin'in veya hangi özellik tanımı komut dosyasını tercih ederseniz, işletme tarafından okunabilen bir DSL olduğu ve zaten böyle bir değer sağladığına kesinlikle katılıyorum .

Ancak, programcı olmayanlar tarafından yazılabildiğini kabul etmiyorum ( Martin Fowler gibi ).

Programcı olmayanlar tarafından yazılan, daha sonra geliştiriciler tarafından kullanılan senaryolar var mı?

Eğer gerçekten yazılabilirlik eksikliği konusunda bir fikir birliği varsa, o zaman senaryolara başlamak ve araçlarını uygulamak yerine , gerçek testlerden ticari olarak okunabilir senaryolar oluşturacak bir araçla ilgili bir sorun görür müsünüz ?

Güncelleme: “senaryo üreteci” aracıyla ilgili olarak, elbette işletme dilini sihirli bir şekilde tahmin etmeyecekti;) Ancak, tam da şu anda regexp eşleştiricileri yukarıdan aşağıya bir yaklaşımla testler oluşturmak için kullandığımız gibi (soyutlama boyutunda) kullanabiliriz dize üreticileri, aşağıdan yukarıya bir yaklaşımla senaryolar oluşturmak için.

“Sadece bir fikir vermek için” bir örnek:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Bilgisayarlar, bilgisayarlar için zaten kod yazabildikten sonra bile, diğer insanlar tarafından tam olarak okunabilen ortak bir dille gelmelerinden çok uzun zaman alacak.

İronik olarak, JBehave 1 (ilk BDD aracı), işletme tarafından okunabilir senaryolar üreterek başladı. Salatalık kadar İngilizce ayrıştırmadık. Ben ... JBehave 1 ilk onlar hakkında konuşmak zorunda olduğunu aslında insanları hatırlatan için yararlı olduğunu düşünüyorum
Lunivore

Yanıtlar:


20

Onu görmüştüm. İyi bitmedi.

Salatalığın, bu kesin nedenden dolayı hantal (<- lol: D) soyutlama olduğunu düşünüyorum. Teknik olmayan kişilerin kendileri tarafından yazması çok zor; teknik insanlar için çok ayrıntılı.

Teknik olmayan insanlar sadece programcılar gibi düşünmeyi öğrenmediler. Soyut bilgiyi anlamak, onu parçalamak, yeniden inşa etmek ve yine de belirsizlikten başarıyla kaçabilmek bizim için bir ayrıcalıktır. Bunun için para alıyoruz.

Gerçekten de, yazılabilirlik eksikliği konusunda bir fikir birliği varsa, o zaman senaryolara başlamak ve bunları uygulamak yerine, gerçek testlerden ticari açıdan okunabilir senaryolar oluşturacak bir araçla ilgili bir sorun görür müsünüz?

Aracın kendisi onları üretemez. Bilgisayar iş alanı hakkında hiçbir şey bilmiyor. Sonunda - programcı ne üretilmesi gerektiğinin çizilmesinden sorumlu olacak ve o zaman bile - bu senaryolar son kullanıcıları için çok ayrıntılı / şifreli olacaktır.


20
Non technical people just haven't learned to think like programmers. Doğrusu. Bu aynı kavram, son 20 yılda birkaç kez yeniden yaratıldı ve yeniden icat edildi ve neredeyse her zaman kötü sonuçlarla sonuçlandı. İşletmeler, sülük yazılımı geliştiricilerini emen bu açgözlü kanı ödemeye gerek kalmadan yazılım edinme kavramını seviyorlar, ancak yazılım geliştirmenin en zor bölümünün iş kurallarını iş adamlarının kendisinden daha derin ve karmaşık bir şekilde anladıklarını unutuyorlar.
maple_shaft

2
“Teknik olmayan insanlar sadece programcılar gibi düşünmeyi öğrenmediler.” Evet, sorunları ayrıştırma ve bunları belirtilen atomik mantıksal terimlerle ifade edebilme yeteneği muhtemelen bir programcı / analist yapan şeydir. İngilizceye benzemenin Gherkin'i herkes tarafından kullanılabilir hale getirme fikri bana inanılmaz derecede saf geliyor. Bunu onayladığınız için teşekkürler :) Computer knows nothing about business domain.Elbette. Fikrimi netleştirmedim, bunun için üzgünüm. Soruya bilgi ekleyeceğim.
MattiSG

8
@maple_shaft: Son 20 yıl mı? Son 60 yılını dene. COBOL etrafındaki ilk yutturmaca bazıları, iş adamlarının programcılara olan ihtiyacı ortadan kaldırarak yazabilmeleriydi. Bu gerçekleşmediğinde, insanlar aynı şeyi yapması gereken dördüncü nesil dilleri denilen bir sürü şeyle karşılaştılar.
David Thornley

11

Bir teknik özellik belgesi yazma konusunda müşteri açısından güçlüğün bir kısmı, müşterinin istediği şeyleri müşterinin gerçekten neye ihtiyacı olduğunu tanımlayan bir dile nasıl çevireceğini bilmemesidir. Müşteri bir sistemde belirli bir davranışın olmasını istediğini söylese de, genellikle, yazılımı müşterinin kendileriyle tam olarak uyuşmayacak şekilde çalıştığını görüp kullanana ve deneyimleyene kadar minutilerle pek ilgilenmezler. ihtiyacı vardır.

Müşteriler bir iş sürecini tanımladığında, genellikle pek çok alakalı bilgi bırakır. Genellikle bu bilgi, müşterinin kendi alanı içinde genel olarak anlaşılan ve bu nedenle programlayıcıya verilen ve çoğu zaman aktarılmayan bir süreçle ilgili şeyler ile ilgilidir. Diğer zamanlarda, müşteri aslında bir sistem içindeki tüm sınır koşullarıyla nasıl başa çıkılacağını bilmez ve programcıya rehberlik etmek ister. Bazen hepsi basit bir kullanılabilirlik durumudur, müşteri bir şeylerin bir şekilde çalışmak istediğini düşünürken, ancak daha sonra işlerin farklı şekilde çalışması gerektiği daha netleştiğinde fikrini değiştirir.

Tamam, "programcılar için müşteri ilişkileri 101" den yeterince. Soru, müşterinin bir şartnamenin nasıl tanımlanacağını tanımlamak için işletme tarafından okunabilen bir DSL kullanma konusunda hala bir değeri olup olmadığıdır. Rehberlikle cevabın geçici bir 'evet' olduğuna inanıyorum ve geçici söylüyorum çünkü akla gelecek soru şudur: bir programcıya daha kolay bir şekilde tanımlayabileceğiniz zaman neden bir müşteriyi bir DSL ile donattınız? Bir sistemin nasıl çalışması gerektiğini tanımlamak için müşteriye basit ama zengin bir dil sağlamak?

Bir müşteriye, sistemin nasıl çalışmasını istediğini açıklayan bir dil verdiğinizde, aşağıdaki satırlar boyunca bir şeyler söyleyen ifadelerle karşılaşacaksınız:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Bu tür bir beyanname, bir gereksinimin çok net bir şekilde tanımlanması ile sona erer, müşterinin sistemin temelde kabul etmesini istediği genel şekli veya ona bakmanın başka bir yolunu da müşterinin sistemin ne olduğunu tanımlamasıdır . Müşterinizden bazı şeyleri biraz daha düşünmesini istiyorsanız, onlardan belki de aşağıdakilere benzer bir dizi ifade kullanarak özelliğin uyması gereken kuralları açıklamalarını isteyebilirsiniz:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Yine çok net açıklamalar, bu kez nasılsistem davranmalı. Mesele şu ki, bir yazılım geliştiricisinin tüm boşlukları doldurması ve müşterinin yalnızca çevresel olarak farkında olabileceği daha fazla ayrıntıyı ortaya koyma ihtiyacının yerini almayacak. Müşteri programcı-dostu bir formatta özellikleri ve davranışları tanımlamak için programcı tarafından 'eğitilmiş' olabilirken, müşteri gerçekten anlamlı test senaryoları oluşturma veya uygulama sağlama becerisine veya bilgisine sahip olmayacaktır. kodu. Bu, OP'nin bahsettiği Martin Fowler makalesinin amacının olduğunu düşünüyorum. Yani evet, yazılımın kendisi müşteri tarafından yazılabilir değildir, ancak yazılımın tanımı kesinlikle - ve IMHO - müşteri tarafından yazılmalıdır. Buna değecekse, Fowler'in makalesini müşterinin bilmemesi gerektiğini söyleyerek okumadım.

Programcıların bazen müşterilerimizin işlerini ve iş süreçlerini anlamada genellikle çok akıllı olduklarını, kesinlikle bizden daha iyi olduklarını unutabildiğimizi hissediyorum. Onlara bir yazılım sistemini nasıl kuracaklarını söyleyen bir programcıları olmadığında, müşteriler genellikle diğerlerine - belki de daha az verimli - kendi özel işletme yönetimi sorunlarını çözme yollarına giderler. Bununla basit veritabanları (Access düşünün) veya elektronik tablolar, hatta elde yazılmış defterler ve bu süreçleri yönetmek için iyi tanımlanmış kurallar ve prosedürler kastediyorum. Birçok müşterinin eksik olması, bir sistemin nasıl çalışması gerektiğini belirlemek yerine araçların nasıl inşa edileceğini ve daha da önemlisi bir sistemin davranış kurallarını çalışanlara ne kadar verimli tanımladığını belirleme aracı değildir.do aslında sistemi oluşturmak için becerilere sahip.

Gerçekten de, yazılabilirlik eksikliği konusunda bir fikir birliği varsa, o zaman senaryolara başlamak ve bunları uygulamak yerine, gerçek testlerden ticari açıdan okunabilir senaryolar oluşturacak bir araçla ilgili bir sorun görür müsünüz?

Ben bu konuyu yanlış yoldan bakıyor düşünüyorum. Bu belgelerin herhangi bir şekilde bir şartnameyi temsil etmesi isteniyorsa, testlerden dokümantasyon üreten bir araçla ilgili büyük bir problem görecektim. Bir senaryoyu test etmek için, onu anlamanız gerekir, bu nedenle senaryo, her ikisi için de bir test tanımlamanız için zaten mevcut olmalıdır. Senaryoyu bir BDD-sözdiziminde tanımlarsanız, daha önce belirlediniz ve böylece senaryoları ancak gerçeklerden sonra gösterebilirsiniz. Diğer taraftan, müşterinin güzel bir programlama dostu DSL'de bir sistemi tanımlamasını sağlayacak bir aracınız varsa ve bu araç bir test paketi olarak kullanılacak kod şablonlarını oluşturmak için kullanılabilirse, Diyelim ki böyle bir araçta büyük değer olacaktı. Müşterinin programcıları denklemden çıkardığını görmeyecek ve BDD tarzında müşterinin isteklerini yerine getirmek ve test kodlu gereksinimler üretmek için gereken çabayı azaltmaya yardımcı olacak ve belki de müşterinin isteklerini daha kolay anlaşılmasını sağlayacaktır. Bununla birlikte, müşterinin ihtiyaçlarını müşterinin isteğinden ayırmasına yardımcı olmak için el altında deneyimli bir yazılım geliştiricinin yerine geçmez.


“Bir senaryoyu test etmek için, onu anlamak için bir test tanımlamak hem sizin için zaten mevcut nedenle senaryo ihtiyaçlarını gerekir.” Kabul ediyorum. Benim sorguladığım şey, dil kısıtlamalarının uygulanmasının bir değeri olup olmadığı. Sadece test yazmamız gerektiğini iddia etmiyorum; ancak iş tanımının her zaman düz, serbest form açıklamaları olacağı (ve muhtemelen olması gerektiği) gerçeğini kabul etmememiz gerekip gerekmediğini merak ediyorum . Bu nedenle, saf işletme planlarımız olacaktı ve insanların eşleşip eşleşmeyeceklerine karar vermelerine izin veren okunabilir senaryolar oluşturduk; numara yapmak yerine test etmek için gerçek descler kullanıyoruz .
MattiSG

@MattiSG ...whether enforcing language constraints is worth anything. Bu iyi bir soru. Serbest biçimli açıklamalar yazar için daha etkileyici ve doğaldır, ancak yararlı bir özellik elde etmek için diseksiyon gerektiren başıboş yorumlarla sonuçlanır. Gereklilikleri ve özellikleri yazmak için resmi 'kurallar' (yani bir DSL) tanımlayarak, hem müşterinin hem de programcının anlayabileceği ortak bir dile sahip olursunuz, yanlış anlaşılmayı sınırlar. Tanımları doğru alırsanız, testleriniz için bir şablon olarak sözlü olarak kullanılabilirler. Bu nedenle karmaşık araçlara hiçbir şey "üretmek" gerekmez.
S.Robins

@MattiSG FWIW, DSL ve BDD kullanarak kendi kullandığım sistem. Gereksinimler, Varlık-Özellik-Fayda ifadeleri olarak tanımlanır ve ilk gereksinimler ifadelerini AAA (İe: Ne Zaman Verilirse Sonra) ifadeleriyle genişleten bir spesifikasyon izlenir ... esasen senaryo ifadeleri. Serbest metni çözme girişimindeki zorluk, bir DSL olmadan, anlamlı koleksiyon senaryoları oluşturabilecek bir algoritma tanımlamanın kolay bir yolunun bulunmamasıdır. Demek istediğim, testleri senaryo oluşturmak için bir başlangıç ​​noktası olarak kullanmak, geriye dönük bir şeydi.
S.Robins

5

Geliştiricilerin senaryo yazdığını gördüm; test ediciler senaryolar yazıyor ve hatta bir ürün sahibi senaryolar yazıyor. Ayrıca, açıkça senaryolar ortaya çıkarmak için tasarlanan konuşmalar da yaptım - "<bu diğer bağlam> göz önüne alındığında, o zaman ne olacak?" - ve işin kullandığı kelimeleri yazdı.

Elimdeki en iyi sonuçlar, ofisteyken, ürün sahibiyle bir görüşme yapmak, onları bir wikide yakalamak ve daha sonra düzeltip daha fazlasını ekleyebilmek için ona yollamaktı. Konuşmamızda özlediğimiz bir çift buldu. Bu sarstı.

Gördüğüm en kötü senaryolar, geliştiricilerin işle hiçbir konuşma yapmadan kendilerini yazdıkları senaryolar. "Arama yaptığımda" veya "Formu bugünün tarihi olan + 3 ile gönderdiğimde" gibi terimler kullandıkları için söyleyebilirim. Genellikle çok ilginç senaryolar değil, çok fazla sayıda, çok düşük bir ayrıntı düzeyi ve bu yüzden tamamen anlaşılmaz. İş ayrıca bunları okumuyor.

IMO sohbetlerine odaklanmak çok daha iyi. Otomasyondan bağımsız olarak birkaç takımın birkaç ay boyunca kaliteyi geliştirdiğini gördüm. Bir ekip, birkaç hafta sonra otomasyonun çok zor bir ortamda çalışmasını sağladı, test cihazının neşesine! Ancak takım konuşmaları ve diğer senaryoları çizmek için senaryolar kullanması koşuluyla, onları kimin yazdığı önemli değil.


+1 İletişim gerçekten önemli ve senaryolar gerçekten de iş dünyasının bizleri çalıştığı anlamında olmalı, bu nedenle OP'lerin sorusu doğrultusunda, bir DSL yaratırsak, bunun gerçekten daha yakın bir eşleşme yapabilmesi gerekiyor. Müşterinin ne söyleyeceğini ve programcıların müşterinin ne demesi gerektiğini düşündüklerini değil.
S.Robins

0

Tecrübelerime göre, en iyi GWT ( O zaman verildiğinde ) s (SpecFlow kullanma tecrübesi) yazmak için BA'ya (İş Analisti) bırakılmasıdır . BA, Müşteri gereksinimlerini GWT'ye çevirebilir ve işletme bunu okuyabilir. Müşteriler sistemleri anlıyorlar ancak gereksinimleri kullanabileceğimiz şekilde yazmayı düşünecek teknolojiye sahip değiller.

İdeal olarak, BA bazı GWT’yi yazacak, bazı revizyonlar yapacağım, BA’nın BA’nın ve işin kapsamı konusunda güven duyuncaya kadar tekrarını gözden geçireceği / revize edeceği belirtildi. Pratik olarak BA, temizlemem ve çalışmam için zorlu bir taslak verirdi. İşletme, neden kimsenin düşünmediği bazı alanları kapsamadığını merak ettiğini söyleyerek silkiyor.


Lütfen GWT'nin sizin için ne ifade ettiğini açıklayabilir misiniz? :)
MattiSG

@MattiSG: Bunun Given-When-Then için olduğunu tahmin edin (bkz. OP).
sleske

@MattiSG - Yayının iyi yakalanması güncellendi.
SoylentGray
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.