ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

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. 前のパスとわずかに違うように1つのパスを追加する。後続の各テストで異なるようにパス中の1つのブランチだけを変えてみる。できる限り、長いパスよりも短いパスを採用する。機能を実現しないパスではなく実現するパスを採用する。
  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

Web API: The Good Parts

 一方、テストについては記述があまりありません。そこで、ソフトウェアテスト・ヒストリアンの辰巳さんのツイートから、『10分で学ぶAPIのテスト!』というWebサイトを覗いてみました。

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? ビジネス主導のテストプロセス改善

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

終わりに

 と、それなりに原稿を書いたところで、ソフトウェアテストヒストリアン・辰巳敬三さんのこのツイート・・・。まったく追いつかない・・・。

*1:そのモニターにもまた、AIが使われるであろうという前提で。

*2:「インターネットの検索サイトが提供するアルゴリズムが、各ユーザーが見たくないような情報を遮断する機能」(フィルター)のせいで、まるで「泡」(バブル)の中に包まれたように、自分が見たい情報しか見えなくなること。 via Wikipedia

【翻訳】AIベーステストの6つのレベル - QAのプロにとって恐れるべきものではない

 Gil Tayarさんの「6 levels of AI-based testing: Have no fear, QA pros」という記事がteckbeacon.comで公開されていたので、紹介します。モバイルアプリやWebアプリなど、画面の操作を伴うアプリケーションを前提とした内容になっています。

techbeacon.com

 「6つのレベル」というのは、自動運転の6つのレベルに着想を受けたものですね。
 フォルクスワーゲンのサイトから引用して、元記事の「6つのレベル」と並べてみましょう。

www.volkswagen.co.jp

レベル 自動運転 自律的なテスト
0 ドライバーがすべての操作を行う。 自律性なし
1 ステアリング操作か加減速のいずれかをサポートする。 ドライブアシスタンス
2 ステアリング操作と加減速の両方が連携して運転をサポートする。 部分的な自動化
3 特定の場所ですべての操作が自動化、緊急時はドライバーが操作。 条件付きの自動化
4 特定の場所ですべての操作が完全に自動化される。 高度な自動化
5 あらゆる状況においても操作が自動化。ハンドルもアクセルも不要。 完全な自動化

 それでは、翻訳です。
 誤訳などについてはコメントをお願いします。

翻訳

 あなたは、人工知能(AI)が近いうちに、視覚的なテストをQAチームから奪っていくと心配しているだろうか? その必要はない。自律的なテストツールは助けてこそくれ、あなたの代わりになってはいないだろう。テスターやQAチームは、ビジネス価値について考えることに時間を使うべきだ。つまり、目的を達成するための手段として自動テストを実行することよりも、どうテストし、どう品質保証するかを考えることに力を注ぐべきということである。

 テストには6つのレベルがある。これで、AIテストの革命に不意打ちされることを避けられるだろう。

レベル0: 自律性なし

 おめでとう。あなたはアプリケーションをテストするコードを書き、リリースのたびに何度も実行できるので、実に幸せだ。完璧である。テストにおいてもっとも大事なことーーー考えることに集中できるのだから。

 でも、その自動テストを書くのを手伝ってくれる人はいない。それに、コードを書くこと自体が繰り返しの作業だ。フォームにフィールドが追加されたら、テストを追加しないといけない。ページにフォームが追加されたら、すべてのフィールドをチェックするテストを追加しないといけない。ページが追加されたら、そのページのフォームと部品をすべてチェックしないといけない。
 開発者がアプリケーションに見境なく変更を加えると、テストが多いほど失敗も増える。そして失敗したテストすべてについて、その原因が本当のバグなのか、新しいベースライン*1なのかを確認しなければならない。

