7

バックグラウンド

チームが新しいモバイル アプリ プロジェクトを組織するのを手伝おうとしています。個々のユーザー ストーリーごとに利害関係者と開発者の間の契約を形成する平易な英語の要件を把握するために、BDD ( BDD の定義も参照)に従うことを選択しました。

受け入れテストを使用して、各ユーザー ストーリーの要件を文書化します。受け入れテストは、スプリント計画の前に作成されます。開発者は、スプリント計画中にテストを改良して追加します。

受け入れ基準をルールのリスト (例: 入力の検証、デフォルト値など) として定義し、受け入れテストを Cucumber シナリオのリストとして定義します。モバイル テストにはCalabashを使用する予定です。

受け入れ基準/テストはより機敏であり、したがって、より正式な要件文書に対するより良いソリューションだと思います。

効果的な解決策を見つけたと思いますが、他の人が要件を収集して受け入れテストを作成する方法を理解したいと思います。

問題

Cucumberコミュニティでは、命令型と宣言型のテスト ステップについて議論があります。開発者は、成果物のユーザー ストーリーがどのようなものかを知っている必要があるため、私は必須に傾いています。

UI カップリング、別名脆弱なテストが問題になるとは思いません。UI をテストから分離する方法があります (例: page objects )。また、詳細な手順を用意しても、技術に詳しくない利害関係者が理解するのが難しくなるとは思いません (Web ブラウザーやモバイル デバイスの使用方法を知らない場合を除きますが、それは別の問題です)。

「受け入れテスト」という用語を流用している可能性があります。私の使用では、受け入れテストは単体テストと同じレベルのスコープではありません。私は受け入れテストを高度な統合テストと見なしています。

例

  • ゲストとして
  • ログインしたい
  • アプリの機能にアクセスする

命令テスト

  • シナリオ: 有効なログイン
    • 「ログイン」画面にいるとします
    • 「email」に「email@domain.com」と入力すると
      • そして、「password」に「password1」と入力します
      • そして「ログイン」をタップ
    • 次に、「ログイン成功」と表示されます

宣言的テスト

  • シナリオ: 有効なログイン
    • 有効なアカウントを持っている場合
    • その後、ログインできます

これらはどちらも同じ機能をカバーでき、後者は短いですが、ユーザー名、電子メール、または facebook/twitter/google/etc アカウントでログインできるかどうかはわかりません。実際にソリューションをコーディングするだけでは十分ではありません

質問

宣言的な手順で機能の要件をどのように把握しますか?

4

2 に答える 2

6

よく書かれた質問！

宣言的な手順で機能の要件をどのように把握しますか?

機能の要件は、ステップ定義に記録されています。

したがって、あなたの命令的な例では：

When I enter "email@domain.com" in "email"
And I enter "password1" in "password"
And I tap "login"

これは、次のように書き直すことで宣言型にすることができます。

Given I login using valid credentials

有効なアカウントに移動する手順 (つまり、「有効」の意味を定義する受け入れ基準の実装) は、このシナリオ ステートメントの手順定義で実装できます。同じことが反対のシナリオにも当てはまります。

Given I login using invalid credentials

ここでも、受け入れ基準を満たすこのシナリオを実装するためのステップは、基礎となるステップ定義で実装できます。

この宣言型のアプローチを取ると、機能からの (必須の) 要件 (つまり、実行する必要がある正確な手順) が失われることを意味し、機能ファイルを読み取るだけでは、これらのシナリオが何を行っているかをビジネスが正確に把握することが難しくなります。ただし、タスクを達成するための特定のステップがステップ定義に記録され、このステップ定義を多くの機能間で共有できるため、テストの脆弱性が軽減されます。

私の会社でも同じ懸念に取り組んでおり、場合によっては、宣言型よりも命令型を使用した方が良い場合や、その逆の場合もあります。たとえば、あなたの場合、「有効なアカウントがある場合」を構成する手順は多くの機能で使用される可能性があるため、宣言的にすることは合理的です。ただし、多くの異なる文字列値が入力される機能がある場合は、それらを命令的に記述するのがおそらく最善です。

「コース用馬！」

SO コミュニティからのこの質問に対する他の回答を見るのは非常に興味深いでしょう。

于 2013-10-21T23:09:42.730 に答える