BDDは実際にはプログラマー以外でも書き込み可能ですか？
象徴的な「Given-When-Then」シナリオの構文を使用した動作駆動型開発は、ソフトウェア機能評価の 境界オブジェクト としての可能性があるため、最近非常に注目されています。
Gherkin 、または任意の機能定義スクリプトが business-readibleDSL 、そしてすでにそのような価値を提供しています。
しかし、プログラマーではない（ Martin Fowler がそうであるように）それがwritableであることに同意しません。
誰かが非プログラマーによって書かれ、その後開発者によってインストルメントされたシナリオのアカウントを持っていますか？
書き込み可能性の欠如について確かにコンセンサスがある場合、シナリオでstartingする代わりに実際のテストからビジネスで読み取り可能なシナリオを生成しますか？
Update：「scenario-generator」ツールについては、もちろんビジネス言語を魔法のように推測することはありません。;）ただし、現在正規表現マッチャーを使用しているように、トップダウンアプローチ（抽象化ディメンション）でテストを作成すると、文字列ビルダーを使用してボトムアップアプローチでシナリオを作成できます。
「アイデアのみを与える」例：
Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…
見たことあります。うまくいかなかった。
きゅうりはこの正確な理由で扱いにくい（<-lol：D）抽象化だと思います。非技術者が自分で書くのは難しい。技術者には冗長すぎます。
非技術者はプログラマーのように考えることを学んでいないだけです。抽象的な知識を理解し、それを分解し、新たに構築し、あいまいさからうまく逃げることができるのは私たちの特権です。それが私たちの報酬です。
書き込み可能性の欠如について確かにコンセンサスがある場合、シナリオから始めてそれらを計測する代わりに、実際のテストからビジネスが読み取り可能なシナリオを生成するツールに問題があると思いますか？
ツール自体はそれらを生成できません。コンピューターはビジネスドメインについて何も知りません。結局のところ、プログラマーはとにかく生成する必要があるものを描画する責任がありますし、それでもなお、これらのシナリオはエンドユーザーにとって冗長すぎたり暗号化されすぎたりする可能性があります。
顧客が仕様書を書くという点での困難の一部は、顧客が顧客が望むものを、顧客が実際に顧客のニーズを説明する言語に翻訳する方法を知らないことが多いことです。顧客は特定の動作がシステムに存在することを望んでいると言うかもしれませんが、顧客が自分のソフトウェアと完全に一致していないと感じる方法で動作するソフトウェアを見て、使用し、経験するまでは、マニューシャにそれほど関心がありません。ニーズ。
顧客がビジネスプロセスについて説明するとき、多くの場合、多くの関連情報が省略されています。多くの場合、この情報は、顧客の特定のドメイン内で一般的に理解されているプロセスに関するものに関連しているため、当然のことと見なされ、プログラマーに中継されないことがよくあります。また、システム内のすべての境界条件を処理する方法を実際に知らず、プログラマにガイダンスを求めている場合もあります。場合によっては、それがすべてユーザビリティの単純なケースであり、顧客は何かをある方法で機能させたいと考えているが、後で物事が異なるように機能することが明確になったときに気が変わる。
さて、「プログラマ向けの顧客関係101」はこれで十分です。問題は、顧客がビジネスで読み取り可能なDSLを使用して仕様を定義する方法を定義することにまだ価値があるかどうかです。ガイダンスがあれば、答えは暫定的な「はい」であると思います。次の質問が頭に浮かぶので、暫定的に言います。プログラマーがより簡単にDSLを定義できるときに、なぜ顧客がDSLを作成するのでしょうか。システムがどのように機能する必要があるかを定義するためのシンプルでありながら豊かな言語を顧客に提供しますか？
システムがどのように機能するかを説明するための言語を顧客に提供すると、最終的には次のような言い方をするステートメントが作成されます。
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
このタイプのステートメントは、要件を非常に明確な方法で説明し、顧客が基本的にシステムに想定したい全体的な形を提供します。または、別の見方は、顧客が説明しているwhatです。 =システムです。顧客にもう少し考えてもらいたい場合は、次のようなステートメントを使用して、機能が従う必要のあるルールを説明するよう依頼できます。
"Given 'some system state', When 'some action occurs', Then expect 'some result'
繰り返しになりますが、今回はhowについてシステムが動作するはずです。問題は、これは、ソフトウェア開発者がすべての空白を埋める必要性に取って代わるものではなく、顧客が周辺でしか認識していない可能性がある詳細を引き出すことです。顧客はプログラマーによって「トレーニング」されて、機能や動作を素敵なプログラマーフレンドリーな形式で説明できるかもしれませんが、顧客は意味のあるテストケースを生成したり、実装を提供したりするためのスキルや知識を持っていません。コード。これが、OPが言及したMartin Fowlerの記事の要点だと思いました。したがって、はい、ソフトウェア自体は顧客が書き込み可能ではありませんが、ソフトウェアの説明は最も確実にできます-そして私見は-顧客によって書かれるべきです。価値があることについて、私はFowlerの記事を読んで、顧客がDSLを作成するべきではない、または作成できないと言っていませんでした。むしろ、顧客がDSLを正常に実装する方法を理解できるようにするツールを作成するコストはこれは事実上禁止されているため、顧客にDSLを表示し、必要に応じて顧客がそれを調整して、ビジネスパーソンとプログラマーの両方が共同で作業を続けるために使用できる共通言語を提供することは、より簡単でおそらく費用効果が高いと思います同じページ。
私たちのプログラマーは、ビジネスやビジネスプロセスに対する顧客の理解が一般的に非常に賢いことを忘れることがあると思います。確かに私たちよりもはるかに優れています。ソフトウェアシステムの構築方法を教えるプログラマーがいない場合、顧客は通常、他の手段（おそらく効率が悪い）を使用して、特定のビジネス管理の問題を解決します。これは、単純なデータベース（Accessを考えます）またはスプレッドシート、あるいは手書きの台帳でさえ、それらのプロセスを管理するための明確なルールと手順を備えていることを意味します。多くのお客様が欠けているのは、システムが機能する必要があるhowを決定する手段ではなく、むしろbuiltであるべき方法であり、さらに重要なのは、 doが実際にシステムを構築するスキルを持っている人へのシステム。
実際に書き込み可能性の欠如についてコンセンサスがある場合、シナリオから始めてそれらを計測する代わりに、実際のテストからビジネスが読み取り可能なシナリオを生成するツールに問題があると思いますか？
これは問題を間違った方法で見ていると思います。ドキュメントが何らかの形で仕様を表すことを目的としている場合、テストからドキュメントを生成するツールで大きな問題が発生します。シナリオをテストするには、シナリオを理解する必要があります。したがって、両方のシナリオのテストを定義するには、シナリオがすでに存在している必要があります。シナリオをBDD構文で説明する場合は、すでにシナリオを指定しているため、シナリオをインストルメント化できるのは、事実の後でのみです。一方、顧客がニースのプログラミングに適したDSLでシステムを説明できるツールがあり、そのツールを使用してテストスイートとして使用されるコードテンプレートを生成できる場合は、このようなツールには大きな価値があると言います。これにより、顧客がプログラマーを方程式から外すことはなく、顧客の要望を取り入れてBDD方式でテストエンコードされた要件を生成するために必要な労力を削減し、おそらく顧客の要望をより簡単に理解できるようになります。ただし、経験豊富なソフトウェア開発者が手元にいて、顧客のニーズと顧客のニーズを区別できるようにするのに代わるものではありません。
開発者がシナリオを書くのを見てきました。テスターはシナリオを作成し、製品所有者でさえシナリオを作成します。私はまた、シナリオを引き出すために明示的に設計された会話をしました。 -そして、ビジネスが使用する言葉を書き留めます。
私が得た最高の結果は、彼がオフィスにいる間に製品所有者と会話し、それらをwikiでキャプチャしてから、彼を修正して追加できるように彼に送信したことでした。彼は私たちの会話で逃したカップルを見つけました。それは揺れました。
私が見た中で最悪のシナリオは、開発者がビジネスと会話せずに自分で書いたシナリオです。 「検索を実行したとき」や「今日+ 3の日付でフォームを送信したとき」などの用語を使用しているため、わかります。これらは通常、あまり興味深いシナリオではなく、あまりに多く、詳細レベルが低すぎるため、完全にメンテナンスできません。企業もこれらを読みません。
会話IMOに集中する方がはるかに良いです。自動化に関係なく、品質が大幅に改善された数か月間、いくつかのチームがこれを行っているのを見てきました。あるチームは、数週間後、非常に困難な環境で自動化を機能させることができました。しかし、実際には、チームが会話し、シナリオを使用して他のシナリオを引き出す限り、誰がそれらを書き留めても問題ではないと思います。
私の経験では、GWT（Given-When-Then）s（SpecFlowを使用した経験）を書くのはBA（ビジネスアナリスト）に任せるのが最善です。 BAは顧客の要件をGWTに変換でき、企業はそれを読み取ることができます。お客様はシステムを理解していますが、技術者が私たちが使用できるように要件を作成することを考えていません。
理想的には、BAがGWTを記述し、私がいくつかの修正を行い、BAとビジネスがカバレッジに自信を持つまで、BAはレビュー/修正を繰り返します。実際には、BAは大まかなドラフトを提供し、それを整理して作業します。ビジネスはそれを断念して、それがなぜそれが誰も考えもしなかったいくつかの領域をカバーしなかったのか不思議に思うと言って肩をすくめました。