レベル1: ドライブアシスタンス

 自律走行車(autonomous vehicle)は、(自律的な)テストのレベルの良いメタファーになる。視覚システムが向上するほど自動車がより自律的になるのと同じように、AIシステムがアプリケーションを「視る」のがうまくなるほど、テストも自律的になる。

 AIはページのDOM(Document Object Model)のスナップショットだけでなく、見た目のイメージ(visual picture)も視られるようになっているべきだ。DOMはイメージの半分に過ぎない。テキスト付きのエレメントがあるからといって、ユーザがそれを見られるとは限らない。ページをわかりづらくするエレメントがあるかもしれないし、ページが正しい位置にないこともある。見た目のイメージがあれば、ユーザが見るデータにフォーカスすることができる。
 テスティングフレームワークが、DOMやスクリーンショットを通じてページを全体的に視られるのであれば、チェック(するコード)を書くのをサポートできるだろう。
 ページのスクリーンショットを取れば、そこにあるフォームのフィールドやテキストを一括してチェックすることができる。各フィールドをチェックするコードを書くかわりに、過去のテストをベースラインとして一気にテストすることができるのだ。

 このレベルのテストを可能にするには、「どの変化が本当の変化で、どの変化が実際には何も変わっていないのか」を判断するためのAIアルゴリズムを、テストツールが備えている必要がある。
 今日のAI技術は、チェックしたいことを人間が書くことで、テストコードの実装をアシストしてくれる。テストの駆動(drive)*2は人間が行わなくてはならないが、AIが一部を自動的にチェックしてくれる。
 AIはテストがパスしたかもチェックできる。しかしテストが失敗した場合は、それを人間に通知しなくてはならない。その失敗が本物(のバグによるもの)なのか、ソフトウェアの適切な変更によるものなのかは、人間が判断するのだ。その変更が適切なものだと確認するか、バグとして拒否しなくてはならない。
 AIがアプリケーションを「視る」というのは、アプリケーションの視覚的側面をベースラインと比べてチェックするということであり、今まで手動テストでしかできなかったことだ。ただし依然として、変化が妥当なものかどうかはすべて、人間が確認しなければならない。

レベル2: 部分的な自動化

 レベル1の自律性に加えて、ベースラインと比較するテストをAIに行わせることで、ページのすべてのフィールドに対するチェックを書くという退屈な作業をテスターは行わなくてよくなる。同じように、ページの視覚的な側面をAIにテストさせることもできる。
 しかしテストが失敗した場合に、その失敗が「良い」失敗なのかバグなのかをすべてチェックするのは退屈である。特に、一つの変更が多くのテスト失敗をもたらしている場合はなおさらだ。AIはその違い*3を、アプリケーションのユーザと同じように理解できる必要がある。つまりレベル2のAIは、意味的に同じ変化を理解することが可能なので、多くのページにおける変化をグルーピングすることができるようになるだろう。(画面の)変化をグルーピングし、変化が同一のものであれば人間にそれを教え、その変化を受け入れるか拒否するかをグループ単位で尋ねることができるのだ。

 要するに、レベル2のAIはベースラインに対して変化をチェックし、退屈な作業を一つのシンプルな作業にまとめるのを手伝ってくれるのだ。

レベル3: 条件付きの自動化

 レベル2においては、失敗したテストや、検出されたソフトウェアの変化をすべて、人間がしっかりと吟味する必要があった。レベル2のAIは変更を解析することができる一方で、ページを視ただけでそれが正しいかどうかを判断することはできない。比較するためのベースラインが必要である。しかしレベル3のAIはそれができるし、ページに対して機械学習の技術を適用することで、もっと多くのことができる。
 たとえば、レベル3のAIはページの視覚的な側面を調査し、アラインメントや余白、色使い、利用フォント、レイアウトなどのデザインの標準ルールに従っているかを判断することができる。

 では、データについてはどうか。レベル3のAIはデータをチェックし、あるフィールドについては特定の範囲に収まっていること、メールアドレスであること、上に並んだ数字の合計となっていることなどを判断することができる。ある特定のページにおいて、テーブルは指定された列でソートされていることを理解している。

 ここでAIは、人間のデザインとデータのルールを理解することによって、人間の仲介なしにページを評価することができる。ページに変化があっても、そのページに問題はなく、人間に確認してもらう必要がないと理解することが可能なのだ。AIシステムは数百のテスト結果をみて、どのように変化してきたかを知ることができる。機械学習の技術を応用することで、変化におけるアノマリーを検出することができるので、人間にはそのアノマリーについてのみ確認を依頼するのだ。

