JSTQB Conference2023 基調講演２

AI テスティング・モバイルアプリケーションテストシラバスのポイントと活用方法シラバス翻訳からの学び Shinsuke Matsuki（snsk） 25th.Oct 2023 ISTQB Conference2023
Keynote2

スピーカー松木晋祐（Shinsuke Matsuki/@snsk）株式会社ベリサーブ執行役員研究企画開発部長 AIQVE ONE株式会社取締役CTO
独立系ソフトウェアベンダにて、テストオペレータから品質部門統括まで、ソフトウェアテストと品質保証にまつわるさまざまなロールを経験後、ベリサーブ・AIQVE ONEへ参画。 NPOソフトウェアテスト技術者振興協会会員 | テスト自動化研究会ファウンダー Androidテスト部ファウンダー | 東京電機大学非常勤講師 | ISO/IEC/IEEE 29119-9 Co-Editor W3C CSSWG コントリビューター | JSTQB Technical Committee など共著/共訳/寄稿など

アジェンダ • AIテスティング、モバイルアプリケーションシラバスのご紹介 • それぞれのシラバスの活用のポイント • シラバス翻訳における学び • 　　マークはシラバスに記載されている内容ではなく、講演者の気づきや、個人的な意見です
• タイトルにマークがある場合、そのスライド全体が対象となります

AIテスティングシラバス

AI テスティングシラバス • Certified Tester AI Testing (CT-AI) 日本語名称は「AI テスティング」
◦ 以後、本資料では「AI テスティング」と呼称 • AIベースのシステムのテストやテスト用のAIに携わる人が対象 • テスト担当者、テストアナリスト、テストエンジニア、などあらゆるレベルのテストに関わる人、および、プロジェクトマネージャー、品質マネージャー、ソフトウェア開発マネージャーなど、AIベースのシステムのテストやテスト用のAIについて、基本的な理解を深めたい人にも適している

AI テスティングシラバスの特徴 • AI ベースのシステムをテストするための知識領域全体を記述したものでは「ない」 • 知識のレベルとは別に「ハンズオンコンピテンシーレベル」が策定されている（これらはモバイルアプリケーションテスト担当者も同様） ▪
H0：演習のデモ、ビデオ（の視聴） ▪ H1：ガイド付きの演習 ▪ H2：ヒント付きの演習シラバスの内容は、AI ベースのシステムをテストするための知識領域全体を記述したものではなく、認定テスト担当者 AI テスティングのトレーニングコースでカバーする詳細レベルを反映している。  テスト技術者資格制度 Foundation Level シラバスAI テスティング Verison1.0.J01 0.7 から一部引用

AI テスティングシラバスの内容紹介 • AI テスティングシラバスの概要（全11章） AI テスティング AI
の紹介 AI ベースのシステムの品質特性機械学習（ML）- 概要 ML - データ ML 機能パフォーマンスメトリクス ML - ニューラルネットワークとテスト AIベースのシステムのテスト概要 AI特有の品質特性のテスト AIベースのシステムのテストのための方法と技法 AIベースのシステムのテスト環境テストにAIを使う出典：https://www.istqb.org/certifications/artificial-inteligence-tester をもとに作図

AI テスティングシラバスの内容紹介 • 全11章の中から、特に現場のテストに近い以下の3つの章に焦点を当てて内容を紹介する ◦ AIベースのシステムの品質特性 ◦ AIベースのシステムのテスト概要
◦ AIベースのシステムのテストのための方法と技法 AI テスティング AI の紹介 AI ベースのシステムの品質特性機械学習（ML）- 概要 ML - データ ML 機能パフォーマンスメトリクス ML - ニューラルネットワークとテスト AIベースのシステムのテスト概要 AI特有の品質特性のテスト AIベースのシステムのテストのための方法と技法 AIベースのシステムのテスト環境テストにAIを使う

AI ベースのシステムの品質特性 • AI テスティングシラバスでは、AIシステムに特有の品質特性として以下が定義されている Quality Characteristics for AI-Based
Systems 柔軟性と適応性自律性進化バイアス倫理副作用と報酬ハッキング透明性、解釈可能性、説明可能性安全性とAI

Systems 柔軟性と適応性当初のシステムに含まれない状況でもシステムを使用できる能力、ハードウェアの違いや運用環境の変化など新たな状況に応じてシステムを容易に変更できる能力自律性システムが長時間にわたって人間の監視や制御から独立して動作し続ける能力進化変化する外部制約に対応してシステムが自己を改善する能力。主に自己学習型の AIベースのシステムに求められる特性バイアス本シラバスにおけるバイアスとは、特定のグループへの「公正な出力」と考えられるものとの距離を統計的に測定したもの。品質特性としては、この距離の隔離を抑える能力。

