ほぼ毎年恒例、JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyoに行ってきました。今年はAI x Testing（AI for TestingとTesting AI）の話多め。
以下、聴講したセッションのメモ。
- AI-Driven Testing: A New Era of Test Automation
- テストの未来、品質の未来 ～自動化はテスター撲滅の夢を見るか？～
- AI-based static analysis for clean code
- AIプロダクトに対する品質保証の基本的考え方
- ゲームのテスト：三銃士モデルを適応してみた！ -Next Generation 次世代の挑戦-
- UX／マイクロサービスアーキテクチャー時代の自動テスト戦略
- 人工知能は何ができて何ができないのか
- 人工知能の未来 ～その未来をどうテストし、どうテストに活用するのか～
AI-Driven Testing: A New Era of Test Automation
Ultimate SoftwareのTariq King氏による基調講演。
- Automationとは、独立してできること。テスト実行を自動化しても確認がマニュアルでは当の自動化ではない。AIで完全な自動化を目指す
- AIST(AI for software testing)は以下を含む分野と定義
- AI driven testing
- testing AI systems
- self-testing systems
- コミュニティが必要なので作った -> AI for Software Testing Association
- 今日はAI driven testingにフォーカス
- testingに使う
- input:d -> program(function) -> output:f(d)
- f(d)は受け入れ可能か？
- 機械学習のモデルも似ている
- domain:dx -> program -> range:OK(d1),OK(d2),,,
- 機能を追加するとcomplexityは増えていく
- coverageも上げるけど追いつかない -> カバレジギャップ
- 解決したい
- AI driven testing: a new era of test automation
- test.aiのJason Arbonと一緒にやっている
- explore 画像で画面とかを学習
- model
- interact
- プロトタイプを公開している
- 『不思議の国のアリス』を解析して再生成する試み
- AI driven test generation
- abstract testの記述言語を作った
- if "first name"が出てきたら
- when 空有白を入れてsubmit
- then エラーが出る
- トレーニングデータ不要
- 限界はある。次に何をするのかわかってない。信頼できるか？
- self testingし続けないといけない。リアルタイムで
Q&A
AIによるテスト結果を信用できるのか
- いくつか取り組みがある
- ブラックボックスでない、説明可能なAI
- AIそのものをテストできるようにする
- それでも100%納得されないかもしれないが、それでも今よりまし。マニュアルでもバグはある。100%でない
- 100%でなくても、数値化・定量化できるのは利点
- ミッションクリティカルなところには適用できないかも。人間の支援として使うとか。それでも、なにもしないより、AIを使うほうがはるかにいいはず
large volume output
- "Pterodactyl"というプロダクトに最初に取り組んだ
- ダッシュボード、複数の問題を集約したりできる
usability testingはできるのか
- 事例さえあれば。このボタンがわかりにくい、このデザインは見づらい、みたいな事例を学習させることで可能
- applitools.comでVisual Testingをやっている
Agentにやってはいけない動作を指定できる？ より探索的にすることはできる？
- ふたつのゴールを同時に達成するのは難しい
- なにもないと、すべてのリンクを見つけてクリクしてしまうので、スコープを制限する機能はある
- アクションを制限することもできる。コンフィグレーションを作る必要はある
- スコーピングする機能は必須
仕様とか検証内容をどう教える（定義する）のか
- ソフトウエアが予想どおりの動きをするかの予想。ドメインナレッジ。人間の脳の中にある
- システムに、ある特定の分野のドメイン知識を入れる必要がある。専門家がトレーニングする
- まだ時間がかかるが、構築する必要がある
- amazonとかgooogle mapから「これ正しい？」という質問が来る。これはトレーニングに使われている
学習モデルは汎用的？
- まだ教育ツールの段階。これにトレーニングしてテストに使う。まだ汎用的ではない
- App Storeのアプリでトレーニングしている人はいる（test.aiのこと？）
- 汎用的なものは目指したいが、モバイルとデスクトップはまた違う
UIのテストのみ？
- input/outputがあればできる
将来像について。汎用化は全体なのか、ドメインごとに特化したのを組み合わせるほうか
self healingなどいつごろ実用化されそうか
- いつ？というのは、コミュニティ次第
テストの未来、品質の未来 ～自動化はテスター撲滅の夢を見るか？～
各社でテスト自動化に取り組んでいる方々によるパネル。まず体制とロールについて。
- 山口さん＠Yahoo!
- Devのチームで品質も見る。QAというロールもプロセスも存在しない
- 支援の横断的チームはある
- 大園さん＠LINE福岡
- 横断的チーム：テスト自動化、SET、QAがある（わかれている）
- 木住野さん＠LIFULL
- 横断的チーム：SET, QA
- SET（QAから分離）：リリース前E2E自動テストと、依頼があれば自動化支援
- 根本さん＠メルカリ
- SET -> Automation&QAグループ(AQA)
- 各プロジェクトにQAが入っている
- 横断的チーム：AQA, iOS Dev, Frontend Dev, Backend Dev
- 松尾さん＠今回はクックパッドの話ベース
- 各プロジェクトにQAが入っている
- 横断的チーム：モバイル基盤グループ(QIT)
アンケート結果について
- テスト自動化への期待と結果
- 素早いフィードバックが期待も結果も多い
- コスト削減は期待にはあるけど結果にはない
- テスト自動化の課題と対策
- フレーキー
- 不安定なテストを書くのは後回し、価値の出るところから優先
- 自動化チームがいない、立ち上げが難しい、人がいない
- Yahoo!の規模（Devが3,000人）になると、Devがみんなテストできるようにならないといけない
- なにを対象とするか、どのテストを自動化するか、準備や計画ができていない
- 手動テストを自動化しようとしてしまう
- テスターがスクリプト書けない
- 自動化チームがマネジメント層やテスター他の関係者から十分なサポートを得られない
自動化はテスター撲滅の夢を見るか
- 自動化チームは必要か
- 必要：技術のキャッチアップとか手がまわらないので必要
- 不要：開発チームがやるのが適切なはず
- QAは必要か
- サービスによる：Webだと手厚くQAするより、手早くfix&releaseするほうがいい。組み込みとかだとQAは必要
- テスターは必要か
- 不要 → 部分的に置き換わる
- 仕事内容が変わる：多様化
Agile, DevOpsがあたりまえの時代に求められる人材とは
- プログラマが出せない価値を出せる人（山口さん）
- 誰もやっていないことに果敢にチャレンジする人（大園さん）
- 技術スキルを持ち、継続的な改善を推進する人（木住野さん）
- 越境する人（根本さん）
- 学びを続けられる人（松尾さん）
まとめ
- テスターの仕事は自動化によっておきかわるか
- すくなくとも、"置き換わらない"は0%
Q&A
未来への投資と目の前の仕事とのバランスについて
- 会社が挑戦していい風潮だった（大園さん）
所感
- 個人的にもYahoo!さんの体制が理想だと思っているので、大手の話だからで終わらせず、そこを目指していくべきだと思う
- 自動化チームは必要かのところ等、自動化チームのロールが曖昧なところがあった気がする*1ので、ややはっきりしない点はあった
他のブログ記事
AI-based static analysis for clean code
Gammaの紹介
- ルールベースのstatic analysisは役に立つが、限界もある
- コミットログを学習してレコメンドするエンジン
- すばやくフィードバック
- サジェストはIDEプラグインを提供（今はEclipseのみ？）
- 学習モデルはインクリメンタルに更新可能
- 学習モデルは3段階
- Project
- Organization
- Community: オープンソースから学習
- オープンソースリポジトリでの利用なら無料で使える
AIプロダクトに対する品質保証の基本的考え方
スライド(pdf): http://qa4ai.jp/QA4AI.JaSST-Tokyo.20190327.pdf
- 機械学習を使用したシステム
- CACE性(change anything, change everything)
- 非線形で同値分析できない
- 石川先生のスライド参照
- QA4AIコンソーシアム
- 5つの軸
- Data Integrity
- Model Robustness
- System Quality
- Process Agility
- Customer Expectation: 良くも悪くも、顧客の期待
- 合理的説明・原因・責任を求めるような客。悪い意味で期待値が高いということ
- 期待値コントロール：低く保ちたい
- バランス
- レーダーチャートは5軸でもいいし、Customer Expectationを除いた4軸でもいい
- 数値化は任意なので感覚的なものになる？
- プロセス
- テスト
- ニューロンカバレジという試みもある
- メタモルフィックテスティング：今のところ名前がついてる有効なテスト方法はこれだけ？
- GANでエラーを探す：GANをQA側で組まなければならない
- 品質の保証とはなにか、をもう一度考え直す必要がある
Q&A
Process Agilityがあったが、なぜアジリティなのか
- 不確実性に対処するためにサイクルをまわす
- 機械学習は、規則性があるかすらわからないので
- Process Qualityでなく、あえてAgility
説明可能性
- 間違えたら、なぜ間違ったのか。狼とシベリアンハスキーを見分けるモデルで、実は背景の雪を見て判断していた話
- 全部説明する必要はないけど、ドメインによっては（銀行のローン審査とか）は、理由が説明されなければならない
System Quality
- AIの寄与度を抑えられているか、という項目はなぜ？
- 不確実性は持っているので、それを抑えられているか、という話
- 守るべきものは、仕様書に書かれる
確率的なので、外れたものを人間が即異常値と判断していいのか。学習途中では許容できたりしないか？
- メモできておらず
ルールベースと機械学習の比率は、ドメインによって違う？ 議論はされている？
- それはネクストステップ。今はまだコンソーシアムとしてはやってない
- 個人的には、そもそもルールベースでは解決できないことをやってるものもある。自動運転とか。なので、都合よくルールベースというわけにはいかないと思う（石川先生）
- かならずしも同じものを実現するとは限らない
- 例外、制約、セーフティネットはルールベースになっていきそう
ゲームのテスト：三銃士モデルを適応してみた！ -Next Generation 次世代の挑戦-
三銃士モデル
- 世界観、コンテキスト、実装。中心にユーザ感情
- テスト観点を構造化する。マインドマップ
- 観点の中に「環境」がある。機種とかOSバージョンとかはここ
- ジャンルによっても異なる
- 単一観点から入って複合に進む
ゲーム業界の○○テスト！？＠KLabさん
- ISO-29119-10 Games Testing（2019/4執筆完了予定？）
- そもそも、ゲームのテストタイプにはなにがあるのか、研究会で考えてみた話
三銃士モデルを現場適用してみた＠アカツキさん
- フリーデバッグ（探索的テストみたいなもの。各社で定義は違う）
- 前倒して実施するようにした。リリース延期とかになるので
- バグ摘出できるのはベテラン。人数を増やしても無駄だった
- そもそも、テスト手順があいまい、組み合わせ条件が甘いなどが問題
- マインドマップで整理してテスト項目にフィードバックすることで事前摘出できるように
UX／マイクロサービスアーキテクチャー時代の自動テスト戦略
- テストピラミッドのIntegration Tests以下をフロントエンドとバックエンドに分ける話
- ファクトベースで振り返り
- 品質はチームで守る意識が芽生えた
- テスト設計、実装、レビューまでやることで意識が芽生える
- 自分たちでテストレベルやテスト密度・手法について考えるようになった
- APIテストは、要件定義からテストチームが入っていた
所感
- そもそもE2Eテストでないならフロントとバックを分けてテストしているものだと思うので、主張はよくわからなかった
- 振り返り、開発チームがテストを書き、品質に関する意識が上がったという話はとてもよかった
人工知能は何ができて何ができないのか
はこだて未来大学の松原先生による招待講演。
- AIに明確な定義はない（そもそも"知能"が定義できてない。知能を定義することが目標？）
- 個人的には鉄腕アトムを作りたい
- ヒューリスティック。いいかげんなIT。アルゴリズムで100%うまくいくようになった分野はAIから"卒業"するので、AIはあいまいな状態が続く
- AIは今、3回めのブーム
- 将棋・囲碁も40年前は絶対無理と言われていた
- エキスパートシステム
- スコアはそこそこ出たけど、ときどきとんでもない間違いをする
- ナレッジを持っている人の、無意識・暗黙知は反映できない
- 創造性はコンピュータにも持てる。将棋、機械学習
- 学習データのマネだけでない新手を指した
- プロの寄付から学習→教師を超える→AI同士で対局して強化学習→強くなったけど、ブラックボックスで人間は理解できない。解説できない
- 俳句。生成できるけど、良し悪しを選んだりできない。まだ評価できない
- 将棋などのゲームは評価基準が明確で、その点はやりやすい
- 100m競争で機械にまけても悔しくない。体力で負けることは経験がある（動物にも負けてる）。でも将棋で負けると悔しい
- AIの社会実装の試みの例
- 公共交通を持続可能にしたい
- リアルタイム乗り合いサービスを提供。SAVS(smart access vehicle service)と呼んでいる
- 技術の中心はエージェントシステム
- 18-19世紀、肉体労働が機械に置き換わっていった。ラッダイト運動
- 21世紀、ネオ・ラッダイト
- 一部の頭脳労働（とみなされていた仕事）にすでに影響が出ている
- 人間とAIのこれから
- 人間とAIで役割を分担する
- 人間＋人工知能として賢くなっていく（人間の概念が拡張されていく）
- 賢くなったAIを人間が受け入れるにはある程度の「とき」が必要と思われる -AIもテストしてもらえる時代になった、という感想
所感
- "一部の頭脳労働（とみなされていた仕事）"という表現が好き。AI以前にITで減らせるはずの仕事はあったので
- "AIに明確な定義はない"ということなので、キズナアイちゃん親分も間違いなくAI
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/03/16
- メディア: 単行本
- この商品を含むブログを見る
人工知能の未来 ～その未来をどうテストし、どうテストに活用するのか～
ヒューリスティックを前提とすると、品質は？ 品質とはどう定義するのか
- 正解率の話なら、正解率でいい。正解のラインが決まっているのなら
- 正解がなにかがわからない分野にAIが使われているし、その評価が難しい。点数をつける基準をつけたり、人の感性でチェックする
システムの一部にAI
- AIは、作ってみるまで価値はわからない。前例がないと特に。データに規則性がちゃんとあるのか、それを特徴点として取り出せるかわからないので
- 文化が違う、試行錯誤、研究に近い開発
AIをAIでテストするとき、指針がほしいのでは。くれって言われない？ > Tariq
- オフラインでのバリデーションでは十分ではなくなるかも
- トレーニングによってその環境に適応していくことがある
- 基準を設けることはできるが、変化が起き続けるので本番環境でモニタリングし続け、評価し続ける必要があるのでは
- 推論するだけでない
- 未解決である。エンジニアリングの手法を再検討する必要がある。古いやり方はできないと理解する
- AI, ML,それぞれの手法の違いを明確に理解する
- cross validation
- AI, MLをまず明確に理解するのが第一歩
本番環境でモニタリングするという話はある？
- 公式には聞かないけど、各所でやりはじめてはいるはず。結果が出てからでないと公式に言わないので
学習過程、explainable
- 規則性を学ぶ、言語化できないルールを見つける
- 狼とシベリアンハスキーの雪背景の話。なぜその判断をしたかがわかるか → explainability（説明可能性）
- 本当に必要か？ なくてもいいのでは？
- 天気予報、天気図が出てるけど、あれ出ないと納得しない？ 本当に見てる？
- 将棋の解説者、説明する相手（弱い相手）にわかるように説明する。自分の思考ではなく相手に向けて再構成している
- 抽象化がいい説明なのかどうか
- 説明とはなにか、わかった気にさせること？
- 相手によって説明のしかたは変える。人間はAIの思考は理解できていない。複雑なので＋その分野の知識がない。→たとえ説明してもらても理解できない
- 機械に対して期待が高すぎる。人間でも適当なことを言う（うまくいくんじゃない？等）が、AIにその答えはゆるされない？
- 説明しなくてはならないシステムをどう作るのか。必要なら作らないと。いらないなら作らなくていい
- 科学でなく哲学の話
- 人間には思い込み、概念がある
- データの網羅性が少ない問題にはexplainableのアプローチは有効なのでは？
- 自動運転で、雪の日、霧の日、とかをあらかじめリストアップする必要があるという話になってしまう。でもそれは大変。社会的な話
- 必要になってからデータ追加・再学習できる体制を作るほうがいいアプローチなのでは
- Mutation testingなど、既存のテストソリューションがAIのテストに応用できるものもあるのでは？
- 人間のように、環境の変化にすばやく適応できるマシンを作るほうを目指したい
- 防ぐことはできてないけど、知識として持てるようになったので気をつけられるようにはなった
- 過学習では精度が上がったように見えてしまうので、テストのやり方を考える必要がある
データの話。品質保証の範疇？
- データ（セット）の情報、バージョン管理などはこれから整えていく必要がありそう
- proverance、それは確かに誰々が描いたものとか、ワインの出処や経路を保証する
- データを自動収集しはじめる、差別用語を覚えてしまうとか。信用できないソースに対して検査するノウハウ・手法も確立すべき
- セキュリティも問題。攻撃される
Q&A
エコシステムは作れないのか。QAがブリーディングする？
- QAはブリーディングする役割にわまらないと、テストとか評価とかの役割ではいらなくなりそう。ダメ出しするだけの人はいらない
- サイクルはいる。クオリティを一番に考えてる人に与えるべき役割は、プロジェクトの進行に対してガイダンスを示してくれる人
- 顧客のニーズを満たせているかが重要
- テクノロジーを恐れる人、仕事を奪われることを恐れる人がいる。でも、やり方が改善されるだけである。Uber, Cell Phoneとか
データ*2を共有できる？
- ナレッジは共有すべきだが、データの共有は気をつけるべき。セキュリティや、データにバイアスがかかるという問題があるので、簡単にはできない
- ツールを作っていく。セキュリティなどの問題を解決するツール
- 訓練データは資産なので、オープンにしにくい
- モデル盗難: AIの動きを外から見て、似たモデルを作ってしまう手法。これに対し、透かしを入れられないかという動きもある
テストデータの数
- 同値クラスの概念がないので絞れない
- モデルに着目してテストしていかなければならない
