【JSTQB(FL)対策】第1章テストの基礎 1.1テストとは何か?~1.3テストの7原則

こちらの記事ではJSTQBのシラバスのうち、第1章テストの基礎分野における以下の分野の学習内容及び学習してみて私が思ったことについて記載する。

1. テストとは何か?


ソフトウェアシステムは金融分野(銀行や証券など)や交通インフラ分野(鉄道や航空など)などといった我々が普段の生活で触れるところで使用されているほど、社会の構成要素に対して欠かせない存在となっている。


しかし、それらのソフトウェアが期待通りの動作をしなかった場合は経済損失、時間浪費、信用失墜などといったリスクが発生する。

最悪の場合、傷害・死亡事故を招いてしまう恐れもある。

それらのような事態を緩和するための手段の一つとしてテストという工程が重要になってくるのである。


テストには動的テストと静的テストの2種類のテストがある。

動的テストはテスト対象のコンポーネントやシステムを実行するテストであり、テストコードを書き、実際にプログラムを実施して正常に動くかを確認する。

一方、静的テストは動的テストとは対照的にテスト対象のコンポーネントやシステムを実行しないテストであり、プログラムを実行せずに、欠陥がないかどうかを確認する。

1-1. テストに共通する目的

プロジェクトにおけるテストに共通する目的を下記に記す。

・作業成果物の評価

要件や設計、コードなどといった作業成果物に対して、レビュー段階で文章が読みやすい内容であるか、誤字脱字がないかなどといった観点を評価する。

・検証

開発物などのテスト対象に対して、動作などすべての要件を満たしていることを検証する。

・妥当性確認

開発物などのテスト対象が完成したことを確認し、ユーザー顧客などの期待通りの動作内容であることを確認する。

・開発物などのテスト対象が所定レベルであることの確証


・欠陥や故障の発見

テストにおけるメインとなる目的であり、ソフトウェアなどの開発物の品質が低レベルになることを軽減する。

・ステークホルダーに意思決定できる情報を提供する

情報内容としてはテスト対象の品質レベルの情報を提供できるようにする。

・契約、法律または規制上の要件や標準の遵守、またはテスト対象がそのような要件や標準に準拠していることの検証


1-2. テストとデバックの違いについて

テストとデバックというものがあり、これらは欠陥を見つけ出し、取り除くところは共通しているが、実際は異なるものである。


テストはテスト担当者が欠陥の原因となる故障を見つけ、開発者担当者に報告し、修正してもらった後に欠陥が取り除かれたことを確認する。

一方で、デバックは開発担当者が欠陥を見つけた後に解析し、プログラム修正した後に欠陥が取り除かれたことを確認するといった、言わば一連の活動である。

まとめると2つの主な相違点は作業する人であり、テストはテスト担当者、デバックは開発担当者がそれぞれ責任を持って実施する。

2. テストの必要性


2-1. テストの貢献

一般的にリリースされたソフトフェアが故障したり、ユーザーのニースに合致していなかったりすることはよく発生する。

そのため正しいテストの専門知識を駆使して正しいテスト技法を実施すれば、このような障害を軽減することが可能である。

2-2. 品質保証とテスト

・品質保証(QA)

品質マネジメントの一部で顧客側にて品質が適切なレベルに到達するために適切なプロセスを遵守する活動のことである

・品質コントロール

品質マネジメントの一部で生産者側にてテスト活動を含めた適切なレベルの品質を達成するための様々な活動のことである。

2-3. エラー・欠陥・故障

人間が侵す誤りそのものをエラーと呼び、主に納期のプレッシャーや複雑なコード、技術不足などにより引き起こされる。

そのエラーが引き起こすプログラム(またはそれに関連する作業成果物)のフォールトやバグが欠陥である。

欠陥のあるコードを動かした結果、想定された機能が発生しないことを故障と呼ぶが放射能や汚染などといった環境条件により発生することもある。

3. テストの7原則


3-1. テストの欠陥性は示せるが欠陥性がないことは示せない

テストで欠陥を発見することにより、「欠陥性がある」ことが証明できるが、欠陥が発見できなかった場合は「欠陥性がない」とは言えないのである(別の観点でテストを実施すれば欠陥が発見される可能性があるため)。

そのため、「欠陥性がない」ことを証明することは実質不可能である。

そのため、より多くの欠陥を検出できるように予め入念にテスト計画を練って実施する必要がある。

3-2. 全数のテストは不可能

すべての条件のテストを実施することは非常に膨大な数と時間がかかってしまうため、非常に困難である。

そのため、テスト計画段階でどの機能をテストするか、目的、優先順位などをあらかじめ決めてからテストを絞って実施する必要がある。

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

欠陥の発見が遅れてしまうとデバックやプログラム修正などに時間がかかってしまい、コストが発生してしまう恐れがある。

そのため、早期段階で欠陥を見つけることによりコスト削減につながるため、早期でテストを実施することが重要となる。

3-4. 欠陥の偏在

欠陥は均等に点在せず、特定の少数の部分に集中して存在する。

そのため、過去の事例や最近のテスト結果を参考し、どこに欠陥が発生するかを予測しながら、どのようなテストを実施するかをしっかり検討する必要がある。

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

同じ殺虫剤を使用し続けると、昆虫に耐性がつき始め、だんだん効果がなくなってくるのと同様に、テストも同じ手法を繰り返していくとだんだん欠陥を発見しにくくなってしまう傾向ある。

そのため、常に欠陥が発見できるように、テスト仕様を定期的に見直したり、常に新しいパターンのテスト手法を作成し続けたりする必要がある。

3-6. テストは状況次第

どのような状況でどのような機能があるかを考慮せずにテストを実行すると不十分な結果になってしまう。

そのため、対象となるテストに応じてあらゆる条件を考慮し、臨機応変に手法を変えていく必要がある。

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

バグの修正作業を行い、バグ数をゼロにした結果、精神的に満足することが多い傾向にあります。

しかし、その欠陥の修正方法の誤りによりシステム全体の機能が遅くなったり、別の個所で障害が発生したりすることにより、結果的に使い勝手が悪くなってしまえば無意味である。


そのため、バグをなくすことにこだわらず、システム全体の妥当性を考慮しながらバグの修正作業を行う必要がある。

4. エピローグ


JSTQB(FL)の第1章テストの基礎 <1.1テストとは何か?~1.3テストの7原則>を学習してみて、我々がソフトウェアを使用できているのもテスト担当者や開発担当者ができる限り、苦労して欠陥を丁寧に取り除いてくれているおかげであると感じました。

私は今まで客先常駐で既存の試験仕様書を参照しながらテストの実行を実施していましたが、今回の学習でテストを実施する目的やテストの7原則などといった当時はあまり考えていなかったことが深く学べたため、テスト工程の深みを更に知れた気がしました。

今後はこれらの学習したことを踏まえたうえでテスト実行はもちろん、テスト計画や設計などといったテストの上位工程にも積極的に挑戦していきたいと思います。