Systems 倫理「倫理」自体の定義、および地域や時代によって異なる倫理の定義、および各国の政策、基準への対応副作用と報酬ハッキング目標の達成のために、暗黙的に（潜在的に）影響の大きい要素を無視してしまう。短絡的にゴールのデータだけをハックしてしまう、など、AIならではの動作特性への対応透明性、解釈可能性、説明可能性 XAIという技術分野の目的と共通する。 AIベースのシステムがどのように結果を導き出すのかをユーザが理解できるようにする能力安全性とAI AIベースのシステムが人や財産、環境に害を及ぼさないと期待するもの

AI ベースのシステムの品質特性 • 品質特性モデルは、当該分野のシステムのテストを考えるうえで、考慮すべき事項をある程度網羅して示すもの ◦ 盲信してはいけないが、領域のスペシャリストによって MECEに考案されているものであるため、参考にはなる •
テスト対象の特性を考慮したうえで、製品にとってこの特性はどう表現されるべきかを踏まえた品質特性モデルの「実体」を個別に考案する必要がある • 品質特性はそのままテストタイプにはならないケースがある ◦ MLOpsなどプロセスで考慮すべき特性もある Quality Characteristics for AI-Based Systems

AI ベースのシステムのテスト概要 • 本章では、AIベースのシステムの仕様に特有のテストの課題、AIベースのシステムにおけるテストレベル、テストデータ、自動化バイアス、MLモデルのドキュメント化、コンセプトドリフトへの対応、MLシステムのテスト手法、等について触れている • ここでは、テスト担当者に特に影響、関心が大きいと考えられる、以下の3つの内容について紹介する Testing
AI-Based Systems Overview AIベースのシステムの仕様に特有のテストの課題 AIベースのシステムにおけるテストレベル MLシステムのテスト手法の選択

AI ベースのシステムのテスト概要 • AIベースのシステムでは、テストベースとなる仕様の策定が特に難しくなる特有の理由が存在する ◦ 多くの場合、AIベースのシステムを開発プロジェクトはデータセットからはじまり、それで何が出来るのかを事前に定義しずらい ◦ システムの精度は独立したテストの結果が出るまでわからない。現実的な受け入れ基準の策定が
遅れる傾向にある ◦ システムへの要求が「人間の行動を再現すること」である場合、不十分な動作要求となってしまうことが多い ◦ 自然言語認識、CVなどは入力と出力のどちらか、またはその双方が無限になり、システムには高い柔軟性が求められる Testing AI-Based Systems Overview AIベースのシステムの仕様に特有のテストの課題一般的なシステムよりも、十分なテストベースを得る難易度が高い場合があるステークホルダーとの対話、期待値調整がより重要となる

AI ベースのシステムのテスト概要 • AI テスティングシラバスでは従来のテストレベルに対し、2つの新たなテストレベルが追加されている • AI システムのテストでは、AIコンポーネント、非AIコンポーネント、AIコンポーネント
を含むシステムのそれぞれを区別し、テストのアプローチを考える必要がある Testing AI-Based Systems Overview AIベースのシステムのテストレベル AIベースのシステムは、通常、AIコンポーネントと非AIコンポーネントの両方で構成される。非AIコンポーネントは、従来のアプローチでテストすることができるが、AIコンポーネントやAIコンポーネントを含むシステムは、以下に示すように、いくつかの点で異なるテストを行う必要がある。   テスト技術者資格制度 Foundation Level シラバスAI テスティング Verison1.0.J01 ７．２から一部引用

AI ベースのシステムのテスト概要 Testing AI-Based Systems Overview AIベースのシステムのテストレベル入力データテスト MLモデルテストコンポーネントテスト
コンポーネント統合テストシステムテスト受け入れテスト入力データテストシステムが学習や予測に使用するデータが高い品質にあることを、レビュー、統計的手法、データパイプラインの静的、動的テストなどを通じてテストする MLモデルテスト選択したモデルが指定されたパフォーマンス基準を満たしていることを確認する。

AI ベースのシステムのテスト概要 Testing AI-Based Systems Overview MLシステムのテスト手法 • 本節では、AI コンポーネントと非AI
コンポーネントの両方を含むシステムに対するリスク分析に基づくテスト手法が提案されている • ここでは、特徴的なリスクとそのテスト手法の組み合わせを紹介する

