スクラムスプリントでのテストの適合方法と、スクラムでのユーザーストーリーの作成方法

私は、会社の新しいプロジェクトの開発チームのリーダーです。これは、会社がスクラムを使用する最初のプロジェクトです。ウォーターフォール/反復SDLCがあります。BAは要件のドキュメントを作成し、開発者とテストに引き渡し、開発者は開発を開始し、反復してテストにリリースします。テスターは、開発者が開発を継続するリリースだけでなく、現在のリリースのバグ修正をテストするのに長い時間がかかります。少し質問があります

1. 5つのストーリーがあるスプリントでは、いつテストのためにリリースしますか？開発者がストーリーを完了した直後か、すべてのストーリーが完了した後、スプリントの終了前に、テストに必要な時間を与えますか？
2. BAがユーザーストーリーを作成する場合、詳細を何にするか。従来、すべてのUIレイアウト、動作、テキストなどをまとめて仕様を作成するには、長い時間がかかります。私の質問は、実装可能でテスト可能なストーリーをどのように書くかです。
3. テストチームは技術的ではありません。スクラムのUIテストを自動化することの重要性。UIはWPFに基づいています。

アジャイル手法（TDD、コードレビュー、リファクタリングなど）を使用した確かな開発経験がありますが、スクラムは初めてです。

編集：反復によって、100の要件がある場合、100の要件がすべて完了するまで待つのではなく、30、35、35の要件を完了したときにテストにリリースできることを意味します。

テストが開発とは別の場合、2つの別々のスクラムチームがあります。片方の手をもう片方に動かすのは悪い考えです。

開発者は、この他のチームとは別に、独自のテストを作成する必要があります。この他の「テスト」チームを顧客として扱う必要があります。

スプリントで...いつテストのためにリリースしますか？

スプリントが完了したとき。完全に完了しました。つまり、独自の単体テストを実行し、確実に機能することを確認しています。開発チームが完了したら、それを他のチームにリリースして、「テスト」または「展開」、または組織で発生するその他のことを行います。

私の質問は、実装可能でテスト可能なストーリーをどのように書くかです。

それはチームごとに異なります。BAは開発チームの一部です。適切な量​​の詳細を取得するには、チーム（BAと開発者）として作業する必要があります。BAからチームの他のメンバーに適切な情報を提供するのはチームの努力です。

スクラムのUIテストを自動化することの重要性。

必須。UI開発には完全に必要です。開発者は、「テストチーム」に渡される前にすべてのテストを自分で行う必要があります。UIがある場合は、テストする必要があります。UIがない場合、自動UIテストは必要ありません。テストが必要であり、UIをテストする必要があります。自動テストは現在のベストプラクティスです。

一番下の行。個別の「テスト」チームと詳細をすべて書くBAは、スクラムにとって最適な組織ではありません。スクラムは、組織とプロセスを再考する必要があることを意味します。

私が提供する回答のほとんどは、ソフトウェア開発のアジャイル手法と反復ウォーターフォール手法に関連しています。スクラムは、たまたま人気のあるアジャイル実装です。

1. 通常のスクラムでは、スプリント全体で正式なテストを行う必要があるため、個別のテストフェーズはありません。開発者がユーザーストーリーを完了すると、QAリソースには既にテストケースが準備され、その時点でテストが開始されます。テストケースに合格すると、ユーザーストーリーを受け入れ、次のストーリーに進みます。すべてのユーザーストーリーが完了して承認されると、スプリントは終了し、次のストーリーを開始します。これはもちろん継続的インテグレーションに依存しているため、開発の変更はすぐにQAで利用できます。今後の開発は、TDDガイドラインに従って、回帰テストが可能な限り迅速かつ無痛であることを確認する必要があります。

2. BAがユーザーストーリーを作成することをお勧めしますが、より詳細かつ具体的な制御のために、ユーザーストーリーを正式な要件ドキュメントに添付できます。ユーザーストーリーは、役割ごとに1人のユーザーの観点から作成する必要があります。ユーザーの観点からニーズを表現しているため、ソフトウェアが現在そのニーズのすべての側面を満たしている場合、ユーザーストーリーは満たされています。ユーザーストーリーは、子ユーザーストーリーと割り当て可能なタスクで構成できます。複数のユーザーストーリーのタスクで重複する場合があります。

3. 自動化されたUIテストは良いことですが、個人的には、TDDメソッドに対するより多くの努力と、すべてのビジネスロジックの100％ユニットテストのカバレッジがより重要であると感じています。ほとんどのソフトウェア開発チームは、ビジネスロジックの100％のカバー率を達成できないようです。そのため、自動UIテストは、BLの単体テストの作成に使用できる貴重な時間の無駄になります。私の意見では、それは贅沢品であり、必要ではありません。

1. スクラムでは、各スプリントの最後に出荷可能なソフトウェアの増分を生成することになっています。その結果、スクラムはチーム全体または部門横断的なチームの概念を促進し、特定のユーザーストーリーを実現するために必要なすべてのスキルがチームに存在する必要があります。

   私の現在のプロジェクトでは、完全にテストされたストーリーが完了の定義の一部であるため、チームにテスターが組み込まれています。スプリントの最初の数日間、開発者は最初のユーザーストーリーの作業を開始しますが、テスターはテストシナリオを準備し、テストデータを設定します。ユーザーストーリーの1つの開発者が終了すると、すぐにテストします。

