テストをスクラムプロセスにどのように統合しますか？
これは本当に私を困惑させています。 「完了の定義」があり、開発「完了」、単体テスト「完了」、開発テスト「完了」が含まれています。ただし、「完了」する必要があるユーザー受け入れテストもありますが、企業はユーザーのストーリーがいつ完了するかを知り、ユーザーが何かを確認できるようにしたいと考えています（リリースまで、uatは優先事項ではありません）。しかし、これは最初の完了（ユーザーストーリーを渡す場所）の外側なので、どのように完了したと言えるでしょうか。そして、これは推定にどのように適合しますか？
テストとスクラムプロセスの統合に関する情報はどこにありますか？これを読む必要があると思います...
しかし、ビジネスはユーザーのストーリーがいつ完了するか知りたい
顧客がそれを完了したと言うまでそれは行われません。「完了」の他の定義は妄想です。ユーザー受け入れテストareユーザーストーリーの成功基準：「管理ストーリー」ではなく「ユーザーストーリー」と呼ばれるのはこのためです。
通常、doneの定義には、統合テスト、受け入れテスト、ドキュメント（開発者向けとユーザー向けの両方）など、含めている以上のものが含まれます。単体テストに合格したら、新しい機能/コンポーネントを統合して、統合テストを実行できます。機能が統合されたら、受け入れテストを実行します。受け入れテストに合格すると、ドキュメントに最近の変更が反映され、機能が完成したことを確認できます。 1つの問題は、受け入れテストをリリースの優先順位にするのではなく、ストーリーの完了を検証および検証する優先順位にすることです。
見積もりに関する限り、見積もりには、ユーザーストーリーの検証から受け入れテストまでのすべてを含める必要があります。ユーザーストーリーを完全に完了、統合、検証、および検証するために必要なアクティビティとタスクのすべてを考慮に入れていない場合、見積もりはそれほど大きな価値をもたらしません。作成とテストはかなり単純な機能かもしれませんが、現在の設計と統合するのは非常に難しいため、他の機能をリファクタリングして再テストする必要があります。これを考慮しないと、速度追跡がオフになります。
ユーザーまたは適切な管理者と一緒に座って、この問題をさらに詳しく検討することをお勧めします。プロフェッショナルソフトウェアの開発とは、ユーザーストーリーを含むテストを行うことです。
これを優先する必要があります。問題に対処せずに、より多くのコードを書き続け、より多くの機能を提供する方が常に簡単です。ただし、これは重要なソフトウェアではなく、QAプロセスの一部が機能していない場合に頼ることができます。
プロセスと長期的なメリットに焦点を当てます。 「オイルの交換には時間がかかります」けれども、いつまでも、または突然、それを延期することはありません。ある日、あなたは厄介な驚きを得ます！したがって、ソフトウェア開発プロセスの一部として、メンテナンス、テストなどのスケジュールを立てます。既存のシステムを変更しようとしているので、プロセスを開始するために、これを少し正式にすることをお勧めします。現在の問題（人々が防御し質問する）ではなく、利益（人々は聞きたい）に焦点を当てます。
組織が専門的なソフトウェア開発について完全に理解していない場合は、それらを教育するか、そうである別の場所を探すことができます。
私が「推奨」することの1つは、自動テストを実装することです。例えば; Windowsフォーム、C＃、またはWPFでテストする場合は、テストに White.Core を使用します。これにより、新しい実装、ビルド、機能をできるだけ早くテストできます。
私はオートメーションエンジニアとして働いており、C++/C＃でWhite.Coreを使用しながら、GUIをテストしながら、開発が終了する前に開発者の修正を検証しています。
doneの異なる状態間の切断は、通常、開発者が完全にコードを非プロジェクトリソースに引き渡すことができると信じたがっているプロジェクト管理の捏造です UATの場合は次に進みます。
これはスクラムではありません。これはアジャイルではありません。これはアジャイルアンチパターンです。
特定のユーザーストーリーに対して「完了」の状態は1つだけあり、それはAcceptedです。スプリントは[〜＃〜] not [〜＃〜]スプリントで割り当てられたすべてのユーザーストーリーがそのスプリントの範囲外にプッシュされるか、受け入れられるまで続きます。
これで、開発者は完全になり、ユーザーストーリーはUATの準備ができていることを意味しますが、ユーザーストーリーが受け入れられるまで、開発者は実際にはフックから外れていません。開発者がスプリントの終了前に対処する必要があるUAT。
ユーザーストーリーの推定では、設計、ドキュメント、実装、およびすべての種類のテストのすべてのフェーズを考慮する必要があります。 QAまたはUATを実行するエンティティは、スプリント計画中のプロジェクトリソースである必要があります。