受け入れテストケースの作成

SCRUMプロセスにテストプロセスを統合しています。私の新しい役割は、後で自動化するためにWebアプリケーションの受け入れテストを作成することです。テストケースの作成方法について多くのことを読みましたが、複雑なWebアプリケーション用のテストケースを作成するための実用的なアドバイスを提供してくれる人はいませんでした。

• テストケースは短くする必要があります。CMSの例を取り上げます。短いテストケースは、保守が容易で、入力と出力を識別するのが簡単です。しかし、長い一連の操作（たとえば、ドキュメントの追加、他のユーザーへの通知の送信、他のユーザーの返信、ドキュメントの状態の変更、ユーザーへの通知など）をテストする場合はどうでしょうか。むしろ、テストケースは完全なシナリオを表す必要があるように思えます。しかし、これにより、明らかに複雑なテスト文書がどのように生成されるかがわかります。

• テストでは、入力と出力を特定する必要があります。：動作が異なる、相互作用するフィールドが多数ある長いフォームがある場合はどうなりますか。すべてに対して1つのテストを作成しますか、それとも1つのテストを作成しますか？

• テストケースは独立している必要があります。しかし、アップロード操作のテストに接続操作の成功が必要な場合、どのように適用できますか？そして、それはテストケースの作成にどのように適用されますか？各操作に対してテストを作成する必要がありますが、各テストはその依存関係を宣言しますか、それとも各テストのシナリオ全体を書き換える必要がありますか？

• テストケースは、軽く文書化する必要があります。この原則は、アジャイルプロジェクトに固有のものです。それでは、この原則を実装する方法について何かアドバイスはありますか？

受け入れテストケースの作成は簡単だと思っていましたが、私がしなければならないすべての決定に圧倒されました（参考：私は開発者であり、プロのテスターではありません）。私の主な質問は次のとおりです。複雑なアプリケーションの保守可能な受け入れテストケースを作成するために、どのような手順またはアドバイスがありますか。ありがとうございました。

編集：私の質問を明確にするために：受け入れテストは要件から開始し、アプリケーション全体をブラックボックスと見なす必要があることを認識しています。私の質問は、テストドキュメントを作成し、テストケースを特定し、テスト間の依存関係に対処するための実用的な手順に関するものです...複雑なWebアプリケーションの場合

私の受け入れスイートでは、技術固有のコントロールを使用することから遠ざかりました。つまり、実際の受け入れテストではなくSUTを設定する手順でフォームに入力する必要がある場合、Webアプリケーションはcssを使用しないでhtml要素を使用しないでください

私は受け入れのためにキュウリを使用し、次のものを持っています

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

この例はWebアプリケーションによって返されますが、受け入れテストではなくSUTのセットアップに手順が使用されるため、テストを使用してデスクトップアプリケーションに対してテストできます。

このテストは、購入の最後に行われます

生成->確認->支払い->領収書の印刷

上記のテストは支払いステップに対するものであり、他のテストで他のステップが設定されます。これは、アプリケーションがデータまたはHTTPアクションでこれらの状態に設定できるためです。この場合、支払いは確認ステップを行い、確認はステップが少し壊れやすいようにステップを生成します

最初に定義する必要があります 受け入れテスト。

あなたが説明しているのは 統合またはシステムテストです。

したがって、ウィキペディアの定義に100％同意するわけではありませんが、それらはまだほとんど有効です。

基本的に受け入れテストの目的は、構築したソフトウェアを利用する「ビジネス」プロセスが実際に意図したとおりに機能し、目的に合っていることを、実際のデータで検証することです。そのため、単体テストやその他のテストケースのようなテストケースを作成することはありません。まったく同じ方法で設計されることは想定されていません。

尋ねる質問は、「システムの使用方法」です。そのため、使用されるはずの方法でテストしてみましょう。もちろん、今ではエンジニアリングの帽子をかぶって、ビジネス要件を宗教的に順守してテストケースを導き出します。これは、ビジネス要件が十分に書かれていることを前提としています。

そうでない場合、手遅れではないので、ユーザーまたはその代表者（およびビジネスアナリストと技術設計者）と一緒に座って、ソフトウェアがビジネス用語で提供するものを書き留める必要があります（これは少なすぎて遅すぎるという明らかな警告がありますが、遅らせることは決してしないよりは良いことです-もちろん、新しい機能を導入しないでください）。これが、テストケースになります。

それを回避するもう1つの方法（このようなドキュメントがある場合）は、ユーザーマニュアルを参照することです。これは実際のビジネス要件から削除された1つのステップなので、他のすべてが失敗した場合にのみ使用されます。

あなたが車を買いに行くとき、あなたは一般的にボンネットの下にあまり深く入りません（あなたがそうである自動車整備士でない限り）。ホイールに座って、快適さ、使いやすさ、外見、音などを確認するだけです。つまり、一般的なものです。車が最初に手に入れられた場合（少なくとも新しい車の場合）、一般に安全でしっかりと構築されていることを保証します（保証があり、家事をして仕様を確認しました） ...）。それで、あなたはこれがあなたが今後数年間運転したいと思う車であるかどうかを確認します。

ソフトウェアについても同じです。

矛盾する情報はイライラさせられる可能性があり、一般化して特定の状況に適用することは困難です。エルゴ、あなたはあなたの文脈で最もうまくいくことをしなければならないかもしれません。

私は長いテストドキュメントの大ファンではなく、いくつかの小規模なプロジェクトでビジュアルを非常に効果的に使用しています。やってみて？テキストのみを使用する代わりに、フローチャート（または状態図などの他のUML図）のように？入力、出力、条件、ループ、レーン、状態、他のコンポーネントとの相互作用などを示し、基準に基づいて成功、失敗、転送、その他（？）を示します。

最初は少し手間がかかるかもしれませんが、長期的には正気を保つのに役立つかもしれません。どの方法を選択したとしても、より多くの作業をすればするほど、より良い結果が得られます。

HTH、そして幸運を！

KM

すでにいくつかの良い基準を打ち出していると思います。2番目のポイントは、テストのスコープを定義する良い方法です。また、エラー条件とバグのテストもお勧めします（すべてのバグ修正には、少なくとも1つの新しいユニットテストが付属することをお勧めします）。今では圧倒的に思えるかもしれませんが、ただ飛び込んで、少し経験を積んだ後、良いテストに役立つものを認識するのが簡単になります。