正常系だけでは品質を保証できない理由とは?IT業務初心者が知っておきたいテストの基本
結論から言うと、正常系だけでは品質を保証できません。
理由は、実際のシステム利用では「正しい入力」「正しい操作」「正常な通信」だけが発生するわけではないからです。
ユーザーは入力を間違えます。ネットワークは切れます。権限不足も起きます。ファイルが存在しない場合や、ディスク容量が不足することもあります。
そのためIT業務では、正常に動くことを確認するだけでなく、異常な条件でも安全に止まるか、適切なエラーになるか、データが壊れないかまで確認する必要があります。
- 正常系とは
- なぜ正常系だけでは品質を保証できないのか
- 「正常に動いた」と「品質が高い」は別
- 品質とは「正しく失敗できること」も含まれる
- 正常系だけでは見つからない不具合の例
- 実際のIT現場でよくある例
- 正常系だけのテストで起きやすい問題
- 異常系では何を確認すればよいのか
- 障害対応でも正常系だけを見ない
- GUIで状態を確認する方法
- コマンドプロンプトで確認する方法
- PowerShellで確認する方法
- 異常発生時はログを確認する
- 正常系・異常系・境界値をセットで考える
- 筆者が新人時代に失敗したポイント
- 初心者がやりがちなミス
- 上司へ報告するときのポイント
- エスカレーションするタイミング
- 現場で評価される確認手順
- 関連して覚えておきたいIT用語
- 正常系と品質に関するよくある質問(FAQ)
- まとめ
正常系とは
正常系とは、システムが想定している正しい条件で処理を実行するケースです。
たとえばログイン機能なら、登録済みのユーザー名と正しいパスワードを入力してログインできるか確認するのが正常系です。
| 確認内容 | 例 |
|---|---|
| 正しい入力 | 正しいユーザー名とパスワード |
| 正常な通信 | ネットワークへ正常に接続できている |
| 正常な権限 | 必要なアクセス権限を持っている |
| 正常なデータ | 仕様どおりの形式や文字数で入力する |
正常系テストはもちろん重要です。
しかし、正常系だけ確認して「問題なし」と判断すると、実際の運用開始後に思わぬ不具合が見つかることがあります。
なぜ正常系だけでは品質を保証できないのか
最も大きな理由は、現実のIT環境では異常な条件が必ず発生するからです。
たとえばファイルアップロード機能で、正常なPDFファイルをアップロードできたとします。
それだけでは、次のようなケースが正しく処理されるか分かりません。
- ファイルを選択しなかった場合
- 許可されていない形式を選んだ場合
- 最大容量を超えた場合
- ファイル名が非常に長い場合
- アップロード途中で通信が切れた場合
- 保存先のディスク容量が不足した場合
- アクセス権限がなかった場合
正常なファイルを1つ送信できただけでは、こうした問題は発見できません。
品質を見るには「成功するか」だけでなく「失敗するときにどう動くか」も確認する必要があります。
「正常に動いた」と「品質が高い」は別
IT業務初心者が混同しやすいポイントです。
テストを1回実施して正常終了すると、「ちゃんと動いたので問題ありません」と考えたくなります。
しかし、それは確認した条件では正常に動いたという事実にすぎません。
たとえば「1~100まで入力可能」というシステムで、50を入力して成功したとします。
それだけでは、次の動作は分かりません。
- 1は入力できるか
- 100は入力できるか
- 0を入力したら拒否されるか
- 101を入力したら拒否されるか
- 数字ではなく文字を入力したらどうなるか
- 空欄の場合はどうなるか
50で成功したからといって、入力機能全体の品質を保証できるわけではありません。
品質とは「正しく失敗できること」も含まれる
システム品質では、正常処理だけでなく異常発生時の動作も重要です。
たとえばパスワードを間違えたとき、システムが停止してしまうのは問題です。
適切なシステムなら、ログインを拒否し、ユーザーに分かりやすいメッセージを表示し、必要なログを残します。
| 状況 | 望ましい動作 |
|---|---|
| パスワード間違い | ログインを拒否する |
| 権限不足 | アクセスを拒否する |
| 容量超過 | 処理を停止してエラーを表示する |
| 通信切断 | タイムアウトや再試行など適切に処理する |
| 不正な入力 | 登録せず入力エラーを表示する |
つまり、エラーにならないシステムが優秀なのではなく、エラーが発生しても適切に処理できるシステムが重要です。
正常系だけでは見つからない不具合の例
入力値の境界で発生する不具合
「8文字以上のパスワード」という仕様で、10文字のパスワードだけ確認しても境界部分の不具合は発見できません。
7文字、8文字、9文字などを確認することで、初めて条件判定が正しいか確認できます。
このような確認では境界値を意識することが重要です。
空欄で発生する不具合
正常系では必要な項目をすべて入力するため、未入力時の問題を発見できません。
必須項目を空欄にした場合に、登録処理が進んでしまわないか確認する必要があります。
権限不足で発生する不具合
管理者アカウントだけでテストしていると、一般ユーザーが利用した場合の問題を見逃すことがあります。
特に社内システムでは、Active Directoryのグループや共有フォルダのアクセス権限が関係するケースが多いため注意が必要です。
通信障害で発生する不具合
ネットワークが正常な状態だけで試していると、サーバーへ接続できない場合の動作は分かりません。
通信障害時に画面が固まる、処理が終わらない、途中まで登録されるといった不具合が発生する可能性があります。
実際のIT現場でよくある例
共有フォルダへのアクセス
正常系では、権限を持つユーザーが共有フォルダを開けることを確認します。
しかし品質を確認するなら、次のケースも考えます。
- 権限がないユーザーの場合
- ファイルサーバーが停止している場合
- DNSでサーバー名を名前解決できない場合
- ネットワークへ接続できていない場合
- 保存先の容量が不足している場合
正常系だけでは、これらの障害が発生したときの動作を確認できません。
Active Directoryのログイン
正常系では、正しいユーザー名とパスワードでWindowsへログインできることを確認します。
異常系では、次のような状態を考えます。
- パスワードが間違っている
- アカウントがロックされている
- アカウントが無効になっている
- パスワードの有効期限に問題がある
- ドメインコントローラーと通信できない
- DNS設定に問題がある
認証システムでは、ログインできることと、ログインしてはいけないユーザーを正しく拒否することの両方が必要です。
正常系だけのテストで起きやすい問題
正常系だけでテストを終えると、運用開始後にユーザーの操作によって問題が表面化することがあります。
| 見落とし | 発生する可能性がある問題 |
|---|---|
| 不正入力を確認しない | 異常なデータが登録される |
| 権限を確認しない | 本来見せてはいけない情報へアクセスできる |
| 容量超過を確認しない | 保存処理に失敗する |
| 通信障害を確認しない | 画面が停止する、処理が途中で終わる |
| 境界値を確認しない | 上限や下限付近で不具合が発生する |
特に権限や認証に関する問題は、セキュリティ事故につながる可能性もあります。
異常系では何を確認すればよいのか
初心者は「ない・違う・超える・足りない・届かない・止まる」という視点で考えると、異常系を見つけやすくなります。
| 考え方 | 例 |
|---|---|
| ない | ファイルがない、入力されていない |
| 違う | パスワードが違う、形式が違う |
| 超える | 文字数や容量が上限を超える |
| 足りない | 権限やディスク容量が足りない |
| 届かない | ネットワークやDNSの問題で接続できない |
| 止まる | サービスやサーバーが停止する |
この考え方は、テストだけでなく障害対応にも使えます。
障害対応でも正常系だけを見ない
「インターネットにつながりません」という問い合わせがあったとします。
ブラウザを開いてつながらないことだけ確認しても、原因は分かりません。
次のように段階的に切り分けます。
- 1人だけか複数ユーザーで発生しているか確認する
- 有線LANやWi-Fiが接続されているか確認する
- IPアドレスが取得できているか確認する
- デフォルトゲートウェイへ通信できるか確認する
- DNSで名前解決できるか確認する
- 特定サイトだけか、すべての通信で発生するか確認する
- 必要に応じてネットワーク機器やサーバー側を確認する
「正常ではない」という事実を、さらに細かく分解して調べることが原因の切り分けです。
GUIで状態を確認する方法
Windows 11では、「設定」から「ネットワークとインターネット」を開くことでネットワーク状態を確認できます。
タスクマネージャーはCtrl + Shift + Escで起動できます。
CPU、メモリ、ディスク、ネットワークなどの利用状況を確認できるため、PCの動作が遅い場合の初期調査に役立ちます。
エクスプローラーはWindowsキー + Eで起動できます。ディスク容量やファイルの存在確認などに利用できます。
コマンドプロンプトで確認する方法
ネットワークの切り分けでは、コマンドプロンプトもよく利用します。
「ipconfig /all」を実行すると、IPアドレス、デフォルトゲートウェイ、DNSサーバー、DHCPなどの情報を確認できます。
「ping 接続先」では、対象機器との基本的な通信確認ができます。
「nslookup ホスト名」を利用すると、DNSによる名前解決の確認が可能です。
ただし、pingが成功しただけで対象サービスが正常とは判断できません。認証、ポート、権限、アプリケーションなど、別の確認が必要な場合があります。
PowerShellで確認する方法
Windows環境ではPowerShellを利用した確認も便利です。
「Get-NetIPConfiguration」ではネットワーク設定、「Get-Service」ではWindowsサービス、「Get-Volume」ではディスク関連の情報を確認できます。
初心者は、障害が発生したからといってすぐに設定変更を行わず、まず現在の状態を取得して記録することを意識しましょう。
異常発生時はログを確認する
正常系では問題がなく、特定条件だけでエラーになる場合はログが重要な手掛かりになります。
WindowsではWindowsキー + Rを押して「eventvwr.msc」と入力するとイベントビューアーを起動できます。
代表的な確認先は「Windowsログ」の「システム」と「アプリケーション」です。
確認する際は次の情報を記録します。
- 障害が発生した日時
- イベントID
- ソース
- エラー内容
- 障害発生前後のログ
- 同じイベントが繰り返されているか
赤いエラーが表示されているだけで原因と決めつけないことも重要です。
障害発生時刻や対象機能との関連性を確認しながら切り分けます。
正常系・異常系・境界値をセットで考える
テストでは、正常系と異常系だけでなく境界値も意識すると確認の精度が上がります。
たとえば「1~100まで入力可能」なら、次のようなテストを考えます。
| 入力値 | 分類 | 期待結果 |
|---|---|---|
| 50 | 正常系 | 入力できる |
| 1 | 境界値 | 入力できる |
| 100 | 境界値 | 入力できる |
| 0 | 異常系・境界付近 | 拒否される |
| 101 | 異常系・境界付近 | 拒否される |
| ABC | 異常系 | 拒否される |
正常系・異常系・境界値を組み合わせることで、より多くの不具合を発見しやすくなります。
筆者が新人時代に失敗したポイント
新人時代は、テスト項目で「正常終了」と表示されると安心してしまい、異常時の確認を後回しにすることがありました。
しかし実際の運用では、正常な使い方だけが行われるわけではありません。
ユーザーが想定外の値を入力したり、権限が不足していたり、通信状態が不安定だったりします。
正常系で問題がなかった機能でも、条件を少し変えただけでエラーになるケースを経験し、「動いたことを確認するだけではテストにならない」と意識するようになりました。
それ以降は、「成功するか」を確認した後に「何をすると失敗するか」「失敗したとき安全か」まで見るようにしています。
初心者がやりがちなミス
- 1回成功しただけで問題なしと判断する
- 正常なユーザーだけで確認する
- 空欄や不正入力を試さない
- 最大値や最小値を確認しない
- 権限がない場合を考えない
- 通信障害時の動作を考えない
- エラーが表示されれば正常と判断する
- エラー発生後にデータが壊れていないか確認しない
- 異常系を本番環境で不用意に試す
特に最後は重要です。
異常系を確認するために、本番環境で意図的にサーバーを停止したり、アカウントをロックしたりしてはいけません。
異常系テストは原則として検証環境で実施し、本番環境で必要な場合は作業計画や承認に従ってください。
上司へ報告するときのポイント
テスト結果や障害状況を報告するときは、「正常でした」「エラーでした」だけでは情報が不足します。
次のような内容を整理すると、相手が状況を判断しやすくなります。
- 確認した正常系の条件
- 確認した異常系の条件
- 正常になる条件
- 異常になる条件
- 再現性の有無
- 表示されたエラーメッセージ
- ログの内容
- 影響範囲
- 確認済みの切り分け
たとえば「ログインできました」よりも、「正常ユーザーではログイン成功。誤ったパスワードでは拒否。ロック済みユーザーでもログイン不可を確認」のほうが、確認範囲が明確です。
エスカレーションするタイミング
異常系で想定していない動作が発生した場合は、影響範囲を確認してエスカレーションを検討します。
特に、データ破損、情報漏えい、権限の不備、複数ユーザーへの影響、サーバー停止などが発生した場合は、自分だけで設定変更を続けないことが重要です。
報告するときは、「どの条件では正常で、どの条件から異常になるのか」を整理して伝えましょう。
現場で評価される確認手順
現場では、正常系を確認しただけではなく、異常時まで想定して確認できる担当者は原因の切り分けや安全な運用につなげやすくなります。
作業やテストを行うときは、次の順番を意識すると便利です。
- 仕様を確認する
- 正常系を確認する
- 異常系を洗い出す
- 境界値を確認する
- 権限が異なる場合を確認する
- 通信やサーバー障害時の動作を考える
- エラー発生時のログを確認する
- データや設定に不整合が残っていないか確認する
単に「動くこと」ではなく、「想定した条件で想定した動作になること」を確認するのがポイントです。
関連して覚えておきたいIT用語
| 用語 | 意味 |
|---|---|
| 正常系 | 想定どおりの条件で処理するケース |
| 異常系 | エラーや例外となる条件を確認するケース |
| 境界値 | 正常と異常などの条件が切り替わる境目の値 |
| 同値分割 | 同じような結果になる入力値をグループ化するテスト技法 |
| 例外処理 | エラー発生時に適切な動作を行うための処理 |
| 切り分け | 確認を重ねて障害原因の範囲を絞ること |
| 影響範囲 | 問題によって影響を受けるユーザーやシステムの範囲 |
正常系と品質に関するよくある質問(FAQ)
Q. 正常系がすべて成功すればリリースしても問題ありませんか?
正常系だけでは十分とは言えません。異常入力、権限不足、境界値、通信障害など、システムに応じた異常系の確認も必要です。
Q. 異常系は全部確認する必要がありますか?
考えられるすべての組み合わせを確認するのは現実的ではありません。影響度や発生可能性、仕様、セキュリティ上の重要度などから優先順位を付けて確認します。
Q. エラーメッセージが表示されれば異常系テストは成功ですか?
それだけでは不十分です。処理が正しく中断されたか、誤ったデータが登録されていないか、必要なログが残っているかなども確認します。
Q. 社内SEやインフラ担当にも正常系・異常系の考え方は必要ですか?
必要です。設定変更、Windows Update、ネットワーク変更、Active Directory運用、バックアップ、障害対応など、さまざまな業務で役立ちます。
Q. 品質を高めるために新人が最初に意識すべきことは何ですか?
正常に動いたときに確認を終えず、「失敗したらどうなるか」「境界ではどうなるか」「権限がなければどうなるか」ともう一段考えることです。
まとめ
正常系だけでは品質を保証できない理由は、実際のIT環境では正常な条件だけでシステムが利用されるわけではないからです。
入力ミス、権限不足、容量超過、ネットワーク障害、DNS障害、サービス停止など、実際の運用ではさまざまな異常が発生します。
そのため、品質を確認するときは正常系・異常系・境界値を組み合わせて考えることが重要です。
新人のうちは、正常に動いたときこそ「では、失敗する条件ではどうなる?」と考えてみてください。
この習慣が身につくと、テストだけでなく、障害対応、設定変更、運用保守でも確認漏れを減らしやすくなります。


コメント