↩ テクノロジー開発スクラムチームのテスト戦略のベストプラクティス

スクラムチームのテスト戦略のベストプラクティス

スクラムからテスト計画を差し引いたものは、強化された POC に相当します。

現在、成功しているプロジェクトのほとんどは、アイデアの比較的小規模な評価である概念実証 (POC) から始まります。そこでは、選択したテクノロジと機能パックが最初に検証され、ビジネスユーザーに対する潜在的な影響が評価され、その後、証明されます。投資に値するものであれば、フルサイズのプロジェクトチームが、フル機能の製品を設計して提供し、本番環境に展開するために割り当てられます。

これはスクラムチームにとって完璧なケースです。チームはプロトタイプを迅速に開発し、スプリントごとに実質的な新機能を追加できます。一方、ビジネスユーザーは、リアルタイムで急速な進捗状況を確認し、わずか約 10 スプリントでアイデアがゼロから構築される様子を確認できます。これは強い印象を残しますが (いずれにせよ、POC の主なターゲットです)、重要な特性も 1 つあります。それは、テスト活動が最小限またはまったくなく、テストプロセスについて考えること自体がまったくの冗談になります。

スクラムチーム内ではこれは楽しいアクティビティではありません。人々は大抵、プロセスを遅らせるプロセスなしで開発するというアイデアを好むでしょう。これは基本的に、あらゆるテストアクティビティが暗黙的に行うことです。そして、エンドユーザーに最も印象を与える必要がある時間に、不必要な遅さを誰が望んでいるでしょうか?

POC 期間が終了した後、プロジェクトチームが同じ方法で継続した場合に起こる状態を、私は 強化版の POC と呼んでいます。これは、生産システムのサイズと機能が増大しているにもかかわらず、依然として POC のように動作する、つまり、次の機能を備えた完全な製品になりたいと考えているシステムです。隠れた欠陥や未調査のコーナーケースがあり、待っているのは深刻なクラッシュだけです。

しかし、そこに移行するまでは、ローリング問題の修正がさらに複雑になるため、チームはスプリントからスプリントへと安定したリリースを維持するのにさらに苦労することになります。

ここでは、私が同様の問題に対処していたときに機能することが証明されたいくつかのテクニックを紹介します。これらは、開発の進行を乱雑にすることなく、堅固なテストプロセスを実装するためのベストプラクティスとして挙げることができると考えています。なぜなら、それが私たち全員が望んでいることだからです。スクラムチーム。

コンテンツ 表示

痛みを分散する

不必要な煩わしさに対処する場合、痛みを分割すること以外にどこから始めるべきでしょうか:)。

これが意味するのは、あちこちの開発者からの小さな追加活動が必要になるものの、時間の経過とともに段階的に、しかし一貫して共通の目標に大きく貢献する計画を作成することです。

#1. 作成された新しいコードごとに単体テストコードを開発する

スプリント内で作成された新しいコードごとに単体テストの開発を「完了の定義」条項に追加するようスクラムチームを説得できた場合、長期的な観点から見ると、これは大きな成果となるでしょう。

理由は非常に明白です。

開発者はコードのさまざまな非標準パスについて考える必要があります。 –

このような単体テストは、自動化された DevOps パイプラインにプラグインして、開発環境またはテスト環境への展開ごとに実行できます。また、パイプラインからのメトリクスを簡単にエクスポートして、ソースコードに直接バインドされたテストケースのカバー率をビジネスユーザーにデモンストレーションするために使用できます。

最も重要なのは、すぐに始めることです。単体テストの開発開始が遅くなるほど、開発者がスプリント内に単体テストを追加するのは気が散るようになります。

既存のコードの単体テストを後方開発するには多大な労力がかかります。コードの一部は別の開発者によって作成されている可能性があり、すべてのコード部分でコードがどのように動作するかについての正確な知識は、現在の開発者には正確にはわかりません。場合によっては、変更したコードに単体テストを追加するほうが、スプリントの機能変更を開発するよりも時間がかかることもあります (これは、スプリント計画中に誰も計算していない状態です)。

#2. 開発環境で単体テストのすべての部分を実行するルーチンを作成する

新しいコードを Master ブランチにマージするためのプルリクエストを作成する前でも、開発環境でフィーチャーコードと単体テストコードの両方をテストすることが標準的なアクティビティとなります。これにより、次のことが保証されます。

単体テストコードは実際に各部分で動作します (最終的には、それは検証する必要がある単なる別のコードです)。このステップは完全にスキップされることがよくあります。単体テストが DevOps パイプラインに組み込まれた場合、最終的にはデフォルトでどこかで実行され、テストされると何らかの形で想定されています。ただし、これは問題をスプリントアクティビティの上位レベルに押し込むことにほかならず、通常、チームはコミットされたすべてのストーリーを完了するのに時間がかかり、ストレスが大きくなります。
新しい機能コードは、開発者によって基本的な機能がテストされます。明らかに、このテストでビジネス機能が完全に検証されることは期待できませんが、少なくともこのテストでは、コードが開発者が意図したとおりに動作することを確認できます (ビジネスロジックが完全に検証される可能性があるという事実は今のところ無視しています)。開発中に誤って理解される可能性があります)。

