わかっているようでわかっていない。テストの7原則について（JSTQB）
QAエンジニアのつーつーです！
今回は国際ソフトウェアテスト資格のJSTQB（Japan Software Testing Qualifications Board）の内容についてお話したいと思います！
何事も基本が大事👍ということで常に意識しておきたい基本的な部分から押さえていこうと思います🥳
これからQAエンジニアとして活動していく方や言われてみればテストのこと我流になってるかもという方の参考になればと思います！
JSTQBついて
下記の背景をもとに業界全体で技術力を向上する手段の一つに、資格認定制度があり、それがこのJSTQBになります！
自動車、携帯電話、社会インフラ、企業システムなど、我々の身の回りは、ソフトウェアで占められています。
すなわち、我々の身体や財産の安全はソフトウェアに委ねられているのです。
しかし昨今の状況を鑑みると、ソフトウェアの品質や信頼性、安全性が十分に確保されているとは言えません。
ソフトウェアの品質や信頼性、安全性の確保は急務なのです。
そのための重要な技術として、ソフトウェアテストがあります。
システムトラブルの報道でしばしば目にする「テスト不足」というキーワードは、テストの工数の不足を示唆しているだけではありません。
業界全体で、テストの技術力が低迷していることを意味しているのです。我々の身体や財産を守るために、ソフトウェア技術者全員が、テスト技術を向上させなくてはなりません。
テストの7原則について
JSTQBでは各認定資格でシラバスが用意されており、それぞれのレベルで抑えるべきポイントがギュッと体系的にまとめられております。
その中でも基礎となる要素の一つ「テストの7原則」について紐解いていこうと思います😊
なお、2024年11月～試験適用される刷新されたシラバスの内容が試験内容となるため少しだけ先取りしてその内容ベースで抑えていければと思います！
１．テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、テスト対象に欠陥 があることは示せるが、欠陥がないことは証明できない。
テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない。
ここで言っている「欠陥」はいわゆる「バグ」になります☠️
そしてこれは、悪魔の立証と言われるやつですね。バグがないことを証明することはできないということです🥶
２．全数テストは不可能
すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である 。全数テストの代わりに、テスト技法、テストケースの優先順位付け 、リスクベースドテストを用いて、テストにかける労力を集中すべきである。
ありとあらゆる組み合わせを全てテストすることです。そりゃあ無理です。非現実的ですよね😓
ということで、やみくもに全部やりましょう！ではなく、戦略的にどのようにテスト推進していくべきかを考え、計画して実施することが重要です！
３．早期テストで時間とコストを節約
プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。
SDLC（ソフトウェア開発ライフサイクル）の後半に発生する故障が少なくなるため、品質コストは削減される。早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである。
不確定要素があるなかでも先行投資をしましょうよ。ということですね👍
陥りがちなパターンとしては、「うちは不具合が多いからそのための工数（余力）をテストのために残しておきたんだよね～」と言って、そもそもバグ混入を未然に防ぐ活動をあまりしないパターンは避けましょうよ。ということですね。。。
わかっていても勇気がいる活動だと思いますので、ガスの元栓を占めるつもりで思考は予防活動に重きを置けるようにしましょう😊
４．欠陥の偏在
通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する。この現象は、パレートの法則を示している。
予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる。
パレートの法則とは全体の数値の大部分（約80%）は、全体を構成する一部の要素（20%）が生み出しているという法則になります。仮説を立てて、検証を行い、その結果をしっかりと分析することでどの領域（機能）を強化していくべきなのかを判断する材料にしていくことができます📝
５．テストの弱化
同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。
しかし、例えば、自動化されたリグレッションテストのように、同じテ ストを繰り返すことが有益な結果を示すことができる場合がある。
これはシステム自体が成長していく過程の中で、作り手側の当たり前基準も成長していくことで起こることと私は考えております。
ｘｘを押さえておけばOK👍という固定観念があると良い方向に働くケースもありますが、システムが複雑になればなるほど悪い方向に働くケース（欠陥が検出しにくくなる）に陥るため、気を付けましょうということですね🫡
６．テストはコンテキスト次第
テストに唯一普遍的に適用できるアプローチは存在しない。
テストは、コンテキストによって異なる方法で行われる。
このアプローチでやれば問題ない！というものは存在しないということですね。システムを利用することで期待する効果は用途によって異なりますので、そのシステムとして必ず担保していくべき要素（セキュリティ重視、柔軟性重視、etc…）を理解してテストアプローチを決めていく必要性があります🤔
７．「欠陥ゼロ」の落とし穴
ソフトウェアを検証するだけでシステムを正しく構築できると期待するこ とは誤り（つまり、思い込み）である。
例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。
検証に加えて、妥当性確認も実施すべきである。
私はこれを見た時に「自分たちの本当の役割を理解せよ」と言われているのでは、と思わずハッとしました😮
システムを作ること自体が目的となってしまい、このシステムを使ってユーザーのニーズに応える。という本質的な目的を理解・意識しながら活動していくことの大事さを痛感しました😓
まとめ
少し長くなってしまいましたが、テスト活動をしていくうえで抑えるべき本質的なポイントなども認識できるような内容かと思います。
QAエンジニアに限らず、システム開発に携わる人達はシステムを作ることが目的ではなく、世の中をより良くするための活動・手段としてシステム開発を行っているということ再認識（意識）するきっかけになれば幸いです🙏
参考文献
この記事が気に入ったらサポートをしてみませんか？