how testers are involved tdd
TDD、BDD、およびATDD手法の概要：
TDD、BDD、ATDDは、アジャイルのテスターの世界に革命をもたらし、勢いを増している用語です。 テスターの考え方の変化 また、新しいスキルを学び、さらに重要なことに、態度や働き方を変える必要があります。
単独で作業するのとは異なり、テスターはプログラマーと協力して作業する必要があります。つまり、
- テストケースの共有
- ストーリーの受け入れ基準の作成に参加する
- 利害関係者に継続的なフィードバックを提供する
- 時間通りに欠陥を解決するために協力する。
- 成果物の品質を向上させるための提案と入力を提供する
- オートメーション
これらのプラクティスへのテスターの関与について説明する前に、まずこれらの用語の背後にある概念を理解してみましょう。
学習内容：
テスト駆動開発
コードを最初に記述してからテストする、ソフトウェア開発の従来のアプローチを検討してください。テスト駆動開発またはTDDは、従来の開発とは正反対のアプローチです。このアプローチでは、最初にテストが行われ、次にコードが記述されます。
混乱しましたか？!!
まだ開発されていないソフトウェアをどのようにテストできますか？
はい！！それはテスト駆動開発またはTDDです。
TDDは、次の場合に少しずつ機能します。
- テストは最初に書かれます
- テストが実行されます–失敗します（明らかな理由で）
- コードは、テストケースに合格するためだけに記述（またはリファクタリング）されています
- テストが再度実行されます
- テストに合格した場合は、次のテストに進みます。ELSEは、テストに合格するようにコードを書き直し/変更します。
フローチャートで説明してみましょう。
ここで、TDDがテスターが行うテストについて話していないという事実を理解する必要があります。むしろ、このアプローチは実際にプログラマーが行うテストについて話します。
はい！！あなたはそれを正しく推測しました！ユニットテストです。
最初に書かれるテストは、テスターが書くテストではなく、プログラマーが書く単体テストです。したがって、手順を次のように言い換えます。
- UNITテストが最初に書かれます
- UNITテストが実行されます–これは失敗します（明らかな理由で）
- コードは、テストに合格するためだけに記述（またはリファクタリング）されています
- UNITテストが再度実行されます
- テストに合格した場合は、次のテストに進みます。ELSEは、テストに合格するようにコードを書き直し/変更します。
ここで発生する問題は、TDDがプログラマーの仕事である場合、このアプローチにおけるテスターの役割は何であるかということです。
TDDはプログラマーの仕事だと言っても、テスターがそれに関与していないという意味ではありません。テスターは、以下で構成されるテストシナリオを共有することでコラボレーションできます。
つまり、テスターは単体テストシナリオの定義に参加し、プログラマーと協力して同じものを実装する必要があります。テスターは、テスト結果に関するフィードバックを提供する必要があります。
TDDを実装する場合、テスターはスキルセットをアップグレードする必要があります。彼らはより技術的であり、分析的および論理的スキルの向上に焦点を合わせる必要があります。
テスターはまた、プログラマーが使用する専門用語を理解するように努力する必要があり、可能であれば、コードを俯瞰する必要があります。同様の方法で、プログラマーはテスターの立場に立ち、単体テストをより堅牢で確実なものにする、より洗練されたシナリオを考え出す必要があります。
プログラマーとテスターの両方がお互いに足を踏み入れる必要があります。これは、プログラマーがバグや欠陥を見つけるためにテスターに依存し、テスターが自分自身を甘やかしたくないためにユニットテストにあまり重みを与えなかった古い従来のアプローチとは異なります。彼らは欠陥を見つけた後に彼らの仕事が終わると思うので、技術的なものを学ぶことに。
ビヘイビア駆動開発
ビヘイビア駆動開発またはBDDは、テスト駆動開発の拡張機能です。
BDDは、その名前が示すように、その動作に基づいて機能を開発する方法を示しています。動作は基本的に、開発を担当するチームの全員が理解できる非常に単純な言語の例で説明されています。
BDDの主な機能のいくつかは次のとおりです。
- 動作を定義するために使用される言語は非常に単純であり、実装に関与する技術者と非技術者の両方のすべての人が理解できる単一の形式です。
- 3つのアミーゴ（プログラマー、テスター、PO / BA）が協力して要件を理解できるようにするプラットフォームを提供します。それを文書化するための共通テンプレートを決定します
- この手法/アプローチでは、システムの最終的な動作またはシステムの動作方法について説明しますが、システムの設計または実装方法については説明しません。
- 品質の両方の側面に重点を置いています。
- 要件を満たす
- 使用に適しています
なぜBDD？
まあ、私たちは欠陥を修正することを知っています/ バグ 開発サイクルの後の段階では、かなりのコストがかかります。製造上の欠陥の修正は、コードだけでなく、設計とその要件にも影響を与えます。私たちがするとき RCA（根本原因分析） どんな欠陥でも、ほとんどの場合、欠陥は実際には誤解されている要件に帰着すると結論付けます。
これは基本的に、要件を理解するための適性が人によって異なるために発生します。したがって、技術者と非技術者は同じ要件を異なる方法で解釈する可能性があり、それが誤った配信につながる可能性があります。したがって、開発チームの全員が同じ要件を理解し、同じ方法で解釈することが重要です。
開発作業全体が要件を満たすことに向けられ、集中されていることを確認する必要があります。あらゆる種類の「要件-ミス」の欠陥を回避するために、開発チーム全体がそれらを調整して、使用に適した要件を理解する必要があります。
BDDアプローチにより、開発チームは次の方法でこれを行うことができます。-
- 簡単な英語で要件を定義するための標準的なアプローチを定義する
- 要件を説明する定義例の提供
- 技術者（プログラマー/テスター）と非技術者（PO / BA /顧客）が協力して集まり、同じページにいて要件を理解して実装できるようにするインターフェイス/プラットフォームを提供します
BDDを実装する方法は？
BDDを実装するために市場で利用可能な多くのツールがあります。私はここでいくつか名前を付けています：
- きゅうり
- フィットネス
- コンコーディオン
- JBehave
- スペックフロー
例：
例を挙げてBDDを理解してみましょう。私の場合、私はガーキン（キュウリ）を使用しています：
認証されたユーザーのみがXYZサイトに入ることを許可したいという単純なケースを考えてみましょう。
Gherkinファイル（機能ファイル）は次のようになります。
特徴： テスト登録ポータル
シナリオの概要： ログインしている有効なユーザー
与えられた： お客様が登録ポータルを開きます
いつ： ユーザーはユーザー名を「」、パスワードを「」と入力します
次に： 顧客はフォームを表示できる必要があります。
例 ：
|ユーザー|パスワード|
| user1 | pwd1 |
| user2 | pwd2 |
簡単な英語を使用して、特定の要件がどのように文書化されているかを確認できます。 3つのアミーゴは連携して機能ファイルを設計でき、特定のテストデータをサンプルセクションに文書化できます。 BDDは、プログラマー、テスター、およびビジネスを1つのテーブルにまとめ、実装する機能の共通の理解を確立するための媒体を提供します。
BDDアプローチは、機能の開発サイクル全体を通じて顧客と開発者のコラボレーションが行われたため、労力とコストを節約し、本番展開後に欠陥がないかどうかを確認します。
開発チームは、これらの機能ファイルを利用して実行可能プログラムに変換し、特定の機能をテストできます。
どうやって？
さて、あなたはそのためにキュウリ/フィットネスを学ぶ必要があります！
受け入れテスト駆動開発
受け入れテスト駆動開発（ATDD）は、実装が実際に開始される前に、チーム全体が協力してエピック/ストーリーの受け入れ基準を定義する手法です。これらの受け入れテストは、適切な例やその他の必要な情報によってサポートされています。
ほとんどの場合、BDDとATDDは同じ意味で使用されます。 ATDDアプローチは、BDDアプローチで機能を記述する方法と同じように、Given-When-Then形式を使用して実装することもできます。
3つのアプローチの違いを簡単にまとめてみましょう。
- TDDはより技術的であり、機能が実装されているのと同じ言語で書かれています。機能がJavaで実装されている場合、JUnitを記述します テストケース 。 BDDとATDDは単純な英語で書かれていますが
- TDDアプローチは、機能の実装に焦点を合わせています。 BDDは機能の動作に焦点を合わせ、ATDDは要件のキャプチャに焦点を合わせます。
- TDDを実装するには、技術的な知識が必要です。一方、BDDとATDDは技術的な知識を必要としません。 BDD / ATDDの美しさは、技術者と非技術者の両方が機能の開発に参加できるという事実にあります。
- TDDは進化しているため、優れた設計の余地があり、品質の「要件を満たす」側面に焦点が当てられています。一方、BDD / ATDDは2に焦点を合わせていますnd「使用に適した」品質の側面
これらの手法はすべて、従来の開発方法論で使用されている「テストラスト」アプローチとは異なり、基本的に「テストファースト」アプローチについて説明しています。
テストが最初に書かれるので、テスターは非常に重要な役割を果たします。テスターは、広大な領域とビジネス知識を持っている必要があるだけでなく、3つのアミーゴの議論中にブレーンストーミングに付加価値を与えることができるように優れた技術スキルを持っている必要があります。
CI（継続的インテグレーション）やCD（継続的デリバリー）などの概念により、テスターはプログラマーとうまく連携し、開発と運用の分野に等しく貢献する必要があります。
charをintc ++に変更します
この議論をアジャイルの有名なテストピラミッドと要約しましょう。
このピラミッドの最下層は、単体テスト層で構成されています。この層は基礎層です。したがって、この層は堅固であることが重要です。ほとんどのテストはこのレイヤーにプッシュする必要があります。この最下層はTDDのみに焦点を当てています。
の中に アジャイル 世界では、ピラミッドのこの層をより強力で堅牢にすることに重点が置かれており、ほとんどのテストはこの層で行われることが強調されています。
ピラミッドのこのレイヤーで使用されるツールは、すべてXunitツールです。
ピラミッドの中間層はサービス層であり、サービスレベルのテストを説明します。このレイヤーは、アプリケーションのユーザーインターフェイスと下位レベルのユニット/コンポーネント間のブリッジとして機能します。このレイヤーは主に、UIからのリクエストを受け入れ、レスポンスを送り返すAPIで構成されています。 BDDおよびTTDDアプローチは、ピラミッドのこの層でアクティブです。
ピラミッドの中間層で使用されるツールは、Fitnesse、Cucumber、およびRobotFrameworkです。 。
ピラミッドの最上層は実際のUIであり、この層に含まれるテストの数が最も少ないことを示しています。つまり、この特定の層でのテストの労力は最小限である必要があります。機能のテストのほとんどは、ピラミッドの最上層に到達したときに完了しているはずです。
最上層で使用されるツールは– セレン 、 QTP 、およびRFT。
で少しずつ作業するので スクラム （スプリントと呼ばれます）、これらすべてのアプローチを手動で実装することは不可能です。これらのアプローチには、自動介入が必要です。この場合、自動化は非常に重要です。
実際、これらのアプローチは実際には自動化によって実行されます。すべてのスプリントの終わりに、新しい機能が追加されているため、以前に実装された機能が期待どおりに機能することが重要になります。したがって、 オートメーション ここでヒーローになります。
結論
記事の終わりまでに、テスターがTDD、BDD、およびATDD手法にどのように関与しているかについて学習している必要があります。
シリーズの第3部では、アジャイルの世界での自動化に焦点を当てます。
著者について： この記事はSTHの作者Shilpaによるものです。彼女は過去10年以上、インターネット広告、投資銀行、テレコムなどの分野でソフトウェアテストの分野で働いています。
このスペースを監視し続けて、さらに多くの更新を確認してください。
推奨読書
- TDDとBDD-例を使用して違いを分析する
- ソフトウェアテスターでモチベーションを維持する方法は？
- テスターのためのソフトスキル：コミュニケーションスキルを向上させる方法
- 書き込みと獲得-経験豊富なQAテスターのためのプログラム
- 開発者は優れたテスターではありません。あなたが言うこと？
- 初心者テスターのためのソフトウェアテストのアドバイス
- テスターにとってドメイン知識はどのように重要ですか？
- 間もなく288億ドルに達するグローバルソフトウェアテストビジネス