モデルベースドテストについて学んでみよう - その1

　この記事は、「モデルベースドテストについて学んでみよう」2018年アドベントカレンダー、1日目の記事です。
　こんな構成で、クリスマスまでに8夜分くらい書く予定です。

1. 例によって、ISTQBシラバスを読みながら、自分の理解をまとめる。
2. MBTを実現するためのツールを使って、具体的なイメージを掴む。

テスト自動化アーキテクチャにおける位置づけ

　第1回では、テスト自動化においてMBTがどう位置づけられているかについて確認していきます。
　ISQTBのAdvance Level - Test Automation Engineer（以下「ALTAE」）のシラバス3.1.1では、「包括的テスト自動化アーキテクチャ」（generic test automation architecture、gTAA）というものを定義しています。その全体図を引用します。

※ALTAEシラバスより引用

　内側に「テスト生成」「テスト定義」「テスト実行」「テスト適合」の4つの層があります。テストプロセスでいうと、生成はテスト設計、定義はテスト実装に、実行はそのままテスト実行に、ほぼ相当します。
　わかりづらいのが適合（adaptation）です。

The Test Adaptation Layer which provides the necessary code to adapt the automated tests for the various components or interfaces of the SUT. It provides different adaptors for connecting to the SUT via APIs, protocols, services, and others.

　ざっくりいうと、テスト対象プロダクトの実装に依存しないテストケースと、プロダクトを結びつけるための層です。
　たとえば状態遷移表から1スイッチカバレッジ100%を満たすテストケースを導出したとしましょう。人間であれば、プロダクトの仕様から、どのような操作をすればこのテストケースを実行できるかを推測することができそうです。一方、機械は（今のところ、たぶん・・・）そうはいきません。ですので、実装に合わせて「このように操作する」ということを翻訳してやる必要があります。これを担うのが「適合」の層です。

　さて話が逸れましたが、モデルは「テスト生成」層にありますね。
　テスト生成の中にあるもう1つの層が「手動設計」であることを考えると、「テストモデル」とは「自動」的にテストを生成するものと想像できます。

Automatically generating test cases from models that define the SUT and/or its environment (i.e., automated model - based testing)

　テスト自動化のアーキテクチャの一部に、テストケースの自動生成というブロックがあるのですね。

長所と短所の概要

　3.2.2では、「テストケース自動化のアプローチ」として、7つのアプローチの概要とメリット/デメリットを解説しています。
　たとえば一番初歩的な、キャプチャ・プレイバックアプローチ。テスターがプロダクトを操作する過程を記録し、それを同じように再生することで、実行の自動化を実現しています。
　また、抽象化やモジュール化を進めて可読性・保守性・再利用性を向上させた「キーワード駆動テスト」も、テストの「実行の」自動化の話であり、スクリプトの形態に違いがあるだけです。詳しくは以下のような記事で言及していますが、これらは「テスト実行」の自動化に伴うスクリプトの書き方に関するものです。

www.kzsuzuki.com www.kzsuzuki.com

　一方、モデルベースドテストは、テストの「実装の」自動化の話。ソフトウェアの一側面を規定のルールに従ってモデル化し、これに対し何らかの基準（カバレッジ基準やフィルタ）を与えることで、条件を満たすテストケースが導出されるという仕組みです。
　「テストケースの自動化」という不思議なタイトルになっているのは、「実行」と「実装」が混じっているからかもしれません。

シラバスの説明の要約

基本的なコンセプト

• MBTは、テストケースの自動実行ではなく、自動生成に関するものである。
• （準）形式的なモデルを利用する。
• テスト生成のメソッドは一つではない。
• スクリプティングフレームワークのためのテストを導出することができる。

　最後の部分が少しわかりづらいのですが、ここは何気なく大事なことを言っています。
　それは、テスト自動実行の形に合わせて、テストケースの自動生成をすることができるということ。つまり、MBTのためのモデルを適切に設計することで、テストケースの生成から実行まで一気通貫で自動化できる、ということを暗示しているのですね。

長所

• 抽象化によって、テストの本質部分（ビジネスロジック、データ、シナリオ、構成、・・・）に集中することができる。
• （システムの内部で利用される）技術が変化していっても、モデルは再利用・保守することができる。
• 要件に変更があった場合でも、モデルだけをそれに合わせればよい。テストケースはそこから自動的に生成される。

