（※当記事は、2024年12月10日時点での最新版(2023V4.0.J02)のシラバスを元に作成しています。）
この記事では、JSQTB (Japan Software Testing Qualifications Board) の Foundation Level のシラバスを分かりやすくかみ砕いて解説していきます。
6記事に分けて、全ての章を解説していきますので、シラバスのなかの要点を押さえたい、ここが分からないという際に参考にしてください。
この記事では、1章 テストの基礎 を解説していきます。
その他の章の解説は下記よりご参照ください。
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
JSTQBにおけるテストとはソフトウェアテストを指します。
ソフトウェアテストとは…
ソフトウェアの品質を評価し、故障リスクを低減する重要な活動。
欠陥を発見し、品質を評価する一連の活動を指す。
ソフトウェアシステムは現代社会において不可欠な要素であり、ソフトウェアが正常に動作しない場合、経済的損失や信用失墜、さらには重大な事故につながる可能性があります。
これらを減らす(低減する)ための手助けとなる活動です。
JSTQB では、テストと似たような言葉で「デバッグ」が挙げられます。
「テスト」と「デバッグ」の大きな違いは行う担当者・作業内容の違いであることを覚えましょう。
| 用語 | 作業内容 | 担当者 |
|---|---|---|
| テスト | 欠陥や故障の発見に焦点を当てる活動 | テスト担当者 |
| デバッグ | 発見された欠陥の原因を診断し、修正する活動 | 開発者 |
また、デバッグのプロセスには「故障の再現」「原因の診断」「修正」が含まれ、修正後には確認テストやリグレッションテストが行われます。
リグレッションテストとは…
ソフトウェアの機能やプログラムを変更した後に、他の部分に意図しない不具合が発生していないかどうかを確認するためのテストのこと。
テストはあくまで品質コントロールの手段の1つです。
ソフトウェアの欠落を発見するために役立ち、設定された範囲、時間、品質、予算の制約の中で合意されたゴールを達成するために行われることを覚えておきましょう。
成功への貢献というと分かりにくいですが、こちらはテストの役割を指します。
テストの役割は大きく下記の通りです。
コスト効果とは…
コスト(費用)に対する成果を指す。
今回は、コスト(費用)をかける価値のある手段
テストで欠陥を発見→修正（デバッグ）のサイクルを通じてソフトウェアの品質向上が期待できます。
テストはやらないよりもやった方が品質の高いソフトウェアができるという当然の考えです。
SDLC（Software Development Life Cycle）とは…
ソフトウェア開発ライフサイクルのこと。
サイクルの各段階でテストを実行することで、サイクル移行時の抜け漏れを発見することができます。
これにより、各段階の品質を評価し、次のステージへの移行判断を行うためにに役立ちます。
開発フェーズに移行後、計画フェーズの計画漏れが発生し巻き戻るなどの手間を減らすことができます。
ユーザーのニーズを反映させたソフトウェアにするために、ユーザーをテストに関与させることも可能です。しかし、ユーザーを関与させるのはコストが高くなるため、基本的には行われません。
（※αテストやβテストなどがこれに当たります。）
成果物の守るべき要件や制限（契約・法律）を漏れなくチェックするために必要な場合があります。契約や法律により、何かしらの確認・テストが必須となっている場合がこれに当たります。
（※法的規制基準に抵触している可能性のあるソフトウェアなど）
テストは品質コントロール（QC）の手法の一部であり、品質保証（QA）とは別物であるということを押さえましょう。
なお、品質コントロール（QC）は欠陥修正に、品質保証（QA）はプロセス改善に使用されます。
品質コントロール(QC)とは…
成果物の適切な品質の達成を目標としたプロダクト思考の是正アプローチのこと。
(成果物をいいものにすればOKの思考 ＝ お客様目線)
品質保証(QA)とは…
成果物制作の適切なプロセス実行と改善を目標としたプロセス思考の予防的アプローチのこと。
（製作手法が誤らなければいいものができるのでOKの思考 ＝ 開発者目線）
エラー・欠陥・故障の関係は下記表の通りです。
| エラー | 人間のミス |
| 欠陥 | エラーにより生み出されたバグ |
| 故障 | エラー欠陥のほか、環境条件により生じるシステムの不具合 |
根本原因とは…
問題（エラーにつながる状態）が発生する根本的な理由のこと。
分析することを根本原因分析と呼ぶ。（KYTなどが当たる）
以下の作業ミスの原因が代表として挙げられています。
欠陥は、ドキュメント（要件仕様書やテストスクリプト）やソースコード、ビルドファイルなど様々なアーティファクトで発見されます。
SDLCの初期段階で早期発見できれば影響は少ないですが、後半になるにつれ大きな影響を及ぼすことがあることを覚えておきましょう。
(早期のテストは欠落残置による影響を減らす役割を持つということ)
エラーや欠陥だけではなく、放射線や電磁波など外的要因も故障の原因になる場合があります。
そのことを環境要因による故障と呼びます。
テストの基本的な7つの原則は下記の通りです。
この7つの原則は、効果的なテストを行うための指針を表しています。
実行するテストプロセスはコンテキスト次第で調整する必要があります。
コンテキストとは…
プログラムの実行に必要な各種情報のこと。
（データ関係・仕様・開発チームの背景などがこれに当たる）
基本的に上記で述べたようにテストプロセスは状況に応じて調整が必要となりますが、汎用的なテスト活動のセットが存在します。
(毎回白紙から計画するわけではなく、ベースとなるテストフローは存在するということ)
また、これらのテスト活動の実行可否やタイミングなどの詳細は「テスト計画」のフェーズで作成・定義されます。
テストは一連の活動であると1節で解説しましたが、具体的には下記のフローを通した活動です。
前述した通り、テスト活動はプロジェクトの状況や以下の要因に依存します。
コンテキストの例としては下記が挙げられます。
テストウェアとは…
テスト活動で生成される成果物（テスト計画書、スケジュール、リスクレジスター、テストケース、テストデータなど）の総称のこと。
これらは構成管理により一貫性を保つ必要があります。
| テスト段階 | 作業成果物一覧 |
|---|---|
| テスト計画 | ・テスト計画書 ・テストスケジュール ・リスクレジスター ・開始基準・終了基準 |
| テストのモニタリングとコントロール | ・テスト進捗レポート ・コントロールのための指示書 ・リスク情報 |
| テスト分析 | ・テスト条件 ・テストベース内の欠陥についての欠陥レポート |
| テスト設計 | ・テストケース ・テストチャーター ・カバレッジアイテム ・テストデータ要件 ・テスト環境要件 |
| テスト実装 | ・テストプロシジャー ・自動テストスクリプト ・テストスイート ・テストデータ ・テスト実行スケジュール ・テスト環境（スタブ・ドライバー・シミュレータ・サービス仮想化） |
| テスト実行 | ・テスト結果記録 ・欠陥レポート |
| テスト完了 | ・テスト完了レポート ・アクションアイテム ・バックログアイテム |
※○○の作業成果物で正しいものを選ぶ問題が出る可能性があるため覚えるべき
カバレッジとは…
対象範囲に対して全体の内どれくらい網羅しているかを示す指標のこと。
（JSTQBでは、測定可能なテスト目的を基準としてどれだけ網羅されているテストかという意で使われている。）
効果的なテストプロセスを実行するにあたり、テストベース（要件やリスクなど）とテストウェア（テストケースや結果など）との間のトレーサビリティを確立・維持することが重要となります。
トレーサビリティとは…
設計過程を可視化すること。
トレーサビリティの指標や役割としては下記の通りです。
テストプロセスにおいて大きな2つの役割を解説していきます。
これらの役割は固定化されることは無く、経験や状況によって変化するものであることを押さえておきましょう。
（「○○さんは最初テスト担当だったため、今後はテストマネジメントの役割をもつべきではない」とはなりません。）
テストの分析、設計、実装、実行を担当するサイドです。
テストにおけるエンジニアリング(技術的)面において責任を求められます。
テスト実行だけが役割ではないため注意！
テスト計画、進捗管理、完了活動を担当します。
テスト活動全体に置いてリーダーシップを取る責任を持ちます。
テストにおけるスキルとアプローチは、効果的なチーム連携や独立性のバランスが重要であり、プロジェクトの特性に応じて柔軟に適用する必要がある点を押さえておきましょう。
テスト担当者が持つべき主なスキルは下記の5種類です。
注意点
テスト担当者は「悪い知らせ」を伝える役割となりやすく、確証バイアスや批判と捉えられるリスクがあるため、建設的な伝え方が重要。
チーム全体アプローチの概念としては、テスト担当者・実装作業者と分けて専門的に行うのではなく、全員が全員同等の知識を持つ環境であれば、よりスムーズに開発が進行するという考えを示します。
チーム全体アプローチの制約
高度な独立性が必要な場合（例: 安全性が重要なプロジェクト）には適用が難しい。
テストにおける独立性とは、テスト担当者と実装作業者の関係を表します。
| 独立性 | テスト担当者 |
|---|---|
| 独立性なし | 作成者が自身でテスト |
| 一定の独立性 | チーム内の他者がテスト |
| 高い独立性 | チーム外の組織内テスト担当者 |
| 非常に高い独立性 | 組織外のテスト担当者 |
独立性におけるメリット・デメリットは押さえておきましょう。
独立性のメリット
・作成者とは異なる視点やバイアスで欠陥を発見しやすい。
・仕様や実装の仮定を検証・反証できる。
独立性のデメリット
・開発チームとの連携不足や対立が生じる可能性。
・開発者の品質責任感が低下するリスク。
・独立したテスト担当者がボトルネックとされる場合がある。
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
This website uses cookies.