単体テスト、結合テスト、業務検証テスト、パフォーマンステスト・・・。

世の中には、実に多くの「テスト」が存在します。しかしながら、その「テスト」の品質はテスター個人のノウハウやスキルに依存するのが実情です。

本ページの執筆のきっかけともなった、とあるプロジェクトにおける「炎上」事例をもとに、どのようにテストをすれば「炎上」を防ぐことができたのか？を「ソフトウェアの7原則」を踏まえて考えていきたいと思います。

「ソフトウェアの7原則」とは、JSTQBと呼ばれるソフトウェアテスト技術者資格認定の運営組織が定義している「ソフトウェアテストの原則をまとめたもの」です。

ある程度の経験を経ている人であれば、どれも「既に知っているよ！」という内容ばかりかもしれませんが、この原則を体系的に理解しておくことは重要です。

個人の勘と経験に頼るテストではなく、原則に則ったテストを行えるように「ソフトウェアテストの7原則」について、具体例を踏まえながら解説します。

ソフトウェアの7原則

ソフトウェアテストの7原則は、以下の７つの言葉で表されます。

• テストは「欠陥がある」ことしか示せない
• 全数テストは不可能
• 初期テスト
• 欠陥の偏在
• 殺虫剤のパラドックス
• テストは条件次第
• 「バグゼロ」の落とし穴

１つずつ、順を追って解説します。

①テストは「欠陥がある」ことしか示せない

テストは「欠陥がある」ことしか示せないという言葉は、言い換えればテストは「欠陥がない」ことを証明できない、ということです。

テストをいくらしても「欠陥が全て無くなった」という証明はできないのである、ということを第1の原則では定義しています。

バグ0件報告の罠

どのようなプロジェクトでも、本番リリースの前にバグがなくなるまでテストを繰り返し行い、それをもってシステムの「完成」としています（もちろん極稀に例外はありますが）。

ですが、どのようなプロジェクトにおいても、本番リリース後にバグが一切出なかったという事例も見つかりません。

したがって、テスト完了をもって「バグが0件になりました」という報告は誤りだと言えます。テストは「バグがない」ことを証明できない、という原則なのですから。

システムのユーザ報告で、ありがちな「バグ0件報告」ですが、それは「嘘」です。予め、クライアントには「バグが０件」であることは証明ができないことを理解いただく必要があると言えます。

②全数テストは不可能

第2の原則では「全数テストは不可能」であると言い切ります。

これは、テストのパターンは膨大であるのに対し「テストの実施期間」には限りがあるためです。

1週間でテストを10000パターン実施することは無理です。もし、仮に全てのデータパターンが100程度であれば全数テストは可能かもしれませんが、データパターンが100程度のシステムなどほぼ存在しません。日付項目が１つあるだけで、1月1日～12月31日まで365通り存在するのですから。

テストは絞りこむ必要がある

「全数テストは不可能」という原則から言えることは

①　テストはパターンを絞って実施する必要があるということ

②　テストは現実として「網羅的」に実施できず
　　あくまでも「論理的に網羅的と言える状態」までしか
　　持って行くことができないということ

したがって、②の論理が破綻してしまうと網羅性に疑問が出ます。したがって、テストパターンは以下に「論理的」に導くかが肝になります。

「炎上」プロジェクトでは、とりあえずテストをやれるだけやるんだ！というスタンスでテストを実施しました。（もちろん、そこのテスターの勘と経験によって、ある程度のパターンは絞られています。）

ただ、その結果が「炎上」なのです。全数テストは不可能であるという原則から外れてのテストは事実として弊害しかもたらしません。

③初期テスト

第3の原則は「初期テスト」です。

簡単に説明すると、「欠陥は見つかるのが遅ければ遅いほど」欠陥の除去にかかるコストが増大していくということです。

開発の初期であれば、バグも軽微なものばかりです。一方で、本番リリース直前になればなるほどバグの内容は複雑化し、その分バグフィックスの修正にもコストを要することになります。

最後にまとめてテストを行うスケジュールを組んだ事例

テストは、開発スケジュールの全期間の中で最もコストがかかります。

要件定義　⇒　基本設計　⇒　詳細設計　⇒　単体テスト　⇒　結合テスト　と進むにつれて、作業内容が膨大となるため人件費がかかります。

「実際のものづくりより、検証に時間がかかるのはおかしい」

このような観点から予算が限られる現場において、真っ先に検討されるのが「テスト工数の削減」です。

とあるプロジェクトにおいて「単体テスト・結合テスト」を統合し「総合テスト」を実施することで、テスト工数の削減を試みた事例があります。

結果はどうなったか？

この「初期テスト」の原則に照らせば、結果は自明かもしれません。

プログラミング時点でのバグも、設計時の考慮もれも総合テストで検知することになり、放置されていた欠陥のあるプログラムと設計書修正に、想定以上の工数をかける結果となりました。単体テストを行っていれば、その時点でバグを検知することができ、後続の作業に永享を与えることはありませんでした。

テストは、１つ１つ作業が進むごとにこまめに行っていくほうが、トータルのコストを削減できるのです。

④欠陥の偏在

第4の原則です。欠陥は、システム全体に均一に発生するのではなく、ある特定のモジュール/機能に集中する、というものです。

モジュールA、モジュールB、モジュールCにそれぞれ100件ずつのバグがあるのではなく、10件、100件、300件と発生個数がバラバラになります。

これまでの経験を踏まえると、設計が難しく複雑な機能についてはバグが多く発生します。また、担当者のスキルによって変わる部分もあり、超凄腕エンジニアの担当するプログラムはリリース後何年もバグが発生しなかったこともあります。

