Gil Tayarさんの「6 levels of AI-based testing: Have no fear, QA pros」という記事がteckbeacon.comで公開されていたので、紹介します。モバイルアプリやWebアプリなど、画面の操作を伴うアプリケーションを前提とした内容になっています。
techbeacon.com
「6つのレベル」というのは、自動運転の6つのレベルに着想を受けたものですね。
フォルクスワーゲンのサイトから引用して、元記事の「6つのレベル」と並べてみましょう。
www.volkswagen.co.jp
| レベル |
自動運転 |
自律的なテスト |
| 0 |
ドライバーがすべての操作を行う。 |
自律性なし |
| 1 |
ステアリング操作か加減速のいずれかをサポートする。 |
ドライブアシスタンス |
| 2 |
ステアリング操作と加減速の両方が連携して運転をサポートする。 |
部分的な自動化 |
| 3 |
特定の場所ですべての操作が自動化、緊急時はドライバーが操作。 |
条件付きの自動化 |
| 4 |
特定の場所ですべての操作が完全に自動化される。 |
高度な自動化 |
| 5 |
あらゆる状況においても操作が自動化。ハンドルもアクセルも不要。 |
完全な自動化 |
それでは、翻訳です。
誤訳などについてはコメントをお願いします。
翻訳
あなたは、人工知能（AI）が近いうちに、視覚的なテストをQAチームから奪っていくと心配しているだろうか？ その必要はない。自律的なテストツールは助けてこそくれ、あなたの代わりになってはいないだろう。テスターやQAチームは、ビジネス価値について考えることに時間を使うべきだ。つまり、目的を達成するための手段として自動テストを実行することよりも、どうテストし、どう品質保証するかを考えることに力を注ぐべきということである。
テストには6つのレベルがある。これで、AIテストの革命に不意打ちされることを避けられるだろう。
レベル0: 自律性なし
おめでとう。あなたはアプリケーションをテストするコードを書き、リリースのたびに何度も実行できるので、実に幸せだ。完璧である。テストにおいてもっとも大事なことーーー考えることに集中できるのだから。
でも、その自動テストを書くのを手伝ってくれる人はいない。それに、コードを書くこと自体が繰り返しの作業だ。フォームにフィールドが追加されたら、テストを追加しないといけない。ページにフォームが追加されたら、すべてのフィールドをチェックするテストを追加しないといけない。ページが追加されたら、そのページのフォームと部品をすべてチェックしないといけない。
開発者がアプリケーションに見境なく変更を加えると、テストが多いほど失敗も増える。そして失敗したテストすべてについて、その原因が本当のバグなのか、新しいベースライン*1なのかを確認しなければならない。
レベル1: ドライブアシスタンス
自律走行車（autonomous vehicle）は、（自律的な）テストのレベルの良いメタファーになる。視覚システムが向上するほど自動車がより自律的になるのと同じように、AIシステムがアプリケーションを「視る」のがうまくなるほど、テストも自律的になる。
AIはページのDOM（Document Object Model）のスナップショットだけでなく、見た目のイメージ（visual picture）も視られるようになっているべきだ。DOMはイメージの半分に過ぎない。テキスト付きのエレメントがあるからといって、ユーザがそれを見られるとは限らない。ページをわかりづらくするエレメントがあるかもしれないし、ページが正しい位置にないこともある。見た目のイメージがあれば、ユーザが見るデータにフォーカスすることができる。
テスティングフレームワークが、DOMやスクリーンショットを通じてページを全体的に視られるのであれば、チェック（するコード）を書くのをサポートできるだろう。
ページのスクリーンショットを取れば、そこにあるフォームのフィールドやテキストを一括してチェックすることができる。各フィールドをチェックするコードを書くかわりに、過去のテストをベースラインとして一気にテストすることができるのだ。
このレベルのテストを可能にするには、「どの変化が本当の変化で、どの変化が実際には何も変わっていないのか」を判断するためのAIアルゴリズムを、テストツールが備えている必要がある。
今日のAI技術は、チェックしたいことを人間が書くことで、テストコードの実装をアシストしてくれる。テストの駆動（drive）*2は人間が行わなくてはならないが、AIが一部を自動的にチェックしてくれる。
AIはテストがパスしたかもチェックできる。しかしテストが失敗した場合は、それを人間に通知しなくてはならない。その失敗が本物（のバグによるもの）なのか、ソフトウェアの適切な変更によるものなのかは、人間が判断するのだ。その変更が適切なものだと確認するか、バグとして拒否しなくてはならない。
AIがアプリケーションを「視る」というのは、アプリケーションの視覚的側面をベースラインと比べてチェックするということであり、今まで手動テストでしかできなかったことだ。ただし依然として、変化が妥当なものかどうかはすべて、人間が確認しなければならない。
レベル2: 部分的な自動化
レベル1の自律性に加えて、ベースラインと比較するテストをAIに行わせることで、ページのすべてのフィールドに対するチェックを書くという退屈な作業をテスターは行わなくてよくなる。同じように、ページの視覚的な側面をAIにテストさせることもできる。
しかしテストが失敗した場合に、その失敗が「良い」失敗なのかバグなのかをすべてチェックするのは退屈である。特に、一つの変更が多くのテスト失敗をもたらしている場合はなおさらだ。AIはその違い*3を、アプリケーションのユーザと同じように理解できる必要がある。つまりレベル2のAIは、意味的に同じ変化を理解することが可能なので、多くのページにおける変化をグルーピングすることができるようになるだろう。（画面の）変化をグルーピングし、変化が同一のものであれば人間にそれを教え、その変化を受け入れるか拒否するかをグループ単位で尋ねることができるのだ。
要するに、レベル2のAIはベースラインに対して変化をチェックし、退屈な作業を一つのシンプルな作業にまとめるのを手伝ってくれるのだ。
レベル3: 条件付きの自動化
レベル2においては、失敗したテストや、検出されたソフトウェアの変化をすべて、人間がしっかりと吟味する必要があった。レベル2のAIは変更を解析することができる一方で、ページを視ただけでそれが正しいかどうかを判断することはできない。比較するためのベースラインが必要である。しかしレベル3のAIはそれができるし、ページに対して機械学習の技術を適用することで、もっと多くのことができる。
たとえば、レベル3のAIはページの視覚的な側面を調査し、アラインメントや余白、色使い、利用フォント、レイアウトなどのデザインの標準ルールに従っているかを判断することができる。
では、データについてはどうか。レベル3のAIはデータをチェックし、あるフィールドについては特定の範囲に収まっていること、メールアドレスであること、上に並んだ数字の合計となっていることなどを判断することができる。ある特定のページにおいて、テーブルは指定された列でソートされていることを理解している。
ここでAIは、人間のデザインとデータのルールを理解することによって、人間の仲介なしにページを評価することができる。ページに変化があっても、そのページに問題はなく、人間に確認してもらう必要がないと理解することが可能なのだ。AIシステムは数百のテスト結果をみて、どのように変化してきたかを知ることができる。機械学習の技術を応用することで、変化におけるアノマリーを検出することができるので、人間にはそのアノマリーについてのみ確認を依頼するのだ。
レベル4: 高度な自動化
ここまでは、AIは自動的にチェックするだけだった。テストの駆動は未だに人間が行っており、（自動化のソフトウェアを使って）リンクをクリックしたりしている*4。レベル4ではAIがテスト自体を駆動する。
レベル4のAIは、ページを視て人間と同じように理解できるので、ログインページを視たときに、プロフィール、登録、ショッピングカードのページと比べて、それを理解することができる。「ページは、相互作用のフローの一部である」と意味的に理解しているので、テストを駆動することができる。
ログインや登録といったページが標準的なものであるのに対して、そうではないものもある。しかしレベル4のAIは、これまで視たことのなかったページであっても、ユーザの相互作用をずっと視ていて、それを可視化し、そのページとページを通したフローを理解できる。
AIがいったんその種のページを理解すると、強化学習（機械学習の一種）などの技術を用いることで、自動的にテストの駆動を始めることができるようになる。テストをチェックするだけでなく、書くことができるようになるのだ。
レベル5: 完全な自動化
レベル5は、今のところSFである。このレベルに至ると、AIはプロダクトマネージャーと会話し、アプリケーションを理解し、AI自身が完全にテストを駆動することができる。
しかし、プロダクトマネージャーによるアプリケーションの説明を理解しているものがいなければ、レベル5は人間より賢くなければならない。
現在の最先端
現状、高度なツールだとレベル1で、レベル2の機能性へと進歩しているところだ。ツールベンダーはレベル2に取り組んでいる。レベル3にはまだ努力が必要だが、可能と思われる。 レベル4のAIは遠い未来だろう。しかし次の10年かそこらで、重い副作用なしの、AIにアシストされたテストに出会うことになりそうだ。
よって、ソフトウェアテストのすべてをコンピュータが自動化してしまうといって、別の仕事を探し始める必要はない。ソフトウェアテストはいくつかの点で運転と似ているが、人間の複雑な相互作用を理解しなくてはならない分、もっと複雑なのだ。今日のAIは、自身が何をしているかを理解していない。単に、大量の過去データに基づいてタスクを自動化しているだけである。
あなたの仕事は「自動化すること」であり「自動化されること」ではない。テストチームとQAチームは、新しい働き方を促進するために、新しい自動化技術をさらに活用することができる。仕事が自動化されることで人が自由になって、どうテストし、どう品質を保証するかに集中できるようになれば、ビジネスのために価値を生み出すことでができるようになる。
所感
この記事を読むと、機械学習の技術を利用したテストを、単純に「自動テスト」と呼ぶと混乱しそうだと感じます。「自動」の中でも特に「自律」であり、駆動にしろチェックにしろ、何をすべきかを人間が明示的に与える必要がないのが「自律」といえるでしょう。
自律的なテストが進歩していくにあたって、以下の二つのことが気になりました。
一つ目は、トレーニングデータの量です。
レベル4では、初見のページであっても、ユーザの操作をずっと観察し続けることでフローを理解できるとしていますが、正確な判定には膨大なトレーニングデータが必要となるはずです。トレーニングのためのこの「ユーザの操作」データはどのように与えるのでしょうか。ページ操作を自動化し、かつ実行ごとに微小な変化・ランダム性を追加することで、大量データを準備するといった方法がある？
二つ目は、欠陥検出に失敗した際のフィードバックです。
機械学習の応用でよく指摘される問題として、「なぜそう判定したのかが人間に見えづらい」というものがありますよね。
手動テストであれ、現在の（判定ロジックを人間が書いている）自動テストであれ、欠陥を見逃してしまった場合はその原因を分析し、以降のテストにフィードバックすることができます。一方、機械学習に基づく自律的なテストにおいて、それは可能なのでしょうか。なぜそれを見逃したかは、よくわからないままになってしまうのではないでしょうか。
あるいはこういう発想自体がレガシーで、「特定の欠陥を見逃したことより、全体としての検出率が上がっていることが重要」という考え方になるのでしょうか。
ともあれこの記事が言っているのは、「機械に任せられる部分をどんどん広げて、人間は考えることに力を入れよう」ということです。全般的に「心配するな！」という論調ではありますが、これは皮肉にも見えて、「AIに代替されそうなことばかりやってるとマズいよ」という話にも読めますね。
