2024年01月12日(金曜日)
1月12日(金)にアウトプット共有会・勉強会をリモートを併用して開催しました。
今回のテーマ：アドホックテスト時の確認ポイントについて
ソフトウェア開発などのテスト工程では、作成されたテスト項目書に従って期待結果を確認するのとは別に、独自のテストナレッジ(ノウハウ)などをもとにテストを実施することがあります。
今回はガジュマルのメンバーが業務で得た知見に基づき、アドホックテストを行う際の流れや確認ポイントについてアウトプット共有を行いました。
1. テスト工程について
テストは主に以下の4工程で行われます。
(1)単体テスト プログラム単体のテスト
(2)結合テスト プログラム間の結合テスト
(3)システムテスト ・システム全体を通したテスト・非機能テスト
(4)受け入れテスト ・業務シナリオテスト
今回共有するポイントは「(3)システムテスト」と「(4)受入テスト」です。
2. 不具合摘出について
2.1.不具合発生要因
不具合は「状態」+「操作」の組み合わせで発生します。
テストは、この二つのポイントを意識して実施します。
※ スマートフォン想定を想定した場合
「状態」:環境、設定条件、動作中、画面
「操作」:キー操作、機能実行、中断、終了、割り込み、挿し抜き(外部メモリ、外部機器)...etc
「確認箇所」:動作、表示、音、お知らせランプ点灯、バックライト点灯、レスポンス
2.2. 「特徴」を意識する
「特徴」とは、 その機能にしかない、特有な「状態」と「操作」を指す
・新機能、追加、変更点など差分があるもの
・機能ごとの工夫した使い方
・外部機器を使用した動作
・操作を必要としない画面遷移(タイムアウト、割り込み)
・不具合が多く出ている機能、状態、操作(不具合管理システムなどで調査)
2.2.1. 機能ごとの特徴例
・受信メールを検索する(状態) → 全件削除する(操作)
=検索された中の全件のみが削除されること(結果)
・アプリをバックグラウンドにした後に別操作してからアプリをフォアグラウンドに戻して操作
=表示がバックグラウンド前と変わらないこと(結果)
など
2.3.結果(期待動作)から手順を作ってみる
(1)手順から結果を導く方法(一般的なテスト方法)
テストは決められた手順を操作してから実施結果が後についてくるもので、
結果が出てから動作が正しいか判断する流れが一般的です。
(2)結果から手順を作り出す方法
まず、その機能で何を確認したいかを考え、どんな結果を期待するか整理します。
次に、その期待動作に対してどのような手順を行うかを洗い出します。
実施の流れ:
機能や見所を決める → 期待動作を考える → 手順を考える
→ 手順の中に「期待動作を阻害する条件」を入れる
ここで大切なポイントは、
「期待動作にならない方法(期待動作を阻害する条件)を考えることです
※ 以下は「期待動作を阻害する条件」を工夫して不具合検出を行う手法の一例です。
■ 決済アプリからの PayPay 決済を確認する(何をするのか具体的なテーマなどを決める)
→ 決済アプリから PayPay アプリに連携して決済する(結果)
→ 決済アプリから決済時の方法で PayPay を選択する(手順)
→ スマートフォンから PayPay アプリを削除して PayPay アプリに連携されないようにする
(期待動作を阻害する条件)
■ 決済アプリで決済する(テーマ)
→ 決済アプリから決済できること(結果)
→ 決済アプリから決済時の方法で任意の決済方法を選択する(手順)
→ 1 日の決済上限金額を超える買い物をして、決済時の上限エラーが出るようにする
(期待動作を阻害する条件)
■ 電話の連絡先を表示する(テーマ)
→ 電話に連絡先が表示されること(結果)
→ 電話から連絡先を選択する(手順)
→ 電話のアプリ権限で連絡先を許可しない設定を行い、連絡先を表示できないようにする
(期待動作を阻害する条件)
2.4.不具合摘出には情報収集、アイデア交換が不可欠
2.4.1. 起票済みの不具合を見ましょう
■ 不具合を見つけるには、知識、技術が必要です。
空いた時間があったら積極的に不具合について学習し、テストの中に活かしていけるよう取り組んでください。
■ 起票済みの不具合では、どんな機能、状態、操作によって発生したかを見てください。
■ 起票済みの不具合は、不具合起票時の手本としても活用することができます。
起票された不具合を学習し、アイデアを出し合いながら情報を集めます。
一人で考え出せるアイデアには限界があるので、チームメンバーで気になる事象などを情報展開することも大切です。
テスト項目を作成してから実施したり、操作してからテスト項目を起こすなど、自分らしいやり方を考えながらテストしてください。
他の人が見落としそうな操作を試してみるなど、個性的なやり方も考慮します。
一人で悩むことなく、積極的に話し合いの場を作っていってください。
2.5.普段の意識
不具合が見つからない時ほど、積極的に探し、攻めの気持ちでテストします。守りの気持ちでは見逃してしまう可能性があります。
2.6.不具合が発生しやすい条件
特に注意すべき条件として、以下の要素があります。
■ 操作の中断・中止後の戻り先画面
■ 操作の中断・中止後の再実行
■ 画面状態の更新
例えば、データフォルダにファイルを格納 → データフォルダー覧にファイルが 1 件増える。
この更新を考慮して、あらゆる状態を作ってからファイルを格納する。
■ 未保存データがある状態の操作 → 保存/破棄 → 再実行
■ 中断中アプリがある状態の操作 → アプリの復帰
3. テスト確認ポイントについて
3.1.一つの操作をいろんな視点から見る
■ 音声電話着信する
確認ポイント:音の鳴動、音量、設定データ、着信画面表示、着信中操作、 着信後の待受表示、マナー中着信、終話後の戻り先
大切なのは、上の例を全て実施するのではなく、
洗い出した項目から優先順位をつけて実施することです。
優先順位がわからない内は、経験者にアドバイスをもらったり、
一通り実施しながら問題が起こりそうな箇所(弱点)をつかんでいってください。
3.2. テストの目的に沿った確認をする
音なら音、文字なら文字に関連付けることがポイントです。
目的を考える
→目的を阻害するような状態作りや操作をする
→目的通りの結果になったかを確認する
■ 音声データ再生
確認ポイント:バックグラウンド再生中、マナー中、イヤホン再生、
音声がある割り込み(音声着信、E メール受信、アラーム...etc)
■ 文字入力
確認ポイント:入力に関する設定(全角/半角、文字種)、入力方法(引用、辞書、候補)
入力画面(メモ帳タイトル・本文、E メール宛先・本文、ファイル名編集...etc)
3.3. テーマを決めて実施する
テストをする際は、どんな不具合を狙って操作するかが重要です。
できるだけ具体的に、表示や画面遷移、中止操作、割込み動作などの方向性を決めて実施してください。
テスト項目を考える際、手順から結果を求めた実施方法だけでなく、
期待する動作から、手順を考えて実施する方法も取り入れてみてください。
3.4.できるだけ同じことをやらない
テスト項目は、「状態」と「操作」から構成されますが、異なる画面で同じ操作を繰り返すのではなく、着信でもいろんな視点から見たり、画面の状態を少し変えたり、常に考えてテストすることを意識してください。
■ 画面の状態
文字入力の通常画面、メニュー表示中、メニュー機能実行中、ポップアップ表示、
他機能連携中、起動元によるルートの違い
※ 起動元によるルートの違い(画面遷移図、起動契機の資料などあれば参考にすること)
ショートカットキーで目的画面を表示
メニューから目的画面を表示
⇒起動契機が異なることで結果が変わっていないこと
3.5.設定入力時はその後の動作も見る
設定を確認する項目は、設定完了の表示が出たら終了ではありません。
すべてのパターンで見る必要はありませんが、設定したら動作に反映されているか見るように意識してください。
■ 設定:
設定/OFF で変更確定前にキャンセルキー ⇒ 変更前の状態
設定/OFF で OFF を再設定 ⇒ 変更前の状態
設定/OFF で ON を設定 ⇒ 変更後の状態
■ 入力:
「09」入力後、「08」へ変更し確定する ⇒ 変更が反映され「08」となっていること (「09」になっていないこと)
3.6.境界値に注意する
設定時入力時は有効同値クラス、無効同値クラスに同値分割して境界値に注意して確認しましょう。
有効同値クラス: システムで有効な値
無効同値クラス: システムで無効な値
境界値: 入力に対する出力結果が変わる境界の値
■全角 512byte(半角 1024byte)入力可能とする場合
⇒513byte まで入力後、全角(2byte)、半角(1byte)を入力するとそれぞれどうなるか。
※ コピー&ペースト、引用して入力なども確認。
※ 1 字 1 字入力して byte 消費するだけでなく改行なども入れるとどうなるか。
3.7.バランスを調整する
テスト方法には、「浅く広く」や「深く狭く」など、実施内容によって時間のかかり方が異なってきます。
朝から晩までずっと同じペースでテストするのではなく、自分でやりやすい方法でペース配分してください。
■ 朝は浅く広く実施し、用意されたテスト項目をこなす
昼は不具合を見つける事に集中し、ポイントを絞った確認をする
夕は朝昼で偏った部分のバランスを調整する
■ 夕のパターン
テスト数が少ない場合は、項目数を意識
不具合が出ていないなら、ポイントを絞った確認をする
※ 「テストに集中して進捗を上げる時間」と「バグ出しに集中してバグを発見する時間」
それぞれのバランスを考えてテストすること
【参加者の感想】
●「開発経験が少ないため、テスト項目などどれくらいの粒度で設定すれば分からなかったが、説明を聞いて分かりやすかった」
●「テスト項目書がある状態でテストを行うことが多いので、結果から考えてテストを実施するという観点は盲点だった」
株式会社ガジュマルでは、今後も定期的に技術勉強会や、エンジニアの交流イベントを開催いたします！
興味がある方、参加してみたいという方は、以下の公式LINEを友だち追加のうえ、お気軽にお問合せください。
LINE登録はこちらから。
今回のテーマ：アドホックテスト時の確認ポイントについて
ソフトウェア開発などのテスト工程では、作成されたテスト項目書に従って期待結果を確認するのとは別に、独自のテストナレッジ(ノウハウ)などをもとにテストを実施することがあります。
今回はガジュマルのメンバーが業務で得た知見に基づき、アドホックテストを行う際の流れや確認ポイントについてアウトプット共有を行いました。
1. テスト工程について
テストは主に以下の4工程で行われます。
(1)単体テスト プログラム単体のテスト
(2)結合テスト プログラム間の結合テスト
(3)システムテスト ・システム全体を通したテスト・非機能テスト
(4)受け入れテスト ・業務シナリオテスト
今回共有するポイントは「(3)システムテスト」と「(4)受入テスト」です。
2. 不具合摘出について
2.1.不具合発生要因
不具合は「状態」+「操作」の組み合わせで発生します。
テストは、この二つのポイントを意識して実施します。
※ スマートフォン想定を想定した場合
「状態」:環境、設定条件、動作中、画面
「操作」:キー操作、機能実行、中断、終了、割り込み、挿し抜き(外部メモリ、外部機器)...etc
「確認箇所」:動作、表示、音、お知らせランプ点灯、バックライト点灯、レスポンス
2.2. 「特徴」を意識する
「特徴」とは、 その機能にしかない、特有な「状態」と「操作」を指す
・新機能、追加、変更点など差分があるもの
・機能ごとの工夫した使い方
・外部機器を使用した動作
・操作を必要としない画面遷移(タイムアウト、割り込み)
・不具合が多く出ている機能、状態、操作(不具合管理システムなどで調査)
2.2.1. 機能ごとの特徴例
・受信メールを検索する(状態) → 全件削除する(操作)
=検索された中の全件のみが削除されること(結果)
・アプリをバックグラウンドにした後に別操作してからアプリをフォアグラウンドに戻して操作
=表示がバックグラウンド前と変わらないこと(結果)
など
2.3.結果(期待動作)から手順を作ってみる
(1)手順から結果を導く方法(一般的なテスト方法)
テストは決められた手順を操作してから実施結果が後についてくるもので、
結果が出てから動作が正しいか判断する流れが一般的です。
(2)結果から手順を作り出す方法
まず、その機能で何を確認したいかを考え、どんな結果を期待するか整理します。
次に、その期待動作に対してどのような手順を行うかを洗い出します。
実施の流れ:
機能や見所を決める → 期待動作を考える → 手順を考える
→ 手順の中に「期待動作を阻害する条件」を入れる
ここで大切なポイントは、
「期待動作にならない方法(期待動作を阻害する条件)を考えることです
※ 以下は「期待動作を阻害する条件」を工夫して不具合検出を行う手法の一例です。
■ 決済アプリからの PayPay 決済を確認する(何をするのか具体的なテーマなどを決める)
→ 決済アプリから PayPay アプリに連携して決済する(結果)
→ 決済アプリから決済時の方法で PayPay を選択する(手順)
→ スマートフォンから PayPay アプリを削除して PayPay アプリに連携されないようにする
(期待動作を阻害する条件)
■ 決済アプリで決済する(テーマ)
→ 決済アプリから決済できること(結果)
→ 決済アプリから決済時の方法で任意の決済方法を選択する(手順)
→ 1 日の決済上限金額を超える買い物をして、決済時の上限エラーが出るようにする
(期待動作を阻害する条件)
■ 電話の連絡先を表示する(テーマ)
→ 電話に連絡先が表示されること(結果)
→ 電話から連絡先を選択する(手順)
→ 電話のアプリ権限で連絡先を許可しない設定を行い、連絡先を表示できないようにする
(期待動作を阻害する条件)
2.4.不具合摘出には情報収集、アイデア交換が不可欠
2.4.1. 起票済みの不具合を見ましょう
■ 不具合を見つけるには、知識、技術が必要です。
空いた時間があったら積極的に不具合について学習し、テストの中に活かしていけるよう取り組んでください。
■ 起票済みの不具合では、どんな機能、状態、操作によって発生したかを見てください。
■ 起票済みの不具合は、不具合起票時の手本としても活用することができます。
起票された不具合を学習し、アイデアを出し合いながら情報を集めます。
一人で考え出せるアイデアには限界があるので、チームメンバーで気になる事象などを情報展開することも大切です。
テスト項目を作成してから実施したり、操作してからテスト項目を起こすなど、自分らしいやり方を考えながらテストしてください。
他の人が見落としそうな操作を試してみるなど、個性的なやり方も考慮します。
一人で悩むことなく、積極的に話し合いの場を作っていってください。
2.5.普段の意識
不具合が見つからない時ほど、積極的に探し、攻めの気持ちでテストします。守りの気持ちでは見逃してしまう可能性があります。
2.6.不具合が発生しやすい条件
特に注意すべき条件として、以下の要素があります。
■ 操作の中断・中止後の戻り先画面
■ 操作の中断・中止後の再実行
■ 画面状態の更新
例えば、データフォルダにファイルを格納 → データフォルダー覧にファイルが 1 件増える。
この更新を考慮して、あらゆる状態を作ってからファイルを格納する。
■ 未保存データがある状態の操作 → 保存/破棄 → 再実行
■ 中断中アプリがある状態の操作 → アプリの復帰
3. テスト確認ポイントについて
3.1.一つの操作をいろんな視点から見る
■ 音声電話着信する
確認ポイント:音の鳴動、音量、設定データ、着信画面表示、着信中操作、 着信後の待受表示、マナー中着信、終話後の戻り先
大切なのは、上の例を全て実施するのではなく、
洗い出した項目から優先順位をつけて実施することです。
優先順位がわからない内は、経験者にアドバイスをもらったり、
一通り実施しながら問題が起こりそうな箇所(弱点)をつかんでいってください。
3.2. テストの目的に沿った確認をする
音なら音、文字なら文字に関連付けることがポイントです。
目的を考える
→目的を阻害するような状態作りや操作をする
→目的通りの結果になったかを確認する
■ 音声データ再生
確認ポイント:バックグラウンド再生中、マナー中、イヤホン再生、
音声がある割り込み(音声着信、E メール受信、アラーム...etc)
■ 文字入力
確認ポイント:入力に関する設定(全角/半角、文字種)、入力方法(引用、辞書、候補)
入力画面(メモ帳タイトル・本文、E メール宛先・本文、ファイル名編集...etc)
3.3. テーマを決めて実施する
テストをする際は、どんな不具合を狙って操作するかが重要です。
できるだけ具体的に、表示や画面遷移、中止操作、割込み動作などの方向性を決めて実施してください。
テスト項目を考える際、手順から結果を求めた実施方法だけでなく、
期待する動作から、手順を考えて実施する方法も取り入れてみてください。
3.4.できるだけ同じことをやらない
テスト項目は、「状態」と「操作」から構成されますが、異なる画面で同じ操作を繰り返すのではなく、着信でもいろんな視点から見たり、画面の状態を少し変えたり、常に考えてテストすることを意識してください。
■ 画面の状態
文字入力の通常画面、メニュー表示中、メニュー機能実行中、ポップアップ表示、
他機能連携中、起動元によるルートの違い
※ 起動元によるルートの違い(画面遷移図、起動契機の資料などあれば参考にすること)
ショートカットキーで目的画面を表示
メニューから目的画面を表示
⇒起動契機が異なることで結果が変わっていないこと
3.5.設定入力時はその後の動作も見る
設定を確認する項目は、設定完了の表示が出たら終了ではありません。
すべてのパターンで見る必要はありませんが、設定したら動作に反映されているか見るように意識してください。
■ 設定:
設定/OFF で変更確定前にキャンセルキー ⇒ 変更前の状態
設定/OFF で OFF を再設定 ⇒ 変更前の状態
設定/OFF で ON を設定 ⇒ 変更後の状態
■ 入力:
「09」入力後、「08」へ変更し確定する ⇒ 変更が反映され「08」となっていること (「09」になっていないこと)
3.6.境界値に注意する
設定時入力時は有効同値クラス、無効同値クラスに同値分割して境界値に注意して確認しましょう。
有効同値クラス: システムで有効な値
無効同値クラス: システムで無効な値
境界値: 入力に対する出力結果が変わる境界の値
■全角 512byte(半角 1024byte)入力可能とする場合
⇒513byte まで入力後、全角(2byte)、半角(1byte)を入力するとそれぞれどうなるか。
※ コピー&ペースト、引用して入力なども確認。
※ 1 字 1 字入力して byte 消費するだけでなく改行なども入れるとどうなるか。
3.7.バランスを調整する
テスト方法には、「浅く広く」や「深く狭く」など、実施内容によって時間のかかり方が異なってきます。
朝から晩までずっと同じペースでテストするのではなく、自分でやりやすい方法でペース配分してください。
■ 朝は浅く広く実施し、用意されたテスト項目をこなす
昼は不具合を見つける事に集中し、ポイントを絞った確認をする
夕は朝昼で偏った部分のバランスを調整する
■ 夕のパターン
テスト数が少ない場合は、項目数を意識
不具合が出ていないなら、ポイントを絞った確認をする
※ 「テストに集中して進捗を上げる時間」と「バグ出しに集中してバグを発見する時間」
それぞれのバランスを考えてテストすること
【参加者の感想】
●「開発経験が少ないため、テスト項目などどれくらいの粒度で設定すれば分からなかったが、説明を聞いて分かりやすかった」
●「テスト項目書がある状態でテストを行うことが多いので、結果から考えてテストを実施するという観点は盲点だった」
株式会社ガジュマルでは、今後も定期的に技術勉強会や、エンジニアの交流イベントを開催いたします！
興味がある方、参加してみたいという方は、以下の公式LINEを友だち追加のうえ、お気軽にお問合せください。
LINE登録はこちらから。
