JaSST19Tokyo 基調講演 「AI-Driven Testing: A New Era of Test Automation」を聴講した

ギジュツショテンの原稿に追われていた&風邪を引いて指先ひとつでダウンしていたという個人的事情で遅くなりました、JaSST 19 Tokyoのレポートになります。

初日の最初にあった、Tariq King氏による基調講演「AI-Driven Testing: A New Era of Test Automation」を聴講しました。

Tariq King氏は現在Ultimate Software社で働いていて、もともとはアカデミックな世界にいらっしゃった方だそうです。

講演の前に、Tariq氏がSecond Authorの論文Microsoft Word – SantiagoKingClarke_PNSQC2018_CameraReady.docx(PDF)を読んで臨んだところ、特にAIやMLについての基本説明の部分も余裕を持って聞けたので有意義でした。

内容は主にAIの、特にソフトウェアテストにおける可能性についてのお話でした。

講演の概要

今まではテストオートメーションと言っても、実際には手動な部分も多くありました。自動テストのスクリプトは人が書かなければいけないし、自動テストの結果は人間が確認しなければいけなせん。現状では、完全に自動化されたとは言えません。Tariq氏は「本当の意味でソフトウェアテストを完全に自動化したい」と考えているそうです。そこにAIが絡んできます。

Tariq氏はAIとソフトウェアテストの関係として

  • AI-DRIVEN TESTING
  • TESTING AI SYSTEMS
  • SELF-TESTING SYSTEMS

の3つの要素を挙げました。それぞれの意味合いとしては、

  • AIを使ってテストをする
  • AIを使ったシステムをテストする
  • 自分自身をテストするシステム

になります。今回の講演では1番めのAI-DRIVEN TESTING=ソフトウェアテストにAIをどう用いるか、に特に焦点を当てて話をされていました。

AIを用いた自動テストのデモとして、例えば画面UIの要素を機械学習によって理解させ操作することや、テストケースの生成も一部見ることができました。

聴講して感じたこと

私はもともと自動テストを主にやっているので、「AI使ってますよ」とうたっている自動テストツールを試したりもしていました。その中で思っていたのが、現状のAI駆動テストツールは既存のテスト自動化関連作業の一部を楽にしているに過ぎないんだな、ということ。しかしTariq氏の話を聞いて、現状はまだ「本当の意味でのテスト自動化」を目指している途中であって、もっともっと先を見ているんだと理解。気持ちの面ではここが一番、個人的にインパクトがあったところでした。

