チェックリストの作り方

【QA】デバッグ_チェックリスト(テストケース)の作り方 ※テスト観点の洗い出し②_レギュラー観点編

読書する人形の画像

以前こちらの記事でテスト観点の洗い出し①_導入編のお話をさせていただきました。

考える人の画像
【QA】デバッグ_チェックリスト(テストケース)の作り方 ※テスト観点の洗い出し①_導入編デバッグ業務の中でチェックリストを作るというのは一つの壁で難しいですよね。 その壁=テスト観点という概念がよくわからないという方も多いと思いますので、そのあたりのお話の導入部をお話させていただきます。...

テスト観点について、
今回はより具体的な内容として「レギュラー観点」についてお話をさせていただきます。

1.テスト観点の種類概要

2.レギュラー観点とは

  • レギュラー観点の概要
  • 表示確認について
  • 動作確認について
  • 処理(ロジック)確認について
  • 各種設定/状況を掛け合わせる確認について

テスト観点の種類

プランニングする人の画像

テスト観点とはどういったものがあるのか、その大枠は以下になります。

・レギュラー観点
基本的な表示/動作を確認する観点

・イレギュラー観点
ユーザーが行う操作の中で、連打のような負荷をかける操作や、移動中に遭遇する通信環境の弱い状況など、イレギュラーな操作や環境下を想定した観点

・機種別/OS別観点
使用する機種やOSによって表示/動作に差異がないかを確認する観点

・互換性観点
主にスマホゲームやオンラインゲーム等の「アップデートを前提としたサービス」において、
旧verと新verの互換性を確認する観点

今回はこの中でレギュラー観点について掘り下げていきます。
(以降はスマホゲームのデバッグなどを例に記述していきます)

レギュラー観点とは

本の画像

レギュラー観点の概要

仕様書(設計書)に記載されているような基本的な表示 / 動作や、
通常にプレイする範囲で行う操作に対する動作担保の観点を指します。

・対象画面の全UIに対しての表示確認(ボタン/画像/背景/テキスト等)

・上記UIに対しての動作確認

・内部処理(ロジック)確認

・上記表示/動作について各種設定/状況を掛け合わせる確認(操作/マスタ/時限など)

表示確認について

基本的に仕様書(設計書)通りのレイアウトになっている事の確認が主です。

ボタンを例にすると・・・

・表示場所 

・サイズ 

・形 

・色 

・ボタン内テキストの内容 

・テキストとボタン幅の関係性(収まり具合)

・他のUIとの距離感

・画質 

・・・等々、ボタンひとつでも確認する観点としては多岐に渡ります。

上記のような粒度で画面内の全ての表示要素を漏れなく確認する必要があります。

動作確認について

画面を構成しているUIに対して操作を加えた際の動作確認を指します。

ボタンを例にすると・・・

・タップした際のボタンの反応(へこむような動作やエフェクト)

・タップ時のSE

・画面の遷移(遷移する場合)

のように、操作を加えた際の反応や動作を確認します。

後述の「各種設定/状況を掛け合わせる確認について」にも記載がありますが、
状況によって動作が変わるものもあるの注意が必要です。

処理(ロジック)確認について

動作確認とひとまとめにする事が主ではありますが、
目に見えない内部で行われている分かりにくい部分に対しての確認を指すため別述としています。(以下例)

(この辺りをテストするためにはマスタの構成や内部でどういったロジックが行われているかの仕様や実装を理解する必要があります ※そのため少し複雑な説明となります)

クエストクリア時の報酬が正しく獲得できているか
というテストをしたい場合



「実機でクエストをクリアして報酬Dを獲得できた!」
という結果を得られたとします。

獲得できたから問題なく正常に動作している、
と端的には思うかもしれませんが、

「設定通りの報酬」を獲得できているのかという点が重要になります。

例えば、
「報酬は “紐付けた1つのテーブル” の中からランダムで排出される」
という処理だとします。

また、マスタ上で報酬のテーブルは
「テーブル①:報酬A , B , C がランダムで排出」
「テーブル②:報酬D , E , F がランダムで排出」
という2つがあり、
該当クエストでは①を紐付けているとします。

その場合、

該当クエストでは報酬ABCのいずれかしか獲得できないはずが、
なぜか紐づけていないはずのテーブル②の報酬Dを獲得しているということになります。

つまり、指定テーブル外の報酬を参照して報酬を排出しているという不具合となります。

ゲーム画面で目視確認できるのは「報酬Dを獲得した」という結果のみなので、
マスタ構成やロジックを理解していないと不具合だとは気付けません。

このように、目に見えない部分に根幹が詰まっているので、重要で難しい検証となります。

各種設定/状況を掛け合わせる確認について

表示や動作は以下例のようにケースバイケースで変化する場合が主です。

(一番簡単な例は以下1ですがボタン1つとっても状況によって挙動は変わります)

・・等、上記は一例ですが、
操作/時限/マスタの様々な状況の組み合わせによって、
適切な表示/動作をしているかを確認する必要があります。

今回はレギュラー観点を掘り下げてお話させていただきました。
次の記事ではイレギュラー観点についてお話させていただきます。

オレンジの鉛筆の画像
【QA】デバッグ_チェックリスト(テストケース)の作成手順 ※テスト観点の洗い出し方③_イレギュラー観点編デバッグ業務でチェックリストを作るにあたり、必要なテスト観点の中でもイレギュラー観点についてのお話をさせていただきます。 基本動作が問題なくても通信エラーなどの予期せぬ状況においては動作が異常になることもしばしば。今回はその点について言及していきます。...