#3. コードをマスターブランチにマージした後に単体テストが実行されることが予想されます

ローカルブランチ (ブランチオーナー以外の誰も新機能を開発していない) に機能コードがあることと、プルリクエストの後に同じコードが機能し、マスターブランチにマージされることはまったく別のことです。

マスターブランチには他のスクラムチームメンバーからの変更が含まれており、競合が解決されてすべてが正常に見えたとしても、マージと競合の解決後のコードは基本的にまだテストされていないコードであり、最初に検証せずにさらに送信するのは危険です。まだ正常に動作しています。

したがって、ここで効果的であることが判明したのは、開発環境ですでに実行されている同じ単体テストを、マスターブランチコードバージョンから構築された環境でも実行するように単純に要求することです。

開発者にとって、これは自分の生活に組み込む必要がある追加のステップかもしれませんが、この場合、新しいものを発明する必要はなく、すでに一度実行されたことを再実行するだけなので、それほど労力はかかりません。

さて、ある特定の場合には、このステップをスキップできます。

DevOps パイプラインの自動単体テストは非常に包括的であるため、その上で実行される手動テスト全体をすでにカバーしています。

この状態を達成することは間違いなく実現可能ですが、私は現実の生活でそのような状態を経験したことがありません。開発者にとって、これほど詳細な自動化された単体テストを作成するのはおそらく時間がかかりすぎるでしょう。チームがこのアクティビティに多くの時間を費やすことは、スプリント内で配信されるストーリーの数に明らかな影響を与えるため、プロダクト所有者にとって容易に受け入れられなくなる可能性があります。

ただし、スプリントコンテンツを優先することは、単体テストを実行しない、または最小限に抑えることの言い訳にはなりません。これを行うことで、チームはコードに単体テストのカバレッジがあまりにも不足している状態に再び変換され、その後の遅れを取り戻すにはすでに手遅れになる可能性があります (繰り返しますが、単体テストを完了するための労力が実際のテストよりも高くなります)。スプリントのコード変更）。

これらすべての理由から、私は迷わずマスターコードバージョンで単体テストを再実行することをお勧めします。それがもたらす価値に比べれば、それは非常に少ない労力です。

これにより、マスターブランチがリリーステストフェーズに向けて準備ができているかどうかの最終チェックが行われます。また、これはほとんどの技術的なバグ (たとえば、ソースコードが正常に終了するまで正常に実行されないバグ) を見つけるのに役立ち、次のフェーズではビジネス機能の検証のみに集中できます。

機能テストの準備をする

これまでのすべてのテスト作業は、マスターブランチコードに技術的なバグがなく、エンドツーエンドの機能フローで問題なく実行可能であるという 1 つの特定の結論に達します。

これは 1 人で簡単にカバーできるフェーズであり、この人には技術的なバックグラウンドは必要ありません。

実際には、開発者とは関係なく、ビジネスユーザーがコードがどのように動作するかを機能的に認識している人がこれを実行する方がはるかに優れています。完了する必要がある主なアクティビティは 2 つあります。

#1. 機能テストを対象とした新しいスプリントストーリー

各スプリントは、理想的には、以前には存在しなかったいくつかの新しい機能 (スプリント目標の増分) をもたらすものであるため、それが検証されるものとします。新しいソフトウェアが、ビジネスユーザーが今それを手に入れて満足する程度に動作することを確認することが重要です。彼らは、少なくとも最後のスプリント全体でそれを楽しみにしていたのは明らかです :)。

（長い間）約束されていた機能がついにリリースされると発表されたのに、先日それが実際にはうまく機能していないことが判明するのは、とても悲しい経験です。

したがって、新しいスプリント機能を適切にテストすることが重要です。これを成功させるには、事前に重要なテストケースを関連する関係者 (製品所有者またはエンドユーザーのいずれかから) から収集し、内部のコンテンツに必要なすべてのテストケースのリストを作成することをお勧めします。スプリント。

一見すると大変そうに見えますが、私の経験から言えば、これも 1 人で完全に管理できます。スプリントはほとんどの場合非常に短いため (期間が 2 週間など短い)、スプリントには技術的負債のストーリー、ドキュメント、設計/スパイクのストーリーなどの追加アクティビティも含まれるため、とにかく新しいコンテンツが多すぎることはほとんどありません。

