国際ソフトウェアテスト資格「JSTQB」が定めるテストプロセスとは
本記事ではソフトウェアテストの資格「JSTQB」について詳しく解説していきます。
JSTQBはソフトウェアテストで大きな役割を持っています。
本記事でぜひ知識を身に付けてください。
国際ソフトウェアテスト資格「JSTQB」が定めるテストプロセス
目次
ソフトウェアテストとは何か – JSTQBが定めるポイントを理解しよう
「エラー」「欠陥」「故障」の違いとは？ – ソフトウェアテストの基本用語を学ぶ
JSTQB認定テスト技術者資格とは？
JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、世界各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織の一つとして2005年4月に認定されています。
ISTQBの加盟組織団体は資格および教育・訓練組織認証について相互認証を行っておりますので
JSTQBが運営するソフトウェアテスト技術者資格は全世界で有効な資格です。
ソフトウェアテストとは何か – JSTQBが定めるポイントを理解しよう
ソフトウェアテストはソフトウェアを実行し結果を確認するだけではなく、テストの計画、 分析、設計、実装、テスト進捗と結果の報告、テスト対象の品質評価などの作業を含む、さまざまな活動のプロセスを指します。テスト実行（結果の確認を含む）は、それらの活動の 1 つにすぎません。
「エラー」「欠陥」「故障」の違いとは？ – ソフトウェアテストの基本用語を学ぶ
エラー、欠陥、故障の違いとは？
ソフトウェアテストにおいては、「エラー」「欠陥」「故障」の三つの用語が頻繁に使われます。これらの用語は一見同じように思えますが、テストの観点から考えるとそれぞれ異なる概念を表します。
エラー
エラーとは、開発過程中にプログラマがコードに組み込んでしまった人為的なミスを指します。これは、誤った計算、不完全または誤解された要件理解、または単なるタイプミスなど、さまざまな形で生じることがあります。
欠陥
欠陥またはバグとは、ソフトウェアが設計仕様に従って正常に機能しない状態を指します。これは、エラーが実際にソフトウェアの機能に影響を及ぼし、ユーザーの期待とは異なる結果を生み出した場合に生じます。
故障
故障とは、システムまたはシステムの一部が正常に機能しなくなった状態を指します。欠陥が存在することにより、ユーザーがソフトウェアを使用する際に故障が生じることがあります。
なぜこれらの違いが重要なのか？
これらの違いを理解することは、ソフトウェアテストを行う上で重要です。エラー、欠陥、故障の各ステージで問題をキャッチすればするほど、問題の修正は低コストで済みます。「エラー」が最も早い段階で、「故障」は最も遅い段階です。早期に問題を発見し修正することで、プロジェクトのコストと時間を節約することができます。
まとめ
ソフトウェアテストは、エラー、欠陥、故障を探し出すプロセスです。各項目を理解し、テストプロセスに組み込むことで、品質を確保し、ソフトウェアの信頼性を高めることができます。そしてこれらを予防し、早期に発見・修正することが、品質の高いソフトウェア開発に繋がります。
ソフトウェアテストの7原則
JSTQBによると、あらゆるテストで共通して使える一般的なガイドラインとして7つの原則を定めています。これらの原則を理解して活用することで、テストのプロセスがより効率的かつ効果的になります。
原則1.テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。
原則2.全数テストは不可能
すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。
原則3.早期テストで時間とコストを節約
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフ サイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。
原則4.欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。
テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリ スク分析を行う。
原則5.殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
原則6.テストは状況次第
状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。
原則7.「バグゼロ」の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
テストプロセスの主な流れ
テストプロセスを構成する主な活動のグループは以下の通りです。
・テスト計画
・テストのモニタリングとコントロール
・テスト分析
・テスト設計
・テスト実装
・テスト実行
・テスト完了
テスト計画
テスト計画はソフトウェアテストの最初の段階で、何をテストするのか、どのようにテストするのかを明確にしその後のテスト作業の方針や体制、スケジュールなどを策定します。
テストのモニタリングとコントロール
テストのモニタリングは、テスト活動の進捗や品質を監視、追跡、記録するプロセスです。モニタリングはテスト計画の目標達成状況の確認、プロジェクトのスケジュール管理、欠陥の発見・管理、テストプロセスの改善などに不可欠な役割を果たします。一方、テストのコントロールは、モニタリングから得た情報を基に、テスト活動を適切に調整し、テスト計画に合致する方向に進めていくプロセスです。規定の基準に達していない場合や予想外の問題が発生した場合、テスト計画を修正または再定義し、テストプロセス全体を有効に管理します。
テスト分析
テスト分析は、テスト設計を行うための適切な情報を集めるプロセスです。
テスト対象の要求仕様といったドキュメントや、テストケースを作成する際にインプットとなるテストベースを分析し、それらをもとにテスト手法や条件、テストタイプを決定します。
テスト設計
分析の結果を基に、「テスト設計」が行われます。テスト設計では、具体的なテストケースやテストデータを作り出します。これにより、どの機能をどのようにテストするか、どのパターンを確認すべきか、明確になります。
テスト実装
次は、「テスト実装」です。ここでは、設計したテストケースを具体的なテストスクリプトや手順に落とし込みます。また、必要なテストデータを作成し、テスト環境を構築します。
テスト実行
テスト環境とテストケースが整ったら、「テスト実行」に移行します。このステージでは、テスト計画に基づき、テストケースを一つずつ実行し、事前に定義した期待結果と実際の結果を比較します。
テスト完了
最後に、「テスト完了」でテストの結果をレポートします。このレポートはプロジェクトチームやステークホルダーと共有され、ソフトウェアの品質状況や問題点を明らかにします。
まとめ
ソフトウェアテストは、エラーや欠陥を早期に発見し、品質の高いソフトウェアを提供するための重要な活動です。テスト分析、設計、実装、実行という一連のプロセスを通じて、テストは体系的に行われます。このプロセスを理解し、適切に遂行することで、品質保証と効率的な開発が実現できます。
「人の心理とテスト」 – 確証バイアスとその対策
ソフトウェアテストはただのプロセスや手順で行われるものではなく、意思決定や問題解決といった人間の心理活動が重要な役割を果たします。その中でも、「確証バイアス」がテスト活動にどのように影響を与え、どのようにその対策を行うべきかについて最後に説明します。
確証バイアスとは？
確証バイアスとは、自分が持っている仮説や信念を支持する情報は受け入れやすい一方で、それに反する情報は否認しやすいという人間の心理傾向を指します。例えば、開発担当者は、作成したコードは正しいという思い込みがあるので、確証バイアスにより、コードが正しくないということを受け入れづらかったりするという状況になります。テスト担当者は自分の予想や信念（例えば、「この部分は問題ないはずだ」）に基づいてテストを行い、その結果に影響を及ぼす可能性があります。
確証バイアスの対策
・対決ではなく、協調姿勢で開始する。
全員のゴールは、高品質のシステムであることを再認識する。
・テストの利点を強調する。
例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
・テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。
客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
・他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する。
・自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する。
以上がJSTQBが定めるテストプロセスになります。
資格の取得などに、ぜひ本記事をご活用ください。