システムテストをアジャイルプロセスにどのように統合しますか?[閉まっている]

Question

アジャイル開発の古典的な説明には、反復の最後にリリース可能なコードがあります。リリース可能な製品を作成するためにさらにテストと検証を行う必要がある場合、それをプロセスにどのように統合しますか?

Answer 1

独自のプロセスを作成することを妨げるものは何ですか?もっと良いものが見つかったら...やるだけ。それがうまくいくなら、それを辛抱してください。そうでない場合は、他のことを試してください。敏捷性を求める場合、決まったプロセスはありません。
より頻繁に使用される用語は「出荷可能' コードはすべての反復の終わりに表示されます。つまり、エンド ユーザーに (共有からコピーしたり、CD/DVD を個人的に配布するための DLL 群として) 提供すると、ユーザーはそれを使用することで価値を得ることができます。そのようなコード すべての単体テスト (開発者) と受け入れテスト (顧客/QA/アナリスト) に合格している それは、それが「完了した」ために必要であるとみなされました！受け入れテストは、エンドツーエンドの顧客シナリオシミュレーションです。

「さらなるテストと検証」が何を意味するのかわかりません。他の「プレリリース」アクティビティも考えられます

• 「トレーニングカンファレンス」や関連コンテンツの作成などの特定の活動。
• お客様による導入がまれであるか、頻繁に実行できない場合は、リリースの 1 か月前にデモまたはベータ サイトに導入します。
• 見込み顧客/専門家/サービスは、噂に聞いていた新製品を実際に覗いてみることができます。

それを最後の反復のエンドポイントの最後に積み重ねるだけです (私のように特に悲観的な人は..過去の平均を取得します。早めにリリースすれば。イェーイ!) したがって、企業が、リリースに適した一連の機能の範囲を Iteration#14 で区切ると判断した場合は、Iteration#14 の終了後、ちょうど「n 週間追加」です。その時点では複雑な計算や不確実性はありません。重要なポイントは、 関係者や顧客と定期的に関わり、フィードバックを取り入れ、許容可能なレベルの品質を維持していれば、土壇場で驚くようなことは起こらないはずです。

必要に応じて、 ローリングスタートをする..つまり開発チームが反復 #13 に入ると、トレーニング チームが作業を開始します。2 週間の反復と仮定すると、1 か月になります。そして、最後のイテレーションで大量の機能が追加されないことを祈ります。したがって、イテレーション #14 から最大 2 週間後、すべての天体と組織の調整に従って、リリースと当然の休暇が得られるはずです。

Answer 2

まず、あなたが話しているテストの範囲を認識してください。 増加する プロジェクトが進行し、ソフトウェアの範囲や複雑さが増すにつれて。このため、この労力を反復に投入しようとしても、1 回または 2 回の反復では機能しません。イテレーションの快適なルールは、プロジェクトの速度によって決まる、各イテレーションの作業レベルが一定であることです。

この問題に対する解決策は、次の 2 つのうちのいずれかになります。自動化の有無にかかわらず。より高いテスト レベルでの自動化により、テストを実行する労力が軽減され、各反復の範囲や複雑さの段階的な増加のみに焦点が当てられるため、作業が再び反復内に収まるようになります。これは、たとえそれが私たちが望んでいることであっても、すべてのプロジェクトのコンテキストで常に達成できるわけではありません。高レベルのテスト自動化を過大評価することは、真剣に受け止めるべき落とし穴です。言い換えれば、十分な経験を積んだ探索的テスターがもたらすものを過小評価しないようにしてください。

自動化がなければ、問題はテスト管理に基づく問題に移行します。時間をずらして並行してテストを繰り返すことが、解決策の 1 つの候補です。たとえば、システム テスト タスクのテスト バックログを確立することを選択できます。このバックログは、開発反復と同じペースで管理されますが、最大 1 回の反復期間だけ遅延または時間シフトされます。これにより、テスターは独自のサンドボックスで独自の優先順位に従って新しいリリースに総合的に取り組むことができます。

開発者の反復バックログがテスターと協力して構築されるのと同様に、テスト反復バックログも開発者と協力して構築されることを推奨します。また、退屈な作業を自動化し、より探索的な方法で作業できるように、自動化の経験のあるテスト チームを推奨します。自動テストのポートフォリオは反復ごとに増加するはずです。また、開発者単体テストにアクセスし、テスト サンドボックス内のリリースで実行できる必要もあります。

このようにフェーズ外で作業しても、増大するテストの範囲や複雑さの問題が解消されるわけではありませんが、チームはバックログ項目の作成、優先順位の調整、一部の自動化、チェックリストの作成などを行っているため、その複雑さを管理するためのメカニズムが提供されます。彼らが次に何をすべきかを集団的に考えていることに基づいています。彼らは大きなアイテムに当たる可能性があります。

テスターが総合的に作業し、自動テストを通じて理解を深め、システムに関する知識を共有できる能力を維持することは、すべて努力する価値があると思われます。

Answer 3

各自動ビルド後の自動テストにより、少なくとも途中までは完了します。

Answer 4

システム テストをスプリント バックログ (スクラム内) または同等のものに追加します。

ユーザードキュメントも同様です。

Answer 5

通常、システム テストの実行は遅すぎて、アジャイル開発に緊密に統合できません。(これには例外があります。例:よく設計された一連のブラウザ テストは、一般的な単体テストよりもそれほど遅くは実行できません)。

統合の 1 つの方法は、夜間ビルドまたは継続ビルドを行うことです。これは常に実行され、すべてのテストをビルドして実行するには数時間かかる場合があります。ビルドがすべてのテスト (単体テスト + システム テスト) に合格すると、リリース可能になり、そのバイナリまたはソース コードのスナップショットを配布できます。アイデアは、x バージョンのバイナリ/コード スナップショットを用意し、それらを非同期で検証し、グリーン ビルドを提供することです。これは、自動システム テストと手動テストの両方で機能するはずです。