こんにちはすずきです。
今回は、作成したアプリケーションのテストを行うための流れをまとめた総集編になっています。
こちらの記事１つでテスト計画からテストケースまで作成していきます。
テストの種類は、下記記事から
テストとは
アプリのリリース前にテストを行う理由は次の2点です。
エラーを無くすため
アプリ開発をしている方は理解ができると思いますが、とんでもなくエラーが出ます。
そのため、テストをして発生する可能性のあるトラブルを事前に確認し、エラーを避けることができるのが、テストです。
品質の向上
適切なテストを実施することでアプリの品質を向上させることができます！
品質が低い製品を市場に出すと、顧客満足度が低下し、それが広範囲にわたる普及の妨げにもなります。
したがって、品質の向上は業績に直接影響する重要な要素！
主に上記2点のためにテストは行われます。
アプリがリリースした後に不具合が出てしまうとユーザーがアンインストールしてしまう原因やクレームや最悪、返金などの対応に追われてしまいます。そのため、このフェーズは企業の信頼を失われないように行うフェーズなので注意して進んでいきましょう。
テストの一連の流れ
テストの一連の流れは、下記になります。
上記に沿ってテストを行っていきます。テスト計画から見ていきましょう。
テスト計画
テスト計画には大きく分けて２つあります。１つ目が全体テスト計画。２つ目が個別テスト計画です。
通常全体テスト計画は開発全体におけるテストの計画なので、開発計画を立てる中で検討をします。プロジェクトの進捗を見ながら修正などを行います。
個別テスト計画は、テストレベルごとの計画です。テスト開始直前までに決める計画。
今回は、個別テスト計画に絞って紹介していきます。
テスト計画では、下記項目を設定します。
テスト計画チェックシート
- どんなテストをするのか
- どこまで担保するのか
- テストを中止する場合や再開する基準は
- 実行環境の確認
- テスト結果
- テストツールは使用するのか
- 全体のスケジュール
- 組織図
- どのようなテストデータを用意するか
- 仕様変更や、FIX決めの対応
- テストリスク
補足があるものだけざっくり解説するよ！
どんなテストをするのか
テストの種類を決めます。単体テスト・機能テスト・セキリュティテスト・負荷テスト etc....
機能テストのテストケースの中にセキリュティテストのテストケースなどを一緒に書かないように！
テスト工程は、テスト工程のケースのみをチェックしないと何を担保しているテストケースかわからなくなってしまう。
どこまで担保するのか
テストの対象・範囲を決めます。どこまでやるか決めないと「やったやってない問題」が発生してしまうかも。
テスト結果
どこまでの範囲がOKでどこからがNGなのかを明確にする
テストツールは使用するのか
使用する場合は、対象案件での使用メリット等も記載して計画する
全体のスケジュール
定例MTGや各テストの期間、実施担当者を選定
組織図
プロジェクトマネージャーやQAマネージャー、QAリーダー、QAテスターの役割の明記などのステークホルダーの確認
テストリスク
リスクの発生頻度や重大度と対策事項（リスクレベルの設定）をまとめる
上記を計画できたらテスト設計に移っていくよ！
テスト設計
テスト設計では、テストの設計方針をきめ、テストケースに落とし込んでいきます。
テストケースとは、テストの具体的な作業手順や条件・期待値などを記述したドキュメントこと。
テストケースを作成することで誰がテストを行っても品質担保ができる。
そんなテストケースを作成するためにまずはテストの設計方針を決定します。
テストの設計方針
テストの設計方針では、テスト計画で設定したテストレベルとタイプごとに、下記３つを設定します。
テスト範囲
テスト範囲は、要件とその要件を実現する機能の対応をもとに設定します。
要件に直接関連する範囲だけでなく、ユーザーの使用方法や改修箇所から影響が及ぶ範囲も含めて設定します。改修箇所が他の機能に与える影響を評価し、テスト範囲に含めます！
料理で例えると、作る料理を決めること！フルコースを準備するのかメインのみにするのかなどなど
テスト観点
テスト目的にもとづき、確認すべき具体的な点を明記します。
仕様書に準拠しているか、ユーザーの一般的な操作や過去の障害から予測される事項も考慮します。
料理で例えると、料理が健康的か？味は美味しいか？見た目は美しいか？などの評価視点を決める！
テスト条件
各テスト観点において、どのテスト条件で確認すべきかという基準とその理由を明記します。
テストケース作成時のデータパターンの検討が効率的に行えるよう、網羅する基準を設定します。
料理で例えると、旬の食事を使う、アレルギーに配慮した料理を作るなどの料理をする上での前提条件を決める！
上記の３つを決めてテストの設計方針が決まったら次は仕様書（テストケース）を作っていくよ！！
テストケースの作成方法（テスト設計）
先ほども紹介したテストケース（テストの具体的な作業手順や条件・期待値などを記述したドキュメント）の作り方を紹介します。
テストケースを作成する意図
そもそもなんでテストケースって必要なの？と疑問に思う方いらっしゃるかもしれません。
結論、品質担保のためです。
上記3点のためにテストケースを作ります。
テストケースの種類
ソフトウェアのテストケースには、正常系と異常系の２つがあります！
| 種類 | 説明 |
|---|---|
| 正常系 | 想定している入力に対して、期待通りの出力を行うか |
| 異常系 | 想定していない入力に対して、問題なく対処できるか |
正常系と異常系を元にテストケースを作成していきます。
テストケースで必ず抑えるべきポイント
上記2点を注視して行わないと、もともと計画していた結果を得られなかったり、人によってテスト結果が変わってしまい、本来のテストケースの目的を失ってしまう。
テストケースの作り方
テストケースの目的を達成するために、テストケースに最低限必要な項目は下記になります。
上記項目は、基本的な押さえている必要がある項目になっています。
現場によって、項目が違うこともあるため、現場の内容に合わせて作成してみましょう。
| 確認項目の例 |
|---|
| maxlengthが指定(※10文字である場合、9文字、10文字は入力可能。11文字は、入力できないこと) |
| maxlengthが指定されていない場合 |
| 空白文字 |
| 半角文字(ｱｲｳｴｵ、ｶｷｸｹｺ) |
| 全角文字(あいうえお、かきくけこ) |
| 機種依存文字(①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳：㍉㍍㌔㌘㌧㌦㍑㌫㌢：㍻㍼㍽㍾：ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ) |
| 小数点（第一位まで、第二位まで） |
| 記号文字(〃 仝 ゝ ゞ 々 〆 ヾ ― ‐ ／ 〇 ヽ ＿ ￣ ¨ ｀ ´ ゜ ゛ ＼ § ＾ ≫ ￢ ⇒ ⇔ ∀ ∃ ∠ ⊥ ⌒ ∂ ∇ ≡ ∨ ≪ † √ ∽ ∝ ∵ ∫ ∬ Å ‰ ♯ ♭ ♪ ‡ ～ ′ ≒ × ∥ ∧ ｜ … ± ÷ ≠ ≦ ≧ ∞ ∴ ♂ ♀ ∪ ‥ ° ⊃ ⊂ ⊇ ∩ ⊆ ∋ ∈ 〓 〒 ※ ″) |
| マイナス値 |
| HTMLエスケープ(<>&"') |
| JavaScriptへの埋め込み文字(<>&"') |
| SQLエスケープ('"%_％＿) |
| リンク表示、リンククリック遷移 |
| ボタン表示、ボタンクリック遷移 |
| プルダウン値、ラジオボタン、チェックボックス、テキストエリア |
| 必須項目で未入力の場合の振る舞い |
| クリックを数回した場合の振る舞い |
| 数回リロードした場合 |
| 存在しないパラメータを渡す |
| 画面間のデータの受け渡し |
| ステータスによる画面表示処理の振る舞い |
| バックエンド確認（SQL、Linuxコマンドでの確認）の例 |
|---|
| DataBaseに接続できる |
| 新規、既存、テーブルがある。カラムの追加がある場合は確認。またテストデータ更新、追加した場合の値の確認。 |
| 「ユーザー」と「管理者」ロール権限の確認 |
| メール自動設定時のcron設定のパス確認。crontab -l |
| 「http」と「https」のプロトコル確認 |
| config設定が正しい |
| エラーレベルは適切か。 |
| エラー時には、Error.logに出力。 |
| jQueryのバージョン確認(※使用ライブラリーの確認) |
| phpのバージョン確認、MySQLのバージョン確認（※バージョンによっては今まで使用できた関数が使えなかったりするので確認が必須） |
| メール送信時には、送信ログが出力。 |
| ストアドプロシージャ(呼び出しの確認) |
| マスターDBのダンプ |
| MySQLスレーブサーバの確認 |
テストケースの入力値
テストケースが多い時に、品質を保ちつつケースを減らす方法として下記４があります。
同値分割
入力をグループ化して、有効なものと無効なものに分けるやり方のこと！
例えば「1桁の自然数」が入力とすると、次の３つのグループに分けることができま！
- １より小さい
- 1〜９
- ９より大きい
つまり入力値として、例えば0と5と10の３つにすればいいということになります。
これが同値分割！
境界値分析
同値分割において、経験則的に「同値グループ間の境界にバグが発生しやすい」ということが分かっている。
どういうことかというと、同値分割で示した例でいう0と1、9と10などの値を入力したとき（正と誤の境界）に、バグが発生しやすくなります。このような境界値では、等号や不等号のミスなどでバグが起きやすくなるのですが、これを境界値分析で検出することができます。
ペアワイズ法
「ほとんどの不具合は1つまたは2つの要因によるものである」という経験則をもとにたくさんある要因のうち「2つの要因の組み合わせだけは網羅する」、という観点で値を選ぶ方法のこと！
すべての要因についてテストを実施するのは大変ですが、ペアワイズ方を用いることで、テストを大きく削ることができます。
これだけだと網羅しきれないこともあるので、組み合わせて行うのが大切！
エラー推測
上の3つの方法論と別視点で、「テストケースを作る人の経験に基づいて、エラーが起きそうな値を決めるやり方」のこと！
例えば「一桁の自然数」という入力値に対して、負の数やヌル文字、空白、全角文字や小数などを用いてテストをする！
まとめ
テストケースの作り方や入力値を見ていきました！
テストケースで重要なのは、読み手のことを考えることです。
作業者だけが理解できる内容でなく、実装する人にもわかるような文章を心がけて作成しましょう！
参考記事