AI ベースのシステムのテスト概要 Testing AI-Based Systems Overview MLシステムのテスト手法の選択データの品質が期待値よりも低い可能性がある運用データのパイプラインに不具合があ
る可能性があるモデル開発に使用した MLワークフローが最適ではない可能性がある MLフレームワーク、アルゴリズム、モデル、モデル設定、ハイパーパラメータの選択が最適ではない可能性がある期待するML機能パフォーマンス基準は MLコンポーネント単体では満たしているが、運用上満たしていないことがある自己学習型システムがユーザーの期待するサービスを提供できていない可能性があるシステムがどのように判断しているか分からず、ユーザーが不満を感じることがあるユーザは、データが訓練データと類似している場合にはモデルが優れた予測を行うが、そうでない場合には結果が不十分と感じることがある • シラバスでは AI ベースのシステムに対するリスクとして以下が例示されている期待するMLパフォーマンス基準は満たしているがユーザは提供された結果に満足し得ない可能性がある期待するMLパフォーマンス基準は満たしているがユーザは提供されサービスに不満を持っている可能性がある

AI ベースのシステムのテスト概要 Testing AI-Based Systems Overview MLシステムのテスト手法の選択モデル開発に使用した MLワークフローが最適ではない可能性がある
MLフレームワーク、アルゴリズム、モデル、モデル設定、ハイパーパラメータの選択が最適ではない可能性がある期待するML機能パフォーマンス基準は MLコンポーネント単体では満たしているが、運用上満たしていないことがある期待するMLパフォーマンス基準は満たしているがユーザは提供された結果に満足し得ない可能性がある • 対応するテスト手法により、分析されたリスクはいくつかのカテゴリに分類できる • 主に、専門家のレビューによって対応するリスクのグループは以下の通りであるデータの品質が期待値よりも低い可能性がある

AI ベースのシステムのテスト概要 Testing AI-Based Systems Overview MLシステムのテスト手法の選択運用データのパイプラインに不具合がある可能性がある期待するMLパフォーマンス基準は満たし
ているがユーザは提供されサービスに不満を持っている可能性がある自己学習型システムがユーザーの期待するサービスを提供できていない可能性があるシステムがどのように判断しているか分からず、ユーザーが不満を感じることがあるユーザは、データが訓練データと類似している場合にはモデルが優れた予測を行うが、そうでない場合には結果が不十分と感じることがある • 以下の個々のリスクについては、コンポーネントに対する動的テスト、パイプライン全体に対する結合テスト、品質特性に基づいて優先順位付けされた非機能テスト、あるいは経験ベースのテストなどによる対応が示されているリスクの種類によって、テストのアプローチが変わってくる JSTQBでは、レビューもテスト（静的テスト）の一種である点に注意

AIベースのシステムのテストのための方法と技法 Methods and Techniques for the Testing of AI-Based Systems
• 本章では、AIベースのシステムに向けた個別の、または応用可能なテスト手法について扱っている敵対的攻撃（敵対的テスト）とデータポイズニングペアワイズテストバックツーバックテスト A/Bテストメタモルティックテスト（MT） AIベースのシステムの経験ベースのテスト AIベースのシステムのためのテスト技法の選択

敵対的攻撃（敵対的テスト）とデータポイズニング敵対的攻撃とは、攻撃者が有効な入力を微妙に乱して学習済みモデルに入力することで、誤った予測をさせることを指す。  テスト技術者資格制度 Foundation Level シラバスAI テスティング Verison1.0.J01 9.1.1 から一部引用 • セキュリティテストにおけるペネトレーションテストと同様に、AIベースのシステムに対し意図的に敵対的攻撃を行うことで脆弱性を特定し、将来の故障を予防する措置を取ることが可能になる

ペアワイズテスト • システムに入力されうる膨大なパラメータの組み合わせに対して、欠陥検出能力を損なうことなく、テストケース数を大幅に削減することが出来る技法 • AIモデルにおけるパラメータというよりは、AIベースのシステムのユースケース（自動運転における自動車の状態、外環境の組み合わせなど）の水準をパラメータとする、などが考えられる AIモデルにおける「パラメータ」はモデルが学習中に獲得、調整する重みやバイアスなどの変数のこと（例えば、おまんじゅうであれば、白や茶色、曲線、楕円形が重視される）。演繹的に開発されたシステムにおける関数のふるまいを変化させる変数とは意味合いが異なる。

バックツーバックテスト • AIベースのシステムのテストには常にテストオラクルの不在という問題がつきまとう（＝テストオラクル問題） • バックツーバックテストはこの問題解決への根本的なアプローチのひとつ • 機能要求のみが適合する、同一のAIベース、および非AIベースコンポーネントを使わない別のシステムを作成し、その出力をテストオラクルとする • バックツーバックテストは主に機能要求に対する不具合を検出する目的で利用される人間による判断もテストオラクルになり得るが、ＭＬＯｐｓ等に組み込む自動化に向かない

