スクラム チームのテスト戦略に関するベスト プラクティス
公開: 2023-01-05スクラムからテスト計画を差し引いたものは、ステロイドの POC に相当します。
現在、最も成功しているプロジェクトは、概念実証 (POC) から始まります。これは、選択されたテクノロジと機能パックが最初に検証され、ビジネス ユーザーへの潜在的な影響が評価され、実証された後、アイデアの比較的小規模な評価です。投資に値する価値があるため、フル機能の製品を設計および提供し、それを本番環境に展開するために、フルサイズのプロジェクト チームが割り当てられます。
これは、スクラム チームに最適なケースです。 チームはプロトタイプを迅速に開発し、スプリントごとに実質的な新機能を追加できます。一方、ビジネス ユーザーは、リアルタイムで急速な進歩と、わずか約 10 スプリントでアイデアがゼロから構築される様子を確認できます。 それは強い印象を残します (POC の主なターゲットです) が、1 つの重要な特性もあります。つまり、テスト活動が最小限またはまったくないことです。また、テスト プロセスについて考えるだけでも冗談です。
スクラム チーム内での作業は楽しいものではありません。人々は、プロセスを遅くするプロセスなしで開発するという考えを好むでしょう。 これは基本的に、テスト アクティビティが暗黙的に行うことです。 そして、エンドユーザーに最も感銘を与える必要がある時間帯に不必要な速度低下を望むのは誰でしょうか?
POC 期間が終了した後、プロジェクト チームが同じ方法で継続した場合に発生する状態は、私がステロイドで POCと呼ぶために使用するものです。重大なクラッシュを待つだけです。
しかし、そこに変換する前に、ローリングの問題の修正がより複雑になるだけなので、チームはスプリントからスプリントへと安定したリリースに追いつくのに苦労するでしょう.
私が同様の問題に対処していたときに機能することが証明されたいくつかの手法を次に示します。これは、開発の進行状況をあまり混乱させることなく、堅実なテスト プロセスを実装するためのベスト プラクティスとして挙げることができると信じています。スクラムチーム。
痛みを分散させる
不必要な煩わしさに対処するとき、痛みを分割するよりも他にどこから始めましょうか:)。
ここで私が言いたいのは、あちこちの開発者による小さな追加活動を必要とする計画を作成することですが、それは時間の経過とともに漸進的ではありますが一貫して共通の目標に大きく貢献するということです。
＃1。 作成された新しいコードの各部分の単体テスト コードを開発する
スクラム チームを納得させて、スプリント内で作成された新しいコードごとにユニット テストの定義の完了句の開発を追加することができれば、長期的な観点からは、これは大きな成果となります。
理由は明らかです。
開発者は、コードのさまざまな非標準パスについて考える必要があります。 –
- このような単体テストは、自動化された DevOps パイプラインにプラグインして、開発環境またはテスト環境へのすべてのデプロイで実行できます。 また、パイプラインからのメトリックを簡単にエクスポートして、ソース コードに直接バインドされたテスト ケースのカバー率をビジネス ユーザーに示すために使用できます。
最も重要なことは、すぐに始めることです。 単体テストの開発が遅れるほど、開発者がスプリント内にそれらを追加することに気が散ってしまいます。
- 既存のコードの単体テストを逆方向に開発するには、かなりの労力が必要です。 コードの一部は別の開発者によって作成されている可能性があり、すべてのコード部分でどのように機能するかについての正確な知識は、現在の開発者には明確ではありません。 場合によっては、変更されたコードに単体テストを追加すると、スプリントの機能変更を開発するよりも時間がかかることがあります (これは、スプリント計画中に誰も計算していない状態です)。
＃2。 開発環境で単体テストのすべての部分を実行するルーチンを作成する
新しいコードをマスター ブランチにマージするためのプル リクエストを作成する前であっても、開発環境で機能コードと単体テスト コードの両方をテストするのは標準的なアクティビティです。 これにより、次のことが保証されます。
- 単体テスト コードは実際に各部分で機能します (最終的には、検証する必要がある別のコードにすぎません)。 多くの場合、このステップは完全にスキップされます。 単体テストがとにかく DevOps パイプラインに接続されている場合、最終的に実行され、デフォルトでどこかでテストされると想定されています。 ただし、これは問題を上位レベルのスプリント アクティビティに押し込むことに他なりません。通常、チームはコミットされたすべてのストーリーを完了するための時間が少なくなり、ストレスが大きくなります。
- 新しい機能コードは、基本的な機能について開発者によってテストされます。 明らかに、このテストからビジネス機能が完全に検証されることは期待できませんが、少なくともこのテストでは、開発者が意図したとおりにコードが動作することを確認できます (今のところ、ビジネス ロジックが完全に検証されるという事実は無視します)。開発中に誤って理解される可能性があります)。
＃3。 マスター ブランチへのコード マージ後に単体テストの実行を期待する
ローカル ブランチ (ブランチの所有者以外は誰も新しい機能を開発していない) で機能するコードを持つことは 1 つのことですが、プル リクエストの後に同じコードが機能し、マスター ブランチにマージされることはまったく別のことです。
マスター ブランチには他のスクラム チーム メンバーからの変更が含まれており、競合が解決されて問題がないように見えても、マージおよび競合解決後のコードは基本的にまだテストされていないコードであり、最初に検証せずにさらに送信するのは危険です。それはまだうまく機能しています。
したがって、ここで効果的であることが証明されたのは、マスター ブランチ コード バージョンから構築された環境でも、以前に開発環境で既に行われた同じ単体テストを実行するように単純に要求することです。
開発者にとっては、生活に組み込む必要のある 1 つの追加ステップかもしれませんが、この場合、新しいものを発明する必要はなく、一度行ったことを再実行するだけなので、それほど労力はかかりません。
ここで、このステップは、ある特定のケースではスキップできます。
- DevOps パイプラインの自動単体テストは非常に包括的であるため、その上で実行される手動テスト全体を既にカバーしています。
この状態に到達することは間違いなく実現可能ですが、私は実際にそのような状態を経験したことはありません. 開発者がこのような非常に詳細な自動化された単体テストを作成するには、おそらく時間がかかりすぎるでしょう。 スプリント内で配信されるストーリーの数に明確な影響を与えるため、チームがこの活動に多くの時間を費やすことは、製品所有者にとって簡単に受け入れられない可能性があります。
ただし、スプリント コンテンツの好みは、単体テストを実行しないこと、または単体テストを最小限に抑えることの言い訳にはなりません。 これを行うことで、チームはコードが単体テストのカバレッジを欠いているような状態に再び変換され、追いつくには手遅れになる可能性があります (ここでも、単体テストを完了するための労力は実際のスプリントのコード変更)。
これらすべての理由から、ためらうことなくマスター コード バージョンで単体テストを再実行することをお勧めします。 それがもたらす価値と比較して、それは非常に低い努力です。
リリース テスト フェーズのマスター ブランチの準備ができているかどうかの最終チェックを行います。 また、ほとんどの技術的なバグ (たとえば、ソース コードが最後まで正常に実行されるのを妨げるバグ) を見つけるのに役立ち、次のフェーズではビジネス機能の検証のみに専念することができます。
機能テストの準備
これまでのすべてのテスト活動は、1 つの特定の結論につながります。つまり、マスター ブランチ コードには技術的なバグがなく、エンド ツー エンドの機能フローで問題なく実行できます。
これは 1 人で簡単にカバーできるフェーズであり、この人は技術的なバックグラウンドを持っている必要さえありません。
実際には、開発者とは関係がなく、ビジネス ユーザーがコードの動作をどのように期待するかを機能的に認識している誰かがこれを実行する方がはるかに優れています。 完了する必要がある主なアクティビティは 2 つあります。
＃1。 機能テストを対象とした新しいスプリント ストーリー
各スプリントは、理想的には、以前は存在しなかったいくつかの新しい機能 (スプリントの目標の増分) をもたらすものであり、したがって検証される必要があります。 ビジネスユーザーが少なくとも最後のスプリント全体を明らかに楽しみにしていたので、新しいソフトウェアが今それを持っていることに満足できる程度に機能することを確認することが重要です:)。
(長い間) 約束されていた機能が最終的にリリースされると発表されたとき、それが実際にうまく機能しないことを先日知るだけで、とても悲しい経験です。
したがって、新しいスプリント機能を適切にテストすることが重要です。 これを成功させるには、重要なテスト ケースを事前に関連する利害関係者 (製品所有者またはエンド ユーザーからも) から収集し、内部のコンテンツに必要なすべてのテスト ケースのリストを作成することをお勧めします。スプリント。
これは一見圧倒されるように見えるかもしれませんが、私の経験からすると、1 人で完全に管理できるものです。 スプリントはほとんどが非常に短いため (2 週間という短い期間など)、スプリントには技術的負債の話、ドキュメント、設計/スパイクの話などの追加のアクティビティも含まれているため、新しいコンテンツが多すぎることはほとんどありません。
次に、目的の機能を最も重要に検証することを目的として、テスト ケースが実行されます。 結果に問題が発生した場合は、関連する開発者 (この特定の欠陥に関連する変更を所有している開発者) のみにアプローチして、問題を迅速に解決します。
このようにして、開発者は機能テストに関連する時間を最小限に抑え、最も好きな活動に集中することができます。
＃2。 回帰テスト ケースの実行
機能テストのもう 1 つの部分は、これまで機能していたすべての機能が次のリリース後も機能することを確認することです。 これが回帰テストの目的です。
リグレッション テストのテスト ケースは、リリースごとに定期的に維持および再検討される場合に最適です。 具体的なプロジェクトの仕様に基づいて、それらをシンプルに保ちながら、システム全体で実行されるコア機能と重要なエンド ツー エンド フローの大部分をカバーすることが最善です。
通常、各システムには多くの異なる領域に関係するプロセスがあり、回帰テスト ケースの最適な候補です。
場合によっては、たとえば、スプリントの新しいストーリーが既存のフローの特定の部分を変更している場合など、リグレッション テストが暗黙のうちにスプリントの新しい機能もカバーすることさえあります。
したがって、ほとんどの場合、新しいスプリント ストーリーの機能テストと並行して回帰テストを完了することは、特にこれが各製品リリースの前に定期的に行われ、製品リリースの周期が小さすぎない場合は、それほど複雑ではありません。
すべての製品リリースの前に品質保証テストを実行するよう主張する
品質保証 (QA) テストは、本番環境にリリースする前の最終ステップであり、多くの場合、このテストは重要ではないためスキップされます。 特に、スクラムチームが新しいコンテンツに対して積極的に管理されている場合.
ビジネス ユーザーでさえ、新しい機能に関心があり、機能を維持したり、欠陥の数を低く抑えたりすることにはあまり関心がないと言うでしょう。 しかし、繰り返しになりますが、時間が経つにつれて、これが開発チームが最終的に速度を落とさなければならない主な理由となり、いずれにせよビジネス ユーザーが求めているものを手に入れることができなくなります。
QA テストは、スクラム チームの外部の人々によってのみ実行されます。理想的には、将来の本番環境にできるだけ近い専用環境で、ビジネス ユーザー自身によって実行されます。 または、製品所有者はここでエンド ユーザーを置き換えることができます。
いずれにせよ、これは、開発スクラム チームとのつながりがなくても、エンド ユーザーの観点からはクリーンで機能的なテストである必要があります。 これは、製品の最終的なビューを 1 つ提示し、おそらくスクラム チームの誰も予想していなかった方法で使用されます (まったく理想的なケースではありませんが、確実に発生する可能性があります)。 土壇場で修正する時間はまだあります。
あるいは、期待がスクラム チームによって十分に理解されていなかったことが明らかになる可能性があります。そのような場合、少なくとも、実際の製品リリースのずっと前に、フォローアップ計画について合意することができます。 これも理想的なケースではありませんが、製品リリースの成功を報告した直後に失敗を認めるのと同じように、はるかに優れています。
ここから次はどこへ？
これらのプラクティスを毎日のスクラム作業に適用すると、本番リリースを遅らせたり、次のリリースの準備だけにスプリント全体を費やしたりすることなく、さらにはスクラム チームの全員に何かを強制することなく、より安定した予測可能なスプリント リリースの習慣を真剣にもたらすことができます。とにかく、スプリントの大部分で効果的に行う方法が本当に好きではないか、わかりません。
しかし、確かにここで停止する必要はありません。
パフォーマンス テストの組み込みは、ここで挙げる 1 つのトピックです。 それらはしばしば無視されるか不要と見なされ、「スクラム活動の最適化」の最初のラウンドでスクレイピングされます。 しかし、パフォーマンスを定期的にチェックしていない場合、生産システムが時間の経過とともにどのように進化すると期待できるかについて、私は常に疑問を抱いていました.
レベルが 1 つ上がるということは、自動テストの導入も意味します。
自動テストの 1 つのグループ (パイプラインでの単体テスト) については既に説明しました。 ただし、テスト環境にデプロイするたびに、完全に自動化され、実行される完全なエンド ツー エンドの回帰テストを開発できます。 これにより、開発スクラム チームはさらに解放されますが、そのような自動化されたテストを開発および維持するには、専任のチームが必要です。 本番コードが変更されるたびに、一部の既存の自動テストが無効になる可能性があるため、パイプラインで作業を継続するには更新する必要があるため、これは一定の作業になります。 喜んでお金を払ってくれる人はごくわずかですが、開発スクラム チームにとっては大きなメリットがあります。
これらは、この記事の範囲をはるかに超えたトピックであり、ここで言及されている各テスト タイプの適切なスケジュールとタイミングを把握することで、スプリント ウィンドウ内で実行できるようにします。 次回も喜んで飛び込みます！