Zenn
🍧

ソフトウェアテストの7原則について自分なりに経験談でまとめてみた

2023/07/08に公開
#
テスト
#
品質
#
品質保証
#
qaengineer
idea

社内QA勉強会の元となる記事を書いたので、公開用に書き直した状態で投稿します。

この記事を書いた私の状況

  • 入社2年目の22卒
  • 約1年間、プロダクトのテスト設計〜実行、修正確認までを行う
  • 今年2月にJSTQBを取得
  • とはいえ、業務と関連づけてシラバスの内容を理解することができていない
    こんな初心者の私がつらつらと書いています。

本日のゴール

  • ソフトウェアテストの7原則を知ることができる
  • 事例や具体例踏まえて7原則を理解することができる

ソフトウェアテストの7原則とは

JSTQBという日本におけるソフトウェアテスト技術者資格認定の運営組織のシラバスで触れられている原則のことです。
テストエンジニアのみならず、開発者やマネージャーなどにも知って欲しい内容になっています。

1. テストは欠陥があることは示せるが、欠陥が無いことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。

解説

テストで見つけたソフトウェアの欠陥を全て修正し、欠陥が「ない」と判断したとしても、正しさの証明にはならないことです。
たまたま今回のテストでは見つからなかっただけかもしれないし、たまたまテスト自体が間違っていて故障を見つけられなかっただけかもしれません。
テストでは、まだ検出されていない欠陥を減らすことしかできないのです。

※欠陥（バグ）：要件や仕様に満たさない不備または欠点。実装上の不備。
※故障：欠陥のあるプログラムを実行したときに期待通りに動かないこと。

考え

×「不具合修正が完了したため欠陥は一切ありません」
○「今回テストの範囲内では、○件の欠陥が見つかりました」
というように、あらかじめ決められたスコープ上で、自分たちで考えて作ったテストではこのくらいの欠陥が見つかりました。と言うことしかできません。
しかも、その範囲やテストってどれだけ有用性があるのでしょうか。本当に今のテストで目的が達成できるのでしょうか。
この原則を業務と絡めた時、テストでどこまでの範囲をどの粒度で担保するのかをあらかじめ定めたり、仕様変更に対するテストケースの修正ができる仕組みづくりを行ったりする工夫が必要だと感じました。

2. 全数テストは不可能

すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

解説

そのままの通り、全ての入力条件をテストすることは非現実的だということです。
テストの納期が定められているため、期限内で効率的にテストを行うためにはテスト技法を用いたり優先度やリスク分析などを行う必要があります。

考え

入力欄のテストを行うだけでも、入力できる値や数値の範囲、使用不可文字、組み合わせなどさまざまなテスト観点があります。単に全部やろうと思っても圧倒的に時間が足りません。
二因子間網羅やテスト設計技法など様々な技術の取得を行うことが重要です。
また、開発との仕様のすり合わせを行ってやるべきテスト、やらないテストを決めることも重要なのかと思いました。

3. 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる

解説

開発が進むほど修正ややり直しのコストが指数関数的に大きくなるため、なるべく早い段階で欠陥を潰し込むと節約につながるということです。
一気にビックバン的なテストを行うのではなく、逆に少しずつテストを行うことで影響範囲が小さくなり、修正の範囲を狭めることができます。
一説によると、リリース後に仕様誤りの修正を行うと、要件定義時点での修正に比べて200倍のコストがかかるとのこと。

早い段階で欠陥を見つけるためには、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。＝「シフトレフト」
要件定義や設計などの上流工程と同時期にテスト計画やテスト設計を行うことで、テストのタイミングで行っていた要件の確認工数を削減することができる。＝「Wモデル」

※静的テスト：静的解析や設計書のレビューなどプログラムを実行せずに実施できるテストのこと。
※動的テスト：プログラムを実行することで実施できるテストのこと。

考え

半年ほど前に現場でビックバン的なテストを行なった結果、仕様が漏れで実装されていない箇所が見つかったことがありました。。。
結果としてコミュニケーションコスト、修正コストがかかってしまい、「早期テストで時間とコストを節約」原則の大事さをみにしみて感じた出来事でした。
現在のプロジェクトでは早い段階からテストの設計を行えたことから、仕様書でわからないことや気になることを早めに共有することが前より可能になったのが幸いです。
とはいえ、仕様書はテストのために書かれたものではないので、書かれていない仕様書の隙間をどのようにキャッチするのかは個人のスキルに委ねられます。ここは私の課題でもあります。
また、テストのレビューを私たちテスト設計者が行うような体制はできていません。これからどのように上流の成果物をレビューするのかをキャッチアップする必要があります。