短所

• SUTを、インタフェース、データ、ふるまいといった観点で抽象化するのは高度な技術であり、モデリングの専門家が必要。
• MBTのためのツールがまだまだ主流ではなく、成長段階にある。
• テストプロセスと統合していかなくてはならない。
• 品質のよいテスト生成のために、モデル自体の品質保証が必要になる。

　長所としては特に3つ目が重要だと思います。テスト対象を分析・抽象化した結果がモデルだであり、これとテスト設計を組み合わせることでテストケースが生成される。最終生成物がどのように導出されたかの「根拠」が、モデルと設計に残っていることが重要です。

　短所として、ツールがまだいまいちというものがあります。ただ実用で通用するのではと思えるものもありますので、このシリーズの後半でそのイメージをお伝えできればと思います。

　では、第2回以降は Foundation Level - Model-Based Tester（FL-MBT）を読んでいきましょう。

JSTQB-TTAシラバスのお勉強 ─ 第2章「構造ベースドテスト」(2)

　ずいぶん間が空いてしまいましたが、TTAの第2章の残り分、2.5～2.8までです。

www.kzsuzuki.com

2.5　複合条件テスト

　対応するカバレッジは、複合条件網羅。すべてのパラメタのすべての真偽を組み合わせる方法です。
　すぐに組み合わせ爆発が起こることは想像に難くありませんね。

www.kzsuzuki.com

2.6　パステスト

　対応するコードカバレッジは、経路網羅。

www.kzsuzuki.com

　パス数が爆発的に大きくなってしまうので、どう妥協していくかの戦略についてシラバスでは言及しています。コードカバレッジといえばある程度機械的に導出できるイメージがありますが、Beizer本から引用されているパステストの方法は、けっこう職人技を感じるものです。

ソフトウェアテスト技法

1. 最も単純で機能を実現する、開始から終了までのパスを選択する。
2. 前のパスとわずかに違うように１つのパスを追加する。後続の各テストで異なるようにパス中の１つのブランチだけを変えてみる。できる限り、長いパスよりも短いパスを採用する。機能を実現しないパスではなく実現するパスを採用する。
3. カバレッジに必要な場合のみ、機能を実現しないパスを選択する。
4. 最も実行される可能性が高いパスを選択する際は、直感を使う。

　シンプルかつ「機能を実現する」パスを最初に選んでそこから少しずつ変えていく方法では、当然似たようなパスが多くなり、同じ個所を何度も実行することになります。この方法がなぜよいかについて、Beizer氏は著書の中で以下のように書いています。

　条件を細かく変化させると、テストのドキュメントが簡単で、少なくて済み、条件設定も容易となる。1本のパスですべての条件をまとめてテストしようとすると、他のテスト項目との共通条件がないため、多くの作業量が必要となる。
　テストとは一種の実験である。実験の原則は、一度に1つの条件だけを変えることである。つぎのテストとの差が大きいと、混乱する可能性が高くなる。
　余分なパスを実行しても、数マイクロ秒のCPU時間、テスト実行に要する時間、ドキュメント化に必要な時間が余分にかかるだけである。テスト工程では、パステスト以外にも何種類ものテスト法で、もっと多くのテスト項目を実行しなければならない。したがって、パス数が多少増えてもテスト全体の作業量からみれば微々たるものである。

　シラバスだけ読んでいると、何となくシナリオテストの話をしているように感じてくるのですが、ここではあくまでもコードのカバレッジですね。

2.7　APIテスト

　APIテストは、コードカバレッジとは関係がありません。テスト技法の名前でもなく、単に「APIのテスト」という意味ですね。
　APIテストのポイントは以下の3つです。

• 正常の範囲から外れた入力を正しく処理できるかを確認する否定テスト
• APIの組み合わせとパラメタ値の組み合わせテスト
• 故障・復旧・リトライといった異常ケースのテスト

　JSTQBの用語集によると、「否定テスト」の定義は以下の通りです。

否定テスト（negative testing）
　コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。

