Difference between testing ordinary software and testing software using machine learning

Slide 1

Slide 1 text

普通のソフトウェアのテストと機械学習を用いたソフトウェアのテストの違い

Slide 2

Slide 2 text

目次 ● 従来のソフトウェア開発 ● 機械学習を用いたソフトウェアの開発 ● 従来のソフトウェアとのテストの違い ● 機械学習のテスト手法の簡単な紹介 ● AIプロダクト品質保証ガイドラインの簡単な紹介 ● 最後に。私はこんなことに遭遇しました

Slide 3

Slide 3 text

自己紹介名前：まつ @mty_mno 活動： ● 新人さんからわかるソフトウェアテスト解説マンガ「テスターちゃん」作者 ● AIプロダクト品質保証コンソーシアム(QA4AI)スタートアップメンバーの一人 ○ ガイドラインのVUI (Voice User Interface) 領域を執筆しています。 ● JaSST Kyushu(ソフトウェアテストシンポジウム九州）の去年までの実行委員長

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

従来のソフトウェアの開発

Slide 6

Slide 6 text

どんなテストをすればよさそう？オススメ機能です。少しどんなテストが考えられるか思い浮かべてみましょう。例：オススメ機能仕様（ルール）：マンガならマンガ、ゲームならゲームというように、購入商品と同じジャンルの商品を1個表示する。商品は発売1か月以内の売り上げ Topの商品である。実装オススメ機能

Slide 7

Slide 7 text

どんなテストをすればよさそう？テストを考えた時、「何を入力して、どんな結果になったらよさそうか」ということが思い浮かんだのではないでしょうか？例：オススメ機能オススメ機能仕様（ルール）・買った商品と同じジャンルの商品を 1つ表示・商品は発売1か月以内の売り上げ Topの商品ゲーム買おう ● 出力商品は買った商品と同じジャンルか ● 出力商品は発売1か月以内か ● 出力商品は売り上げ Topか

Slide 8

Slide 8 text

従来のソフトウェア開発従来のソフトウェアテストでは、要求→要件→仕様→ソフトウェアと、手前で決めたことを具体化する形で開発が進行します。要求具体化要求を実現する要件を策定要件具体化要件を満たす仕様を策定仕様具体化ソフトウェア仕様を満たす実装を行う演繹(えんえき)的

Slide 9

Slide 9 text

従来のソフトウェア開発テストの際は、作られたソフトウェアが仕様、要件を満たしているかをテストします。仕様や要件を答え（期待結果）としてテストができます。要求具体化要件具体化仕様具体化ソフトウェア仕様、要件を満たしているかテスト要求を満たしているか確認

Slide 10

Slide 10 text

機械学習を用いたソフトウェアの開発

Slide 11

Slide 11 text

どんなテストをすればよさそう？ではオススメ機能の例をみてみましょう。よくある機械学習を用いたオススメ機能です。少しだけどんなテストをすればよさそうか思い浮かべてみましょう。例：オススメ機能個別の購入履歴から学習商品を購入した人の購入履歴を入力として、一緒に買う傾向が一番高い商品を出力システムに組み込むオススメ機能 Aさんの購入履歴 Bさんの購入履歴 Cさんの購入履歴 …

Slide 12

Slide 12 text

テストオラクル問題テストをしようにも「何が出力されたら正解か」がわからないですよね。「出力が期待通りかどうかを判定する方法」をテストオラクルといい、今のようにその判定を行う方法がない、その方法が見つからないという問題をテストオラクル問題と言います。例：オススメ機能オススメ機能商品を購入した人の購入履歴を入力として、一緒に買う傾向が一番高い商品を出力ゲーム買おう？

Slide 13

Slide 13 text

機械学習を用いたソフトウェア開発従来のソフトウェアはルールを決めてそれ通り実装し、個別データの処理します。機械学習は「個別の事例（データ）から、特徴やルールを見つける」です。このことが機械学習を用いたソフトウェアのテストの難しさに繋がっています。個別の事例個別の事例個別の事例個別の事例を使って学習し、学習済みモデルを生成するシステムに組み込むソフトウェア帰納(きのう)的

Slide 14

Slide 14 text

従来のソフトウェアとのテストの違い

Slide 15

Slide 15 text

機械学習で見つけたルールが常に成り立つとは言えない

Slide 16

Slide 16 text

機械学習で見つけたルールが常に成り立つとは言えない機械学習では個別の事例を一般化しています。学習データ以外でも、学習した特徴やルールが常に成り立つとはいうことができません。従来のテストでは基本的に「常に成り立つ」を前提にテストをしているので前提から違うのです。機械学習与えられた個別の事例からルールを見つける学習済みモデル？個別の事例

Slide 17

Slide 17 text

同値分割ができない！

Slide 18

Slide 18 text

同値分割ができない！同値分割法は、入力値や出力値を同じ特徴をもつグループにわけて、その代表値でテスト（設計）する方法です。ですが機械学習を用いた機能部分は同値分割法が適用できません。 →猫 →犬 →ハムスター学習出典：idearu

Slide 19

Slide 19 text

同値分割ができない！同値分割法は「入力に対し同じ処理がされるなら代表値で確認する」です。我々からすれば同じ犬に分類されるような画像でも様々なニューロン（ノード）を通り複雑な計算がされており、全く同じ処理がされることがありません。出典：idearu 犬…Pass 猫…Pass ハムスター…Pass 犬、猫、ハムスターがそれぞれ代表画像で通ったからOK!!

Slide 20

Slide 20 text

再学習するとモデル全体に影響

Slide 21

Slide 21 text

再学習するとそのモデル全体に影響データを加えて再学習することはよくあると思います。再学習を行うと全体的に重みが調整されます。出典：idearu 再学習で重みが調整される犬の画像の推論結果がいまいちだから再学習しよう！

Slide 22

Slide 22 text

再学習するとそのモデル全体に影響結果、狙った部分はよくなったものの、他の部分が前より劣化する場合もあります。こういった、変更が全体に影響を及ぼす性質をCACE性(Changing Anything Changes Everything)と言ったりします。出典：idearu 犬…Pass 猫…Fail ハムスター…Pass 今までよかった部分がおかしくなった…

Slide 23

Slide 23 text

機械学習のテスト手法の簡単な紹介

Slide 24

Slide 24 text

機械学習のテスト手法の簡単な紹介（ネコ本より） ● メタモルフィックテスティング ○ 「入力をこう変えると出力はこう変わるはず」という関係をテストする方法 ● ニューロンカバレッジテスティング ○ DNNの中間層のニューロンが全体の内どれだけが活性化したかがニューロンカバレッジ ■ C0カバレッジやC1カバレッジなどの考え方の DNN版 ○ ニューロンカバレッジが 100%になるようにテストデータを追加し検証 ● 最大安全半径 ○ 最大どれくらいのノイズまで推論結果が変わらないかを求める（保証されたロバスト性） ● 網羅検証 ○ 入力データの範囲と期待される推論結果の条件を指定し、範囲内のすべての入力データに対して推論結果がその条件を満たすことを検証

Slide 25

Slide 25 text

メタモルフィックテスティングの簡単な説明

Slide 26

Slide 26 text

メタモルフィックテスティングメタモルフィックテスティングはテストオラクル問題に対応する手法のひとつです。オリジナルの入力と加工された入力に一定の関係があるとき、出力の関係にも一定の関係が成立するという関係性(メタモルフィック関係)を確認しようという手法です。入力データソフトウェア出力データ入力データ改ソフトウェア出力データ加工する関係を評価する

Slide 27

Slide 27 text

メタモルフィックテスティング ● 推薦ランキング生成で、1位商品を候補から抜いてランキング再生成 ○ →2位だった商品が1位になるはず ● 時系列の異常分析で、入力信号をすべて定数値ずらして再分析 ○ →異常と検出されていた入力は、やはり異常と検出されるはず ● ドローンの探索プランニングで、入力地図を90度回転させる ○ →出力されるルートも90度回転されるはず ● OCRで文字に下線を入れる ○ →出力される文字列は変更されないはず JaSST’22 Kansai JaSST’19 Hokkaido より

Slide 28

Slide 28 text

メタモルフィックテスティング ● メリット ○ 出力の期待値が定められない場合でも利用可能 ■ 正解を確認する手法というより「こうした場合は問題がありそう」がわかる ● 例：ラベルづけしてない5万枚の動物画像で、オリジナルの結果とノイズ加えたときの出力結果を比較 ○ 何の動物か知らんけど 2万4300枚目の画像はオリジナルとノイズ入れたデータで出力結果が変わったからそこに何か問題がありそう、など ○ 既存のテストから新しいテストを作ることができる ■ 自動テストしやすい ● 文字の下に線、文字の回転など ● デメリット ○ そもそもの「～ならば〇〇」というメタモルフィック関係を見出すのが難しい ■ ロジックも関係してくる。テストする人だけで判断せず開発者など含め判断 ○ 費用対効果の判断が難しい

Slide 29

Slide 29 text

詳しく知りたい人はこの本で (あとは検索など) AIソフトウェアのテスト　答のない答え合わせ[4つの手法]

Slide 30

Slide 30 text

AIプロダクト品質保証ガイドラインの簡単な紹介

Slide 31

Slide 31 text

AIプロダクト品質保証ガイドラインこのガイドラインはAI プロダクトの品質保証に対する共通の指針を与えよう、という目的で作成されています。

Slide 32

Slide 32 text

AIプロダクト品質保証ガイドライン AIプロダクトの品質保証において考慮すべき軸として、Data Integrity, Model Robustness, System Quality, Process Agility, Customer Expectationの5軸を挙げ、これらのバランスを取ることを推奨している。ドキュメントにはそれぞれの軸のチェックリストも用意されている。 ● Data Integrity ○ 質においても量においても適切かつ充分なデータの確保、学習用データと検証用データが独立しているかなどについて考慮 ● Model Robustness ○ モデルの精度と頑健性、デグレードなどについて考慮 ● System Quality ○ AI プロダクト全体の品質の確保について考慮 ● Process Agility ○ プロセスの機動性について考慮 ● Customer Expectation ○ よい顧客との関係性について考慮

Slide 33

Slide 33 text

AIプロダクト品質保証ガイドラインまた、以下それぞれのシステムに関して品質保証について記載されている ● 生成系システム ● VUI (Voice User Interface) ● 産業用プロセス ● 自動運転 ● AI-OCR

Slide 34

Slide 34 text

最後に。私はこんなことに遭遇しました

Slide 35

Slide 35 text

前処理のUnit testしてない (機械学習以前の問題)

Slide 36

Slide 36 text

前処理のUnit testをしていない雑談エンジンのように入力に合わせ「元気元気ー」などと文字列生成する、株価予想のようにデータを入れたら上がる下がるを返すようなモノ、つまり結果を見ても「そっかー」と思うようなものを想像してみてください。まずは実験段階でイイカンジのモノができます。【実験段階】定性評価でイイカンジだった !!

Slide 37

Slide 37 text

前処理のUnit testをしていない実験でイイカンジだったので早速プロダクトに実装していきます。ですが実装時に前処理にバグがあり、想定したものとは異なるデータが送られてきていました。これは実行結果から気づくのは非常に難しいです。（再検証時にようやく気づく）前処理にバグがあったが、テストしてないのでわからないこんにちは！！え？急にどうしたの？その株は爆上がりするので買いですほなポチるわ

Slide 38

Slide 38 text

作り手が別だったり最後にまとめてテストすることに慣れた組織がやりがち

Slide 39

Slide 39 text

入力パターンが爆発しがち

Slide 40

Slide 40 text

入力パターンが爆発しがちスマートスピーカーの天気を聞く機能を想像してみてください。聞き方のパターンは非常に多岐にわたります。これらをエンド2エンドで声でテストするのは困難です。青森県の天気は？青森市の天気は？青森県青森市の天気は？天気は？天気教えて / 天気”を”教えて傘いる？ / 傘”は”いる？晴れる？ / 晴れるかな？様々な言い方でもちゃんと天気として認識できる？

Slide 41

Slide 41 text

入力パターンが爆発しがちスマートスピーカーの雑な説明音声認識自然言語理解占い天気音楽音声合成今日の青森市の天気は？機能：天気時間：7月13日場所：青森市

Slide 42

Slide 42 text

入力パターンが爆発しがち対処した方法としては、Pairwise法で組み合わせを作り……

Slide 43

Slide 43 text

入力パターンが爆発しがち「様々な言い方でも天気として認識できるか」を目的としたテストだったので、自然言語理解に組み合わせたクエリを送り、返ってきたデータが期待値通りか確認音声認識自然言語理解天気音声合成 Test Automation 今日の青森市の天気は？機能：天気時間：7月13日場所：青森市

Slide 44

Slide 44 text

入力パターンが爆発しがち天気機能が、自然言語理解で分解され送られた入力に対して適切なデータを返せるかは別テストでやったほうがいい（当時の僕はまとめてやっていて、すごいゴチャったテストになっていた記憶）音声認識自然言語理解天気音声合成入力に対して適切な天気データを返せるか確認する目的のテストは別でやったほうがいい（僕の時は外部サービスだったけど）

Slide 45

Slide 45 text

● 入力パターンの爆発はぶっちゃけゴリ押した ● テストの目的に応じてスコープはわけて確認した方がいい ● タスク指向のプロダクトの場合入力パターンは多いけど出力は決まっている場合も多い

Slide 46

Slide 46 text

おわり