自動テストをとりまく要素から見た、成功のポイント
ヒューマンクレストは、ソフトウェアテストを専業とする企業。自動テストを中心に、継続的なリファクタリング支援、脆弱性診断、負荷テストなどのソリューションを提供している。浅黄氏はこの10年で機能テスト、リグレッションテスト、APIテストなど、70件の自動テストのプロジェクトに携わってきた。それらには組織に定着したもの、継続しなかったものがあるとし、成功事例と失敗事例を共有した（本講演で対象となるのはUIやサービスのテストで、Unitテストは対象外）。
浅黄氏が示した成功事例は以下の表のとおり。
| テスト対象 | テストタイプ | 実行トリガー | UI | |
|---|---|---|---|---|
| 事例1 | BtoB Webシステム（グループウェア） | シナリオテスト（40シナリオ） | 定期実行 毎日0時 | PCブラウザ（Chrome、firefox、Edge） |
| 事例2 | BtoC Web、スマホ向けシステム（HR系） | シナリオテスト（30シナリオ） | 定期実行 毎日8時、14時 | PCブラウザ（Chrome）、スマホブラウザ（Chrome、Safari）、スマホアプリ |
| 事例3 | BtoC スマホアプリ | 機能テスト（26ケース）→チェックポイント数百箇所 | 定期実行 毎日0時,12時 | スマホ（Android、iPhone） |
| 事例4 | BtoB Webシステム（リアルエステート） | 機能テスト（260ケース） | Push時 | Webブラウザ（DockerChrome） |
これらの事例の解説にあたり浅黄氏は、自動テストを取り巻く要素を整理した図「Test Automation Circles（テストオートメーションサークル）」を提示した。
テストオートメーションサークルの中心には「なぜテストをするのか？」というコア（目的）が置かれ、その周りには、「どんなテストをするのか？」というコンセプト（戦略や設計、スコープ）がある。その外側には「何で実現するか？」のアーキテクチャ（環境、フレームワーク、ツール、CI/CD）があり、さらに外側にはモニタリングとコントロール（実現された自動テストの実行、結果分析、レポーティングなど）がある。そして、それらはベース（チームのリソース、スキルセット、文化）の上に成り立っている。
浅黄氏は、テストオートメーションサークルのコア、コンセプト、アーキテクチャ、モニタリングとコントロール、ベースを先の4つの成功事例にあてはめた表を示した。
4つの事例ともにコア（目的）は定まっている。事例1では、元々あった手動テストを自動化してきた背景から、コンセプトにあたる設計部分があまりよくない。また、単独のテストでCI/CDには取り組んでいないため、アーキテクチャも弱い。事例2も同様に単独のテストでCI/CDには取り組んでいないため、アーキテクチャが弱い。
浅黄氏は、これらの成功要因は2つあり、その1つはデベロッパーが自動テストの結果を求めていること、もう1つはバグが発生した際にその後の手順が明確であることだとした。
「テストが失敗した後、バグだとわかった後にどんな手順でどこまで修正するか、誰がそのテストケースをもう1回実行するのかが明確になっていると、継続される率が高いです」（浅黄氏）
浅黄氏がみつけた自動テストが失敗する要因とは？
続いて浅黄氏は、自動テストが継続できなかった失敗事例2つを紹介し、テストオートメーションサークルにあてはめた。
失敗事例は以下の表の通り。
| テスト対象 | テストタイプ | テストケース数 | 実行トリガー | UI | |
|---|---|---|---|---|---|
|
事例 5 |
BtoB Webシステム（IoT） | 機能テスト | 60 | デベロッパーが必要な時 | Webブラウザ（Chrome） |
|
事例 6 |
BtoC Webシステム（管理系） | 機能テスト | 45 | Merge時選択 | DockerChrome |
問題はベースだった。事例5の場合は開発チームとテストチームの責任範囲が違っていて、お互いの仕事に興味を持てない状態が続いていた。事例6も同じようにチーム内でのテストに対する興味が薄かった。
浅黄氏はこれまでの経験から、テストオートメーションサークルの中心のコアから外側に行くに従って物事を決めていくとうまくいくと説明した。たとえば、ツールの導入はアーキテクチャに属するが、これを目的にすると、何のために行うかがわからないため、うまくいかない。最初にツールが決まっていてもいいのだが、「なぜ自動テストをするか」をまず確定しておきたい。そして、次のコンセプトでは戦略や範囲を決めることで、その先のアーキテクチャにおいて採用するツールの選定がしやすくなり、モニタリングとコントロールもうまく機能する。
しかし、このような手順で準備しても失敗するケースはある。浅黄氏は、アーキテクチャ層と、モニタリングとコントロール層との間に深い溝が生じることがあると指摘した。それぞれを担当するメンバーの責任範囲が異なる場合が多く、お互いに関心を持てなくなってしまうことが多いのだ。自動テストを機能させるには、そのベースが非常に重要となる。
浅黄氏は、ベースを構成する要素を示し、なかでも人的リソースとチーム、文化の調和が重要だと唱えた。開発者やSRE、インフラ、運用など、関係する人々のコラボレーションがうまくいかなければ、自動テストの文化も育たないのだ。
「共に働く」「協力する」「協調する」ことが大切
コラボレーションとは、「共に働く」「協力する」「協調する」ことを指す。コラボレーションについて悩んでいた浅黄氏はあるとき、作業療法に携わるパートナーとの会話からヒントを得る。
作業療法は、人々の健康と幸福を促進するために、医療、保健、福祉、教育、職業などの領域で行われる、作業に焦点を当てた治療、指導、援助である。作業とは、対象となる人々にとって目的や価値を持つ生活行為を指す。
家庭で、浅黄氏が「コラボレーションって大事だよね」とつぶやくと、パートナーが「そうだよね、信頼関係がないとできないよね！」と答えた。詳しく聞くと、お互いが対等な立場で、お互いが信頼していないとコラボレーションできないことが、作業療法でも言われていた。
作業療法を施す相手とその家族、ケアマネージャー、医師、地域関連職など、関係者がお互いに対等な立場で取り組まないとうまくいかない──これがソフトウェアプロダクトの現場にも当てはまる。開発者がテストをする人を軽視する、あるいはその逆のように、メンバー間の関係がよくなければ、プロジェクトはうまく進められない。
自動テストの浸透は、QA（品質保証）担当だけでなく、開発担当と運用担当、環境を作るインフラ担当など関係するメンバーがお互いに共通の目標を持ち、成果とともに共有していくことが重要だ。
コラボレーションの文化を育むには、組織が持つコンテキストの理解が必要だ。コンテキストを構成する要素はさまざまで、プロダクトが採用しているアーキテクチャや、開発環境・テスト環境・本番環境（オンプレミスorクラウド）といった環境要素、ウォーターフォール・アジャイルなどプロセス、メンバーの持つスキルやチームに関わる人の関連性などがある。
社内の風土や組織の規則、価値観も重要だ。たとえば、保守的な人が多ければ立ち上げが難しく、新しいもの好きが多いとスタートが早いが、飽きるのも早い。ほかにも、場所や経済・歴史的背景、過去にどのような取り組みをしたかといった時間的要素もある。これらの要素のなかでも浅黄氏が一番重要だとするのが、組織が持つ課題だ。
「何を問題と思っていて、どう解決したいかを理解することです。自動テストによって開発者へのフィードバックを早くして生産性を向上させる。そのためにやらなければならないことは何なのか。もしくは、上層部から期待されていることは何なのか…… これらを整理整頓しないとうまくいきません」（浅黄氏）
このようにコンテキストはさまざまな要素があり、それぞれは変化していくため、常に最新の状態を理解しておく必要もある。ウォーターフォールからアジャイル、バグの発見から生産性向上など、変化に応じてテストのやり方も変えなければならない。
自動テストの浸透におけるコラボレーションやコンテキストの重要さを唱えた浅黄氏は最後に次のようにコメントした。
「当社の企業理念は『あるがままでなく、あるべき世界を見ろ』で、私もいつもそのように考えています。『自動テストっていいよね』というのではなく、『実際はこうしたほうがいい、その方がいい世界になります』といったことを皆さんにお伝えしていきたい」