　わたし自身はAPIのテストを本格的にやったことがなかったので、この記事を書くにあたって、『WebAPI - The Good Parts』を一通り読んでみました（シラバスではWeb APIに限定しているわけではないのですが）。本書は、Web APIの重要性や考え方から始まって、理想的で美しく、堅牢な設計について丁寧に述べられており、楽しみながら読むことができました。

Web API: The Good Parts

　一方、テストについては記述があまりありません。そこで、ソフトウェアテスト・ヒストリアンの辰巳さんのツイートから、『10分で学ぶAPIのテスト！』というWebサイトを覗いてみました。

ご参考(その2)
Learn API testing in 10 minutes!https://t.co/sl4zzjSDIS

— Keizo Tatsumi (@KeizoTatsumi) September 8, 2018

www.guru99.com

　こちらは、APIの一般的な概要について述べた後、APIのためのテストケースや、アプローチ、APIテストとユニットテストの対比などについて説明しています。 　たとえば、「APIテストで摘出されるバグの種類」として、以下を挙げています。

• エラー状態の不正な扱い
• 使われていないフラグ
• 機能の重複・欠損
• 信頼性についての問題。APIへの接続やレスポンス受領が困難。
• セキュリティの問題
• マルチスレッドに関する問題
• 性能の問題。APIのレスポンスタイムが大きすぎる
• 呼び出し元に対する不適切なエラー・警告
• 有効な変数値の不適切な扱い
• 形式的に正しくないレスポンスデータ

　また、「APIテストの課題」としては、以下を挙げています。

• パラメタの組み合わせ、選択、コール順序
• GUIがないので入力値を与えるのが面倒
• 出力値の検証・妥当性確認が少々難しい
• パラメタの選択とカテゴライズを知る必要がある
• 例外処理のテスト
• コーディングの知識が必要

　本当に10分あれば読める内容なので、Web APIテストビギナーの方は読んでみてはいかがでしょうか。

2.8　構造ベースの技法の選択

　2.6までで説明されたコードカバレッジについて、故障発生時の影響の度合いから選択する例が説明されています。
　たとえばDO-178Bという標準で定められた故障条件が「A. catastrophic」であれば、コードカバレッジはMC/DCでテストする必要がある、といったものです。

Ericssonの『ユニットテストカバレッジの神話』を読んでみる

　今年の4月に『Mythical Unit Test Coverage』（ユニットテストカバレッジの神話）という論文が出ました。ソースコードの品質指標として言及されることの多いコードカバレッジについて、先行研究を整理したうえで、商用の大規模ソフトウェアにおける追加検証をしたものです。IEEEのサイトでも全文公開されています。

Mythical Unit Test Coverage - IEEE Journals & Magazine

　長い論文ではないのですが、わたしには論理展開のわかりづらい部分があったので、整理してみました。

アブストのアブスト

• 「リリース前にどれだけのテストをすべきか」というのはずっと問題。
• テストの十分性の指針として、Ericssonで長年使ってきたユニットテストのカバレッジのクライテリアを検証した。
• 結果として、ユニットテストカバレッジは、欠陥のないソフトウェアを作ることと明らかな関係はないようだ。

「1. テストカバレッジのメジャー」のアブスト

• テストカバレッジ*1のメジャー*2としては、Statement Coverage（命令網羅）、Decision Coverage（判定網羅）、Function Coverage（機能網羅）の3つがポピュラー。
• テストカバレッジが欠陥の傾向（defect-proneness）に与える影響はわかっていない。

「2. 既存の研究」のアブスト

• カバレッジと欠陥の関係についての先行研究のうち、めぼしいものが8件。
• 先行研究8件のうち、
  • 7件は「カバレッジと欠陥数の関連は弱い」と結論。
  • 1件は「中程度または強い関連がある」と結論。
• 先行研究8件のうち、
  • （上とは別の）7件については、欠陥が故意に埋め込まれたもの（mutants）だったり、プログラムのサイズ・変更頻度・複雑度などの交絡因子*3がコントロールされていなかったり、プロダクトが小規模で欠陥数も少ないという課題がある。
  • 残りの1件は現実のケースに近いもので、「関連は弱い」と結論。
• 人工的な条件を避け、交絡変数をできるだけコントロールして、実践者のための結論を出すことが必要。

「3. 調査対象の製品」のアブスト

