概要
ソフトウェアテストの勉強をしている中で、JSTQB認定テスト技術者資格があるのを知りました。そのシラバス内に「テストの7原則」が記載されており、テスターとして業務する上で絶対に知っておくべき内容だと思ったので、自分の知識を定着させる意味でもまとめておきます。
この記事の対象者
・ソフトウェアテスト関連の業務をされている方
・ソフトウェアテストを勉強中の方
・JSTQB認定テスト技術者資格に興味がある方
JSTQB認定テスト技術者資格とは？
まずJSTQB（Japan Software Testing Qualifications Board）とは、日本におけるソフトウェアテスト技術者資格認定の運営組織のことです。JSTQB認定テスト技術者資格は大きく分けてFoundation LevelとAdvanced Levelの2つのレベルがあります。(2023/5/9時点)
| レベル名称 | 種類 | 概要 |
|---|---|---|
| Foundation Level | ・Foundation Level | ソフトウェアテスト全般に対する基礎的な知識を問う試験 |
| Advanced Level | ・Test Manager（テストマネージャ） ・Test Analyst（テストアナリスト） |
Foundation Levelの上位試験 試験を受けるためには下記の条件を満たすことが必要 （1）Foundation Levelの試験に合格している （2）現場での業務経験が3年以上あること （(2)はテストマネージャーのみ） |
今後もっと受験可能資格は増えるようなので、最新情報は下記リンクのJSTQB公式サイトをご確認ください。
ちなみに世界各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）という国際組織があります。ISTQBにはもっと多様な種類のテスト資格があるようです。気になる方は下記リンクから見てみてください。
JSTQBはISTQBの加盟組織であり、資格認定について相互認証を行っています。そのため、JSTQB認定テスト技術者資格は海外でも有効な資格です。
シラバスについて
シラバスはJSTQBのサイト内で各種類ごとにダウンロードすることができます。この記事で扱うシラバスはFoundation Levelシラバス（以下、FLシラバス）です。
（JSTQB公式サイト シラバス(学習事項)・用語集から）(2023/5/9時点での最新版)
・テスト技術者資格制度 Foudation Level シラバス 日本語版 version 2018V3.1.JO3
「テストの7原則」とは？
「テストの7原則」とは、FLシラバスの第1章「テストの基礎」に記載されている、あらゆるテストで共通に使える一般的なガイドラインのことです。人によっては当然の内容かも知れないのですが、私は未経験から入社したこともあり、この7原則を勉強したことでテスト業務をするうえでとても為になりました。（もっと早く知っとけばよかった・・！）
FLシラバスを引用しながら、1つずつ紹介していきます。
（以下1～7まで引用元はJSTQB公式サイト 「テスト技術者資格制度 Foudation Level シラバス 日本語版 version 2018V3.1.JO3」内の「1.3テストの7原則」）
1.テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。
テスト結果が全てOKで欠陥がみつからなかったとしても、テストパターンを変えたり、テストの数を増やせば欠陥が見つかる可能性がある。あくまでもテストは「欠陥がある」ということしか示せないということ。
最初の頃は「テストを実施でバグがない＝欠陥がない」ことだと思っていたので、この原則を知ることでテストの認識を正すことができました。この原則と原則2を知るとテストは正しさを証明する絶対の方法ではないことがわかります。いかに限られた中で不具合を事前に見つけることができるか、そのためにテスト観点をどのように設定するかの重要性がわかってきます。（だから実施すべき箇所のテスト観点が抜けてたりすると怖いのだなと・・）
2.全数テストは不可能
すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。
全組み合わせをテストしようとすると、膨大な数になりコストと時間がかかりすぎてしまい不可能である。分析をしてどこをテストするか判断し、労力を集中させることが大事ということ。
小規模の機能改修の際に、テスト仕様書を作成したことがあります。入力パターンが少数だったので、最初全組み合わせを考えて作成していました。ただ、1つの組み合わせでも複数の確認事項が入ってくるので、気づけば試験数が多くなりすぎてしまったことがありました・・。どの機能が重要なのかを確認し、テスト観点を作成する段階で分析して判断しておけば良かったと実感しました。（分析する場合は重要度やリスク等に点数をつけるなどして、分析する方が良い。）
3.早期テストで時間とコストを節約
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる
開発の早い時期から静的テストと動的テストを開始すべきである（設計段階やコーディングの初期段階で不具合を見つけることができれば修正するのは簡単なため）開発が進んだ後の修正は後戻り工数がかかり大変になるため開発の早い段階でテストを行って不具合を潰しておくことが重要であるということ。
これはテスターとしてだけでなく、自分が開発の初期段階から携わることになったときのためにも留意しておきたいと思いました。
4.欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う（原則 2で触れたことと同様）。
欠陥は満遍なく存在するわけではなく、特定の箇所に集中して存在するということ。テスト結果等から欠陥が集中している箇所と原因を特定し、テストの労力を集中させることが大事。（そうすることで未検出欠陥を効率よく発見することができる）
自分がテストを実施していた中でも、欠陥の偏りは実感していました。どのモジュールに欠陥が集中しているかを意識することはテスターの立場でも大事だと思います。
5.殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
殺虫剤の効果と同じで、同じテストケースを繰り返すと段々と新しい欠陥を見つけにくくなってしまう。(見つけた欠陥は修正され、同じようなバグは作られなくなっていくため)
定期的にテストケースを見直す必要がある。※プログラムの変更・改修があり、そこで実施するリグレッションテストでは同じテストケースを繰り返すことは有効である。
自分がテストケースを作成する場合に、陥りそうだと思ったので注意していきたいです。色々な人にレビューをしてもらったり、定期的に作成者を変更したり、色々な視点を入れることが有効だと思います。
6.テストは状況次第
状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる
何が重要かはソフトウェアの種類によって変わってくる。また、各開発活動に対応したテストの実行方法がある。開発活動の種類・ソフトウェアの種類を考慮して、テストを設計しなければいけないということ。
最初の頃はテストケースにはフォーマットがあると思っていました。この原則を知ると万能なテストケースというのはなく、ケースバイケースで考える必要があるのだとわかりました。各開発活動に対応したテストの実行方法というのもFLシラバスに記載があったので、今後の記事でまとめていきたいです。
7.「バグゼロ」の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
例えば、バグゼロを実現するために修正を行ったが、結果的に使いにくいシステムになったり、処理速度が低下してしまうなどのシステムの性能を落としてしまう場合がある。バグゼロが必ずしもベストではない場合もあることを意識し、全体の性能とのバランスを見て修正すべきバグかどうかの判断が必要である。
この原則を知るまではバグは全部修正するものであると思っていたので、これも認識を正すことができました。テスターとして業務する際には、気になる点も含めてバグは全て報告するのは変わりませんが、今後開発側にまわったときには充分留意しておきたいです。
最後に
今回は「テストの7原則」について紹介しましたが、他の箇所も今後書いていきたいです。FLシラバスでは基本的なテスト技法の知識を学べるだけでなく、各担当者の明確な役割や心理的な影響も知ることができたり、勉強していて面白いです。第1章～6章まで分かれているので、章ごとに重要だと思った点をまとめていけたらいいなと思っています。（最後は勉強法についても書いていきたいです。）
参考
株式会社 カラビナテクノロジーは「命綱や支点を素早く確実に繋ぐカラビナ。そんなカラビナのような役割をテクノロジーで実現したい」という想いのもと、福岡で設立。 主にシステム開発・アプリ開発・ Webサイト制作を行っています。採用情報→karabiner.tech/recruit/requirements/
Discussion