6

私は、高レベルの仕様をシナリオ形式で記述し、そのためのテストを書くことを想像できるような方法で、私の職場でビヘイビア駆動開発を実装することを提案してきました。

テスト可能な仕様に対して作業を行うと、開発者の生産性が向上する傾向があることは確かです。そして、これが私たち自身のプロジェクトに当てはまるいくつかの例をすでに思いつくことができます.

ただし、これの価値をビジネスに示すことは困難です。

これは、共同アプリケーション開発 (JAD) プロセスが既に整っているためです。このプロセスでは、開発者、管理者、ユーザー エクスペリエンス、テスターがすべて集まり、共通の一連の要件に同意します。

では、テスターが作成したテスト ケースに対して開発者が取り組む必要があるのはなぜでしょうか。これらは検証用であり、開発者が現在取り組んでいる UX チームによって作成された上位レベルの仕様に基づいています。

開発者にとってはこれで十分であり、仕様の記述方法を変更する必要はないと彼らは言います。

彼らには一理あるようです。

テストケースが現在開発者に与えられているより高いレベルの仕様と完全に互換性があるテストチームをすでに持っている場合、BDD/TDD の実際の利点は何ですか?

4

4 に答える 4

3

これが役立つことを彼らに納得させたい場合、あなたがする必要がある主なことは、それが解決するであろう問題を特定することです。

これが改善すると思うあなたの状況で何が起こっていますか？

BDDの主な利点は、利害関係者と開発者の間のコミュニケーションを改善することです。

これらの検証テストに失敗するコードを作成している場合、開発者はテスターとは異なる方法で仕様を理解しています。つまり、仕様が明確でなく、BDDによって状況が確実に改善される可能性があります。

開発者として、チーム全体のプロセスを変更せずに作業できるプロセスの部分もあります。単体テストレベルに焦点を合わせ、従来のテスト駆動開発を行うと、生産性が向上する可能性があります。

于 2011-01-10T01:54:37.810 に答える
2

これは素晴らしい質問です。実際、BDD に関して言えば、これが「結論」の質問です。TDD や単体テストの作成における大きな課題の 1 つは、開発者が物事の全体像やビジネスの視点を理解していないように見えることです。実際の「ビジネス」シナリオをテストするために仕様を記述し、ユニット テストを生成する演習は、開発者が「職人技」を超えてビジネスの視点を把握するのに役立ちます。詳細については、この投稿をチェックしてください。

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

于 2011-11-16T16:22:07.487 に答える
1

BDD を最も軽い形で考えると役立つかもしれません。特定のシナリオに関する議論として。

ユースケースがあります。あなたはあなたの要件を持っています。ここで、それらについて本当によく理解していることを確認したいと思います。開発者かテスターかもしれませんが、誰かが言います。右？"

そして、テスターは「はい、そうです」と言うでしょう。

次に、UX またはアナリストは、「まあ、<この別のコンテキストが存在しない限り>」と言います。

シナリオについて議論することで、全員が共通の理解を持っていることを確認するのにかかる時間が大幅に短縮されます。私たちは通常、明白なシナリオを大目に見て、エッジ ケースに焦点を当てます。新しいドメイン用語、部門間で異なる概念、レガシー システムとの難しいやり取りについて。

開発者は、実際にはテスト ケースに基づいて作業するわけではありません。それらは、常に行うのとまったく同じ方法で、要件と受け入れ基準に基づいて機能します。テストケースは、彼らが期待する種類の例にすぎません。ユーザーがシステムの価値から恩恵を受ける、またはシステムの価値を伝えるシナリオ。テストの労力はコードベースのサイズにほぼ比例して増加するため、これらのテストケースを自動化すると便利です。

BDD は、要件やドメインに関する不確実性が高く、人々の理解が大きく異なるプロジェクトで最適に機能します。プロジェクトがすでに機能している場合は、それに固執してください。アイデアを思いつくことと、それを実装することの間の最大のギャップがどこにあるかを調べて、BDD がその分野で役立つのであれば、それを使用してください。それ以外の場合は、他のものを選択してください。とにかく、あなたがしていることはBDDプロセスと非常によく似ています。

于 2011-01-13T17:58:29.313 に答える
0

私はちょうどこの質問に出くわし、それは本当に非常に興味深い質問なので、私が検討したいと思いました.

方法論が壊れているのは、チーム全体が壊れていると感じ、最終的にプロジェクトが失敗した場合だけです。

現在のシステムがうまく機能している場合は、「BDD/TDD のほうが好きかもしれませんが、このように作業できるでしょうか?」と自問する必要があります。あなたの答えが「いいえ」で、他のシステムで働くことに不満を感じている場合は、キャリアを別の場所に移す必要があることを示している可能性があります。はいの場合は、システムを受け入れます。

実際、私だったら、とにかく新しいシステムを受け入れます。1 つには、もしあなたがそれに親しむ機会を与えてくれれば、相対的な長所と短所についてより多くの情報に基づいた判断を下すことができます。が必要でした。

結局のところ、方法論の良し悪しは、その最終結果にかかっています。動作するソフトウェア、およびすべての利害関係者の満足。

:-)

于 2011-12-06T05:47:50.363 に答える