A/Bテスト • テストオラクル問題を解決するもう一つのアプローチ • プログラムのふたつのバージョンに対するユーザ等の反応を比較し、どちらのバリエーションが優れているかを判断することを目的とした手法 • AIベースのシステムにおいては、主に「以前のバージョン」を比較対象とし、その出力の質やパフォーマンスを比較する • バックツーバックテストが不具合の検出を目的とするのに対し、A/Bテストは比較検討することが主な目的となる • この特性から、自己学習型のシステムのテストにも利用できる

メタモルフィックテスト（ MT） • 合格したテストケース（ソーステストケース）に基づいて、相対関係にあるテストケース（フォローアップテストケース）を生成することを目的とした技術 • この相対関係のことを、メタモルフィック関係（MR）と呼ぶ • メタモルフィック関係に基づいて、テストオラクルを導出する ◦ 多くの場合「出力が変わらないこと」という MRが利用されるが、これに限定されるものではない

メタモルフィックテスト（ MT） • メタモルフィック関係の例 ◦ この例では、グレースケールにしても並びや形状から「紅白饅頭」と判定されることを期待している • 画像判定での適用例が見られるが、平均値の判断など数値、文字データを扱うAI ベースのシステムでもメタモルフィック関係が作れれば適用可能

メタモルフィックテスト（ MT） • ISSTA 2018での論文発表によると、サポートベクターマシンベースとディープラーニングベースの製品で、実装バグの71%を　メタモルフィックテスティングで補足できた、と報告がある We have developed metamorphic relations for an application based on Support Vector Machine and a Deep Learning based　application. Empirical validation showed that our approach was able to catch 71% of the implementation bugs in the ML applications   Dwarakanath, Anurag, et al. "Identifying implementation bugs in machine learning based image classifiers using metamorphic testing." Proceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis. ACM, 2018.

AIベースのシステムの経験に基づくテスト • 経験ベースのテスト（エラー推測、探索的テストなど）はAIベースのシステムのテストにも適用できる • 探索的テストはそもそもテストベースが不十分な場合に適用可能なテストのアプローチである • システム的に偏った訓練データを使用したために、システムが過去にどのような失敗をしたか、などの知識に基づく • アプローチの特性上、EDA（探索的データ分析）と密接に連携する

補足：EDA（探索的データ分析） • R言語やPython等も、EDAに利用される代表的なツール • AIテスティングシラバスには、EDAが各所に登場するため、併せて学んでおくとより理解が深まる探索的データ分析（EDA）は、データ・サイエンティストがデータ・セットを分析および調査して、主な特性を要約するために使用する手法で、データ可視化の手法が活用されることが多くあります。   探索的データ分析とは | IBM https://www.ibm.com/jp-ja/topics/exploratory-data-analysis から一部引用

AIテスティングシラバスの活用のポイント • AI ベースのシステムをテストするための知識領域全体を記述したものでは「ない」と冒頭に記載があるが、そもそものAIベースのシステムの特性、そのテストのアプローチを現時点で概観するには充分な資料となっている • 元言語版の初版リリースが2021年10月であるため、2022末からのLLMの潮流以前のものではあるが、それでも本シラバスに記載の内容はLLMベースのシステム
に対しても十分に適用可能である ◦ 逆に、LLMベースのシステムに対しては適用が難しい内容は見当たらない • 現場への適用については、今回紹介した3つの章をとっかかりにして頂けると幸いである

Foundation Level Specialist シラバスモバイルアプリケーションテスト担当者

モバイルアプリケーションテスト担当者 • Certified Tester Mobile Application Testing (CT-MAT)、日本語名称は「モバイルアプリケーションテスト担当者」 ◦
以後、本資料では「モバイルアプリケーションテスト」と呼称 • モバイルアプリケーションに対するテスト戦略の作成、モバイルアプリケーションのビジネス的、技術的推進要因の理解、本分野における主なリスク、期待の理解、固有のテストタイプとレベルの理解と適用などを目的とする

モバイルアプリケーションテストの内容紹介 • モバイルアプリケーションテストシラバスの概要（参考文献、付録を除き全6章）モバイルアプリケ｜ショ
ンテストイントロダクションモバイル分野ビジネスとテクノロジーの原動力モバイルアプリケーションのテストタイプモバイルアプリケーションで一般的なテストタイプとテストプロセスモバイルアプリケーションのプラットフォーム、ツール、環境テスト実行の自動化

モバイルアプリケーションテストの内容紹介 • これら6章の中から、現場のテストになじみの深い以下の3つに絞ってポイントを紹介する ◦ モバイルアプリケーションのテストタイプ ◦
モバイルアプリケーションで一般的なテストタイプとテストプロセス ◦ テスト実行の自動化モバイルアプリケ｜ションテストイントロダクションモバイル分野ビジネスとテクノロジーの原動力モバイルアプリケーションのテストタイプモバイルアプリケーションで一般的なテストタイプとテストプロセスモバイルアプリケーションのプラットフォーム、ツール、環境テスト実行の自動化

