- 動作駆動型開発 (BDD) は、技術チームと非技術チーム間のコラボレーションを優先する開発プロセスです。
- BDD を使用すると、テスト ケースは自然言語で記述され、ビジネスの価値とユーザー機能が考慮されます。 LoadView は、技術的なユーザーと技術者以外のユーザーの両方がすぐに理解できるレポートを備えたアクセス可能なプラットフォームを提供するため、BDD 開発ツールキットの便利なツールになります。
開発者は、Webサイト、アプリ、またはAPIを軌道に乗せるための不可欠な部分ですが、関与しているのは開発者だけではありません。 プロダクトマネージャーからビジネスアナリストまで、誰もが強力な ウェブ プレゼンスの開発と維持に同等の利害関係を持っています。 チームが異なれば、強み、知識、スキルセットも異なります。 マーケティングアソシエイトはソフトウェアエンジニアほど開発に精通していないかもしれませんが、チームのすべてのメンバーが同じページにいることを確認するにはどうすればよいですか? そこで、行動主導の開発の出番です。
行動駆動型開発 (BDD) は、チーム間のコラボレーションを優先して、関係者全員に役立つ方法でサイトを軌道に乗せるのに役立つ開発プロセスです。 BDD プロセスを実装すると、チームは、プログラマと非プログラマが同様に理解できる、一貫性のあるアクセス可能な言語を形成できます。 テストケースは自然言語で記述され、ビジネスの価値とユーザー機能を考慮に入れます。
LoadView では、すべての部門でビジネスの成功を支援することに投資しているため、BDD についてもう少し学び、BDD がチームの共同作業にどのように役立つかを見てみましょう。
BDDの簡単な歴史
2006年、ソフトウェア開発者のDan Northは、彼が働いていた社内の部門間のコミュニケーションにギャップがあることに気づきました。 製品マネージャーやマーケティングマネージャーのような技術チームが少ないチームは、主要な開発について暗闇に取り残されており、ソフトウェア開発者は、サイトをナビゲートしている間、主要なユーザーの懸念に気づいていないように見えました。
これらのギャップから、ノースは新しいシステムを開発することができました。 テスト駆動開発 (TDD) から分岐した BDD は、実際の人間の行動、平易な英語、および明確な論理モデルに焦点を当てています。 このプロセスでは、技術的な要求だけでなく、ビジネス上の懸念も考慮されます。 以前は複雑なモデルを採用し、平易な会話英語に可能な限り近づけた新しいドメイン固有言語(DSL)に翻訳しました。
この DSL は、BDD の定義要因である give/when/then モデルになりました。
ギブ/タイミング/その後モデル
give/when/then モデルでは、各部分がトランザクションのステージ、つまりオンラインでの対話を定義します。
- 与える:方程式の与えられた部分を参照します。 現状。 インターフェイスがユーザーによって操作される前に開始した場所
- 日時: は、インタラクションを開始するためにユーザーが実行するアクションです。 検索バーに入力されたクリック、トランザクション、またはキーワードはすべて「いつ」可能ですか
- 次に、その後に来るもの、アクションが引き起こす反応です。
ギブ/タイミング/その後のシナリオの例を次に示します。
- アカウント 1 の $0 とアカウント 2 の $100 の場合
- アカウント2がアカウント1に50ドルを送金する場合
- 次に、アカウント1には50ドル、アカウント2には50ドルがあります。
この平易な英語モデルにより、プログラミング状況を部門間で簡単に共有できます。 DSLは、開発者であろうとなかろうと、誰でも理解できます。 機能テストと非機能テストを実行する場合、give/when/thenモデルを使用すると、通信にギャップがなくなります。
これはBDDの本質的な機能であり、平易な英語を使用してすべての人が理解できるDSLを開発します。 BDD を使用して Web サイト、アプリ、または API を開発することには、多くの利点がありますが、DSL の開発はその 1 つにすぎません。
BDD を使用した開発の長所
BDD は、多様なチームで作業している場合に大きな利点があります。 機能性、明確なコミュニケーション、ユーザーエクスペリエンスに重点を置いているため、技術に精通していない顧客とのオンラインビジネスやデジタルサービスに最適なプロセスとなっています。 BDD は次のとおりです。
- 効率的: すべての利害関係者が合意した機能と言語を明確に定義することは、BDD の重要な利点です。 全員が同じページにいることで、ビジネスとコーディングの角度からの開発をタイムリーに形にすることができます。 すべてのチームが協力することで、機能しない要素に戻ってやり直すために必要な時間が短縮されます。
- 安い: BDD はビジネスの価値だけでなく、収益にも適しています。 明確に定義された言語は、テストケースの作成と検証が簡単であることを意味します。 これらのテストケースは、何がいつ予想されるかを明確に理解することで自動化できます。 これらのテストを自動化すると、アプリケーションテストのコストを削減できます。
- 高品質:非開発ベースのチームの助けを借りて、デザイナーとプログラマーはユーザーエクスペリエンスに関するフィードバックをすぐに受け取ります。 これにより、ユーザーの視点から考え、開発することを余儀なくされます。 ユーザーの視点からの開発は、開発者が安定したスケーラブルでテスト可能なコードを記述するのにも役立ちます。 これにより、ユーザーの問題が発生する前に防止できます。
BDD を使用した開発の短所
BDD は特定の状況では優れたプロセスになる可能性がありますが、普遍的ではありません。 BDDは、TDDアプローチの問題を解決し、ギャップを埋めるために発明されました。 プログラマの経験が浅い場合、TDD 開発プロセスに精通していない場合、または特定のツールやプログラミング言語に依存している場合、BDD は適切な選択ではない可能性があります。
BDD は良好なコミュニケーションに依存しており、コスチューム、ユーザー、および他のチームの代表者と効果的にコミュニケーションできる専任の開発者のチームを持つことを意味します。 これは、追加のオーバーヘッドを意味する可能性があります。
一般的な BDD ツール
BDD は、開発者コミュニティで人気を博しています。 多くの人がBDDアプローチを採用し、仕事を成し遂げるための一連のツールを開発しました。 ここでは、一般的な BDD ツールをいくつか紹介します。
- キュウリ BDDコラボレーションのための人気のあるオープンソースプラットフォーム。 これは、チームがプレーンテキストで機能を構築するのに役立ちます。 チーム全体と共有しやすいDSLを使用して結束性を提供します。 ガーキン構文を実装しています。
- レタス はキュウリの上に構築されており、Pythonベースのアプリケーションに最適です。
- Specflow は、ガーキン構文を使用する別のオープンソース BDD プラットフォームです。これは、.NET プラットフォーム用に構築されています。
ロードビューを使用した動作駆動型開発
BDD はプロセスであり、パフォーマンス テストはそのプロセスの重要な部分です。 パフォーマンス テストの自動化は BDD の重要な部分であり、Web サイトを軌道に乗せるための迅速なターンアラウンドを確保するのに役立ちます。 LoadView は、単純なスクリプトを使用して実際のユーザーの動作をシミュレートするパフォーマンス テストを実行するため、BDD のベスト プラクティスを使用してテストを自動化できます。 さまざまなユーザー負荷、ユーザーの場所、およびストレスレベルでWebサイトがどのように実行されるかをテストできることは、行動駆動開発に関与するすべての部門に役立ちます。
LoadView はアクセス可能なプラットフォームであり、事前のコーディング知識を必要としないため、複数の非技術部門で作業するチームに最適です。 ロードビューはテスト用に構築されています。
- ウェブページ
- ネイティブモバイルアプリ
- API
ロードビューを今すぐお試しください
BDD は、開発プロセス中にビジネス価値の中心に置かれ、ユーザーの最終結果を常に念頭に置くように設計されています。 LoadView は、効率的で理解しやすい開発のためにパフォーマンス テストを自動化するのに役立ちます。LoadView を無料で試すか、今すぐデモをスケジュールして、会社の BDD プロセスにパフォーマンス テストを実装する方法を確認してください。