レベル4: 高度な自動化

 ここまでは、AIは自動的にチェックするだけだった。テストの駆動は未だに人間が行っており、(自動化のソフトウェアを使って)リンクをクリックしたりしている*4。レベル4ではAIがテスト自体を駆動する。

 レベル4のAIは、ページを視て人間と同じように理解できるので、ログインページを視たときに、プロフィール、登録、ショッピングカードのページと比べて、それを理解することができる。「ページは、相互作用のフローの一部である」と意味的に理解しているので、テストを駆動することができる。
 ログインや登録といったページが標準的なものであるのに対して、そうではないものもある。しかしレベル4のAIは、これまで視たことのなかったページであっても、ユーザの相互作用をずっと視ていて、それを可視化し、そのページとページを通したフローを理解できる。
 AIがいったんその種のページを理解すると、強化学習(機械学習の一種)などの技術を用いることで、自動的にテストの駆動を始めることができるようになる。テストをチェックするだけでなく、書くことができるようになるのだ。

レベル5: 完全な自動化

 レベル5は、今のところSFである。このレベルに至ると、AIはプロダクトマネージャーと会話し、アプリケーションを理解し、AI自身が完全にテストを駆動することができる。
 しかし、プロダクトマネージャーによるアプリケーションの説明を理解しているものがいなければ、レベル5は人間より賢くなければならない。

現在の最先端

 現状、高度なツールだとレベル1で、レベル2の機能性へと進歩しているところだ。ツールベンダーはレベル2に取り組んでいる。レベル3にはまだ努力が必要だが、可能と思われる。 レベル4のAIは遠い未来だろう。しかし次の10年かそこらで、重い副作用なしの、AIにアシストされたテストに出会うことになりそうだ。
 よって、ソフトウェアテストのすべてをコンピュータが自動化してしまうといって、別の仕事を探し始める必要はない。ソフトウェアテストはいくつかの点で運転と似ているが、人間の複雑な相互作用を理解しなくてはならない分、もっと複雑なのだ。今日のAIは、自身が何をしているかを理解していない。単に、大量の過去データに基づいてタスクを自動化しているだけである。

 あなたの仕事は「自動化すること」であり「自動化されること」ではない。テストチームとQAチームは、新しい働き方を促進するために、新しい自動化技術をさらに活用することができる。仕事が自動化されることで人が自由になって、どうテストし、どう品質を保証するかに集中できるようになれば、ビジネスのために価値を生み出すことでができるようになる。

所感

 この記事を読むと、機械学習の技術を利用したテストを、単純に「自動テスト」と呼ぶと混乱しそうだと感じます。「自動」の中でも特に「自律」であり、駆動にしろチェックにしろ、何をすべきかを人間が明示的に与える必要がないのが「自律」といえるでしょう。

 自律的なテストが進歩していくにあたって、以下の二つのことが気になりました。

 一つ目は、トレーニングデータの量です。
 レベル4では、初見のページであっても、ユーザの操作をずっと観察し続けることでフローを理解できるとしていますが、正確な判定には膨大なトレーニングデータが必要となるはずです。トレーニングのためのこの「ユーザの操作」データはどのように与えるのでしょうか。ページ操作を自動化し、かつ実行ごとに微小な変化・ランダム性を追加することで、大量データを準備するといった方法がある?

 二つ目は、欠陥検出に失敗した際のフィードバックです。
 機械学習の応用でよく指摘される問題として、「なぜそう判定したのかが人間に見えづらい」というものがありますよね。
 手動テストであれ、現在の(判定ロジックを人間が書いている)自動テストであれ、欠陥を見逃してしまった場合はその原因を分析し、以降のテストにフィードバックすることができます。一方、機械学習に基づく自律的なテストにおいて、それは可能なのでしょうか。なぜそれを見逃したかは、よくわからないままになってしまうのではないでしょうか。
 あるいはこういう発想自体がレガシーで、「特定の欠陥を見逃したことより、全体としての検出率が上がっていることが重要」という考え方になるのでしょうか。

 ともあれこの記事が言っているのは、「機械に任せられる部分をどんどん広げて、人間は考えることに力を入れよう」ということです。全般的に「心配するな!」という論調ではありますが、これは皮肉にも見えて、「AIに代替されそうなことばかりやってるとマズいよ」という話にも読めますね。

*1:訳注: 一度「正しい」と判断され、以降のテストにおける結果判定の基準となるものを指しています。

*2:訳注: executeやrunで表される「実行」とは少し違って、何をしなければならないかを自ら判断して動作することを指しているように思います。

*3:訳注: 妥当な失敗とそうでない失敗の違いを指しているものと思います。

*4:訳注: 人間が自動化ツールに明示的に指示している、という意味でしょう。

リバーシ(オセロ)を部分的に実装して、ソフトウェア開発関係者であることを証明する ー その2

 前の記事では、右方向の石置き可否判定を実装しました(Excel関数で)。
 今回は、上下左方向の石置き可否判定について考えていきましょう。

www.kzsuzuki.com

「逆方向」の難しさ

 右方向さえできれば、左方向も本質的には同じ、簡単に実装できそうです。
 しかしここで、Excelの暗黙の前提が効いてきます。Excel関数は基本的に「左から右に」「上から下に」が前提で、その逆を行おうとすると複雑さが増していくのです。

 たとえば、カンマで区切られた2つの単語 apple,orange を、左と右に分けることを考えてみましょう。
 左側は、カンマの位置をFINDで探して、そのすぐ左までをLEFTで切り取ります。

=LEFT(対象セル,FIND(";",対象セル)-1)

 一方右側は、FINDの位置を見つけて対象文字列の長さLENから引いたうえで、RIGHTで切り取ります。ひと手間増えていることがわかりますね。

=RIGHT(対象セル,LEN(対象セル)-FIND(";",対象セル))

 返し判定についても同じで、OFFSETMATCHを逆方向に使うと、一気に複雑になってしまうんですね*1
 ここで少し、発想の転換が必要になります。

盤面を回す

 ジョジョ、それは無理矢理方向を変えようとするからだよ。逆に考えるんだ、『方向は固定、盤面を回しちゃえばいいさ』と考えるんだ。
 ということで、盤面を時計回りに90度回転させます。たとえばセルC4の座標(4, 3)で、回転後は(3, 5)に移動します。一般化すると、座標(x, y)(y, 8-x+1)に移動するわけです。これで、右方向への判定を上方向(-90度方向)に適用することができます。

03

 同じように、180度・270度回転させれば、上下左右方向すべてについて、同じロジックで石置き可否判定ができるようになりますね*2。 これをORで結ぶことで、上下左右のいずれかで返せればTRUE、とすることができました*3
 こんなイメージになります。左から4つの盤面がそれぞれ右・上・左・下方向の判定で、一番右の判定は上下左右方向を合わせた判定です。

04

斜め方向の判定

 さて、次は斜め方向です。普通に考えて、Excel関数で斜め方向に何らかの処理を行うのは、難しさが一気に増しそうです。
 ジョジョ、それは斜めに判定しようとするからだよ。逆に考えるんだ、『盤面を斜めに回しちゃえばいいさ』と考えるんだ。
 ただ90度回転とは違い、斜め回転には少し工夫が入ります。結論を言うと、盤面を分割する必要があります。百聞は一見にしかず、要は、こう。

05

 この分割後の盤面について、最初のロジックで判定すればいいわけです。シンプルな解法ですよね。

力尽きる

 単に石を置けるかどうかだけでこんなに苦労してしまいました。もしかして、Excelワークシート関数で実装するという判断は誤っていたのでしょうか?

 あとはExcel職人の皆さんにお任せしたいと思います!
 それでは良い週末を!

*1:「下」については、右とほぼ同じに作れます。

*2:前記事の条件1でISBLANKを使うと、回転後のセルが空白ではないため、石のないセルでも判定がFALSEになってしまいます。

*3:ORの中にエラーがあると全体がエラーになるので、ISERRORで0にしています。