システムテストの観点と七原則

システムテストの重要性と七原則

はじめに

最近、システム障害によるサービスの一時停止や、システムの不具合を利用したサイバー攻撃による個人情報の流出等、システムの欠陥に起因する様々なトラブルを耳にする機会が多くなりました。日々ITシステムの管理や導入をされている方にとっては、これらのニュースは決して他人事ではないと思います。

このようなシステムの不具合によるトラブルは、システムのリリース前、ないしは機能改修時において、適切な検証・テストを実施することで、未然に防ぐことができる場合もあります。今回は、システムテストの基本的な考え方についてご説明します。

システムテストの4つの観点

現代社会では、経済活動や日常生活のほぼ全てにコンピュータシステムが活用されており、人が作った OS やアプリケーションなどのソフトウェアによって管理および制御され、当たり前のように日々ユーザーにサービスが提供されています。

しかし、これらのシステムを “正しく” 動作させるということは、実はとても難しいことです。 システムを “正しく” 動作させるためには、下記の4つの観点で正常性を担保する必要があります。

  • 利便性(快適に)
  • 可用性(止まらずに、遅くならず)
  • 正確性(エラーがないように)
  • 安全性(安全に)

システムは、多くの場合、ハードウェア、OS、ミドルウェア、アプリケーションが層として構成されており、これらが相互に連携して動作しているため、全ての層の、全てのコンポーネントにおいて、上記の要件を満たしていることを担保することは非常に難しく、とりわけ、近年のアプリケーションは、基本的に LAN やインターネットを介したネットワーク通信を必要とするものがほとんどであるため、ブラウザのようなユーザーエージェントや、クライアントアプリケーションとの接続性も意識しなければならず、そのシステムの動作の “正しさ” を保証することは年々難しくなっています。

システムテストの重要性

ほぼ全てのソフトウェアは、開発者が業務要件を満たすためのビジネスロジックや業務フローを分析し、それをプログラムで表現していくことによって実装されています。 しかし、開発者も人間であるため、時にミスを起こすことがあります。 そして、これらのミスは、実装上の不備や、ドキュメントの欠陥として顕在化し、しばしば故障の原因となり、結果として様々な損害が発生することがあります

システムの欠陥による損害の具体的事例
システムの欠陥による損害の具体的事例

このようなリスクを回避するため、プロダクト開発者やサービス提供者は、サービスのリリース前、または機能改修時において、ソフトウェアが仕様書通りの挙動となっているかをチェックし、システムに欠陥がないことを確認する“システムテスト”を行う必要があります。 ソースコードやインフラ、ドキュメントを厳しくテストし、システムが稼動する前に欠陥を摘出して修正することが出来れば、実行環境において予期せぬ障害が発生するリスクを低減でき、結果としてプロダクトの品質を最低限保障することが出来ます。

システムテストの目的

  • 欠陥を摘出する
  • 対象ソフトウェアの品質レベルが十分であることを確認する
  • 意志決定のための情報を示す
  • 欠陥の作りこみを防ぐ

システムテストの七原則

しかしながら、システムテストの重要性は理解しているが、時間およびコスト的な制約もある中で、どのような考え方やアプローチで、テストを計画・実行してよいかわからないという方も多数いらっしゃると思います。

そこで、より効率的かつ有効なテストの実行に役立つかもしれない「システムテストの七原則」をご紹介します。 すでにご存知の方もいらっしゃるかもしれませんが、この七原則は、世界共通の一般的なガイドラインとなっており、システムテストの40年以上の歴史の中で培われてきた、いわば先人の知恵の集積といえます。

システムテストの七原則

原則 1: テストは欠陥があることしか示せない
テストによって欠陥を抽出することは出来るが、先述したようにシステムの全ての層での動作の正常性を網羅的に担保することは難しく、さらに、テスト自体も人間が実施している以上、未知の欠陥が存在している可能性は0とは言えません。 このため、テストでは、欠陥が存在しないことを証明することは出来ません。
原則 2: 全数テストは不可能
ごくシンプルな構造のソフトウェアを除き、全ての入力値をチェックすることは不可能に近く、このため、テスト技法などを駆使して潜在的にリスクが潜んでいる可能性のあるパラメーターを選別してテストを行わなければなりません。
入力フォームの機能テストの場合
入力フォームの機能テストの場合
原則 3: 初期テスト
コーディングやプロトタイプの開発フェーズといった開発工程の初期段階でテストを実施し、不具合を発見してバグを修正することが出来れば、結果としてテストに掛かる工数は小さくなります。
原則 4: 欠陥の偏在
欠陥が満遍なく分布していることは稀であり、リリース前のテストで見つかる欠陥や運用時に露呈する故障の大部分は、ある特定のモジュールやコンポーネント、クラスに集中している場合が多くあります。
原則 5: 殺虫剤のパラドックス
同じ成分で構成された殺虫剤を繰り返し使用していくと、それに耐性を持った虫が出現することで、いずれ効果がなくなってしまうのと同じように、同種のテストを何度も繰り返してばかりでは、最終的にそのテストでは新しい欠陥を見つけられなくなります。 例えば、API テストにおいて、入出力の観点でテストケースを作り、これを繰り返し実行していくと、そのテスト自体では次第に欠陥は発見されなくなります。 そのため、別のパラメータを使ったテストケースの追加や、セキュリティやパフォーマンスなど、別の観点でのテストの実施を検討する必要があります。 殺虫剤のパラドックス
原則 6:テストは条件次第
テストの対象物の性質や目的に応じて、テストの観点や内容を決定する必要があります。 例えば、静的コンテンツしかほぼ存在しないホームページと、社内の全てのリソースの集中管理をする ERP とではテストの際に必要となる観点や実施レベルは大きく異なります。 テストは条件次第
原則 7:「バグゼロ」の落とし穴
当たり前のことですが、いくら欠陥を見つけてソフトウェアの不具合を修正したところで、構築したシステムが使えなかったり、ユーザー要件や期待を充足させられなければ意味がありません。 例えば、不具合報告がほとんどないスマートフォンゲームが存在したところで、ストアからダウンロードされず、プレイされていなければ意味がありません。 それは、テストという行為は生産活動そのものではないためです。
これらの原則を意識することで、テストの効率化が図れると考えられておりますので、皆様も是非こうした考え方を頭の片隅に入れておいていただければと思います。

まとめ

  • 人為的なミスがプロダクトの欠陥として顕在化し故障の原因につながる
  • システムテストの目的は「ソフトウェアが仕様書通りの挙動となっているかチェックし、システムに欠陥がないことを確認する」ことにある
  • 効率的なテストの実施のヒントは「システムテストの7原則」にある

システムテストに関するお問い合わせ
各種サービスについて、お気軽にご連絡ください。
03-3379-2053
営業時間:平日9:30~18:30
お問い合わせ