【QA】デバッグ_チェックリスト（テストケース）の作り方 ※テスト観点の洗い出し①_導入編

今回はこの点について言及していきます。
テスト観点は多岐に渡るため、いくつかの記事に分けてお話をさせていただきます。

テスト観点とは

テスト観点の基本概念

「テスト観点とはなんなのか」
まずこの点があると思います。

「テストを行う目的＝不具合の無いサービスを提供するため」です。
テスト観点は上記目的を達成するために必要なものであり、
「テスト観点＝不具合の無いサービスを提供するために必要なこと」
という概念となります。

昨今、テストの対象は「ゲーム、web、アプリ」など様々ですが、
どんなテストであれこの考え方は変わりません。

基本中の基本の考え方ではありますが、
意外とこの目的が頭から抜けてしまうことはよくあります。

不具合ゼロ＝「システムなどの問題がない状態」+「一般ユーザー視点で見た時に不具合と思われるものがない」

という点ですが、

後者のユーザー視点の観点はふと抜けてしまいがちです。

（仕様通りに開発ができていても、ユーザーから見てバグだと思われるようなサービスでは、サービスとして成立していないということですね）

「仕様通りになった＝不具合ゼロ」ではなく、
「サービスとして全ての懸念がない状態＝不具合ゼロ」であるので、
この点がテスト観点として考えるべき一番大事な基本概念になります。

「テスト観点の洗い出し＝計画」と「チェックリスト（テストケース）を作る＝実行」という考え方

チェックリストを作る上で大事なのが、
テスト観点の洗い出しをした上でチェックリストを作る、という順番で進行できているかという点になります。

理由としては、
「テスト観点の洗い出し＝計画」であり、
「チェックリスト（テストケース）を作る＝実行」であるという考え方にあります。

これはPDCAのサイクルと同じ考え方で、

PLAN（計画）
↓
DO（実行）
↓
CHECK（評価）
↓
ACTION（改善）

というサイクルでチェックシートを作ることが重要です。

つまる所、

「テスト観点の洗い出し=P（PLAN）」

「チェックリスト=D（DO）」

ですね。

よくあるケースで、
仕様書（設計書）を基にまずチェックリストを作ってみようというケースあります。
（PDCAを意識していない場合、こうなるケースが比較的多いです）

計画なしに実行というのはリスクがありますし、
よくよく考えたら「間違っている / 不要だった」というような事実に後から気付き、
いま実行していることが無駄になってしまったりもするので生産性が悪いです。

さて、
ではどのように進めていけば良いかですが、
「テスト観点の洗い出し」「チェックリストを作る」については以下のようなポイントがあります。

まずテスト観点の洗い出しとして大枠でやることをまとめます。

メモ等でOKなので、箇条書きのような形で観点を書き出していきます。
簡易的ではありますが、例を記載します。

こういった内容をテスト観点として書き出します。

上記テスト観点をベースにチェックシートでは以下のように細分化します。
（例として、一部のみ抜粋して項目化しています）

チェックリスト化にあたってのイメージとしては、
テスト観点をベースに細分化して膨らませていくような形となります。

テスト観点の種類

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

細分化すると更に分けることも可能ですが、
大枠としてはこの辺りとなります。

本記事では基本的なテスト観点の概念を中心にお話させていただきました。
各種観点の詳細についてはそれぞれの記事でご紹介させていただきます。

※こちらの記事では本記事の続きとして、テスト観点の基本となるレギュラー観点についての考え方を記載しています。

【QA】デバッグ_チェックリスト（テストケース）の作り方 ※テスト観点の洗い出し②_レギュラー観点編デバッグ業務でチェックリストを作るにあたり、テスト観点の一番基本となるレギュラー観点についてのお話になります。 レギュラー観点の概要/表示確認/動作確認/処理（ロジック）確認/ 各種設定&状況を掛け合わせる確認について記載しています。 デバッグの一番ベース部分なのでこの部分をしっかり構築できているかどうかでその後のテストの精度が変わってくる重要なポイントです。...