2. これは、スクラムIMOの最大の問題の1つです。実装可能でテスト可能なユーザーストーリーを得るために必要な仕様の適切な量を見つける必要があります。事前の分析、ドキュメント、および仕様が多すぎると、スプリントの過程で必然的に間違っていることが判明する厳格な計画になります。逆に、製品所有者によって明確に定義および表現されていないユーザーストーリーは、スプリント中に開発者とPOの間の通信帯域幅が飽和し、POがスプリントの途中でユーザーストーリーに関する決定を行う間、開発が遅れます。 。

   このケースでは、ユーザーストーリーの詳細の適切な量を1 /「〜として…」という形式の説明、および2 /一連の受け入れと定義しました。基準。UIのモックアップを事前に作成することはほとんどありません。スプリント計画中に発生する可能性がありますが、それらは後で破棄されるより多くのスケッチです。

3. 私の経験では、自動UIテストは非常に時間がかかり、非常に脆弱です。WPFでそれを行う方法はありますが、その方法を実行する前に、このようなテストの維持コストと利点を慎重に検討します。

短いイテレーションで作業すると、これらすべてのハンドオフがますます高価になります。愚かで単純なルールに従うことで、これらのコストを削減できます。バッチサイズを半分に削減し、作業方法を変更して快適にする、満足するまで繰り返す。

5階建てのスプリントの例を見てみましょう。チームが5つのストーリーすべてのコードを記述し、5つのストーリーすべてをテストすることに慣れている場合、バッチサイズは5ストーリーです。それを半分に切る。次のスプリントでは、3つの最も緊急のストーリーに最初に取り組み、できるだけ早くテストの準備をします。テスターはこれらの3つのストーリーをテストしているため、残りの2つのストーリーはテストの準備ができています。これはいくつかの成長の痛みを引き起こします。これをより快適にするために、作業方法を変更します。

たとえば、各ストーリーで一緒に作業する人が増えるので、ペアリングを増やして、それが着実に作業に役立つかどうかを確認します。または、おそらく、テスターはストーリー2で問題を見つけて、ストーリー5で作業しようとしているプログラマーの気を散らすので、次のスプリントでプログラマーとテスターが「最初のバッチのストーリーの1つをテストする方法プログラマーがミスを犯す可能性が低くなるため、テスターがテストで簡単にキャッチできます。

プログラマーがストーリーの次のバッチで作業している間に、ストーリーの小さなバッチをテストするテスターに​​関連する大きな問題を解決するには、いくつかのスプリントが必要になる場合があります。快適になったら、バッチサイズを再度半分にします。そしてまた。プログラマーがストーリーを使い終えたと信じているため、チームは1年ほどで快適にストーリーをテストし、おそらく途中でミスを少なくするでしょう。各ストーリーはより早く行われます。

もちろん、この時点で、チームが製品所有者から受け取るバッチ、またはチームが運用組織に出荷するバッチで同じことを実行できるようになりました。等々。この時点で、「BAがストーリーのためにどれだけ詳細に書き込む必要があるか」に取り組むことができます。問題。

ところで、テスターがターンアラウンドタイムを短縮できるようにするには、自動化の方法を学ぶことと、自動化を支援するプログラマーを組み合わせることで、自動化を採用する必要があります。バッチサイズを小さくしようとすると、これらの問題をいつ修正する必要があるかがわかります。本があなたにそれが必要だと言っているからといって、自動化を追加しないでください。

それがあなたのお役に立てば幸いです。

以下のようにいくつかの経験を共有したい、それがあなたに役立つことを願っています。

5つのストーリーがあるスプリントでは、いつテストのためにリリースしますか？開発者がストーリーを完了した直後か、すべてのストーリーが完了した後、スプリントの終了前に、テストに必要な時間を与えますか？

大きなユーザーストーリーごとに、多くのサブタスクに分割し、サブタスクが開発者によって完全に完了したら、すぐにテストのためにQCにリリースする必要があります。これらのサブタスクのテストが完了したら、欠陥を修正する必要があります。

BAがユーザーストーリーを作成する場合、詳細を何にするか。従来、すべてのUIレイアウト、動作、テキストなどをまとめて仕様を作成するには、長い時間がかかります。私の質問は、実装可能でテスト可能なストーリーをどのように書くかです。

スクラムでは、ストーリーを取り巻く会話が発生し、完了または静的であると予想されない限り、ユーザーストーリーは任意の形式である必要があります。単にユーザーストーリーと呼ばれる小さなストーリーは、よく理解されており、スプリント内で実装できます。ストーリーの優先度は、ROI、ビジネス価値、またはユーザーが重要であることに同意するその他のものに基づくことができます。これは、POによるアクティビティです。

テストチームは技術的ではありません。スクラムのUIテストを自動化することの重要性。UIはWPFに基づいています

スクラムで自動化テストを適用するのは非常に難しい作業です。すべての機能は不完全に実装されており、QCが何らかの自動テストツールによってテストケースを実装できるほど安定していないためです。回帰と呼ばれるスプリントに対して行う必要があります。