皆さん、こんにちは。
先週に引き続き、JSTQBシラバス「モバイルアプリケーションテスト担当者」の
3項「モバイルアプリケーションで一般的なテストタイプとテストプロセス」をご紹介していきたいと思います。
3項は以下の構成となっています。
■目次リンク
・3.1モバイルアプリケーションに適用可能な一般的なテストタイプ
・3.2モバイルアプリケーションに適用可能な追加のテストレベル
・3.3経験ベースのテスト技法
・3.4モバイルテストプロセスと手法
□3.1モバイルアプリケーションに適用可能な一般的なテストタイプ
こちらでは、モバイルアプリケーションのテストタイプについて、以下が紹介されています。
・3.1.1設置性テスト
・3.1.2ストレステスト
・3.1.3セキュリティテスト
・3.1.4性能テスト
・3.1.5使用性テスト
・3.1.6データベーステスト
・3.1.7グローバル化とローカル化のテスト
・3.1.8アクセシビリティテスト
◇3.1.1設置性テスト
「設置性テスト」は、あまり聞きなれないですが、名称から読み取れるように、アプリケーションののインストール、アップデート、アンインストールについての内容となります。
●アプリケーションストア
AndroidOSの場合はGoogle Play Store、iOSの場合はApple Storeなどからインストールできます。
エンタープライズアプリケーションの場合、リンクまたはHockeyApp（※１）やApp Centerなどの配布サービスを介して、インストールテストを実行することが要求される場合があります。
※1:HockeyAppは2018年にサービス終了
●サイドローディング
OSによっては、アプリケーションをモバイルデバイスにコピーして、そのファイルからアプリケーションをインストールできるものです。
アプリケーションストアを介さずにインストールできるアプリが該当します。
●デスクトップアプリケーション
Apple iTunes、Android App Installerなどのデスクトップアプリケーションを使用し、アプリケーションをスマートフォンにインストールできるものです。
対象のアプリケーションをこれらのデスクトップアプリケーション内にダウンロードし、有線接続（USBケーブル、ライトニングケーブルなど）、Wi-Fi、またはモバイルデータ通信経由のOTA（※2)を介してスマートフォンにインストールします。
インストールに関しては、以下の方法で実施することも可能です。
※2:OTAは、無線、データ通信など。
また、インストールの他アンインストール機能も備わっています。
「設置性テスト」のテスト条は、以下について考慮でき、テスト観点に含めることができると思います。
（インストール／アンインストール）
・内部メモリ、外部メモリでのインストール、アンインストール、アップグレード
・「アプリケーションデータを保持」を選択後、アンインストール後の再インストール
・「アプリケーションデータを保持」オプションを選択せずに、アンインストール後の再インストール
（キャンセル、割り込み）
・インストールまたはアンインストールのキャンセルまたは割り込み
モバイルデバイスのシャットダウンまたはインターネットからの切断
・インストール、アンインストール、アップグレードの処理のキャンセルまたは割り込み
・モバイルデバイスのシャットダウン、およびアップグレードの処理のキャンセルまたは割り込み後のそれらの処理の再開
（アクセス、アップデート）
・アクセス許可関連のテスト
（アドレス帳、カメラ、写真などを使用する場合、アクセス許可を求める際に、許可／拒否するふるまいのテスト）
・アプリケーションをアップデートして、データ喪失が発生していないことの確認
尚一部のアプリケーションは、Jailbreak（ios)、root化（Android）が行われており、ユーザーに管理者権限を付与可能なデバイスを必要とする場合があります。
ほとんどのプラットフォームプロバイダーでは、法律上の問題が発生する可能性があるため、Jailbreakおよびrootをサポートしていません。
◇3.1.2ストレステスト
ストレステストは、過度に負荷がかかった条件でのアプリケーションの性能効率性を判定することに重点をおきます。
JSTQBシラバスでは、モバイルデバイスのみ対象としています。
ストレステストで考慮するテスト条件は、以下が挙げられます。
・高CPU使用率
・メモリ不足
・少ないディスク（ストレージ）スペース
・バッテリー負荷
・故障
・貧弱な帯域幅
・きわめて多量のユーザー操作
尚、「ストレステスト」と良く混同してしまう「負荷テスト」については、JSTQBシラバスでは、特に言及されていません。
基本的に、負荷をかけてのテストについては、「ストレステスト」との認識で良いかと私は思います。
ストレスフルな条件の一部は、「Monkey」ツールなどを使用して作成することができます。
○UI / Application Exerciser Monkey
https://developer.android.com/studio/test/monkey?hl=ja
エミュレータ、Androidデバイス用で動作するプログラムです。
クリック、タッチ、ジェスチャーなどのユーザーイベントや、ストレステストの実行なども行えます。
コマンドラインベースで、ADBシェルコマンドラインライン（URL3）で実行することも、手動で実行も可能です。
巨大なファイルや他のアプリケーションを使用して、高CPU使用率やメモリ消費の条件を作成することができます。
◇3.1.3セキュリティテスト
JSTQBのシラバスでは、モバイルデバイスでの主要なセキュリティ問題について、以下が明記されています。
・デバイス上の機密データへのアクセス
・暗号化されていない情報転送または安全ではないストレージ
セキュリティテストで考慮するテスト条件は以下となります。
・コードインジェクション（※3)およびオーバーフローを引き起こす入力
・転送済データの暗号化
・ローカルに格納されているデータの暗号化
・使用後または異常終了の一時データの削除
・パスワードフィールドのテキストクリア
・※3：「コードインジェクション」は、ウェブサイト等で想定外の行動を引き起こすように入力やパラメーターの値を変更する攻撃手法
また、JSTQBシラバスでは、「Open Web Application Security Project（OWASP）の上位10件のモバイル関連脆弱性もテストの対象にする必要がある」と表記されています。
こちらの「Open Web Application Security Project（以下OWASP）」は、Webアプリケーションセキュリティの分野で自由に利用できる記事、方法論、ドキュメント、ツール、テクノロジーを作成するオンラインのコミュニティです。
「OWASP」は、「OWASPトップ10」と呼ばれるWebアプリケーションのセキュリティリスクトップ10」と呼ばれるセキュリティリスクのリストを掲載しています。
https://owasp.org/www-project-top-ten/
現在は2021のトップ10が掲載されていました。
これらをモバイル関連の脆弱性についてもテスト対象となると、セキュリティに関する専門知識を持たないといけません。
ISTQBでは、セキュリティテストに関する個別のスペシャリストシラバス「ISTQB_CTAL_SEC_2016」が用意されています。
https://www.istqb.org/certifications/security-tester
セキュリティテストの具体的な内容については、別途、上記シラバスのご紹介時、また自身のセキュリティに関する知見が深まった際に、ご紹介したいと思います。
◇3.1.4性能テスト
性能テストにおいては、JSTQBでも2022年4月に初版が公開され、国内でも重要性が上がってきていると考えられます。
https://jstqb.jp/syllabus.html#syllabus_foundation_specialist_performance
モバイルアプリケーションでは、以下の内容について、性能テストを実施し、測定する必要があると述べられています。
・ユーザーがインストールしたアプリケーションのレスポンスが遅い場合（例：3秒超）、アンインストールして別の代替えとなるアプリケーションをインストールする場合がある。
・性能効率性は、単体のデバイス上でテストする必要があり、さらには、バックエンドシステムや他のモバイルデバイスとの連携についてもテストする必要がある。
・アプリケーション自体の性能テストには、最も重要なワークフローの時間測定を含む必要がある。
例）オンラインバンキングでのワークフロー例
ログイン、住所の変更、PINおよびTANによる振り込みなど
・時間測定法による測定に加えて、ユーザーが認識する性能も考慮する。
ユーザーエクスペリエンスは、特定の機能が完了するまでにユーザーが待機できる時間の長さに大きな影響を及ぼす可能性がある。
・尚、システム全体の性能テストは、テスト戦略での定義に応じて実行する必要があり、モバイル固有のものではない。
（詳細はISTQBスペシャリストシラバスを参照）
◇3.1.5使用性テスト
JSTQBシラバスにおいて、「使用性はモバイルアプリケーションにとって極めて重要」と述べられています。
モバイルアプリケーションにおいては、Web、デスクトップ向けソフトウェアよりも使用性の重要度は高いと考えられます。
使用性と性能が貧弱である場合、大多数のユーザーはインストール中のアプリケーションをわずか数分でアンインストールするケースもあります。
JSTQBシラバスに明記されていた参考資料のURLが掲載されています。
Nearly 1 in 4 people abandon mobile apps after only one use | TechCrunch
調査資料は、2016年のもので少し古いですが、モバイルを利用しているユーザーの23％がアプリを1度の使用で放棄した、アンインストールした旨が記載されています。
使用性が悪いアプリケーションは、上記のようにインストールをされたとしても、一度使用した後は、アンインストールされる可能性があります。
使用性テストを行い、識別された「発見事項」は、欠陥だけでなく、使い勝手の改善点なども含む場合があります。
テスト担当者は、「発見事項」をチーム、プロダクト所有者、ステークホルダーに説明するの能力を持ち、可能であれば改善するように促すことが求められます。
モバイルアプリケーションにおいて、十分な使用性を達成するため、以下の要素を備えておく必要があります。
性能テスト観点、または探索的テストなどで、テスト観点として取り入れてもよい内容かと思います。
・操作等、自明で直感的である。
・ユーザーの誤りを許容する。
・文言表現と振る舞いを一致する。
・プラットフォームの設計ガイドラインを遵守している。
・各画面サイズとタイプで、必要な情報の表示とアクセスが可能である。
◇3.1.6データベーステスト
モバイルアプリケーションでは、PCソフトウェア同様、データをローカル（本体、SDカードなど）に格納する必要があります。
データベーステストとして、以下の観点が考慮するテスト条件となります。
●データストレージ問題の検証
・同期
・アップロード競合
・データセキュリティ
・データに関する制約
・CRUD（作成：Create、読み込み：Read、アップデート：Update、削除：Delete）の機能性
・検索
●デバイスまたはサードパーティアプリケーションによって提供されるデータに対する統合テスト
・例として、連絡先、カメラ、写真、メッセージなどによってそれぞれのデータを連携するもの
●データをデバイスに格納する性能
◇3.1.7グローバル化とローカル化のテスト
昨今のアプリでは、国内のみに展開しているアプリの他、グローバルに展開しているアプリも多岐にわたります。
グローバル化のテストでは、日本語の他、英語表記で文字やUIデザインが適応しているかなどが思い浮かぶと思います
JSTQBのシラバスでは、グローバル化、ローカル化については、以下のように述べられています。
・アプリケーションの国際化（I18N）(※４)／グローバル化テストには、
異なる地域、日付、数値、通貨の形式、実際の文字列と疑似文字列の交換に対するアプリケーションのテストが含まれる。
・ローカル化（L10N)テスト(※４)には、
特定の地域向けローカル化された文字列、画像、ワークフローを備えるアプリケーションのテストが含まれる。
画面サイズに制限がある場合、翻訳された文字列で問題が発生する可能性がある。
これらの問題は、標準のグローバル化／ローカル化テストとして確認する必要がある。
確認する必要のある極めて重要な側面は、年-月－日、または日-月-年などの日付の形式である。
※4
I18Nは、「Internationalization」のIとNの間に18文字ある略称。
デバイスがユーザーとやり取りを行う言語などの「ロケール」を指定するファイル。
L10Nも、I18Nと同様、「localization」のIとNの間に10文字ある略称
ソフトウェアやシステムを特定の地域の言語や習慣に合うように改良すること。
◇3.1.8アクセシビリティテスト
「アクセシビリティテスト」は、身体的な制約を持つ人を含むユーザーがどの程度容易にコンポーネントやシステムを利用できるか判定するために行うテストです。
Google、Appleでは、それぞれアクセシビリティガイドラインが用意されています。
Google ユーザー補助機能
Googleでは、「Android」「Chrome」「YouTube」のそれぞれで、ユーザー補助機能について記載されていました。
Androidでは、テキスト読み上げ、触覚フィードバック、ナビゲーションなどの補助機能が搭載されています。
・Apple
アクセシビリティ – Apple（日本）
Appleでも同様に、拡大鏡、文字サイズ変更、Apple Watch等の連携、音声での読み上げなどが紹介されています。
また、モバイルWebに関しては、W3C（※5) から「Web Content Accessibility Guideline（WCAG）2.0」と呼ばれるガイドラインが公開されています。
・Web Content Accessibility Guideline（WCAG）2.0
https://waic.jp/docs/WCAG20/Overview.html
※5:W3Cは、World Wide Webで使用される各種技術の標準化を推進するために設立した標準化団体、非営利団体のこと。
上記それぞれのガイドラインを参考に、対象となるモバイルアプリケーションでアクセシビリティが考慮されているかのテスト観点がピックアップできそうです。
□3.2モバイルアプリケーションに適用可能なその他のテストレベル
3.1項にてモバイルアプリケーションのテストタイプ、テストプロセスが紹介されました。
こちらでは、コンポーネントテストから受け入れテストに至る一般的なテストレベルで実施が可能です。
3.2項では、上記以外のテストレベルで、モバイルアプリケーションのテストとして必要なテストレベルが述べられています。
・フィールドテスト
・アプリケーションストアの承認テストとリリース後テスト
◇3.2.1フィールドテスト
フィールドテストは、実地試験のことです。
ユーザーが期待するモバイルアプリケーションの利用シナリオで、正しく機能することを確認します。
Wi-Fiやモバイルデータ通信など、様々なネットワーク及び様々な通信技術タイプなどテストが含まれます。
・フィールドテストの特徴
携帯電話基地局やネットワーク、Wi-Fiの使用、及びアプリケーション使用時の携帯電話基地局切り替えを行う必要があります。
また、様々なダウンロード速度および電界強度を使用して実施する必要があり、不感地帯の処理も対象にする必要があります。
・フィールドテストを実施する場合
入念な計画と、テストを実行するために必要な全ての項目の特定が必要です。
（例）
・フィールドテストに適切なデバイスタイプ（最新OS、または必要最低限OSverなど）
・Wi -Fi
・事業者の料金プラン
・フィールドテストの注意点
フィールドテストを実施するためのルートや交通手段、時間帯をスケジュールする必要があります。
フィールドテストでは、温度や使用シナリオに関連する類似の条件などの環境要因も考慮する必要があります。
◇3.2.2 アプリケーションストアの承認テストとリリース後テスト
アプリケーションの公開前に、チェックリストベースのテストに合格して、アプリケーションストアの承認を得られるようにする必要があります。
Google Play StoreやApple Storeでは、それぞれのガイドライン、チェックリスト、承認プロセスなどが用意されています。
GooglePalyでは、チェックリストやデベロッパープログラムポリシー等が該当すると思われます。
●Google Play Store/Android
・公開前チェックリスト
https://developer.android.com/distribute/best-practices/launch/launch-checklist?hl=ja
・デベロッパープログラムポリシー
https://support.google.com/googleplay/android-developer/answer/11987217
●Apple
・Apple Store Reviewガイドライン
https://developer.apple.com/jp/app-store/review/guidelines/
・ガイドライン（アートワーク、ウォレットなど各ガイドラインリンク）
https://developer.apple.com/jp/app-store/guidelines/
「チェックリスト」
チェックリストは、オペレーティングシステム固有のもの、ユーザーインターフェースデザインや、アプリケーションストアによって提供されているライブラリおよびAPIの使用などのガイドラインに基づくものです。
上記Google Play Storeの公開前チェックリストなどが該当するでしょう。
「承認プロセス」
承認プロセスでは、チェックリスト等内部的に実施た後、アプリケーションの承認を行う際、時間を要することがあります。
Apple Storeでは24時間から48時間あたりで概ね承認結果が判別されるようです。
尚、承認プロセスで問題が発見されると、新しいバージョンの発行が要求され、問題解決および修正対応のため、さらに時間を要することがあります。
「リリース後テスト」
アプリケーションが各ストアでの承認が下り、リリースとなった場合、リリース後のテストとなります。
このテストレベルには、アプリケーションストアからのアプリケーションのダウンロードとインストールが含まれ、また既存機能がデグレしていないかの確認を含めるケースもあります。
□3.3経験ベースのテスト技法
こちらでは、経験ベースのテスト技法について述べられています。
JSTQB FLレベルでは、エラー推測、探索的テスト、チェックリストベースドテストが挙げられていましたが、モバイルアプリケーションでは以下のテスト技法について、取り上げられています。
・ペルソナとニーモニック
・ヒューリスティック
・ツアー
・セッションベースのテストマネジメント
◇3.3.1 ペルソナとニーモニック
「ペルソナ」
ペルソナは、ユーザー中心設計やマーケティングなどにおいて、サイトやアプリケーションを使用するユーザーを表すために作成された仮想的な人物像を表します。
アプリケーションを実際のユーザー使用するように、シナリオを立てて操作することを指します。
（ペルソナの特徴）
・動機、期待、問題、週間、および目標を持っており、実際のユーザーの振る舞いを模倣する必要がある場合に使用します。
・ペルソナは、名前、性別、年齢、収入、学歴、地域を持つこともできます。
・モバイル環境の場合、他のアプリを使用する、またはモバイルデバイスを1時間に複数回確認するなど、個人的な特徴を持つこともあります。
「ニーモニック」
ニーモニックは、一般的にはプログラムを実行させるための機械語（数字の羅列）をプログラミングしやすくするための簡略記憶記号を指します。
テストの分野において、ニーモニックのすべての文字は、技法、テスト方法、またはテストの焦点を表します。
JSTQBでは、ニーモニックの一例として、「SFiDPOT」を取り上げています。
こちらは、以下スライドで解説されており、各頭文字をとったものとなっています。
Karen N. Johnson – software testing heuristics & mnemonics
●SFiDPOT
・S-Structure
構造：例）ユーザーインターフェース要素、他アプリケーションの要素、およびそれらの順序と呼び出し階層。
・F-Funcftion
機能：例）想定通りに機能が動作している、利用できる、要件に従って機能しているなど。
・i-input
入力：例）必要な全ての入力が利用でき、キーボード、センサー、カメラなどからのの入力として想定通りに処理される。
・D-Data
データ：例）データは、要件に定義されているように（SDカード）格納、変更、追加、削除を行うことができる。
・P-Platform
プラットフォーム：例）アプリケーションのダウンロード用のストアなど、特定のオペレーティングシステム機能がデバイス設定に応じて利用できる。
・O-Operations
運用：例）モバイルデータ通信とWi-Fi間の移動など、一般ユーザーの活動が可能である。
・T-Time
時間：例）時間帯、時刻、日付の設定と表示。
また、モバイルに特化しているニーモニックとヒューリスティックは、「I SLICED UP FUN」であるとJSTQBでは述べられています。
こちらも各文字がそれぞれのイニシャルになっていて、以下を指しています。
●I SLICED UP FUN
ISLICEDUPFUN.pdf (kohl.ca)
・I-Inputs：入力
・S-Store：ストア
・L-Location： 場所
・I-Interactions and interruptions：連携と割り込み：
・C-Communication：通信
・E-Ergonomics：人間工学
・D-Data：データ
・U-Usability：使用性
・P-Platform：プラットフォーム
・F-Function：機能
・U-User scenarios：ユーザーシナリオ
・N-network：ネットワーク
上記ニーモニックは、私自身、もう少し掘り下げないと、理解が深まりません。
JSTQBにおいて、代表的なニーモニックは「SFiDPOT」「I SLICED UP FUN」があると認識すればよいかと思います。
◇3.3.2ヒューリスティック
「ヒューリスティック」とは、「発見的手法」という意味の心理学用語で、必ずしも正しい答えではありませんが、経験や先入観によって直感的に、正解に近い答えを得ることができる思考法を意味します。
JSTQBでの「ヒューリスティック」は、問題解決、学習、検出のための「経験則」を使ったアプローチです。
こちらは、最適、完璧であることを保証するものではありませんが、当面の目標を達成するためには十分であると見なすことができます。
注意点として、多くのヒューリスティックがモバイルテスト向けに存在し、ほとんどのニーモニックはヒューリスティックとして使用できますが、全てのヒューリスティックがニーモニックであるとは限らないとJSTQBシラバスでは表記されています。
◇3.3.3ツアー
「ツアー」はアプリケーションを特定の観点および焦点から探索するために、探索的テストで使用されます。
アプリケーションの動作の仕組みを理解し、ワークフローのモデルを作成するために実行できます。
ツアーは、フィールドテスト用の効果的な手法を提供します。
「ツアー」の例として、「ランドマークツアー」があります。
◯ランドマークツアー
ユーザーは都市の著名なランドマークを訪れることによってツーリストの訪問を模倣します。
以下の表は、ツアーで行われる訪問先について、モバイルテストで従うためのアナロジー（類推）として使用できることを示しています。
また、JSTQBでは、アプリケーションテスト用のツアーの好例と、テストのアイデアをカバーする領域を示した内容が掲載されています。
「ツアー」に関しても、探索的テスト時に、テスト観点を広げたり、テストのアイデアを整理する等に利用できると思います。
◇3.3.4セッションベースのテストマネジメント（SBTM）
セッションベースのテストマネジメント（SBTM)を使用すると、タイムボックス方式で探索的テストを管理できます。
１つのセッションは3つのタスクで構成されます。
・セッションセットアップ
・テスト設計と実行
・問題の調査と報告
SBTMでは、テスト目的を提供するテストチャーターが記載されているセッションシートを使用します。
セッションシートは、実施されたテスト実行の活動を文書化するためにも利用されます。
探索的テストは、60分～120を1セッションとして、その中でどのようなテストを実施するか構想し、それをもとにテスト実施、その後テスト実行の内容を明記するといった流れで行うことがあります。
このように、探索的テストの実施をまとめ、管理するやり方を行う際に有効なものだと思います。
□3.4モバイルテストプロセスと手法
こちらの項目では、モバイルのテストプロセスとその手法について述べられています。
モバイルテストを行う上で、１つの指針になる内容かと思います。
・テストプロセス
・テストアプローチ
◇3.4.1テストプロセス
モバイルのテストプロセスでは、固有の側面があります。
以下に大枠となるテストプロセス、プロセス内でのテストタイプなど明記しています。
○テスト計画作業
・テストする必要のあるデバイスの組み合わせ
・テスト環境の一部としてのモバイルエミュレーターとモバイルシミュレーターの使用
・モバイルアプリケーションテストでの特別な課題
・モバイルアプリケーションテストで特に必要なテストタイプ
○分析と設計
・アプリケーションストア承認テスト
・フィールドテスト
・デバイス互換性
・使用するラボの種類
・モバイルアプリケーションテストで特に必要なテストタイプ
○テスト実装とテスト実行（１）
・フィールドテスト
・ダウンロードと設置性のリリース後のテスト
・経験ベースの技法
○テスト実装とテスト実行（2）
・テストはユーザーインターフェースとアプリケーションのプラットフォームガイドラインに基づく。
・ガイドラインに基づくテストは通常、アプリケーションストア認証プロセス用に、プラットフォームプロバイダーによって実行される。
・承認拒否の可能性を排除するために、アプリケーションをプラットフォームプロバイダに提供する前に、アプリケーションプロバイダーとしてこれらを実行することが推奨される。
フィールドテスト、アプリケーションストア承認テストなど、モバイル特有のテストタイプ等を計画、設計時に考慮する必要があります。
工数や全体スケジュールを考慮して、対応する必要がありますね
◇3.4.2テストアプローチ
モバイルアプリケーションのテスト活動は、開発者、テスト担当者によって実行されます。
「テストレベル」、「モバイル開発プラットフォーム」について述べたいと思います。
・テストレベル
コンポーネントテスト、統合テスト、システムテスト、フィールドテスト、アプリケーションストア認証テスト、リリース後テスト、ユーザー受け入れテストごとにテストの適切な深度を決定することは、優れt品質のプロダクトを提供するために重要です。
テストレベルごとに必要なテストの深さとして、アプリケーションのアーキテクチャ、複雑度、意図するユーザーなど、多くの要因によって決定されます。
モバイルアプリケーションにとってテストピラミッドが逆さになることは、一般的であるとJSTQBでは述べられています。
それは、手動テストの量が大きくなる可能性があることを意味しています。
・モバイル開発プラットフォーム
モバイル開発プラットフォームは（Android Studio,Xcodeなど）、様々なレベルでテストを支援するツールが提供されています。
ツール自体と特定のレベルへの適用方法を理解することが重要となります。
実際のデバイスが利用できない場合、モバイルシミュレーターそしてモバイルユーザーインターフェースの一部の側面をテストが可能です。
また、ツールの早期導入は、デバイスが正しくセットアップされていること、実行のためにすべての前提条件が予定通りに満たされることを確認するために重要なポイントとなります。
■最後に
以上、JSSTQBシラバスモバイルアプリケーションテスト担当者の3項について紹介致しました。
次週は3項について、ご紹介したいと思います。
最後まで読んで頂き、ありがとうございました。
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方
