はじめまして、ミストレイです。
先日京都にて開催された「JaSST’22 Kansai」に参加してきました。
本記事はそのイベントレポートとして、講演内容を簡単にまとめたものになります。
今回のテーマは「テストオラクルのない世界」です。
テストオラクルとは
まず、テストオラクルとはなにかという話なのですが、
JSTQBの用語集ではテストオラクルについて、以下の様に説明されています。
テストオラクル（test oracle） テスト対象のシステムの実行結果と比較する期待結果のソース。
参照：ISTQB Glossary
私なりの言葉に言い換えると「システムテスト時の期待結果の根拠となるもの」となります。
こちらには、様々なものが該当しますが、筆者としては、主に下記3つがテストオラクルになりうると考えています。
1)開発者の仕様書
2)利用者や依頼者がシステムに求めている機能
3)他システムでも用いられている一般的な挙動や仕様
それぞれ簡単に解説をしていきます。
1)「開発者の仕様書」
こちらは開発者が「このように作成した」という資料となります。
テスト時には、こちらの仕様書を参考にしながら期待結果を導きだす事が多くあります。
しかし、開発者の考慮不足等により、後述する2)「利用者や依頼者がシステムに求めている機能」を満たせていない場合もある為、全て鵜呑みにする訳にはいかない事もあります。
2)「利用者や依頼者がシステムに求めている機能」
こちらは、利用者や依頼者からの「どのような機能が欲しいか」「どのような挙動になって欲しいか」という、依頼者や利用者が求めている事になります。
こちらも、技術的に不可能ですべての要望を満たせていない場合もあり、妥協案として1)「開発者の仕様書」が作成される場合もある為、1)と2)の複合的に考えて期待値を導き出します。
3)他システムでも用いられている一般的な挙動や仕様
こちらは、例えば「入力誤りがある場合にエラーが発生する」といった、別システムでも用いられている一般的な挙動です。
1)「開発者の仕様書」に記載している場合や2)「利用者や依頼者がシステムに求めている機能」に含まれている場合もありますが、そうではない場合も、一般的なシステムと比較して、「こうなるべき」「こうなっていると使用しやすい」という期待値を導き出します。
今回のテーマ「テストオラクルがない世界」とは、
昨今のAIなどの、期待結果に絶対的な指標がないシステムに対してどのようなアプローチで
期待結果を導きだすかというテーマのようです。
当日の様子
今回も前回開催された「JaSST’22 Tohoku」と同じくオンサイトとオンラインでの
ハイブリッド開催となっており、私はオンサイトで参加しました。
オンサイトでは、大学のホールにて行われており、PCやタブレットを持ち込んで参加する方が多かったです。
質疑応答用のサイトは用意されており、公演者への質問は行えましたが、今回は残念ながら、参加者同士の交流用のチャットなどはありませんでした。
公演に対する他参加者やオンライン参加者の議論や意見などにもとても興味があったのですが、今回は確認する事は出来なさそうです。
※「JaSST’22 Tohoku」も別の方が参加した際のレポートをブログ化としておりますので、
興味のある方はそちらもぜひご確認下さい。
■「JaSST’22 Tohoku：テスト自動化その前に ～テスト自動化アンチパターン～」
スコープ
本記事では、特に興味深かった以下のセッションについてまとめました。
・基調講演：テーマ「正解がないシステムをテストする」
・招待講演：テーマ「『よわよわエンジニア』から『つよつよエンジニア』へ」
基調講演
講師：石川冬樹 氏 (国立情報学研究所)
テーマ：「正解がないシステムをテストする」
■近年のテスト事情
従来のシステムは主に計算・検索・予約など期待値が一意に定まっている処理が多かった
→近年はその場の状況に対して複雑な処理を行い、期待値が一意に定まっていない、正解がないシステムをテストする機会が増えてきた
▼正解がないシステムの例
・自動運転の経路選択
・教育コンテンツの推薦
・配達ロボットサービス
・画像生成、動画生成
・画像認識…等
このような「どのような結果であればOK」という基準が曖昧なシステムをどうテストするか？
■疑似オラクルの従来技術について
従来の技術として、テストオラクルがないシステムに対して、疑似的にオラクルを作成して、それをテストオラクルとするという方法がある
・疑似オラクルの従来技術1)：Ｎ-Version Programming 同等の技術を持つ比較対象を用いる方法
・(同じ不具合が発生しないように)別の人・方式で作成したシステムを比較する
・汎用的に機能など、オープンソースや他社製のものを利用出来る場合には、そちらを利用して比較する
・疑似オラクルの従来技術2)：Metamorphic Testing
・入力を変えると出力はこう変わるはずという関係性に着目する方法
例1) ：推薦ランキング生成
1位商品を候補から抜いて再度ランキング生成を行う
→2位だった商品が1位になるはず
例2) ：時系列の異常分析
入力信号をすべて一定の値ずらして再分析を行う
→異常検出されていた入力値は、こちらでも異常と検出されるはず
例3) ：ドローン等の経路選択
90度回転させた地図を入力する
→方角が変更されていても同じ地形の為、出力されるルートは90度回転したものに変更されるはず
■疑似オラクルの従来技術の悩ましい点
▼Ｎ-Version Programming
・同様のシステムを複数作成するのは開発するコストが単純に2倍近くになる為、
費用対効果が悪く、既存のものがある状態に限られてしまいがちになってしまう
▼Metamorphic Testing
・「テストの為のテスト」や「バグ探しの便宜上だけのテスト」と思われてしまう事がある
・現在の汎用的な指針は、テスト条件に対して「追加・削除・並び替えなどのパターンから模索」する程度のものしかない
■機械学習型AIのテスト
・機械学習型AIは、画像識別や自動翻訳など規則性を書きだす事が困難な機能であっても、 過去のデータを蓄積する事で実現する事が出来ますが、下記理由により期待値の設定が困難になっている
・給与判断などの正解を設定するものが難しいケースや推薦システム等の本来正解がないケースがある ・分類や予測が100%成功する事はない為、「結果が合わなければ、不具合である」といった、従来の価値観を適用出来ない
・また、その結果がプログラムミスによるものだった場合でも気が付く事が難しい
・的中率何%になれば合格といった期待値設定もどこまで精度をあげる必要があるのか、どこまでの精度を求められているのかなど、判断が難しい
上記により、機械学習型AIのテストでは、
前述のMetamorphic Testingを適用して疑似的なオラクルを作成してのテストが多く行われている
■機械学習型AIに対してのMetamorphic Testingの適用例
例1) ：機械学習の訓練済みモデルへの適用
・頑健性(ノイズに対する耐性)のテスト
▼具体例
・画像認識システムにて、入力する画像の雨がないパターンと雨があるパターンで似たような結果となるか
※現実ではこのようなテストが多く実施されている
例2) ：機械学習の訓練パイプラインへの適用
・機械学習を行う際の訓練用データセットに特定の変化を加える
▼具体例
・画像認識システムの訓練用データセットの画像の海を色を変更して、学習させた際に、同様の結果となるか
※実装バグの検出の可能性は上がるが、現実的にはここまで行うかは悩ましい
■これからの機械学習型AIのテスト
・予測性能や実装の正しさだけではなく、現実世界の様々な状況に対応したデータの蓄積や、公平性や倫理観等の、より現実世界や人間に踏み 込んだ品質が求められるようになった為、これらをどのようにテストしていくかが課題となる
■まとめ
・疑似オラクルの技術ももちろん必要だが、そもそもそのシステムで重要な事と向き合ってテストを行うべき
・現実世界・人間に踏み込むシステムが開発され、扱う品質が多様化している(公平性/倫理/満足度…)
・不具合検出に限らない様々な価値を追求するテストを行う事が理想
■所感
近年のAI等の期待結果が一意に定まっていないシステムに対する、アプローチや今後のテストのあるべき姿など、具体的な事例を交えて解説をされていて、とても参考になりました。
今後のテストに求められている様々な品質に対応する為に、様々な事例や知識を蓄え、よりよいテストを行っていきたいと感じました。
招待講演
講師：山田一夫 氏（日本ビジネスデータープロセシングセンター）
テーマ：「『よわよわエンジニア』から『つよつよエンジニア』へ」
■これからのエンジニアへの要件
・技術の進歩、API/lotのツール、モバイルOSの脆弱なアプリ等により、ハッキングが容易になっている
・現状では、セキュリティ領域はセキュリティ会社に委託しているケースがほとんど
・開発の最後の工程で行う脆弱性診断により、工程の手戻りが多く発生し、開発工程の遅延、コストの増大が発生している
・開発初期からセキュリティ会社に入ってもらうケースもあるが、その分開発コストも増加し、利益が減少してしまう
→上記のような要因からこれからのエンジニアにはセキュリティ領域のスキルも必要
・セキュリティスキルには各工程で行うべき事があるが、
4の脆弱性診断のスキルから習得するのがおすすめです。
▼開発工程に対応するセキュリティ工程
1.要件定義+セキュリティ要件策定
2.設計工程+セキュリティ設計
3.実装+セキュアコーティング
4.各種試験+脆弱性診断
▼理由
・1のセキュリティ要件策定のスキルから習得しようとすると、後の工程で実際に求められている要素を正しく抽出する事が難しい為、必要以上の要件策定や設計を行ってしまう可能性がある
・4の脆弱性診断のスキルから習得し、最終的に脆弱性と呼ばれる事例を理解してから、
徐々に実装フェーズや設計フェーズに反映させていく方が、業務上の無駄なく習得出来る
これからのエンジニアはセキュリティのスキルも同時に習得し、『よわよわエンジニア』から『つよつよエンジニア』へ！！
■セキュリティスキルの習得方法
・Webアプリケーションの重大なセキュリティリスクをランキングと事例の公開を行っている、OWASP TOP10を活用し、実際の脆弱性を確認しながらを理解を深める
・脆弱性診断の基礎知識を学ぶ手段として、脆弱性診断のスキルマップが公開されている
【参考】Webアプリケーション脆弱性診断ガイドライン
・脆弱性診断を実践する場として、「OWASP BWA」「OWASP JuiceShop」等の意図的に脆弱性をもたせたWEBアプリケーションがある
・「BURP SUITE」「PortSwigger」等のWEBサーバーとブラウザ間の通信内容を確認可能な、脆弱性診断専用ツールがある
■セキュリティ品質向上に向けての提案
提案1)：定期的に脆弱性のランキングであるOWASP TOP10や脆弱性の集約DBにて、傾向を把握して重要な脅威にのみ努力を集中する
※近年の傾向としては、 2020年ごろから急激に「アクセス制御」の脆弱性の報告が増え始め、現在も増加傾向！！
提案2)：社内向けバグバウンティプログラムを導入する
▼バグバウンティシステムとは
- 企業のウェブサーバスやアプリケーションにセキュリティ上問題となる脆弱性がないかどうか、世界中のハッカーに依頼し、発見されたバグの重要度に応じて、報奨金を支払う仕組み
※2021年のバグバウンティプログラムの報奨金の合計は約48億円！！
このバグバウンティプログラムを社内向けに導入し、自社システムの脆弱性を発見した方に報奨金を出す事により、社員のセキュリティへの意識を高め、自社システムのセキュリティ向上に役立てようという提案
■まとめ
- 今後のエンジニアはスムーズに開発を進める上でセキュリティスキルも必要
- 脆弱性を意図的に含んだテスティング環境を利用してセキュリティスキルを習得
- 身に着けたセキュリティスキルをテストから設計へと可能な所から着手
- 世界レベルでの情報を収集とスキル習得を常に継続
- 現在世界で活用されているバグバウンティプログラムを社内に適応して品質向上を目指すという手もある
■所感
これからの開発工程では、セキュリティスキルが必須レベルとなってきており、
テスト工程で脆弱性診断を行うだけではなく、開発の全工程に適応が必要な事が分かりました。
今後自分でも、セキュリティに関するスキルを身に着けたいと強く感じました。
また、世界で行われているバグバウンティプログラムを社内向けに導入しようというのは面白い試みだと思いました。
総括
今回のような公演会に参加するのは初めてでしたし、全く知らない知識やこれからの課題などとても興味深いお話を多数聞く事が出来ましたので、とても有意義な時間でした。
また、疑似オラクルの方法やセキュリティスキルを習得し、業務に活かせそうな内容はどんどん活かしていきたいと感じました。