次に、主に目的の機能を検証することを目的としてテストケースが実行されます。結果に何らかの問題が発生した場合は、問題を迅速に解決するために、関連する開発者 (この特定の欠陥に関連する変更を所有する開発者) のみにアプローチします。

このようにして、開発者は機能テストに費やす時間を最小限に抑えながら、最も好きなアクティビティに集中できます。

#2. 回帰テストケースの実行

機能テストのもう 1 つの部分は、これまで動作していたすべての機能が次のリリース以降も動作することを確認することです。これが回帰テストの目的です。

回帰テストのテストケースは、定期的にメンテナンスされ、各リリース前に再検討されるのが最適です。具体的なプロジェクトの詳細に基づいて、それらをシンプルに保ちながら、非常にコアな機能の大部分と、システム全体を実行する重要なエンドツーエンドのフローをカバーすることが最善です。

通常、各システムにはさまざまな領域に関わるプロセスがあり、それらが回帰テストケースの最適な候補となります。

場合によっては、回帰テストはスプリントの新機能も暗黙的にカバーしています。たとえば、スプリントの新しいストーリーが既存のフローの特定の部分を変更している場合などです。

したがって、ほとんどの場合、新しいスプリントストーリーの機能テストと並行して回帰テストを完了することは、特にこれが各実稼働リリース前に定期的に実行され、実稼働リリースの周期が小さすぎない場合には、それほど複雑ではありません。

本番リリースの前に必ず品質保証テストを実行する

品質保証 (QA) テストは、運用環境にリリースする前の最終ステップですが、多くの場合、このテストは重要ではないためスキップされます。特にスクラムチームが新しいコンテンツに対して積極的に管理されている場合はそうです。

ビジネスユーザーでさえ、機能を維持したり、欠陥の数を低く抑えることには興味がなく、新機能に興味があると言うでしょう。しかし、繰り返しになりますが、時間が経つにつれて、これが最終的に開発チームのペースを落とさなければならなくなる主な理由であり、そうなるとビジネスユーザーはいずれにしても求めているものを手に入れることができなくなります。

QA テストは、スクラムチームの外部の人だけが実行する必要があります。理想的には、将来の本番環境に可能な限り近い専用環境で、ビジネスユーザー自身が実行する必要があります。あるいは、製品所有者がエンドユーザーの代わりに使用することもできます。

いずれの場合も、これは開発スクラムチームとのつながりがなく、エンドユーザーの観点から見たクリーンな機能テストである必要があります。これは、製品の最終的なビューを 1 つ提示し、スクラムチームの誰も予想していなかった方法で使用されることになります (まったく理想的なケースではありませんが、間違いなく起こり得ます)。土壇場で修正する時間はまだあります。

あるいは、期待がスクラムチームに十分に理解されていないことが明らかになる可能性もあり、その場合、少なくとも、実際の製品リリースのかなり前に、フォローアップ計画に同意することができます。これもまた理想的なケースではありませんが、製品リリースが成功したと報告した直後に失敗を認めるのと同様に、はるかに良いケースです。

ここから次はどこに行きますか？

これらのプラクティスを日々のスクラム作業に適用すると、実稼働リリースを遅らせたり、スプリント全体を次のリリースの準備だけに費やしたりすることなく、あるいはスクラムチームの全員に自分たちがやるべきことを強制することなく、より安定した予測可能なスプリントリリースの習慣を真剣に身につけることができます。つまり、スプリントの大部分を効果的に実行する方法があまり好きではない、または方法がわかりません。

しかし、確かにここで立ち止まる必要はありません。

ここで取り上げるトピックの 1 つは、パフォーマンステストの組み込みです。これらは無視されるか、不必要とみなされ、「スクラム活動の最適化」の最初のラウンドでスクレイピングされることがよくあります。しかし、定期的にパフォーマンスをチェックしない場合、実稼働システムが時間の経過とともにどのように進化することが期待できるのか、私は常に疑問を抱いていました。

1 つ上のレベルに進むということは、自動テストの導入も意味します。

自動テストの 1 つのグループ (パイプライン内の単体テスト) についてはすでに説明しました。ただし、完全に自動化された完全なエンドツーエンドの回帰テストを開発し、テスト環境に展開するたびに自動的に実行することができます。これにより、開発スクラムチームはさらに解放されますが、そのような自動テストを開発および維持するには専用のチームが必要になります。実稼働コードが変更されるたびに、既存の自動テストの一部が無効になる可能性があるため、パイプラインで動作し続けるためには更新する必要があるため、これは継続的な作業になります。これは少数の人だけがお金を払う努力ですが、開発スクラムチームにとってのメリットは大きいでしょう。

これらは、この記事の範囲をはるかに超えたトピックであり、スプリントウィンドウ内でテストを完了できるように、ここで説明した各テストタイプの適切なスケジュールとタイミングを把握します。次回も喜んで潜らせていただきます！