モバイルアプリケーションのテストタイプ • モバイルアプリケーションのテストタイプの章は以下の3つのセクションで構成される • デバイスハードウェアとの互換性テストでは、モバイルハードウェアに特有の機構とアプリケーションとの連携、アプリケーションとデバイスソフトウェアの連携のテストでは、主にSDKによるOSの機構との連携を扱う Mobile Application
Test Types デバイスハードウェアとの互換性テストアプリケーションとデバイスソフトウェアの連携のテストさまざまな接続方法のテスト

モバイルアプリケーションのテストタイプ • モバイルアプリケーションはさまざまな機構を備えるハードウェア、OSの組み合わせからなる製品に対して配信される • そのカバー範囲はビジネスのKPIとも密接に関係するため、互換性テストはモバイルアプリケーションのテスト担当者の関心が高い Mobile Application Test
Types デバイスハードウェアと互換性テスト

モバイルアプリケーションのテストタイプ • 本シラバスでは、デバイスハードウェアとの互換性テストの要素として以下を挙げている ◦ デバイスの機能 - 電源オフ、ナビゲーション、 HW/SWキーボード、カメラ、スピーカー、マイク、無線等のハードウェア機能
◦ ディスプレイ - ppi、dpi、画面サイズ、解像度、アスペクト比、タッチ感度、マルチタッチ ◦ デバイス温度 ◦ デバイス入力センサー - GPS、加速度計、姿勢制御装置、磁力計等 ◦ さまざまな入力方法 - タッチ、スワイプ、キーボード入力、ジェスチャー、カメラ入力（ QRコードなど） ◦ 画面の向きの変更 - いわゆるランドスケープ、ポートレートの切り替え ◦ 典型的な割り込み - 着信、Pushメッセージ、充電開始、メモリひっ迫　等 ◦ デバイス機能に対するアクセス許可 ◦ 電力消費とバッテリーの状態 Mobile Application Test Types デバイスハードウェアと互換性テスト非常に網羅的に挙げられているため、テスト対象の機構に応じて取捨選択する必要がある（例えば画面ローテーションなど）

モバイルアプリケーションのテストタイプ • 本シラバスのリリースは2019年である。参考までに2019年から2023年までの主なスマートフォンのハードウェア面での進化を振り返る • 2019年→2023年のiPhoneの進化 ◦ iPhone11(2019年) → iPhone14(2022年)
▪ 5G対応、トリプルレンズの採用、miniのラインナップ（後に廃止）、6.7インチモデルの復活、衝突事故検出、ノッチの変更、統合 CPUにAI処理専用のコア搭載 • 2019年→2023年のAndroid端末の進化 ◦ Pixel 3/XperiaXZ2/GalaxyS10(2019年) → Pixel 7/Xperia1 IV/GalaxyS23(2023年) ▪ Pixelのハードウェア面での進化 ▪ 5G対応、望遠レンズの搭載、バッテリーシェア、 Google Tensor搭載 Mobile Application Test Types デバイスハードウェアと互換性テストおおまかに、カメラの機能強化、各社専用統合CPUの搭載、5G対応などが挙げられる

モバイルアプリケーションのテストタイプ • デバイスソフトウェアは、概ねOS（SDK）機能のことを指している • 節ごとに以下のテストを紹介している ◦ 通知のテスト ◦ クイックアクセスリンクのテスト ▪
長押しなどで実現されるアプリケーションプレビューのこと ◦ オペレーティングシステムで提供されるユーザ設定のテスト ▪ 言語設定、地域、低電力モードなど ◦ さまざまなタイプのアプリケーションのテスト ▪ ネイティブ、ハイブリッド、ウェブアプリケーション ◦ 複数のプラットフォームおよびオペレーティングシステムバージョンとの互換性のテスト ◦ デバイス上の他のアプリケーションとの相互互換性と共存性のテスト Mobile Application Test Types アプリケーションとデバイスソフトウェアの連携のテスト例えば、電力消費を抑えるためにGPSをオフにするアプリケーションと、GPSを自動的に音にするアプリケーションが共存する可能性がある   テスト技術者資格制度 Foundation Level Specialist シラバスモバイルアプリケーションテスト担当者 Verison2019 2.2.6 から一部引用

