各スプリントで回帰テストをすると大変なのですがどうしたらいいですか？

Q: 各スプリントで回帰テストをすると大変なのですがどうしたらいいですか？

完成の定義という品質基準をスプリント開始前に定めて、スプリントではその品質を満たすようにしないといけません。 そもそもその基準を満たしていないものは、リリース判断の対象にすらならず、プロダクトバックログアイテムも完成とはなりません。 したがってテストは自動化し、コードの変更を行うたびに全てのテストを毎回自動で実行しリグレッションがないことを検証するといった活動が必要です。 スクラムでは自動化自体は定義されていませんが、毎スプリントでリリース判断可能なものをつくるためには事実上はテスト自動化が必須です。 なお、実際のリリースに際して必要なすべての品質をスプリント中に満たせるのであれば、スプリント中でもいつでもリリース可能となります。 一方でプロダクトの性質によっては数か月単位でのリリースに決まっていたり、リリースするには外部のセキュリティベンダーによるペネトレーション試験が必要だったりすることもあります。 こういったケースでは、リリース前に「リリーススプリント」と呼ばれるテスト期間をとることもあります。 ただし、スプリントで担保している内容と、実際のリリースで担保しなければいけない内容に差が多ければ多いほど、急な変化に対応したりはできなくなりますし、大きな品質問題が最後に見つかる可能性もあります。

完成の定義という品質基準をスプリント開始前に定めて、スプリントではその品質を満たすようにしないといけません。そもそもその基準を満たしていないものは、リリース判断の対象にすらならず、プロダクトバックログアイテムも完成とはなりません。したがってテストは自動化し、コードの変更を行うたびに全てのテストを毎回自動で実行しリグレッションがないことを検証するといった活動が必要です。スクラムでは自動化自体は定義されていませんが、毎スプリントでリリース判断可能なものをつくるためには事実上はテスト自動化が必須です。

なお、実際のリリースに際して必要なすべての品質をスプリント中に満たせるのであれば、スプリント中でもいつでもリリース可能となります。一方でプロダクトの性質によっては数か月単位でのリリースに決まっていたり、リリースするには外部のセキュリティベンダーによるペネトレーション試験が必要だったりすることもあります。こういったケースでは、リリース前に「リリーススプリント」と呼ばれるテスト期間をとることもあります。ただし、スプリントで担保している内容と、実際のリリースで担保しなければいけない内容に差が多ければ多いほど、急な変化に対応したりはできなくなりますし、大きな品質問題が最後に見つかる可能性もあります。