4. 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。

解説

欠陥はありとあらゆる箇所に均一に存在するのではなく、ある部分に集中しているということです。
難易度の高い機能や開発者のスキル差などよって欠陥の偏在が生まれます。
一説には、「ソフトウェア欠陥の8割は全体の2割の箇所に集中して存在する」という話もあるとのことです。

考え

実際に、同じ箇所で複数欠陥が生まれているなとうっすら認識していました。
ただ、不具合の分析をしたり直近のテストからバグを予測することがまだできていません。バグの内在率など、絶対的に必要な指標しかないので不具合の分析をするのに必要な情報ってなんだろう？と疑問に思いました。

5. 殺虫剤のパラドックスにご用心

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。

解説

1つのソフトウェアに対して何度も同じ観点のテストを繰り返すと、新しい欠陥を見つけることができなくなるということです。
同じ成分を持った殺虫剤を繰り返し使用すると、耐性の持つ虫が出てきて最終的に効果がなくなってしまうことに例えているそうです。
新しい殺虫剤を開発するのと同様に、新しい視点で新しい内容のテストを考えていかなければ、新しい欠陥を見つけられなくなります。

しかし、自動化によるリグレッションテストにおいては同じテストを繰り返すことで、修正の影響による他の箇所の故障を発見することができるため有用です。

※リグレッションテスト：「機能の追加・修正で予想外の不具合が発生していないか」を観点として行うテストのこと。

考え

実際のところ、テストは1回作った後なかなか改善することができていないと感じます。
理由としては時間の制約や積もるタスクで手が回らないからだけではなく、根本的に仕様変更〜テスト設計に落とし込むまでのフローができていないからだと思っています。
また、リリース前とリリース後のテストは目的が違ったりするので、今どのようなテストをすべきか、どの観点を追加すべきか、など常に今取り組んでいるテストに対する目的を明確にしたいと思いました。

6. テストは状況次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1 節を参照）。

解説

ソフトウェアが使われる状況や目的などによって、テストの方法を変える必要があることです。
全てのソフトウェアや開発ライフライクルにおいて共通するテスト設計や方法は存在しません。
→どのようなソフトウェアをいつどの環境で行うかによって、テストの方法を変更しなければならない。

考え

共通するテスト設計や方法はないのに、答えがあるのではないかと模索していたことがありました。
今回のプロダクト、一機能に対して、何をテストしなければならないのか。これは命に関わるシステムなのか。それとも少しぐらいバグがあってもなるべく早くリリースしなければならないのか。などなど。
ソフトウェアの状況を考えた上でテストの設計を行なっていきたいと思いました。

7. 「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

解説

「テストで故障を見つけてバグを0にすると、高品質なシステムができる」というのは誤った思い込みであることです。また、0にしたとしても、ソフトウェアとしては役に立たないことがあります。
→「欠陥を直すと良いソフトウェアができる」とは限りません。
実際はバグの件数だけでなく、非機能要件（セキュリティや信頼性、使用性など）も品質の重要な指標となっています。

考え

リリース前に不具合が発見された時、バグをゼロにするためだけに修正するのは避けた方がベターです。直すことで他の箇所に影響が及ぶ可能性があるため、バグ0にすることを目的にするのは本末転倒になってしまいます。
また、「〜ができない」という不具合チケットの事象を修正したが、結果動作が重くなってしまい使えなくなってしまった。などユーザーにとって使いやすいかという使用性が損なわれることがあります。
バグを0にするためだけに修正を行うのはアンチパターンだと気づきました。

まとめ

「べき」に囚われない

現場から見て「今の運用はソフトウェア原則とかけ離れているから原則に従うべきだ」と主張することは良いとは思えません。従ったからといって、今の組織にとって本当に効果があるかはわかりません。
あくまで原則でしかないことから、この原則を元にどういった観点が必要かを見極める必要があると感じました。

参考

Discussion