ITテストの観点はこれだけ！覚える【6つのテスト】と注意点
この記事は読むのに 9 分くらいかかります！
こんにちは、めけです。
（@Meke_korepro）
単体テストに結合テスト..制御フローテストにデータフローテスト..状態遷移テストにユーザビリティテスト..たくさんありすぎてわからない！
大丈夫！覚えるべきテストの種類は大きく”6つ”です。それ以外はテストの”観点”として押さえましょう。
プロジェクトの成功に密接に関わる”品質”。
「お客様の要求が満たされているか＝顧客満足度」を示す”品質”ですが、それを裏付けるために必要な工程がテスト工程です。
テストって結局何をしたらいいの？
何に気を付けてテストしたらいいの？
もくじ
押さえておきたいテスト種類
「～テスト」という呼び名はたくさんありすぎて、全てを覚えるのは現実的ではありません。
当ブログでは覚えるべきテストを『静的テスト、単体テスト、結合テスト、システムテスト、受入テスト、強化テスト』の6つに限定し、それ以外のテストについては”観点”として据え置く事をおすすめしています。（観点として据え置いたテストについては「〇〇テスト」ではなく「〇〇チェック」として記述します）
静的テスト
静的テストはわかりやすく言うと”レビュー”です。
ここでは要件定義書や設計書などの資料レビューを指すのではなく、プログラムを机上で追いかけながら動作をトレースする作業を指します。
「ソースコードレビュー」のことだね！
| 観点 | 別名 |
| 要求内容や設計内容が適切に反映されているか | 仕様チェック |
| 動作ロジックが意図しない構造となっていないか | 論理構造チェック |
| 機能間での桁数やデータ型などにズレが生じていないか | 整合性チェック |
| 誤字や脱字などの記述上の不足はないか | 誤字脱字チェック |
ソースコードレビューを「静的テスト」と呼ぶのに対し、以降の単体テスト～受入テストは実際に製品を動かしながら確認するので『動的テスト』と呼ばれます。
単体テスト
単位は「1プログラムずつ」だったり「1画面ずつ」だったりしますが、予め決められた単位でテストを行う方法を指します。
| 観点 | 別名 |
| 仕様通りに動作するか | 機能確認チェック |
| 条件分岐を踏まえた流れで動作するか | 制御フローチェック |
| 作成/検索/更新/削除を踏まえた流れに漏れはないか | データフローチェック |
| 同じ属性の値（たとえば月跨ぎのチェックなら7/5と7/10など）が入力された場合に意図した動作となるか | 同値チェック |
| 境界値（たとえば月跨ぎのチェックなら6/30と7/1など）が入力された場合に意図した動作となるか | 境界値チェック |
| 意図的にエラーとなる操作を行い想定した動作となるか | エラーチェック |
上記のうち”制御フローチェック”と”データフローチェック”は内部構造を意識したチェック項目になるので、「ホワイトボックステスト」と呼ばれたりするよ。
反対に内部構造を意識しない他のチェック項目は「ブラックボックステスト」と呼ばれますね。
結合テスト
単体テストの時に決めた単位をベースに、”プログラムどうし”、”画面どうし”をつないでテストを行う方法を指します。
| 観点 | 別名 |
| つなげて動かしても問題なさそうか | 機能間チェック |
| 「電気がついた」「きえた」といったように状態が変わった時に意図した動作となるか | 状態遷移チェック |
総合テスト
“設計された仕様通りに動くか”については、上記までのテストで確認ができているため、総合テストでは『当初決められた要件と照らし合わせ、実際に運用しても問題なさそうか』を確認します。
提供者側で行う”最終チェック”的な位置付けだね。
| 観点 | 別名 |
| 業務の流れに沿って意図した動作となるか | 業務フローチェック |
| 運用中に異常動作が発生した場合にも継続運用できるか | 障害許容性チェック |
| 災害等で利用不可となった場合に適切に復旧できるか | リストアチェック |
| 障害修正により動作していたはずの機能が機能しなくなっていないか | デグレードチェック |
| 不正操作などでセキュリティが脅かされないか | セキュリティチェック |
| レイアウトや操作性などユーザーの使い勝手はどうか | ユーザビリティチェック |
| 実際の運用以上の負荷がかかっても適切に機能するか | 負荷チェック |
| 実行時のロジックに無駄はなく実行速度も十分か | 性能チェック |
| 連続実行による長時間運用に問題はないか | ロングランチェック |
| 製品を本番稼働させるにあたって必要な作業に不足はないか | 移行チェック |
受入テスト
静的テスト～システムテストとは異なり、受入テストは製品を受け入れる”顧客側”で実施するケースが多いテストになります。
実際に運用するお客さんならではの観点ってあるもんね。
| 観点 | 別名 |
| 要求した事項が満たされているか | 受け入れチェック |
| 実際の操作環境下において意図した動作となるか | 運用チェック |
| 開発者以外のユーザーが操作してみて不具合はないか | アルファチェック |
| 稼働直前の製品を一般ユーザーが操作してみて不具合はないか | ベータチェック |
強化テスト
本来、静的テスト～受入テストで品質が最大化できるのであれば強化テストは不要です。
が、実際には「思いもよらない箇所で障害が見つかった..」「同じような類の障害がたくさん出る！」といったように品質は安定しないケースの方がほとんどでしょう。
各テストの結果から障害の傾向を分析し、心配だと思う観点についてシステム全体を横並びでチェックするのが強化テストの目的です。
そのため、特段観点の指定はなく上記までのチェック項目から必要だと思う項目を抜粋して確認してください。
“追加テスト”という呼び方の方がしっくりくる人が多いかもね。
ちなみにこれまで挙げた”何か手順に従ってテストを進める方法”は『スクリプト型テスト』と呼ばれます。本記事では紹介しませんが、手順のないモンキーテストや探索的テスト（テスト熟練者の経験や勘に頼るテスト）は「非スクリプト型テスト」というテストもあります。
テストを行うにあたり注意したいこと
最後に少しだけ、長年の間テストに関わり感じた注意点について紹介させてください。
障害の都度対応は避ける
特定の障害が復旧しないと先に進めないケースを除き、基本的には一度用意したテストケースを全て検証してしまう事をおすすめします。
「こんなのすぐ直せるよ！」という気持ちは分かりますが、意外と小さな対応でも、思わぬところに影響が出るケースはよくあるお話。
後からまとめて対応順序や方法を検討する方が、影響も少なく効率的な対応が望めるでしょう。
テスト後のデータは消さずに残す
全てのテストが完了した際、一度全てのデータをキレイに削除してしまう方がいらっしゃるのですが、個人的には避けた方が良いと考えます。
テスト中に作成したデータは、後々障害が発生した際の調査ネタにも使える宝の山です。
特にデータ補正が必要になった場合は、作成された過去のデータを用いてより運用に即した補正パッチを作成することができます。
テストケースは減らして整える
テストケースの洗い出しは..
- 観点を一通り書き出す
- 不要な観点を【消す】
- 各観点に基づいてテストケースを抽出
- 不要なケースを【消す】
といった手順で行います。
この時、削除する観点やケースについては完全に削除するのではなく、背景色を灰色にしておくなど「仮消し」状態としておくのが望ましいでしょう。
基本的にテストケースを洗い出した後は、第三者がその妥当性をチェックすると思いますが、チェックする人も時間が十分にあり、必ずしも網羅的なチェックができるわけではありません。
そんな時、残しておいた「仮消し」状態の観点やケースがあることで、「いや、こういうケースも考えられるな..」とチェックする際のヒントになります。
時間を置いてから再度見直す
テスト項目書に限らずですが、何かを作成した時、直後のチェックはもちろん、一度時間を置いてから全体を俯瞰してみることをおすすめします。
特に別の作業を挟んでから改めて見返してみると、記述が曖昧で誤解を招きそうな表現が見つかったり、冷静に考えると不要にしても問題なさそうなケースが見つかったり..と意外な気付きはあるものです。
障害の原因分析ではプロセスも見直す
テストを始めた最初の頃は、「ここが悪いから障害が起こった」という表面的な原因で終わりがちです。
本当に必要なのはその前。
お客様との話し合いが足りなかったのか、設計の進め方に問題があったのか、製品やサービスの構築ルールが守れていなかったのか..
障害は”より良い商品を生むための基盤づくり”に欠かせない貴重なきっかけです。
ぜひ利用しましょう。
障害の対策では横並び対策も施す
見つかった障害が直ればOK、で終わってはいけません。
必要なのは「他の場所でも似たような障害は起こり得ないのか？」という視点です。
面倒..という理由で調べる時間を省いてしまうケースも見受けられますが、“後から同じ障害が見つかった時の時間ロスの方が深刻”である事を決して忘れてはいけません。
まとめ
製品やサービスが世に出る前の『最後の砦』であるテスト。
少しでもお客様の満足度が上がり、笑顔が生まれるお仕事をしたいですね。
この記事が参考になった！という方は是非コメント、フォロー頂ければ幸いです。