『テスト管理を語る夕べ』での発表内容についての補足（とか言い訳） ー 前編

　『テスト管理を語る夕べ』というイベントで、お話をさせていただきました。
　主催のみっきーさん、インフラ整えてくださってしんすくさんとなそさん、twitter実況してくれた書記のぱいんさんとブロッコリーさん、←どんなメンツなんだ？
　そしてこんなマニアック目なテーマの勉強会に金曜夜を使ってくれた奇特な参加者のみなさんに感謝します。

kataruyube.connpass.com togetter.com

　「テスト管理」というと対象範囲が広く、たとえば「テストの進捗に遅延が発生した際に、どのように解決していくのか！」といった、かっこいい感じの「テスト管理」もあるのですが、今回の発表は地味な「テストケースの持つべき情報・構造」に関するものです。

　Excelによる2次元表でのテストケース＆テスト実行管理というのがもっとも「わかりやすい」ものですが、その扱いづらさ、限界、破綻を感じるは少なくないでしょう。
　たとえば2回同じテストを行い、その結果がExcelの1行に「pass/fail」と記載されているのを見たことがありませんか。こんな些細なことでも以下のような問題があります。

• 1つの行に複数の結果が書かれており、集計が困難になる。
• 2回のテストが、どのプロダクトバージョンで行われたか追跡できない。
• 同じプロダクトバージョンで2回目で合格したとしたら、テストケースの方を修正した可能性があるが、それも追跡できない。

　場合によってはそこから、いわゆる「テスト管理ツール」の検討に進む組織もあるでしょう。しかしそれもうまくいくとは限りません。
　テスト管理ツールが提案するテスト管理・表現方法と、自組織の考え方が合わない。手動テストと自動テストをうまくシームレスに扱えない。導入のためのイニシャルコスト（検討、ツール比較、パイロット導入、ルール作成、トレーニング、・・・）が払えないなど。
　幸いわたしは、仕事の一部にテスト管理ツールを導入できていますが、それもどうも、ニーズを完全に満たすものではない。

　そんな中で、そもそもテストケースというものはどのような「カタチ」をしているべきなのだろう。また他の成果物とどのような関係を持つべきなのだろう。ということをあらためて考え始めました。ざくっとまとめてTwitterに投げたのが、以下です。

@yoshitake_1201 @MAQ69 @s_banban 月初に話したテスト管理のやつ、昨日の夜中に書き殴ったので御レビューお願いしますw 僕が触ったことのあるテスト管理ツールはSquashTMとTestLinkだけです。
※パワポテンプレは無視して…。 pic.twitter.com/yVLIzLY1l2

— Kazu SUZUKI (@kz_suzuki) September 17, 2018

　これに対し有益なコメントをたくさんいただけたので、一人で盛り上がって2次検討した結果が、以下の表とER図です。ER図は記法がいい加減なので「エセ」ですが。

　今回はこの2つを中心に、

• テストケースのバージョンとは
• テストケースのパラメタライズとは
• キーワード駆動テストとは

などについて自分の考えを説明しました。

　後半はパトスがほとばしり過ぎて謎の早口おじさんになっていた気がしますが、少なくとも一部の方には興味を持っていただけたようで、ほっとしました。

　さて、以下に資料を公開していますが、当日多くのツッコミを受けたことからもわかるとおり、ドラフトに過ぎない資料です。
　今回いただいたご質問・ご指摘を踏まえてもう少しブラッシュアップしようと思っています。また、これもう少し進めたいねというご意見があれば、第2回目もやりたいなー（わたしはあまりしゃべらない立場で）とも思います。

20181102 twilight session4testmanagement_01 from Kazuhiro Suzuki

www.slideshare.net

　この記事は「前編」です。「後編」では、いただいたコメントに対し、現時点での回答を試みます。

モデルベースドテストについて学んでみよう - その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