モバイルアプリケーションのテストタイプ • 2G～5Gなどベアラネットワークの違い ◦ 接続の確立やハンドオーバー自体は OSで処理するため、アプリケーションとしては基本的に速度面を考慮する（5Gでもミリ波とSub6で速度と距離のトレードオフがある） • Wifi、NFC、Bluetooth等近距離通信 ◦
特にNFCやBluetoothはアプリケーションで個別の機構として利用される • 接続性テストの実行環境ごとの考慮点 ◦ デバイスシミュレータ ▪ 機能性の確認には利用できるが、（再現）能力に限界がある ◦ 独自のモバイルネットワーク ▪ 再現性は最も高いが、極めて高価になりがち ◦ フィールドテスト ▪ 潜在的に費用対効果が高い対策であるが、再現性は限定的 Mobile Application Test Types さまざまな接続方法のテスト

モバイルアプリケーションで一般的なテストタイプとテストプロセス • 本章は以下の4つの節で構成されている • 経験ベースのテスト技法は本来ドメインを選ばないが、本シラバスではモバイルに向いたアプローチを紹介している Common Test Types and
Test Process for Mobile Applications モバイルアプリケーションに適用可能な一般的なテストタイプモバイルアプリケーションに適用可能な追加のテストレベル経験ベースのテスト技法モバイルテストプロセスと手法

モバイルアプリケーションで一般的なテストタイプとテストプロセス Common Test Types and Test Process for Mobile Applications
モバイルアプリケーションに適用可能な一般的なテストタイプ設置性テスト • モバイルアプリケーションは他ドメインのソフトウェアと比べても、インストール、アンインストール、アップデートの頻度が高い（特にB2C） • それぞれのアプローチとして本シラバスでは以下の3点が紹介されている ◦ アプリケーションストア ▪ App Store、Play Store ◦ サイドローディング ◦ デスクトップアプリケーション ▪ iTunesなど（ただし、最近のiTunesではipaの管理をサポートしていない） • 実質的にはサイドローディングと同様になる

モバイルアプリケーションに適用可能な一般的なテストタイプ設置性テスト • また、本セクションではインストール、アンインストール、アップデート時に考慮すべきいくつかのテスト条件を提示している ◦ 内部メモリ・外部メモリへのインストール、アンインストール、アップデート ◦ アプリケーションデータの保持または非保持 ◦ インストール、アップデート、アンインストールの中断、割り込み ◦ アクセス許可の設定 ◦ アップデート時のデータ保全

モバイルアプリケーションに適用可能な一般的なテストタイプストレステスト • モバイルアプリケーションのストレステストにおいて考慮すべきテスト条件として本シラバスでは以下を挙げている ◦ 高CPU使用率 ◦ メモリ不足 ◦ 少ないディスクスペース ◦ バッテリー負荷 ◦ 故障 ◦ 貧弱な帯域幅 ◦ きわめて多量なユーザ操作これらの条件の一部はADBなどSDKに付属するツールを利用して実現できる

モバイルアプリケーションに適用可能な一般的なテストタイプセキュリティテスト • モバイルアプリケーションにおける主要なセキュリティの問題として本シラバスでは以下を挙げている ◦ デバイス上の機密データへのアクセス ◦ 暗号化されていない情報転送または安全でないストレージ • また、セキュリティテストのテスト条件として以下が挙げられている ◦ コードインジェクションおよびオーバーフローを引き起こす入力 ◦ 転送済みデータの暗号化 ◦ ローカルに格納されているデータの暗号化 ◦ 使用後または異常終了後の一時データの削除 ◦ パスワードフィールドのテキストのクリア

モバイルアプリケーションに適用可能な一般的なテストタイプセキュリティテスト • OWASPの上位10件のモバイル関連脆弱性もテスト条件になり得る表の出典：https://owasp.org/www-project-mobile-top-10/

モバイルアプリケーションに適用可能な一般的なテストタイプ性能テスト・使用性テスト • 性能テスト、使用性テストはどちらもモバイルアプリケーションにとっても非常に重要なテストタイプであるが、基本的な方針については各種スペシャリストシラバスをリファレンスしている • 性能テスト：ISTQB®スペシャリストシラバス[ISTQB_CTFL_PT_2018] • 使用性テスト： ISTQB®スペシャリストシラバス[ISTQB_FLUT_2018]

モバイルアプリケーションに適用可能な一般的なテストタイプ使用性テスト（参考） • 使用性テストについてはiOS, Androidともにプラットフォームベンダーから開発者向けにUI/UXガイドラインが配布されている https://developer.android.com/design?hl=ja

モバイルアプリケーションに適用可能な一般的なテストタイプデータベーステスト • 本シラバスではモバイルアプリケーション用のデータベーステストにむけて考慮すべきテスト条件として以下を挙げている ◦ データストレージ問題の検証 ▪ 同期 ▪ アップロード競合 ▪ データセキュリティ ▪ データに関する制約 ▪ CRUDの機能性 ▪ 検索 ◦ デバイスまたはサードパーティアプリケーションによって提供されるデータとのデータ統合テスト ◦ データをデバイスに格納する性能