• Ericssonが開発した大規模（約2MLOC）なテレコム系プロダクト。
• 各年に製品のメジャーリリースを行うエンジニアは約150人。
• アジャイル/リーン開発方法論を適用。

「4. 調査方法」のアブスト

• 1年間におけるファイルごとの欠陥数（統合テスト、システムテスト、顧客環境）を収集。ユニットテストは対象外。
• カバレッジは、ユニットテストにおけるものを測定。
• 予想は、「ユニットテストでカバレッジが高ければ、以降で欠陥が現れる可能性が低下する。逆も同様」。
  • カバレッジと欠陥の間に明確な負の相関（-0.4以下）があれば、テストの十分性としてカバレッジを利用できるだろう。
• サイズ・複雑度・ファイルの変更回数について、カバレッジ・欠陥数・両者の関係にどのくらい影響するかを理解するために計測した。
• プログラミングやテストのスキル、言語、利用ツールなどはランダム分布していると仮定。

「5. 結果」のアブスト

• サイズ・複雑度・変更回数と、欠陥数・カバレッジの相関を一覧化。
  • カバレッジ同士は相関が強いので、他の要素との相関は statement coverage のみを見る。
• カバレッジと欠陥数の相関係数は小さく、テストの十分性のクライテリアとして適切ではない。ただし、
  • 同じカバレッジ50%でも、1,000LOCと100LOCでは欠陥数にも違いがあるだろう。実際、サイズと欠陥数には強い相関がある。サイズをコントロールする必要がある。
  • 変更頻度についても同様。多くの変更があるファイルは集中的に開発されているということで、欠陥をはらむ可能性も高くなる。
  • 「LOCあたりの平均カバレッジ」と、「バージョンあたりの平均カバレッジ」をいうメジャー*4を追加。
  • その結果、この「カバレッジ密度」と欠陥の数の相関は若干上がっているが、それでも弱いまま。

「6. 複雑度の影響」のアブスト

• 最大ブロック深度（Maximum Block Depth、ネストレベルの最大値）にはいくつか特徴がある。
  • コードメトリクスで唯一、サイズ・変更回数との相関がない。
  • カバレッジと明確な負の相関を持っている。ネストの深いコードは、テストを書くのが難しいと理解できる。
  • 欠陥数とも相関がある。シンプルなコードよりもネストの深いコードの方が、バグを作りやすいと理解できる。
• 変更回数と欠陥数にも正の相関がある。開発が集中するところに欠陥が入り込みやすいと理解できる。
• 欠陥数に影響与える要素「サイズ」「最大ブロック深度」「変更回数」のうち、開発において制御しやすいのは最大ブロック深度。プログラミングの技術によって抑制して、欠陥数やカバレッジに与える影響を小さくできる。

「7. むすび」のアブスト

1. Ericssonにおけるユニットテストのカバレッジクライテリアは神話であった。
2. 国際標準におけるこのメジャーの推奨は、見直しが必要。
3. この問題がどれほど一般的なのかを理解するために、他のドメインでも同様のケーススタディを行う価値がある。
4. コードの複雑さをコントロールすることで、欠陥混入の可能性を下げ、コードのテストのしやすさを向上させられる。

感想

　「Ericssonの特定の製品については」という点を慎重に述べている印象です。ただ先行研究の大半においても、「コードカバレッジと欠陥数の相関は小さい」としていることから、一般性にある結論かもしれません。

　この論文を読んで最初に思ったのは、「そもそもサンプルデータとして高カバレッジのコードしかなく、相関が低いというのはそのエリアの話なのではないか？ つまり、カバレッジが一定以上になるとそれ以上のカバレッジ向上は品質への寄与が小さい、ということではないのか？」ということです。しかしこの論文に描かれた等高線図を見ると、カバレッジの範囲は0%～100%でプロットされており、そういうわけでもなさそうです。
　たとえばカバレッジが0%から50%に上がっても、欠陥数には影響しないということですね。にわかには信じがたいが・・・。

　後半の「最大深度」と欠陥数の相関は、直感的でわかりやすいですね。
　一方、ちょっと古い記事ですが、Googleはこのようなコードメトリクスではなく、変更回数も含めた変更履歴の情報から、欠陥予測のアルゴリズムを作っていました。 www.publickey1.jp

