浅黄氏がみつけた自動テストが失敗する要因とは？
続いて浅黄氏は、自動テストが継続できなかった失敗事例2つを紹介し、テストオートメーションサークルにあてはめた。
失敗事例は以下の表の通り。
| テスト対象 | テストタイプ | テストケース数 | 実行トリガー | UI | |
|---|---|---|---|---|---|
|
事例 5 |
BtoB Webシステム（IoT） | 機能テスト | 60 | デベロッパーが必要な時 | Webブラウザ（Chrome） |
|
事例 6 |
BtoC Webシステム（管理系） | 機能テスト | 45 | Merge時選択 | DockerChrome |
問題はベースだった。事例5の場合は開発チームとテストチームの責任範囲が違っていて、お互いの仕事に興味を持てない状態が続いていた。事例6も同じようにチーム内でのテストに対する興味が薄かった。
浅黄氏はこれまでの経験から、テストオートメーションサークルの中心のコアから外側に行くに従って物事を決めていくとうまくいくと説明した。たとえば、ツールの導入はアーキテクチャに属するが、これを目的にすると、何のために行うかがわからないため、うまくいかない。最初にツールが決まっていてもいいのだが、「なぜ自動テストをするか」をまず確定しておきたい。そして、次のコンセプトでは戦略や範囲を決めることで、その先のアーキテクチャにおいて採用するツールの選定がしやすくなり、モニタリングとコントロールもうまく機能する。
しかし、このような手順で準備しても失敗するケースはある。浅黄氏は、アーキテクチャ層と、モニタリングとコントロール層との間に深い溝が生じることがあると指摘した。それぞれを担当するメンバーの責任範囲が異なる場合が多く、お互いに関心を持てなくなってしまうことが多いのだ。自動テストを機能させるには、そのベースが非常に重要となる。
浅黄氏は、ベースを構成する要素を示し、なかでも人的リソースとチーム、文化の調和が重要だと唱えた。開発者やSRE、インフラ、運用など、関係する人々のコラボレーションがうまくいかなければ、自動テストの文化も育たないのだ。
