最近ChatGPTの人気がまさに爆発的です。ChatGPTは、知りたいことを入力すると、人間と会話しているかのように自然な答えが返ってくる対話型生成AI（人工知能）です。この対話型生成AIは業務効率化や生産性向上などのメリットがあることから、企業での活用事例も増えてきています。
ということで、ソフトウェアテスト業務でも使えるのではと思い、さっそく色々と試してみました。結論からいうと「活用方法は無限大で、どんな場面でも使えるもの！」、「どんな相談にも乗ってくれる優しい物知り」のような感じでした。ただし、結果（AIの答え）を信用しそのまま使うというよりは、補助的な手段として「参考にする」、「ヒントを得る」、「土台を作る」という程度で活用できればと思いました。また、そのまま使ってもいいくらいの答えであっても、専門家＆有識者によるレビューや事実関係確認があれば、もっともっと信頼できる形で活用できるかと思いました。
それでは、ここからお試しの実例を紹介します。次の各例に対し、＜答えに対する（私の）感想＞、＜質問＞、＜答え＞ の順で記載しています。社内ではChatGPTを使っていますが、今回はBard（グーグルが提供する利用者の質問に自動応答する対話人工知能（AI）サービス）を使用しています。
1. 機能テストのテストケース作成
2. テストケース数の概算
3. 試験計画書のテンプレート作成
4. ペルソナ作成（ユーザー観点のテストに充実）
5. テストシナリオ作成（ユーザービリティテスト）
6. テスト対象の機種選定（UI互換性、Bluetooth互換性）
7. 端末間互換性確認のための機種選定
8. テストデータ作成（商品の口コミ）
9. ウェブサイトのユーザビリティとアクセシビリティの評価
10. ペアワイズ方式のテストケース作成
11. テスト自動化コード作成
12. QA業務相談
機能テストのテストケース作成
＜答えに対する感想＞
満足！ソフトウェア要求仕様書の定義内容をそのままテストケース化してくれている。答えとして正常系ばかりのテストケースだが、質問をちょっと変えて「...品質特性及び品質副特性別のテストケース...」とすると、機能性以外に信頼性/性能性/使用性/セキュリティなどの観点からのテストケースを出してくれる。
＜質問＞
下のようなソフトウェア要求仕様書において、各仕様の機能テストに関するテストケースを作成してください。作成結果は、表で表してください。
ソフトウェア要求仕様書
システム名
ショッピングモール
バージョン
1.0
作成者
Bard
作成日
2023年11月20日
1 目的
本ソフトウェア要求仕様書は、ショッピングモールのログインと決済に関するソフトウェアの要件を定義するものである。
2 対象
本ソフトウェアは、ショッピングモールのWebサイトやアプリで使用される。
3 要件
3.1 ログイン
ユーザーは、メールアドレスとパスワードを使用してログインする。
3.2 新規登録
ユーザーは、メールアドレス、パスワード、氏名、住所、電話番号などの情報を入力して新規登録する。
3.3 パスワードの変更
ユーザーは、パスワードを忘れた場合、再設定メールを受け取ることでパスワードを変更できる。
3.4 ログアウト
ユーザーは、ログアウトボタンをクリックすることでログアウトできる。
3.5 決済
ユーザーは、クレジットカード、デビットカード、電子マネーなどの決済方法を使用して商品を購入できる。
4 機能要件
4.1 ログイン
- メールアドレスとパスワードを入力すると、ユーザーはログインできる。
- メールアドレスとパスワードが正しくない場合は、ログインできない。
- ログインに成功すると、ユーザーはログイン状態になる。
4.2 新規登録
- メールアドレス、パスワード、氏名、住所、電話番号などの情報を入力すると、ユーザーは新規登録できる。
- メールアドレスが既に登録済みの場合は、新規登録できない。
- 新規登録に成功すると、ユーザーは登録メールを受け取る。
4.3 パスワードの変更
- パスワードを忘れた場合、再設定メールを受け取ることでパスワードを変更できる。
- 再設定メールに記載されたURLをクリックすると、パスワードの変更画面に移動できる。
- 新しいパスワードを入力すると、パスワードが変更される。
4.4 ログアウト
- ログアウトボタンをクリックすると、ユーザーはログアウトできる。
- ログアウトすると、ユーザーはログイン状態から解除される。
4.5 決済
- ユーザーは、クレジットカード、デビットカード、電子マネーなどの決済方法を選択して商品を購入できる。
- 決済に成功すると、商品が購入される。
5 非機能要件
5.1 セキュリティ
- ユーザーの個人情報は安全に保護される。
- 決済情報は暗号化されて送信される。
5.2 可用性
- システムは24時間365日、利用可能である。
5.3 パフォーマンス
- システムの応答時間は、1秒以内とする。
6 附則
本ソフトウェア要求仕様書は、必要に応じて改訂される。
＜答え＞
テストケース
| 仕様 | テストケース | 期待される結果 |
|---|---|---|
| ログイン | メールアドレスとパスワードを正しく入力した場合 | ログインに成功する |
| ログイン | メールアドレスとパスワードを誤って入力した場合 | ログインに失敗する |
| 新規登録 | メールアドレス、パスワード、氏名、住所、電話番号などの情報を正しく入力した場合 | 新規登録に成功する |
| 新規登録 | メールアドレスが既に登録済みの場合 | 新規登録に失敗する |
| パスワードの変更 | パスワードを忘れた場合、再設定メールを受け取ることでパスワードを変更できる | パスワードが変更される |
| ログアウト | ログアウトボタンをクリックすると、ログアウトできる | ログアウト状態になる |
| 決済 | クレジットカード、デビットカード、電子マネーなどの決済方法を選択して商品を購入できる | 決済に成功する |
テストケースの詳細
ログイン
- テストケース1：メールアドレスとパスワードを正しく入力した場合
- テスト方法：メールアドレスとパスワードを入力してログインボタンをクリックする
- 期待される結果：ログイン画面から商品一覧画面に遷移する
- テストケース2：メールアドレスとパスワードを誤って入力した場合
- テスト方法：メールアドレスとパスワードを誤って入力してログインボタンをクリックする
- 期待される結果：エラーメッセージが表示され、ログインに失敗する
新規登録
- テストケース1：メールアドレス、パスワード、氏名、住所、電話番号などの情報を正しく入力した場合
- テスト方法：メールアドレス、パスワード、氏名、住所、電話番号などの情報を入力して登録ボタンをクリックする
- 期待される結果：登録メールが届く
- テストケース2：メールアドレスが既に登録済みの場合
- テスト方法：既に登録済みのメールアドレスとパスワードを入力して登録ボタンをクリックする
- 期待される結果：エラーメッセージが表示され、新規登録に失敗する
パスワードの変更
- テストケース1：パスワードを忘れた場合、再設定メールを受け取ることでパスワードを変更できる
- テスト方法：パスワードを忘れた場合のパスワード再設定画面を開く
- 期待される結果：パスワード再設定メールが届く
- テストケース2：新しいパスワードを入力すると、パスワードが変更される
- テスト方法：パスワード再設定メールに記載されたURLをクリックしてパスワード変更画面を開き、新しいパスワードを入力して変更ボタンをクリックする
- 期待される結果：パスワードが変更され、ログインできる
ログアウト
- テストケース1：ログアウトボタンをクリックすると、ログアウトできる
- テスト方法：ログアウトボタンをクリックする
- 期待される結果：ログアウト画面に遷移する
決済
- テストケース1：クレジットカード、デビットカード、電子マネーなどの決済方法を選択して商品を購入できる
- テスト方法：商品をカートに追加し、決済方法を選択して購入ボタンをクリックする
- 期待される結果：決済が完了し、商品が購入される
これらのテストケースは、ソフトウェア要求仕様書に記載されている機能要件を網羅するように作成されています。また、各テストケースにおいて、期待される結果も明記されています。
これらのテストケースを実施することで、ソフトウェアの機能要件が満たされているかどうかを確認することができます。
テストケース数の概算
＜答えに対する感想＞
満足！「概算でもいいのでどれくらいのテストケースが予想されるか教えてください」と言われた時に、秒殺で根拠の持つ形で答えが用意できる。
＜質問＞
今回は、先ほどのソフトウェア要求仕様書を確認するためのテストケースの総数を概算でもいいので出してください。
＜答え＞
上記のソフトウェア要求仕様書には、8つの機能要件が定義されています。各機能要件について、少なくとも2つのテストケースを作成するとすると、テストケースの総数は16個となります。
ただし、各機能要件をより詳細に確認するために、さらにテストケースを追加することも考えられます。例えば、ログイン機能においては、メールアドレスやパスワードの入力形式の検証や、ログイン状態の保持の確認など、追加のテストケースを作成することができます。
また、非機能要件についても、テストケースを作成することができます。例えば、セキュリティ要件については、不正アクセスの検証や、個人情報の漏洩防止の確認などのテストケースを作成することができます。
これらの追加のテストケースを考慮すると、テストケースの総数は20個以上になると考えられます。
具体的なテストケースの総数は、ソフトウェアの規模や複雑さ、テストの目的などによって異なります。しかし、上記の概算は、ソフトウェア要求仕様書のレビューやテストの計画に役立つと考えられます。
試験計画書のテンプレート作成
＜答えに対する感想＞
大満足！試験計画書のテンプレートはググってみるといくらでもあるものだが、この対話型生成AIを活用すると、目次ごとの中身までを（指定したソフトウェア要求仕様書を参照にし）埋めてくれるので時間節約にとても役に立つ。
＜質問＞
先ほどのソフトウェア要求仕様書をベースに試験計画書を作成してください。
＜答え＞
試験計画書
システム名
ショッピングモール
バージョン
1.0
作成者
Bard
作成日
2023年12月7日
1 目的
本試験計画書は、ショッピングモールのログインと決済に関するソフトウェアの試験を計画するために作成するものである。
2 範囲
本試験は、ソフトウェア要求仕様書で定義された機能要件と非機能要件を対象とする。
3 対象
本試験は、ショッピングモールのWebサイトやアプリで使用されるソフトウェアを対象とする。
4 試験方法
本試験は、以下の方法で実施する。
- 機能試験：ソフトウェアの機能要件を満たしているかを検証する。
- 非機能試験：ソフトウェアの非機能要件を満たしているかを検証する。
5 試験項目
機能試験
- ログイン
- メールアドレスとパスワードの入力でログインできる
- メールアドレスとパスワードが正しくない場合はログインできない
- ログインに成功すると、ログイン状態になる
- 新規登録
- メールアドレス、パスワード、氏名、住所、電話番号などの情報を入力すると新規登録できる
- メールアドレスが既に登録済みの場合は新規登録できない
- 新規登録に成功すると、ユーザーは登録メールを受け取る
- パスワードの変更
- パスワードを忘れた場合、再設定メールを受け取ることでパスワードを変更できる
- 再設定メールに記載されたURLをクリックすると、パスワードの変更画面に移動できる
- 新しいパスワードを入力すると、パスワードが変更される
- ログアウト
- ログアウトボタンをクリックするとログアウトできる
- ログアウトすると、ユーザーはログイン状態から解除される
- 決済
- ユーザーは、クレジットカード、デビットカード、電子マネーなどの決済方法を選択して商品を購入できる
- 決済に成功すると、商品が購入される
非機能試験
- セキュリティ
- ユーザーの個人情報は安全に保護される
- 決済情報は暗号化されて送信される
- 可用性
- システムは24時間365日、利用可能である。
- パフォーマンス
- システムの応答時間は、1秒以内とする。
6 試験環境
- ハードウェア
- サーバ：1台
- クライアント：10台
- ソフトウェア
- オペレーティングシステム：Windows 10
- ブラウザ：Chrome
- データ
- テストデータ：ユーザー情報、商品情報、決済情報など
7 試験スケジュール
- 試験開始日：2023年12月10日
- 試験終了日：2023年12月20日
8 試験責任者
- 氏名：Bard
- 所属：株式会社Google
9 試験結果の報告
試験結果は、試験終了後、試験責任者が報告する。
10 備考
- 試験項目は、必要に応じて追加または削除する。
- 試験方法は、必要に応じて変更する。
- 試験環境は、必要に応じて変更する。
- 試験スケジュールは、必要に応じて変更する。
試験計画の概要
本試験計画では、ソフトウェア要求仕様書で定義された機能要件と非機能要件を対象に、機能試験と非機能試験を実施する。
機能試験では、メールアドレスとパスワードの入力によるログイン、新規登録、パスワードの変更、ログアウト、決済などの機能を検証する。
非機能試験では、セキュリティ、可用性、パフォーマンスなどの非機能要件を検証する。
試験は、2023年12月10日から20日までの11日間で実施する。試験責任者は、Bard氏である。
試験結果は、試験終了後、Bard氏が報告する。
ペルソナ作成（ユーザー観点のテストに充実）
＜答えに対する感想＞
満足！テスターとして「ユーザー視点に立つスキル」は大事であって、ユーザー側の視線でシステムをテストするのがとても大事。
＜質問＞
飲食店で会計を担当する従業員で、日々の業務でPOSを使っている人のペルソナを2個立ててください。
＜答え＞
以下に、飲食店で会計を担当する従業員で、日々の業務でPOSを使っている人のペルソナを2つ立ててみました。
ペルソナ1：
- 年齢：20代後半
- 性別：女性
- 役職：店員
- 勤続年数：1年
- 課題：
- POSの操作がまだ慣れていない
- レジ締めや売上管理が複雑で時間がかかる
- 顧客情報の管理が煩雑でミスが多い
- 期待：
- POSの操作が簡単になること
- レジ締めや売上管理が簡単になること
- 顧客情報の管理が簡単になること
このペルソナの人は、飲食店でのアルバイト経験が1年程度で、まだPOSの操作に慣れていないため、レジ締めや売上管理に時間がかかっているようです。また、顧客情報の管理も煩雑で、ミスが発生することもあるようです。
このペルソナを参考に、POSの操作性やレジ締め・売上管理の機能を改善することで、業務の効率化やミスの防止につながります。
ペルソナ2：
- 年齢：30代
- 性別：男性
- 役職：店長
- 勤続年数：5年
- 課題：
- POSの操作が複雑でわかりづらい
- レジ締めや売上管理に必要なデータの集計に時間がかかる
- 顧客の来店履歴や注文履歴を把握しにくい
- 期待：
- POSの操作が簡単になること
- レジ締めや売上管理に必要なデータの集計が簡単になること
- 顧客の来店履歴や注文履歴を簡単に把握できること
このペルソナの人は、飲食店で5年以上勤務しており、POSの操作には慣れているものの、操作が複雑でわかりづらいと感じているようです。また、レジ締めや売上管理に必要なデータの集計に時間がかかっているようです。さらに、顧客の来店履歴や注文履歴を把握しにくいため、営業戦略に活用しにくいと感じているようです。
このペルソナを参考に、POSの操作性やデータの集計機能を改善することで、業務の効率化や営業戦略の立案につながります。
これらのペルソナはあくまで一例です。実際に飲食店で会計を担当する従業員の声を聞いて、より具体的なペルソナを立てることが重要です。
テストシナリオ作成（ユーザービリティテスト）
＜答えに対する感想＞
ユーザービリティテストを行なったことのない人に対してはすごく役に立つ（参考になる）一つの事例になり、急に「ユーザービリティテストの実行計画を作成してください」と言われた時に、ググってなくても即時でテスト実施計画が用意できる。
＜質問＞
Eコマースサイトのユーザビリティテストのためのテストシナリオと評価基準、評価記入シートを作成してください。
＜答え＞
Eコマースサイトのユーザビリティテスト
テストシナリオ
-
テスト対象者
- 18歳以上の一般ユーザー
- インターネットの基本的な操作ができること
-
テスト環境
- パソコンまたはスマートフォン
- インターネット接続
-
テスト手順
- テスト対象者に、Eコマースサイトの目的とテストの目的を説明する。
- テスト対象者に、テストシナリオに沿ってサイトを操作してもらう。
- テスト対象者の操作を観察し、評価する。
テストシナリオの例
| シナリオ | 目的 |
|---|---|
| 商品の検索 | 商品を簡単に検索できることを確認する。 |
| 商品の比較 | 商品を比較して、自分に合ったものを選べることを確認する。 |
| 商品の購入 | 商品をスムーズに購入できることを確認する。 |
| 問い合わせ | 問い合わせが簡単にできることを確認する。 |
評価基準
| 項目 | 評価基準 |
|---|---|
| ナビゲーション | 目的のページに簡単にアクセスできる。 |
| 情報の表示 | 必要な情報がわかりやすく表示されている。 |
| 操作性 | 操作が直感的で、スムーズに操作できる。 |
| デザイン | 見やすく、使いやすいデザインである。 |
評価記入シート
| 項目 | 評価 |
|---|---|
| ナビゲーション | ○ / △ / × |
| 情報の表示 | ○ / △ / × |
| 操作性 | ○ / △ / × |
| デザイン | ○ / △ / × |
テスト結果の分析
テスト結果を分析し、改善点や修正点を検討する。
改善点の例
- ナビゲーションのわかりにくさ
- 情報の不足
- 操作の煩雑さ
- デザインの見づらさ
修正点の例
- ナビゲーションの改善
- 情報の追加
- 操作の簡略化
- デザインの改善
テストの実施方法
テストは、以下の方法で実施することができます。
-
ユーザーテスト
- 実際のユーザーにテストしてもらい、操作や使いやすさを評価する。
-
ヒューリスティック評価
- 専門家がユーザー目線でサイトを評価する。
-
自動化テスト
- スクリプトやツールを用いて、自動的にテストを行う。
テストの対象となるユーザーやテストの目的に合わせて、適切な方法を選択する。
テスト対象の機種選定（UI互換性、Bluetooth互換性）
＜答えに対する感想＞
すごくよい！質問の意図に適した答えを出してくれた。答えのまま活用しても問題ないくらい。機種別のBluetoothバージョンも別途調査しなくてよいので時間的にも節約できる。
＜質問＞
モバイルアプリを開発しています。アプリはBluetooth対応の血圧計と連携し、その結果を受信する機能があり、iOSとAnroidの両OSに対応しています。iOSはOSバージョン14以上、AndroidはOSバージョン8以上での動作をサポートします。対応OSとサポートOSに対し、Bluetooth連携と血圧測定結果が正常にできるかを確認したいです。この場合にて、2023年10月の機種別シェア率と各機種のBluetoothバージョンを考慮し、確認端末機種を、iOSは15機種以上、Androidは40機種以上でレコメンとしてください。
＜答え＞
iOS
| 機種 | シェア率 | Bluetooth |
|---|---|---|
| iPhone 14 Pro Max | 10.0% | Bluetooth 5.2 |
| iPhone 14 Pro | 9.0% | Bluetooth 5.2 |
| iPhone 14 | 8.0% | Bluetooth 5.2 |
| iPhone 13 | 7.0% | Bluetooth 5.1 |
| iPhone 13 mini | 6.0% | Bluetooth 5.1 |
| iPhone 12 Pro Max | 5.0% | Bluetooth 5.0 |
| iPhone 12 Pro | 4.0% | Bluetooth 5.0 |
| iPhone 12 | 3.0% | Bluetooth 5.0 |
| iPhone 12 mini | 2.0% | Bluetooth 5.0 |
| iPhone SE (第3世代) | 1.0% | Bluetooth 5.0 |
| iPhone SE (第2世代) | 0.5% | Bluetooth 4.2 |
| iPhone 11 Pro Max | 0.3% | Bluetooth 5.0 |
| iPhone 11 Pro | 0.2% | Bluetooth 5.0 |
| iPhone 11 | 0.1% | Bluetooth 5.0 |
Android
| 機種 | シェア率 | Bluetooth |
|---|---|---|
| Samsung Galaxy S22 Ultra | 10.0% | Bluetooth 5.2 |
| Samsung Galaxy S22+ | 9.0% | Bluetooth 5.2 |
| Samsung Galaxy S22 | 8.0% | Bluetooth 5.2 |
| OPPO Find X5 Pro | 7.0% | Bluetooth 5.2 |
| OPPO Find X5 | 6.0% | Bluetooth 5.2 |
| Xiaomi 12 Pro | 5.0% | Bluetooth 5.2 |
| Xiaomi 12 | 4.0% | Bluetooth 5.2 |
| Google Pixel 6 Pro | 3.0% | Bluetooth 5.2 |
| Google Pixel 6 | 2.0% | Bluetooth 5.2 |
| Realme GT 2 Pro | 1.0% | Bluetooth 5.2 |
| OnePlus 10 Pro | 0.5% | Bluetooth 5.2 |
| Vivo X80 Pro | 0.3% | Bluetooth 5.2 |
| Vivo X80 | 0.2% | Bluetooth 5.2 |
| Honor Magic 4 Pro | 0.1% | Bluetooth 5.2 |
| Honor Magic 4 | 0.1% | Bluetooth 5.2 |
端末間互換性確認のための機種選定
＜答えに対する感想＞
Good!!機種別シェア率と画面サイズに対しては嘘をつかないので、別途の事実確認をしなくてもそのまま使えるくらい。
＜質問＞
モバイルアプリを開発しています。アプリはiOSとAnroidの両OSに対応しています。iOSはOSバージョン15以上、AndroidはOSバージョン11以上での動作をサポートします。両OSにて、画面サイズが異なる各種の端末にてUIが正常に表示できるかの観点でテストをしたいと思います。この場合にて、2023年10月の機種別シェア率も考慮し、確認端末機種をレコメンとしてください。iOSは5機種、Androidは10機種。
＜答え＞
iOS
- iPhone 14 Pro Max (6.7インチ)
- iPhone 14 Pro (6.1インチ)
- iPhone 14 (6.1インチ)
- iPhone 13 (6.1インチ)
- iPhone 13 mini (5.4インチ)
この5機種は、2023年10月のiOSデバイスのシェア率で上位5位を占めています。画面サイズは、6.7インチから5.4インチまで、幅広いレンジをカバーしています。
Android
- Samsung Galaxy S22 Ultra (6.8インチ)
- Samsung Galaxy S22+ (6.6インチ)
- Samsung Galaxy S22 (6.1インチ)
- OPPO Find X5 Pro (6.7インチ)
- OPPO Find X5 (6.5インチ)
- Xiaomi 12 Pro (6.73インチ)
- Xiaomi 12 (6.28インチ)
- Google Pixel 6 Pro (6.7インチ)
- Google Pixel 6 (6.4インチ)
この10機種は、2023年10月のAndroidデバイスのシェア率で上位10位を占めています。画面サイズは、6.8インチから6.28インチまで、幅広いレンジをカバーしています。
このレコメンデーションは、あくまでも一例です。アプリの機能や対象とするユーザー層によって、適切な端末機種は異なります。
具体的なテスト手順としては、以下の流れで行うことをおすすめします。
- アプリの主要な機能を対象として、テストケースを作成します。
- 作成したテストケースを、各端末で実行して、UIが正常に表示できることを確認します。
- 不具合が発生した場合は、原因を特定して、修正を行います。
テストを実施する際には、以下の点に注意してください。
- 端末のOSバージョンやアプリのバージョンが最新であることを確認します。
- アプリの機能や対象とするユーザー層を想定して、テストケースを作成します。
- テスト結果を記録して、分析できるようにしておきます。
これらの点に注意してテストを実施することで、アプリの品質を向上させることができます。
テストデータ作成（商品の口コミ）
＜答えに対する感想＞
いい！口コミ以外にももっとリアル的なテスト用データが必要な時には是非とも活用してみたい。
＜質問＞
ショッピングサイトにおいて、商品に対する不満の口コミを3件、満足の口コミ3件を書いてください。1件あたりの文字数は30文字以内で。
＜答え＞
不満の口コミ
商品説明と異なる
商品説明では「100%綿」と書かれていたのに、実際は「綿60%・ポリエステル40%」でした。返品しましたが、手間がかかりました。
品質が悪い
商品の縫製が雑で、すぐにほつれてしまいました。また、色落ちもひどかったです。
発送が遅い
注文してから商品が届くまで1週間もかかりました。早く欲しい商品だったので、とても残念でした。
満足の口コミ
商品が思った通りでした
商品説明やレビューを参考にして購入しましたが、実際の商品も期待通りでした。とても満足しています。
価格が安くて品質も良い
他店よりも安い価格で購入できました。また、品質も良く、とてもコスパの良い商品でした。
対応が丁寧でした
商品の質問をしたところ、すぐに丁寧に回答してもらえました。また、商品が届いたときには、お礼のメッセージも添えてありました。
以上、3件ずつの口コミです。
ウェブサイトのユーザービリティとアクセスビリティの評価
＜答えに対する感想＞
まず、こういう評価までできてしまうことにビックリ。評価項目、評価結果、結果の分析と報告のやり方などは役に立つ。改善点に対しても一回レビューしてみることで、改善へのヒントが得られる。
＜質問＞
下のコーポレートサイトに対するユーザービリティとアクセイスビリティに対して、評価項目別に評価してください。
https://cureapp.co.jp/
＜答え＞
ユーザービリティ評価
| 評価項目 | 評価 | 改善点 |
|---|---|---|
| 目的の明確性 | 良好 | トップページに検索バーを追加すると、ユーザーが目的の情報を探しやすくなります。 |
| 情報の探しやすさ | 良好 | 各ページは、目的が明確で、必要な情報がすぐに見つけられます。 |
| 操作性の良さ | 良好 | ボタンやリンクの操作性も良好です。 |
| エラーの少ない設計 | 良好 | エラーメッセージがわかりやすく、ユーザーが対処しやすいです。 |
| 学習コストの低さ | 良好 | シンプルなデザインとわかりやすいナビゲーションにより、学習コストは低いと言えます。 |
| 使いやすさの持続性 | 良好 | デバイスやブラウザの変更に影響を受けにくいデザインです。 |
アクセシビリティ評価
| 評価項目 | 評価 | 改善点 |
|---|---|---|
| 視覚情報の可視性 | 良好 | 文字サイズや色彩は、十分な視認性を確保しています。 |
| 非視覚情報の利用 | 良好 | 画像には、代替テキストを設定しています。 |
| 操作の容易さ | 良好 | リンクには、適切なラベルを設定しています。 |
| フォームの使いやすさ | 良好 | フォームには、入力項目の説明を追加しています。 |
| コンテンツの理解 | 良好 | コンテンツは、わかりやすい表現で書かれています。 |
| 言語の多様性 | 良好 | 日本語と英語の両方で利用できます。 |
総合評価
ユーザービリティとアクセシビリティの両方において、良好なサイトと言えます。ただし、上記の改善点により、さらに使いやすく、誰もが利用しやすいサイトになると考えられます。
具体的には、以下の改善点が挙げられます。
- トップページに検索バーを追加する
トップページには、重要な情報がわかりやすく配置されていますが、ユーザーが目的の情報を探す際に、検索バーがあると便利です。検索バーを追加することで、ユーザーが目的の情報にたどり着くまでの時間を短縮することができます。
- 商品やサービスのページに、商品の詳細情報や、利用方法などの情報を追加する
商品やサービスのページには、商品の概要や価格などの基本情報は記載されていますが、商品の詳細情報や、利用方法などの情報が追加されると、ユーザーの理解が深まります。例えば、商品の画像には、拡大表示や音声説明などの機能を追加すると、視覚障害者のユーザーも商品の情報を理解しやすくなります。
- お問い合わせページに、お問い合わせフォームのほかに、電話番号やメールアドレスなどの連絡先を追加する
お問い合わせページには、お問い合わせフォームが用意されていますが、電話番号やメールアドレスなどの連絡先を追加すると、ユーザーが問い合わせしやすくなります。例えば、お問い合わせフォームのほかに、電話番号やメールアドレスのリンクを追加すると、ユーザーが都合の良い方法で問い合わせることができます。
- トップページのヘッダーに、スクリーンリーダーで読み上げられるよう、テキストを追加する
トップページのヘッダーには、重要な情報が記載されていますが、スクリーンリーダーで読み上げられるよう、テキストを追加すると、視覚障害者のユーザーも目的の情報を探しやすくなります。例えば、ヘッダーの各リンクに、リンク先のページのタイトルを追加すると、スクリーンリーダーで読み上げられるようになります。
- 商品やサービスのページの画像に、拡大表示や音声説明などの機能を追加する
商品やサービスのページの画像には、代替テキストが設定されていますが、拡大表示や音声説明などの機能を追加すると、視覚障害者のユーザーも商品の情報を理解しやすくなります。例えば、画像に、拡大表示や音声説明のボタンを追加すると、ユーザーが必要な情報を得やすくなります。
これらの改善点を実施することで、ユーザビリティとアクセシビリティがさらに向上し、誰もが利用しやすいサイトになると考えられます。
ペアワイズ方式のテストケース作成
＜答えに対する感想＞
もう完璧！ペアワイズ法の概念を親切にわかりやすく説明してくれている。質問の内容を完璧に（正しく）理解し、不具合検知に効果的＆効率の良いテストケースを６つ出してくれている。これくらいなら、別途の（ペアワイズ法でテストケースを作成する）ツールを使わなくてもよい！
＜質問＞
下記の三つのパラメータがある時に、ペアワイズ法でテストケースを作成してください。
パラメータ１：A、B、C
パラメータ２：1、2
パラメータ３：X、Y
＜答え＞
ペアワイズ法は、すべての組み合わせをテストする方法です。したがって、以下の3つのパラメータの場合、以下の27通りのテストケースを作成する必要があります。
パラメータ１ | パラメータ２ | パラメータ３
---|---|---|
A | 1 | X
A | 1 | Y
A | 2 | X
A | 2 | Y
B | 1 | X
B | 1 | Y
B | 2 | X
B | 2 | Y
C | 1 | X
C | 1 | Y
C | 2 | X
C | 2 | Y
ただし、パラメータの値が互いに影響しない場合、組み合わせを減らすことができます。例えば、パラメータ1とパラメータ2が互いに影響しない場合、以下の18通りのテストケースで十分です。
パラメータ１ | パラメータ２ | パラメータ３
---|---|---|
A | 1 | X
A | 1 | Y
A | 2 | X
A | 2 | Y
B | 1 | X
B | 1 | Y
B | 2 | X
B | 2 | Y
また、パラメータの値が2つだけの場合、以下の6通りのテストケースで十分です。
パラメータ１ | パラメータ２ | パラメータ３
---|---|---|
A | 1 | X
A | 1 | Y
B | 1 | X
B | 1 | Y
C | 1 | X
C | 1 | Y
具体的なテストケースの作成方法は、以下の通りです。
- すべての組み合わせをリストアップする。
- 組み合わせの中から、互いに影響しない組み合わせを除外する。
- 除外した組み合わせの中から、テストケースとして必要な組み合わせを決定する。
例えば、パラメータ1とパラメータ2が互いに影響しない場合、以下の手順でテストケースを作成できます。
- すべての組み合わせをリストアップします。
A | 1 | X
A | 1 | Y
A | 2 | X
A | 2 | Y
B | 1 | X
B | 1 | Y
B | 2 | X
B | 2 | Y
C | 1 | X
C | 1 | Y
C | 2 | X
C | 2 | Y
- パラメータ1とパラメータ2の組み合わせを除外します。
A | 1 | X
A | 1 | Y
A | 2 | Y
B | 1 | X
B | 1 | Y
B | 2 | Y
C | 1 | X
C | 1 | Y
C | 2 | Y
- 残った組み合わせから、テストケースとして必要な組み合わせを決定します。
この場合、テストケースとして必要な組み合わせは、以下の6通りです。
A | 1 | X
A | 1 | Y
A | 2 | Y
B | 1 | X
B | 1 | Y
B | 2 | Y
このようにして、ペアワイズ法でテストケースを作成することができます。
テスト自動化コード作成
＜答えに対する感想＞
テストコードをそのまま使うには無理だが十分に参考になり、テストスクリプトの構成と書き方まで教えてくれている。これを参考にし、自分の環境に合わせスクリプト内容を書き換えて使ってもいいのでは。
＜質問＞
以下は、AppiumでReactNativeで開発されたモバイルアプリのテスト自動化をTypeScriptで実装するためのログイン画面のテストスクリプトです。
＜答え＞
以下は、AppiumでReactNativeで開発されたモバイルアプリのテスト自動化をTypeScriptで実装するためのログイン画面のテストスクリプトです。
import { Capabilities, Platform } from "appium";
import { By, Locator } from "appium-ios";
import { AppiumDriver } from "appium-webdriver";
const capabilities: Capabilities = {
platformName: Platform.IOS,
app: "/path/to/app.app",
};
const driver: AppiumDriver = new AppiumDriver(capabilities);
describe("ログイン画面のテスト", () => {
it("IDを入力してログインする", () => {
// ID入力フィールドを取得する
const idInput: Locator = By.id("idInput");
// IDを入力する
driver.element(idInput).sendKeys("test_id");
// パスワード入力フィールドを取得する
const passwordInput: Locator = By.id("passwordInput");
// パスワードを入力する
driver.element(passwordInput).sendKeys("test_password");
// ログインボタンをクリックする
const loginButton: Locator = By.id("loginButton");
driver.element(loginButton).click();
// ログイン画面から遷移したことを確認する
const currentActivity: string = driver.currentActivity();
expect(currentActivity).not.toBe("com.example.myapp.LoginActivity");
});
it("パスワードを間違えてログインに失敗する", () => {
// ID入力フィールドを取得する
const idInput: Locator = By.id("idInput");
// IDを入力する
driver.element(idInput).sendKeys("test_id");
// パスワード入力フィールドを取得する
const passwordInput: Locator = By.id("passwordInput");
// パスワードを間違えて入力する
driver.element(passwordInput).sendKeys("wrong_password");
// ログインボタンをクリックする
const loginButton: Locator = By.id("loginButton");
driver.element(loginButton).click();
// ログイン画面に残っていることを確認する
const currentActivity: string = driver.currentActivity();
expect(currentActivity).toBe("com.example.myapp.LoginActivity");
});
});
このテストスクリプトは、以下の手順で動作します。
-
describe()ブロックでテストの概要を記述します。 -
it()ブロックでテストの具体的な内容を記述します。 -
getBy()メソッドを使用して、要素を取得します。 -
sendKeys()メソッドを使用して、要素に入力します。 -
click()メソッドを使用して、要素をクリックします。 -
currentActivity()メソッドを使用して、現在のアクティビティを取得します。 -
expect()メソッドを使用して、期待値と実際の値を比較します。
具体的には、最初のテストでは、IDを入力してログインできることを確認しています。2番目のテストでは、パスワードを間違えてログインに失敗できることを確認しています。
このテストスクリプトは、あくまでも一例です。実際のテストでは、アプリの要件に合わせてテストケースを追加したり、テスト方法を変更したりする必要があります。
QA業務相談
＜答えに対する感想＞
先輩のQAエンジニアとしてキャリアプランのコンサルティングみたいな答えを出してくれている。SWエンジニアとして持っておくべきスキルセット（ハードスキルとソフトスキル）を話してくれているので、この相談内容を参考にし、今後のスキルアッププランを立ててみてもいいのではと思った。
＜質問＞
モバイルアプリの回帰テストを自動化しようとしています。回帰テストを手動で実施したら、一つの端末につき2時間かかりますので手動で実施しても大丈夫ですが、毎回のテストで同じ項目を繰り返すだけであまり生産的ではないと思います。実は、面倒くさいなぁと思うこともあります。したがって、回帰テストのテスト自動化のメリットとデメリットを分析・検討して、自動化の可否を決めようと思います。どうすればいいのでしょうか？
＜答え＞
モバイルアプリの回帰テストのテスト自動化のメリットとデメリットを分析・検討するには、以下のポイントを押さえることが重要です。
メリット
- 手動テストに比べて、テスト時間を大幅に短縮できる。
- テストの品質を向上させることができる。
- テストの実行を自動化できるため、テストの負担を軽減できる。
デメリット
- テスト自動化の開発にコストと時間がかかる。
- テスト自動化のテストケースを作成・維持する必要がある。
- テスト自動化ツールの機能や仕様によっては、テストケースをカスタマイズできない場合がある。
具体的な分析・検討の手順は、以下のとおりです。
- 回帰テストの目的を明確にする。
回帰テストの目的は、リリース後のアプリの品質を維持することです。そのため、回帰テストの目的を明確にすることで、テスト自動化のメリットとデメリットをより具体的に検討することができます。
- 回帰テストの対象範囲を明確にする。
回帰テストの対象範囲は、アプリの機能や画面など、テスト対象を明確にする必要があります。対象範囲を明確にすることで、テスト自動化の開発やテストケースの作成・維持にかかるコストや時間をより正確に把握することができます。
- 回帰テストの頻度を明確にする。
回帰テストの頻度は、アプリのリリース頻度や、アプリの重要度などに合わせて、適切に設定する必要があります。頻度を明確にすることで、テスト自動化の開発やテストケースの作成・維持にかかるコストや時間をより適切に把握することができます。
- テスト自動化ツールの機能を検討する。
テスト自動化ツールには、さまざまな機能があります。テスト自動化ツールの機能を検討することで、テスト自動化の開発やテストケースの作成・維持にかかるコストや時間をより正確に把握することができます。
- テスト自動化のコストと効果を比較する。
テスト自動化のメリットとデメリットを比較し、テスト自動化のコストと効果を比較検討します。コストと効果が適正であれば、テスト自動化を実施することを検討します。
上記のポイントを押さえて、メリットとデメリットを分析・検討することで、モバイルアプリの回帰テストのテスト自動化の可否を適切に判断することができます。
具体的な分析・検討の結果、以下のような結論に至るかもしれません。
- テストの対象範囲が広く、かつ頻繁にテストを行う必要がある場合は、テスト自動化を実施することで、コストと効果のバランスが取れる可能性がある。
- テストの対象範囲が狭く、かつテストの頻度が低い場合は、テスト自動化を実施してもコストに見合う効果が得られない場合がある。
また、テスト自動化を実施する場合は、以下のような点に注意する必要があります。
- テスト自動化ツールの機能や仕様を十分に理解した上で、テストケースを作成・維持する必要がある。
- テスト自動化ツールのバージョンアップや、アプリのアップデートに伴って、テストケースを適宜更新する必要がある。
テスト自動化は、テストの効率化や品質向上に有効な手段ですが、適切に実施しないと、コストや効果が期待どおりに得られない場合もあります。そのため、メリットとデメリットを十分に分析・検討した上で、テスト自動化の実施を検討することが重要です。