モバイルアプリケーションに適用可能な一般的なテストタイプグローバル化とローカル化のテスト • 異なる地域、日付、数値、通貨の形式、実際の文字列と疑似文字列の交換に関するアプリケーションのテスト • モバイルアプリケーションは他ドメインのソフトウェアと比較してもUI部品の横幅に余裕がない場合が多い ◦ 特に、ドイツ語、ロシア語は他の言語の単語より長くなる傾向にある ◦ 日本語→英語でも1.3倍ぐらいになる • 日付の表示形式は極めて重要なテスト条件となる

モバイルアプリケーションに適用可能な一般的なテストタイプグローバル化とローカル化のテスト（参考） • フランスやベトナム等の国では、実数において整数部と小数部を分ける記号に、カンマを用いる • 実際にスマホゲームでカンマとピリオドが逆に扱われることに起因する不具合が発生している • C#などでは実数のParseに専用の関数と引数を指定する、などで回避する出典：https://automaton-media.com/articles/newsjp/20211221-186713/

モバイルアプリケーションに適用可能な一般的なテストタイプアクセシビリティテスト • モバイルアプリケーションは、OSレベルでアクセシビリティオプションが豊富に用意されている • OSレベルで提供されているアクセシビリティ機能が充分にその役目を果たせるような設計に務めるべきであり、そのための要求はそのまま重要なテスト条件となる • アクセシビリティについてもUIガイドライン同様に各プラットフォーマーから専用のガイドラインが発行されている

モバイルアプリケーションに適用可能なその他のテストレベル • 本シラバスでは [ISTQB_CTFL_2018] で説明されているテストレベルに加えて、モバイル分野において特徴的な以下のふたつのテストレベルを紹介している • フィールドテスト ◦ モバイルアプリケーションはその特性上「移動中」に利用されることも多い。交通機関やベアラネットワーク（帯域幅）の違いなどさまざまな環境条件を考慮したシナリオの想定が必要となる • アプリケーションストアの承認のテストとリリース後テスト ◦ 事実上、モバイルアプリケーションはプラットフォーマーのストア経由で配布される。このストア登録の承認にはいくつかのチェックリストに合格する必要があり、これはリリースプロセス時に必須のテスト条件となる

経験ベースのテスト技法 • モバイル分野におけるペルソナの特性（1時間に何回モバイル機器をさわるか、等）およびテスト条件の導出に役立つ「ニーモニック」が紹介されている ◦ その他、一般に探索的テストやその管理の指針として役立つ「ツアー」や「ヒューリスティクス」「SBTM」などについても触れられている • ニーモニックは単語、文の頭文字がそれぞれ直接のテスト条件、またはテスト条件を想起するためのガイドワードとして利用できる • 本シラバスではモバイルアプリケーションのテストに特に定義されたニーモニックである「I SLICED UP FUN」が紹介されている

経験ベースのテスト技法 • I ＝Input（入力） • S ＝ Store（ストア） • L ＝ Location（場所） • I ＝ Interactions and interruptions（連携と割り込み） • C ＝Communication（通信） • E ＝ Ergnomics（人間工学） • D ＝ Data（データ） • U ＝ Usability（使用性） • P ＝ Platform（プラットフォーム） • F ＝ Function（機能） • U ＝ User Scenario（ユーザシナリオ） • N ＝Network（ネットワーク） http://www.kohl.ca/articles/ISLICEDUPFUN.pdf

モバイルテストプロセスと手法 Mobile Test Process and Approaches • 本章では、 [ISTQB_CTFL_2018] で説明されているテストプロセスをモバイルアプ
リケーションに適用する場合の固有の側面を、規定のテストプロセスに沿って紹介しているテストプロセスでの主な活動グループモバイルテストで考慮する必要のある典型的な領域テスト計画作業 • デバイスの組み合わせ • テスト環境としてのエミュレーター /シミュレーター • モバイルアプリケーションに特化した課題、テストタイプ分析と設計 • ストアの承認にまつわるテスト • フィールドテスト • デバイス互換性 • 使用するテストラボ • テストタイプ出典：テスト技術者資格制度 Foundation Level Specialist シラバスモバイルアプリケーションテスト担当者 Version 2019.J01 をもとに作図

モバイルテストプロセスと手法 Mobile Test Process and Approaches テストプロセスでの主な活動グループモバイルテストで考慮する必要のある典型的な領域テスト実装とテスト実行 •
フィールドテスト • ダウンロードと設置性、リリース後のテスト • 経験ベースの技法 • インターフェース、プラットフォームガイドへの準拠出典：テスト技術者資格制度 Foundation Level Specialist シラバスモバイルアプリケーションテスト担当者 Version 2019.J01 をもとに作図