　こちらのポストでいうと、「コードチャーン (code churn)」*5というものですね。 www.kzsuzuki.com

*1:コードカバレッジについては、以下のポストもご覧いただければと思います。www.kzsuzuki.com

*2:SQuBOKガイドによると、「測定法」に対応する英単語は、2007年のISO/IEC 15939:2007から「measure」を採用しているとのこと。それ以前は「metric」だったようです。

*3:交絡因子の説明とコントロール方法について、それぞれ以下のサイトがわかりやすかったです。 www.nies.go.jp 研究デザインにおける交絡のコントロール

*4:追加された2つのメジャーの意味が理解できませんでした。カバレッジの平均とは・・・？ とにかく、サイズと変更回数の影響を減らすための正規化のような操作だと解釈しています。

*5:Google日本語変換では「ちゃーん」の変換第一候補が「ちゃ～ん」でした。イクラなんでもそれは・・・。

Sogetiの考える「人工知能のテスト」を調べてみた。

　2018年3月、「AIプロダクト品質保証コンソーシアム」の設立が発表されました。

monoist.atmarkit.co.jp

　略称は「QA4AI」、つまり「AIのためのQA」ですね。前回の翻訳記事は「QAのためのAI」だったので、今回は「AIのためのQA」も含めた話題を紹介します。TPI NEXTやTMapで知られるSogetiによるホワイトペーパー・「人工知能のテスト」です。

TPI NEXT? ビジネス主導のテストプロセス改善

　目次は以下の通り。かいつまんで紹介してみます。

1　Executive summary
2　Setting the scene
3　Testing of Artificial Intelligence
4　AI Quality Engineering Skills
5　Conclusion
6　Acknowledgments

1. 概要

　要点は以下の3点です。

• 人工知能（AI）が台頭してきて、人々の生活を変え始めている。
• AIがテストを代替するソフトウェア開発においては、アジャイルやDevOpsの流れで定着してきた2週間といったサイクルでも遅い。
• テストに関する既存の知識は、AIのためのテスト、AIによるテストにおいても有効だが、新たなスキルも必要になる。

2. 準備

　まず、単語について簡単に説明しています。特徴的なのは以下の2つ。

• Machine Intelligence: 機械知能。「AI」という言葉を使った途端に、「本当のAIとは」と話が逸らされていくので、AIやMLと同じような意味で使っているとのこと。
• Cognitive IT: コグニティブIT。知覚と知識に基づいて振る舞うことのできる情報技術。テストや品質保証のためにコグニティブITを使うことを、Sogetiでは「コグニティブQA」と呼んでいます。

　次に、AIを用いたシステムをテストすること（testing OF AI）と、AIを用いてシステムをテストすること（testing WITH AI）の二つを説明しています。 後者は「デジタルテスティング」と表現されてもいます。

3. AIをテストする

6つの軸

　AIの品質の軸として以下の6つを挙げ、目新しいものとして後の3つについて詳述しています。

1. Mechanical（機械）
2. Electrical（電気）
3. Information Processing（情報処理）
4. Machine Intelligence（機械知能）
5. Business Impact（ビジネス・インパクト）
6. Social Impact（社会的インパクト）

　本ペーパーで何度か言及されることですが、テスターに求められる作業として、以下の二つが挙げられています。

• システムが時間（と学習）につれて変化していくため、システムの出力が満たすべき境界や許容範囲を決め、テスト中も本番環境でも、その範囲に収まっていることを確認する。
• 入力に対する出力への影響を理解する。また、システムの入力を制限して、出力への影響を限定する。

　入力と出力の両方に注目していることがポイントです。また特に後者については必ずしも開発中の話ではないようです。リリース後にユーザからの入力から学習する前提で、それを継続的にモニターすることを求めています*1。
　4章では、Microsoftのチャットボットが起こした問題に言及しつつ、機械がどのように学んでいるのか、入力に対してどのように反応しているのかを理解する必要があるとしています。

www.buzzfeed.com

　また「社会的インパクト」について、新技術が社会や個人にもたらす影響に注意を払う必要があり、社会学や心理学の知見が必要としています。ソフトウェア品質保証の「V&V」では検証（Verification）と妥当性確認（Validation）があり、特に後者では「仕様どおりに」作られていることよりも、その製品が本来求められている要求を満たしているかを確認することが必要になりますが、その範囲が「ユーザ」という個人から、さらに拡張されている感じですね。

