Web アプリケーションを構築しており、テスト計画/テスト ケースと結果の作成を開始しています。
上記を作成するためにIEEE 829標準http://en.wikipedia.org/wiki/IEEE_829を見てきましたが、私のニーズには少しやり過ぎのようです。
自分のアジャイル プロジェクトで使用するテスト計画 (および関連するケースと GUI テストなどの結果) の例を持っている人はいますか?
どうもありがとう
Web アプリケーションを構築しており、テスト計画/テスト ケースと結果の作成を開始しています。
上記を作成するためにIEEE 829標準http://en.wikipedia.org/wiki/IEEE_829を見てきましたが、私のニーズには少しやり過ぎのようです。
自分のアジャイル プロジェクトで使用するテスト計画 (および関連するケースと GUI テストなどの結果) の例を持っている人はいますか?
どうもありがとう
ユーザーの視点からシステムの機能を説明する BDD シナリオを使用します。私たちはそれらを次のように言います:
Given <a context>
When <an event happens>
Then <an outcome occurs>
given、when、then はいくつでも使用できます。
Given <a context>
And <another context>
When <an event happens>
Then <an outcome occurs>
And <another outcome occurs>
When <another event happens>
Then <yet another outcome>.
通常、BA がこれらを作成しますが、開発者やテスターがアナリストやビジネス関係者と協力して作成するのを見たことがあります。
Cucumber、SpecFlow、または JBehave などの BDD フレームワークを使用してそれらを自動化するか、開発者が小さな DSL でそれらを実装することができます。ここに例があります。これは、小さな C# ペット ショップの GUI に対して実行される実際のシナリオです。
シナリオについて私が最も気に入っているのは、システムが行うべきさまざまなことについて、さまざまなコンテキストで結果が変わるかどうか、見逃された重要な結果が他にあるかどうかなどを尋ねることができることです。これらの会話は、新しい例を生成します。 .
すべてを自動化するわけではありませんが、システムがどのように動作するかを示し、何か問題を発見できる可能性が十分にあるように自動化しています。たとえば、1 つまたは 2 つの検証を表示する場合がありますが、すべてが検証されていることを確認するわけではありません。これは、単体テスト レベルで実行できます。
シナリオは、テスターが従うのに十分なほど読みやすく、コードを実装する前にシナリオを生成するため、より良い見積もりと高品質のコードも得られます. オフショア チームは、明確なシナリオと、それらについて質問する自由があることから大きな恩恵を受けています。