受け入れテストケースの作成
SCRUMプロセスにテストプロセスを統合しています。私の新しい役割は、後で自動化するために、Webアプリケーションの受け入れテストを書くことです。テストケースの作成方法についてはたくさん読んだことがありますが、複雑なWebアプリケーションのテストケースを作成するための実用的なアドバイスはありませんでした。
テストケースは短くする必要があります： CMSの例を取り上げます。短いテストケースは、保守と入力と出力の識別が容易です。しかし、長い一連の操作（たとえば、ドキュメントの追加、別のユーザーへの通知の送信、他のユーザーの返信、ドキュメントの状態の変更、ユーザーへの通知）をテストしたい場合はどうでしょうか。テストケースは完全なシナリオを表す必要があるように私にはむしろ思われます。しかし、これが明らかに複雑なテストドキュメントを生成する方法を確認できます。
テストは入力と出力を識別する必要があります：：動作が異なり、相互作用するフィールドが多数ある長いフォームがある場合はどうなりますか？すべてに対して1つのテストを作成しますか、それともそれぞれに1つのテストを作成しますか？
テストケースは独立している必要があります：しかし、アップロード操作のテストで接続操作が成功する必要がある場合、どのように適用できますか？そして、それはテストケースの作成にどのように適用されますか？各操作のテストを作成する必要がありますが、各テストは依存関係を宣言する必要がありますか、それとも各テストのシナリオ全体を書き直す必要がありますか？
テストケースは簡単に文書化する必要があります：この原則はアジャイルプロジェクトに固有です。この原則を実装する方法について何かアドバイスはありますか？
受け入れテストケースを書くのは簡単になると思っていましたが、自分がしなければならないすべての決定に圧倒されました（参考：私は開発者であり、プロのテスターではありません）。したがって、私の主な質問は次のとおりです。複雑なアプリケーションの保守可能な受け入れテストケースを作成するために、どのような手順またはアドバイスがありますか。ありがとうございました。
編集：質問を明確にするために：受け入れテストは要件から開始し、アプリケーション全体をブラックボックスと見なす必要があることを認識しています。私の質問は、テストドキュメントを記述し、テストケースを特定し、テスト間の依存関係に対処するための実用的な手順に関連しています...複雑なWebアプリケーションの場合
私の受け入れスイートでは、テクノロジー固有のコントロール（つまり、Webアプリケーションではcssを使用せず、フォームに入力する必要がある場合はHTML要素を使用しない）を使用せずに、実際の受け入れテストではなく、SUTをセットアップする手順の詳細を設定します
私は受け入れにキュウリを使用し、次のものを持っています
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つのステップなので、他のすべてが失敗した場合にのみ使用されます。
あなたが車を買いに行くとき、（あなたがそうである自動車整備士でない限り）あなたは一般にボンネットの下にあまり深く入りません。ホイールに座って、快適さ、使いやすさ、ルックス、サウンドなど、一般的なものを確認します。自動車が最初に手に入るようになった場合（少なくとも新しい自動車の場合）、それは一般に安全でよく構築されていると保証します（保証があり、自宅での作業を行い、仕様を確認したことになります） ...）。それでは、これが今後数年間運転したい車かどうかを確認します。
ソフトウェアと同じです。
矛盾する情報はイライラさせられ、一般化して特定の状況に適用することが難しい場合があります。エルゴ、あなたはあなたの文脈で最もうまくいくことをしなければならないかもしれません。
私は長いテストドキュメントの大ファンではなく、いくつかの小さなプロジェクトでビジュアルを非常に効果的に使用しています。やってみますか？テキストのみを使用する代わりに、フローチャート（または状態図などの他のUML図）のように？入力、出力、条件、ループ、レーン、状態、他のコンポーネントとの相互作用などを示し、基準に基づいて、それらが成功したか、失敗したか、転送されたか、その他（？）かを示します。
最初は少し労力がかかるかもしれませんが、長期的には正気を保つのに役立ちます。どの方法を選択する場合でも、それを扱う作業が多ければ多いほど、それをうまく利用できます。
HTH、そして頑張ってください！
KM
私はあなたがすでにいくつかの良い基準を釘付けにしたと思います。 2番目のポイントは、テストのスコープを定義するための良い方法です。また、エラー条件とバグ修正についてもテストすることをお勧めします（すべてのバグ修正には、少なくとも1つの新しい単体テストが付属していることをお勧めします）。今では圧倒されるように見えるかもしれませんが、ちょっと飛び込んで、少し経験を積んだ後で、優れたテストの原因を認識するのが簡単になります。