いずれにせよ、「欠陥は偏在」しているということを踏まえてテストを行う必要があります。

「テストパターン」の罠

第2の原則「全数テストは不可能」であることを踏まえ、テストパターンは絞りこむ必要があると説明しました。

しかし、このテストパターンの絞り込みは機械的にできるものではないのです。

第4の原則「欠陥の偏在」を踏まえると、より難易度が高い機能にテスト工数をかけ、難易度が低い場合にテストを最小限に抑える、また担当者のスキルに応じてパターン数を調整するということが必要なのです。

大規模プロジェクトになると、テストマニュアルなるものを作成しテスト方法を一律で定義する場合が出てきます。テスター個々人によって品質がばらばらとなるのを防ぎ、成果物のクオリティー担保が狙いです。

ですが、この方法だけで進んでしまうと、機械的にテストパターンを絞り込むことはできないため、テスト漏れや、費用対効果の薄いテストが実施されることにつながります。

そのプロジェクトでは、本番リリース後に特定の機能でバグが頻出しました。クライアントからは「テストの有効性」を指摘される結果となりましたが、もしそのとき「バグ頻出機能」を重点的にテストしていれば・・・・。

「欠陥の偏在」を踏まえたテストパターンの絞り込みが重要であることが分かります。

⑤殺虫剤のパラドックス

第5の原則です。

「殺虫剤のパラドックス」とは、同じ殺虫剤を使い続けていても、そのうち耐性を持った虫が出てきてしまいます。結果として殺虫剤の効果が薄れてしまうという例から「殺虫剤のパラドックス」という言葉が用いられています。

同じ殺虫剤を利用し続けるのではなく、手を変え品を変え異なる殺虫剤を用いる必要がある―。すなわち、テストも同じようなパターンで実施するのではなく、手を変え品を変え、様々なテストパターンで実施する必要がある、ということです。

同じ条件のテストを繰り返していても、見つかるバグは同じものだけです。未知のバグに対しては、全く意味を持たないテストとなります。

「いつも同じテスター」の罠

テスターが限られる場合、この罠に陥ります。

人間はだれしも、「慣れ」が出てきます。テスターも同じです。その人独自の観点には限界があるため、その人の観点を越えて新規のバグが見つかることは少なくなってきます。

とある少人数プロジェクトでは、要件定義から開発、テストまでを一貫して同じメンバーで実施していました。

その結果、本番リリース後に起こった現象は何か？

それは、「今まで一度も議題にあがったことがない問題」が頻出したのです。「そもそも〇〇という業務の存在を知らなかった」「パフォーマンスの観点が完全に抜けていた」などという、根本から見直しが必要なバグの発生です。

もし、テスト時に「業務フローに対する一般的な知識を持つテスター」「パフォーマンス問題に明るいテスター」が入っていれば、そのような根本問題は発生しなかったのではないでしょうか？

同じ人間が、同じ手順に従ってテストを実施するのには限界があるのです。

⑥テストは条件次第

これは、テストは対象のシステムや、モジュールごとに実施手順が変わる。もっと言えば、テストの目的も条件によって異なってくるということを言っています。

ハードウェアを更改する際に、「アプリケーションは変わらない」という前提で導入時のテストをそっくりそのまま実行するとします。

「テストは条件次第」という原則に照らせば、ここには問題があります。

なぜなら、導入時のテストはアプリケーションの動作（業務ロジック）が適切に動くことを証明するためのテストである一方で、ハードウェアの更改で証明したいのは、パフォーマンスに問題がなくアプリケーションもこれまで同様に動くことです。

導入時のテストでは、パフォーマンス問題を中心に検証することはできませんし、業務を遂行できるかというテストは無意味になります。

達成度の罠

あるプロジェクトでは、数千人の社員を一元管理するシステムを構築していました。

テストでは、文字通りバグがなくなるまで実施し、本番リリース後も大きな障害を発生することはありませんでした。

ただし、当初の予算を２億円超過したのです。

問題点は「テストは条件次第」であることを踏まえていなかったことに一因があります。

もし、今回の構築対象のシステムが「医療機器システム」であれば、予め予算を抑え入念なテストが必要であったでしょう。しかしながら今回は「社員管理システム」なのです。

絶対にバグを許せないシステムに対するテストと、ある程度のバグがでることを想定しているシステムに対して同じテストを行うのは誤りです。

「テストは条件次第」で、やり方もゴールも異なることを押さえておきましょう。

⑦「バグゼロ」の落とし穴

最後の原則です。

「バグゼロ」というのは、決して良いことではないということです。第1の原則からも、テストは「欠陥がある」ことしか示せないことを既に説明しました。

また、「バグゼロ」という報告がなされた場合には、そのテスト自体を疑うべきである場合が圧倒的です。

本当にバグがゼロになることがあるか？論理的にはあるかもしれませんが、現実そのようなシステムを未だ見たことはありません。

超・成功プロジェクトに起こった悲劇

スケジュール通りの納品、予算超過なし、欠陥なしのシステムを作り上げたプロジェクトがあります。

以前、筆者が所属していたプロジェクトです。

残念ながら、本番リリース後はほぼ毎日朝まで残業する結果となりました。「欠陥なし（バグゼロ）」というのは、嘘だったのです。テストでバグがあまり出なかったことを「ポジティブ」に捉えたのが、誤りだったのです。

テスト漏れや、嘘の報告が蔓延し結果として、本番リリース後に当初の予算を超過して改修を行うという結果になりました。

「バグゼロ」は目指すものではあるが、ありえないことである―。

この最後の「原則」こそ、システム開発者が誤って理解してはいけない最も重要な原則なのかもしれません。