テスト実行の自動化 Automating the Test Execution • 本章ではモバイルアプリケーション種別ごとのテスト自動化手法（アプローチ）、テスト自動化の方法、テスト自動化ツールの評価、テストラボのセットアップ、等のトピックについて（他の章と比べて）軽めに触れている •
章の大半を占める2つの節を紹介する自動化手法自動化方法自動化ツールの評価自動化テストラボをセットアップする方法

テスト実行の自動化 Automating the Test Execution • ネイティブアプリケーション、モバイルウェブアプリケーションに対するテスト自動化のアプローチ手法を述べている自動化手法モバイルウェブへのアプローチとして、一般的なウェブアプリケーションテスト自動化
フレームワークと、UserAgentの変更によるアプローチが紹介されているが、現時点においてはそれは推奨されない点を日本の翻訳チームからフィードバックしている • ネイティブアプリケーションのテスト自動化フレームワークが一般的にそなる（備えることを期待している）機能として以下が挙げられている ◦ オブジェクトの識別/操作 ◦ テストレポート、ドキュメント ◦ 拡張可能なAPI ◦ 他ツールとの統合 ◦ テスト開発プラクティスからの独立

テスト実行の自動化 Automating the Test Execution • モバイルウェブアプリケーションに対するテスト自動化におけるオブジェクト認識の種類の紹介、画像認識、OCR/テキスト認識、オブジェクト認識 • 本シラバスでは、オブジェクト認識と画像/OCR比較のそれぞれにおける比較（評
価）項目を以下の観点から掲載している自動化方法比較項目内容信頼性自動テスト実行の安定性ユーザエクスペリエンス自動テスト作成の容易さ実行速度自動テスト実行の速度メンテナンス自動テスト保守の実務作成における課題自動テスト開発の前提スキル、作業

テスト実行の自動化 Automating the Test Execution • モバイルのテスト自動化には特徴的な以下の課題が横たわっている ◦ デバイスの相互運用性、互換性にまつわるテスト実行環境の問題 ◦
UIオブジェクトの取得に専用ツールが必要（ Webと比べると相対的に難しい） ▪ ただ、最近はツールが充実してきていて以前ほどのハードルは無い ◦ プラットフォーマーによるSDKの定期アップデートと数年に1度来る UXの大改革 ◦ キャリアやメーカーによるOSのカスタマイズモバイルアプリケーションにとってテストピラミッドが逆さになることは極めて一般的である   [Knott15]  テスト技術者資格制度 Foundation Level Specialist シラバスモバイルアプリケーションテスト担当者 Verison2019 3.4.2 から一部引用

シラバス翻訳で得られた学び

シラバス翻訳の作業概要 • 講演者は、2020年から2022年に亘って「モバイルアプリケーションテスト担当者」、「AI テスティング」のふたつのシラバスの翻訳をリード • 翻訳は用語等一定の質が保たれた下訳に対して作業する • 原文の、概ね1,2行（量によってはパラグラフ）ごとに以下の観点から翻訳をチェックしていく
◦ 原文の翻訳漏れがないか ◦ 訳文は原文の表現を十分に再現できているか ◦ 日本語として正確であり、できるだけ自然に読み下せるか ◦ シラバス全編にわたり、同じ単語は同じ言葉で訳出されているか ◦ 他シラバスとの不整合は無いか • 数名からなる完全なボランティアであり、翻訳だけでもシラバスの大きさにもよるがだいたい半年から1，2年掛かる＋リリースまでの諸作業

シラバス翻訳で得られること • ソフトウェアテストの当該領域において世界中の識者、専門家による「その時点での大まかなまとめ」の情報を一気に得ることができる • 原則、試験やトレーニングを提供することが前提となっているため、情報の質が高い • 原文の表現が不明な場合は原典も当たるので、結果としてより深く学ぶことができる
• 英語力も多少はあがる裏返せば、当該領域のテストを学ぶのに非常に効率の良い方法

シラバス翻訳で得られること • 必ずしも「翻訳WG」での作業でなくても、これらの効果は十分に得られる • 包括的かつ最新の情報を得つつ、将来実施される（かもしれない）試験の学習にもなって二度おいしい • いっぽう、シラバスに載っているのは世界中の識者、専門家によって議論を尽くされた、一定量「固い」（安定した）情報である •
この世界で新しい技術を開発する人にとっても、「そもそも何が新しい技術なのか？」の足場を得るためにも、シラバスを学ぶ意義はある

ご清聴ありがとうございました。翻訳済みシラバスの誤訳、脱落などありましたらぜひ教えてください

JSTQB Conference2023 基調講演２

JSTQB Conference2023 基調講演２

More Decks by Shinsuke Matsuki(snsk)

Other Decks in Technology

Featured

Transcript