AIのテストにおける確認事項

　例に挙げられた確認事項は以下のように、技術的な側面だけでなく、社会的側面、法的側面、倫理的側面についても言及があるのが特徴です。

• 受け入れ条件は何か
• 最小工数でその条件をテストするために、テストケースをどうデザインするか
• トレーニングとテストでデータを分離しているか
• テストデータは、予想されるデータを適切に代表しているか
• テストとトレーニングデータは法的なフレームワークに準拠しているか
• トレーニングデータは偏っていないか
• モデルの期待出力は何か
• モデルがオーバーフィット/アンダーフィットしていないか
• ソリューションは非倫理的ではないか
• 性能と堅牢性は十分か

4. AI品質保証のエンジニアリング技術

必要となる知識

　テスト技法やテスト管理など、既存のテスト関連技術は今後も応用できる一方で、今後新たに必要になるスキルセットについて言及しています。

• 機械学習、ビッグデータ解析、クラウドコンピューティング
• PythonやScalaなどのプログラミング言語、TensorFlowのようなOSS
• 数学。特に統計・微分積分・線形代数・確率
• A/Bテスティング、メタモルフィックテスティング
• ハードウェアアーキテクチャ
• 機械、電気。ロボットが物理的なものなら。
• 生物学、経済学、社会科学、心理学。データサイエンティストにとって使い道が多い。
• 哲学や倫理学。インテリジェントなソフトウェアの世界では重要さを増す。

　A/Bテストやメタモルフィックテスティングについては、以下の動画や記事をご覧ください。

What A/B Testing is & How to Use It www.kzsuzuki.com

セキュリティ、プライバシー

　データポイズニングやAdversarial Examplesといった攻撃手法や、フィルターバブル*2、偏見の増幅による差別の拡大といったビッグデータの課題、顔認識技術の発達によるプライバシーの問題などについて言及しています。たとえばKasperskiのこの記事が参考になるかもしれません。

blog.kaspersky.co.jp

5. 結論

　第5章では、AIのテスト、AIによるテストにおいて求められるスキルが列挙されています。上述の「知識」と重複する部分もありますが、よりマネジメント・ビジネスに近い内容もあるので、ぜひホワイトペーパーをご覧ください。

　また最後の主張として、これらの高度なスキルをすべてもった人間を連れてくるのは困難なので、既存のスキルを備えたメンバーに対し、新たな教育の投資をしていこうと書かれています。前の翻訳記事では「AIによって仕事を失ったりはしないよ！」みたいな論調でしたが、AIをテストしようとする人は、これまで以上にハードな継続的学習が必要になりそうです。とってもげんなりワクワクしますね！

www.kzsuzuki.com

終わりに

　と、それなりに原稿を書いたところで、ソフトウェアテストヒストリアン・辰巳敬三さんのこのツイート・・・。まったく追いつかない・・・。

Sogeti社のレポート
機械知能の品質特性; AIとロボティックスの品質の測定方法
Machine Intelligence quality characteristics
How to measure the quality of Artificial Intelligence and roboticshttps://t.co/kyQCPHuO0A https://t.co/DfYCr8pe0K

— Keizo Tatsumi (@KeizoTatsumi) 2018年7月29日

*1:そのモニターにもまた、AIが使われるであろうという前提で。

*2:「インターネットの検索サイトが提供するアルゴリズムが、各ユーザーが見たくないような情報を遮断する機能」（フィルター）のせいで、まるで「泡」（バブル）の中に包まれたように、自分が見たい情報しか見えなくなること。 via Wikipedia

【翻訳】AIベーステストの6つのレベル - QAのプロにとって恐れるべきものではない

　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に代替されそうなことばかりやってるとマズいよ」という話にも読めますね。

*1:訳注: 一度「正しい」と判断され、以降のテストにおける結果判定の基準となるものを指しています。

*2:訳注: executeやrunで表される「実行」とは少し違って、何をしなければならないかを自ら判断して動作することを指しているように思います。

*3:訳注: 妥当な失敗とそうでない失敗の違いを指しているものと思います。

*4:訳注: 人間が自動化ツールに明示的に指示している、という意味でしょう。