テストエンジニアの方や、初めてテスターとしての役割が与えられた人向けに「システムテスト/ソフトウェアテスト実施時に知っておきたいテストの７原則」を解説します。
テスター/テストエンジニア・・・ってなんかつまらなさそう・・・と思っている方も少なくないとは思いますが、テストこそシステム品質保証の最大重要タスクです。
システムを安定稼働させるためにはプログラミングスキルだけではなく、その後のテストスキルも非常に重要です。
いかにテストが網羅的に行われるか？どれだけ効率的に効果的なテストを実施できるのか？はシステムの品質を大きくするポイントです。
このページではテストって何？そもそも何のためにテストをするの・・・？という疑問をお持ちの方にテストの目的や観点から「テストの７原則」まで網羅的に解説します。
「ソフトウェアの7原則」とは、JSTQBと呼ばれるソフトウェアテスト技術者資格認定の運営組織が定義している「ソフトウェアテストの原則をまとめたもの」です。
ある程度の経験を経ている人であれば、どれも「既に知っているよ！」という内容ばかりかもしれませんが、この原則を体系的に理解しておくことは重要です。
個人の勘と経験に頼るテストではなく、原則に則ったテストを行えるように「ソフトウェアテストの7原則」について、具体例を踏まえながら解説します。
テストの目的と重要性
初めにシステム開発におけるテストの重要性から解説します。
このページを読んでいる人の中には「正直テストとか楽しそうじゃない・・・」とか「テストって誰でもできるし価値がなさそう」と思っている方もいるかもしれません。
が、結論から言えばテストはシステムの品質を大きく左右する超・重要タスクであり、かつ実施する人によって大きく結果が異なるもの（スキルが高い人ほど価値あるテストを実施する）と言えます。
システム導入後、バグ・不具合が多発するのは、設計者やプログラマーに原因があるのは否定しませんが、テスターにこそ１番の責任があるといっても過言ではありません。
100点を取れる開発者はいない
テストの重要性を語る前提となるのが「100点（バグ０）を取れる開発者はいない」という点です。
どれだけハイスキルなプログラマーや熟練の開発者であっても、設計・開発が完了した時点でバグや不具合を0にすることは不可能。
もちろん設計・開発段階の心意気として「バグ0のシステムを作ろう！」というのは大事ですが、どれだけその心意気を持っていても人間である以上バグ・不具合から逃れることは事実上不可能と言えます。
開発者・プログラマーが知らない業務やデータパターン、ツールのバージョンアップに伴う影響、その他システム独自のロジックの網羅性に欠陥がある場合など、必ずシステム・ソフトウェアの導入においてはバグや不具合は存在します。
そのバグや不具合をできるだけ多く洗い出し、本番稼働後のシステム稼働率を高めること。これがテストの大きな目的です。（言い換えると「バグや不具合が残っていた」場合の責任の一端はテスターにあるとも言えます。）
【システム開発】テストの7原則
テストは実施者によってその成果が大きく異なります。
正しいことを、正しいやり方で検証できるかどうか？で洗い出せるバグの数も質も異なります。
ここでは、テスト品質を向上させるために大前提として頭に入れておきたいテストの７原則を解説します。
原則１：テストは「欠陥がある」ことしか示せない
テストは「欠陥がある」ことしか示せません。
言い換えればテストは「このシステムには欠陥がない」ということを証明できないのです。
例えば、テストを100回してバグや不具合が発生しなかったとしても、それがイコール「バグ0のシステムである！」とは断言することはできません。
100回テストして「たまたま」バグを検知しなかっただけで、101パターン目のデータでバグを検知する可能性は残る―。これが第１の原則です。
「テストは『欠陥があること』しか示せない」ということを頭に入れていない場合、テストの結果で不具合が検出されなかった場合に誤った認識をもってしまうため注意しましょう。
原則２：全数テストは不可能
第2の原則は全数テストは不可能という点です。
たいていの場合システム開発の期間は限られているにも関わらず、テストパターンは膨大であることが一般的です。
例えば３か月の間で、数十個の機能をテストするようなケース。このようなケースにおいて１機能×100パターンのテストを実施しようとしただけでも多大な労力と時間を要します。
「全数テストは不可能」という原則を踏まえると、いかにデータパターンを絞るか？どのように網羅性を担保するか？いかに余分なテストを省略するか？がテスト計画時のポイントになります。
これらのテスト効率化・網羅性を担保する手段の１つとして境界値分析や同値分析といったものが存在します。
原則３：初期テスト
第3の原則は「初期テスト」です。
簡単に説明すると「欠陥は見つかるのが遅ければ遅いほど」欠陥の除去にかかるコストが増大していくということです。
バグや不具合は、後続の工程（単体テスト＜結合テスト＜総合テスト）に行けば行くほど、修正にかかるコストが増大します。例えば、単体テストで検知できなかったバグを総合テストで検知した場合は、再度単体テストからのやり直しとなります。
テスト実施者がバグの発見を早めることができればその分コストを多くかけずに修正することが可能になるのです。
スキルや勘所・経験のあるエンジニアがテストを実施すると、例えば単体テスト実施中に結合・総合テストフェーズの不具合やバグを検知することも可能です。テスターのスキル１つでシステム開発の推進に大きく寄与できる点も押さえておきましょう！
原則４：欠陥の偏在
第4の原則。欠陥はシステム全体に均一に発生するのではなく、ある特定のモジュール/機能に集中するというものです。
機能A～機能Eにかけて満遍なくバグが存在するわけではなく、バグはどこかに偏って存在するということです。
機能Aで10件のバグが出たからと言って、機能Bでも同じだけ出るとは限りません。逆もまたしかりで、機能Cでは10件以上のバグが検出される可能性もあります。
これは機能自体の難しさや開発担当者のスキルに起因します。
例えば他機能と複雑な連携やデータパターンが多岐にわたるようなプログラムはバグが生まれやすいポイントになりやすいです。また１つのバグ・不具合を修正しても、また別のバグが発生することも頻繁に発生します。
逆に単純な「ログイン」や「計算」などの処理では１度バグを修正してしまえば、それ以上同じような不具合が発生することは少なかったりもします。
この原則を頭に入れておくことで、バグを効率的に狙い撃ちするようなテストの実施が可能になります。
原則５：殺虫剤のパラドックス
第5の原則です。
「殺虫剤のパラドックス」とは、同じ殺虫剤を使い続けていても、そのうち耐性を持った虫が出てきてしまうことを説明した言葉です。
同じ殺虫剤を利用し続けるのではなく、手を変え品を変え異なる殺虫剤を用いる必要がある―。すなわち、テストも同じようなパターンで実施するのではなく、手を変え品を変え、様々なテストパターンで実施する必要があるということです。
同じ条件のテストを繰り返していても見つかるバグは同じものだけです。未知のバグに対しては、全く意味を持たないテストとなります。
同じようなパターン・観点でテストを繰り返していてもバグや不具合がすべて洗い出せません。そのため、パターンや観点の変更（さらに言えばテスト実施者の入れ替え）が必要です。
原則６：テストは条件次第
テストは条件次第で目的や方法が変わります。
例えば医療用の精密機械に対するテストと、単純な社内用便利ツールに対するテストではやり方も重要度も大きく異なります。
どのようなシステムに対しても同じような目的・手順で実施するのではなく、システムの性質・特性を踏まえテストを実施する必要があります。
人の命にかかわるようなシステムの場合はコストと時間をかけてじっくりテストを実施する必要があるのに対して、単純なEコマース系のテストの場合にはそれほど多くの時間をかける必要性はありません。
同じシステムの中でもお金を扱う機能については重点的にテストし、それ以外の機能は薄く広くテストする、というような方法も考えられます。
原則７：「バグ０」の落とし穴
最後の原則です。
テスト結果としての「バグ０」は決して良いことではないということです。第1の原則からも、テストは「欠陥がある」ことしか示せないことを既に説明した通り、テスト実施の前提として「必ずバグや不具合が仕込まれている」ことを踏まえる必要があります。
たいていの場合「バグ０」という報告がなされた場合には、そのテスト自体を疑うべきである場合が圧倒的です。テストは正しいやり方で行われているか？正しいデータパターンで行われているか？
バグが少ないことは喜ぶべきことですが、テスト実施の結果バグや不具合が検知されなかった場合は注意が必要です。