本日は、なぜマニュアルテストはまず上手く行きそして失敗するのか、自分の考えていることを書いてみたいと思う。
ソフトウェアテストの自動化は常識である。優れたエンジニアは自ら優れたテストを書き、その結果として優れた品質を担保し続ける。一方で、テスト実装を推進できていないプロジェクトに遭遇することもある。こうしたプロジェクトは、大抵何れかのフェーズで必ず品質問題に直面する。こうしたプロジェクトの軌道を修正するベストな方法は何であろうか。
マニュアルテストのはじまり
テスト自動化を推進できない理由の典型例が「新規案件に忙しすぎてテスト自動化を推進する工数がとれない」というものである。TDD 論者がこの説明を聞いたときに「忙しいからテストができないのではなくて、テストを自動化しないから忙しいのだ」と答える様子は想像に難くない。だがここでは、あえてこの議論には深く触れず、こうしたプロジェクトがどういう道のりをたどるのかを考えてみる。
開発者がテストを実装する時間がないという理由を聞いたマネジメントは、たいてい外部のテストチームにその品質管理を頼る。開発チームから上がってくる品質が信用に足らないから、テストチームは念入りに検査をしてくれと言った具合だ。
マニュアルテストの罠
マニュアルテストの怖いところは、ある一定の規模までは機能してしまうことである。以下の図に示すとおり、ある一定の範囲で障害を最小化できるスイートスポットが存在する。
リリースにあたって障害が多発する場合、おそらくリリースの頻度を下げて品質を担保しようとするだろう。変更をまとめてバッチサイズを大きくすることで、回帰試験の回数を減らして工数を抑える。そして、品証の時間を十分とることでしっかり準備しようという考え方だ。実際この戦略はある一定の規模まではうまくいく。
しかし、あるタイミングで破綻する。なぜなら一回の変更のサイズが増えれば増えるほど、システムの複雑性が指数関数的に増えるからである。2 つのシステムが相互にやり取りするシステムと、3 つのシステムが相互にやり取りするシステムの複雑性は線形比例にならない。リンクの数が指数的に増えるからである。
バッチサイズを大きくすることで確かに回帰テストの回数は減る。だがシステムの複雑さが加速度的に上がるため、より多くのバグが埋め込まれ、より発見が難しくなる。つまり、過去の成功体験にならって人員増強や試験期間の延長をしても対処ができなくなるのである。
罠から抜け出す
テストの自動化や CI/CD の利点は、工数やコスト削減の削減ではない。バッチサイズの最小化である。優れた IT 組織はこれをよく熟知しているため、テストの自動化と CI/CD に十分な投資を行っている。大きなプロダクトであればあるほど、小さく変更して頻繁にリリースする。そうすることでバグの埋め込みを防ぐのである。
ではマニュアルテストの罠にはまってしまったプロジェクトはどうするべきだろうか。残念ながら答えは一つしかないと思う。自動化を推進してバッチサイズを小さくしていくしかない。自動化に反対する人まずいない。問題は自動化が整うまでの暫定的処置を関係者と合意することだ。自動化を推進する間も開発を止めない方法を求められることもあるだろう。だが結局の所銀の弾丸はないのである。
罠から抜け出すには優れたリーダーシップが必要である。チームがあるべきテストの姿を推進するための工数を確保するために開発チームのリーダーは動かなければならない。ステークホルダーとコミュニケーションをし、ときにメンバーを守り、ひたすらに自動化を推進することが結果的に製品の成功への近道となるのである。
英文記事:
