記録用ブログ

個人的な記録のためのブログ。主にソフトウェアテストの話題。

テストを減らさなくてはならないときに考えること

コスト等の都合で、特定の期限までに行うテストを減らさなくてはならない場合によく考えていることを、整理してみる。

  • 実施タイミングを変更できるテストはないか?

    • リリース直後は使われない機能やシナリオのテストを後回しにする
  • テスト対象を限定できないか?

    • 開発の目的やテスト対象ソフトウェアの存在意義と直結しない機能やシナリオのテストをなくす、減らす
    • リスク、特にプロダクトリスクが低い部分のテストをなくす、減らす
    • ブラックボックステストの場合は、ホワイトボックスで考えた時に関係ないといえる部分のテストをなくす、減らす
  • 網羅基準を変えられないか?
    • 同値分割のズームアウトをする、テストの抽象度合いを調整する
    • いわゆる正常系のテスト(システムや機能が持つ目的を達成できるテスト)以外をなくす、減らす
  • 他で同様のテストをしていないか?
    • システムテストと受入テストで重複部分があれば、なくす、減らす
      • 重複を安易に削ると、テストの目的、テストに求められる役割を果たせなくなることがあるので注意
  • 他のテスト、特により軽量にできるテストで代替できないか?
    • 入力値のバリエーションの網羅的な確認はユニットテストや狭い範囲での統合テストで行い、システム全体を対象にするテストでは検証しない
      • 似ているテストだと思って安易に削ると、テストの目的、テストに求められる役割を果たせなくなることがあるので注意


大体の場合は、どれか1つではなく、組み合わせて考えることが多い。

いずれを採用するにしても、ステークホルダーの期待値マネジメントは必須。このテストを減らしたときに何が起こるか?を説明しなくてはならない。
いずれを採用するか決める際は、削減しなければならないテストの規模、求められる品質レベル、他のテストやレビュー、プロセス、チームの状態を考慮する。