メモ

  • AI の可能性、ソフトウェアテストがどのように変わるか
  • これからイノベーションが起こる。今まで我々は寝ていた
  • テスト自動化を再定義
  • オートメーションが何を意味するか正確に理解する
  • 全員が同じ定義でソフトウェアテストの話ができるように
  • コミュニティづくりをしてきた
    • AISTA
  • automation の定義
    • 独立して何かができる
  • ソフトウェアのテスティングはマニュアルテスティングが多い
    • 私自身はマニュアルテスティングが嫌い
    • Automation という言葉を使いつつも実際にはマニュアルだ、ということがある
    • 「正しさ」を定義して、テスト方法論を使ってシナリオを作り上げる。そんな必要がある。そのへんの設計とかシナリオ作るとか結局人手でやってる。
    • そこから結果が出てきても、人間が確認しないといけない。
    • 実は、テストは全部マニュアルなんだ、というのが自分の考え。
    • 完全に自動化した、というのとは違ったものになっている。現状。
    • 本当の意味でソフトウェアテストを完全に自動化したい。
  • 最終的には自分で自分をテストできるところまで持っていけるのでは
  • この KeyNote では AI 駆動のテストにフォーカスする
  • AI って何?ML って何?
    • CS の1分野
    • 機械が Inteligent なふるまい、知性を模倣する
    • 別の考え方では、IA の研究である
      • Inteligent agent
  • ML とは
    • AI の一分野
    • プログラミングモデルを使う
    • 人間のこどもの学習と人間の学習の違い
      • 機械には命令して学ぶ
      • 娘は命令を聞かない
      • 経験して学ぶ
    • 機械学習
      • プログラムが経験をする
      • 答えはデータにある
    • 分類:Classifitcation
    • 機械学習のカテゴリ
      • 教師あり
      • 教師なし
      • 強化学習
  • ニューラルネットワークの話
  • ソフトウェアテストにどう適用したらいいか
    • プログラムを Function f と考えて、input / output を考える
    • d を f に与えて、f(d)が得られる
    • f(d)が許容できるか?(OK(d)なのか、NG(d)なのか)
    • P25
    • ideal test
    • input をなんとか有限に抑えるか、重要なものに絞るか
    • ソフトウェアにフィーチャを追加すると複雑度が上がる
    • AI と ML を使うことによって、カバレッジを上げる
      • P28
  • 現実の世界ではどうか
    • 様々な AIDriven なツールがある(みんな、なんとかしようとしている)
  • AI 駆動のテストを細かくみていく
    • P32
    • EXPLORE:要素の理解を機械学習
      • 画像で
      • DOM で
    • MODEL:
      • 不確かさを扱うことができる、確率論的モデル
      • 人間の行動を模倣
    • INTERACT
      • 行動生成
    • LEARN
      • 学習
    • BOT の能力
      • 監視
      • 分析
      • 計画
      • 実行
  • OpenSource で出してる
    • ultimate software のリポジトリを見て
  • appium + test.ai も
  • デモ
    • 画像を使ったトレーニング
    • テストケースの生成
  • AI の知識を身につけて
  • テキスト生成
    • AI に物語を書かせてみた
    • P40
    • テストでも使えるのでは、と思った
    • マシンにセンテンスを与えて、テキストを生成される
    • 抽象テストの言語を作った
      • トレーニングデータをいちいち作らなくとも推測
      • P48
  • 限界もある
  • リアルタイムで自分自身をテストし続けなければならない
  • AI-DRIVEN TESTING, TESTING AI SYSTEMS, SELF-TESTING SYSTEMS は切り離せない
    • コミュニティで包括的に考えていくべきこと
  • Q&A
    • AI 使ってテストをした場合、信頼関係、などなど
      • 今だって 100%納得しているわけではないと思う
      • 必ず何かしらある、と分かっていて出荷している
      • AI では、マシンの信頼度を定量化できる点が良いのでは
      • 人間に取って代わるのではなく、支援・サポートである
    • TestGeneration、エージェントの話。アウトプットのほうの研究はしたか。
      • システム全体をコマンドセンターのようなものにする
      • ちょっとよくわからなかったので調べる
      • テストを生成するとき、たくさんのダッシュボードが必要だった
      • 複数の失敗があったときに、単純化(重複排除)できる
    • テスト環境などによってはクラッシュ引き起こしたりしそう。動作の制限てどうやってやるの?人間を上手に模倣すると、かえって探索の幅が狭くなる(ランダム性が減る)のでは?
      • 2つのゴールを1度に達成するのは難しい。できるだけ探索してほしいけれども制限もしたい、ということは。
      • スコープを制限する。テストをする世界を制限する。
      • アクションを制限する。
        • このタイプのテストを生成してやってほしい。とか。
      • スコーピングできるようなフィーチャがないといけない。
    • テストの予想結果を機械に教えてあげるためには?どうやって実現する?
      • 予想通りのふるまいをするかどうか、ほかの行為はしないか、というドメインナレッジ(=脳の中にある)
      • 魔法はない。実際は。
      • 専門家が学習させる
    • 画面がないものに対してもっと早く AI を使ったテストをする研究とかはある?
      • 入力と出力である。UI があろうがなかろうが。
    • この世界の将来図をどうとらえているか。1つは汎化していくのを目指すのか、ドメイン特化技術をいくつも作って組み合わせるのか。2つめは、Self-healing や Self-configuration という言葉があったが、この辺の将来。いつごろどんなものが出てくるか。
      • 普通、GeneralSolution でいったら問題は解けない。汎用的なソリューションを作ると「自分が知っていること」で制限がかかる。汎用にはやらないほうがいいと思う。General でやってる人は誰もいないのでは?
      • そのドメインでの General なもの、を目指している。
      • 「他にも適用できるな」と思えばそれはそれでいいのだけれど、それは汎用的とは違うと考えている
      • ドメインの人たちがその中で頑張ってやって、他に共有していくことで、じゃあ一緒に General にと向かっていけるのでは
      • 2つ目はよく聞かれる。昨日も聞かれた。
        • いつ、というのは、我々コミュニティの努力次第である。

この記事を書いた人

yoshikiito

都内でテストエンジニア&ブロガーをやっている@yoshikiitoです。

ソフトウェアエンジニアの学習方法や成長するための考え方、会社に依存せず自分の力で生きていけるエンジニアになる方法などについて興味があります。
こういった方法や考え方、自分が試したことなどをブログを通じて発信します。

仕事は主にソフトウェアテストやテスト自動化。
趣味は浦和レッズと読書と技術書を買って積むこと。

技術評論社から本を出すのが夢