【JSTQB(FL)対策】第2章ソフトウェア開発ライフサイクル全体を通してのテスト
こちらの記事ではJSTQBのシラバスのうち、第2章ソフトウェア開発ライフサイクル全体を通してのテスト分野における以下の分野の学習内容及び学習してみて私が思ったことについて記載します。
1. ソフトウェア開発ライフサイクルモデル
ソフトウェア開発ライフサイクルモデルは多種にわたり、主にシーケンシャル開発モデルやインテレーティブ開発モデル、インクリメンタル開発モデルなどがある。
1-1. ソフトウェア開発とソフトウェアテスト
シーケンシャル開発モデル
シーケンシャル開発モデルはいくつかの独立した一連の段階を順番的に実施していくことでシステムを完成させていくモデルを指し、主にウォーターフォールモデルとV字モデルがある。
ウォーターフォールモデルは滝の水が上から下へ落ちるようにコーディングやテストなどといった開発活動を逐次完了するモデルであり、後戻りは不可能である。
V字モデルはプログラム設計段階を境に上流と下流に分けており、それぞれ対応するテストレベルがあるモデルである。
アルファベットのV字のような構成になっており、以下の図のように要件定義とシステムテスト、基本設計と統合テスト、詳細設計とコンポーネントテストが上流下流でそれぞれ対応している。
インテレーティブ開発モデルとインクリメンタル開発モデル
短い開発期間でシステムを完成させる開発モデルである。
インテレーティブ開発モデルはインテレーティブが「反復」。
インクリメンタル開発モデルはフューチャーが徐々に増加していくことを意味するようにシステムを分割し、要件の確定、設計、構築、テストのように分割単位ごとに分けて作業をする。
1-2. 状況に応じたソフトウェア開発ライフサイクルモデル
プロジェクトやプロダクトに応じて適切に選択・調整を行う必要がある。
2. テストレベル
テストレベルはテストを系統的にまとめマネジメントしていくテスト活動のまとまりのことを指し、以下のように分けられる。
・コンポーネントテスト
・統合テスト
・システムテスト
・受け入れテスト
2-1. コンポーネントテスト
テスト工程にて最初に実施されるテストであり、ソフトウェアにおけるモジュールやクラスなどといった機能や画面などが単体レベルで正確に動作するかどうかを検証する。
この工程で早い段階で漏れや欠陥がないかを確認することにより、後のテスト工程での手戻りすることを少なくするために重要である。
統合テストにはコンポーネント統合テストやシステム統合テストといった異なる２つのレベルのテストがある。
コンポーネント統合テストは統合するコンポーネント間の相互処理とインターフェースに焦点を当てるテストであり、コンポーネント同士を結合したときに正しい動作をするかを検証する。
システム統合テストはシステム、パッケージ、マイクロサービス間の相互処理とインターフェースに焦点を当てるテストであり、システム同士を結合したときに正しい動作をするかを検証する。
2-2. 統合テスト
長期間(プロジェクトの中盤から終盤)で実施されるテストであり、単体で動作するコンポーネントやシステムを組み合わせて、同時に稼働することで実際に想定通りに動作するかを検証する。
この工程では後工程のシステムテストや受け入れテスト、さらにはテスト実施の工程や品質にも影響を与えるため重要である。
2-3. システムテスト
結合テストの後工程で行われるテストであり、システム全体を動かすことにより要件定義で作成した要件の内容を満たしているかを検証する。
総合テストとも呼ばれる。
2-4. 受け入れテスト
テスト工程の最後に行われる、ユーザー側の観点で実施するテストであり、システムの発注者側のニーズを満たしているかどうかや、納品後またはリリース後にソフトウェアが運用可能な状態にあるかどうかなどを検証する。
たとえシステムが仕様書通りであっても、実際の利用環境で機能しなければ最終的に利用されなくなってしまう事態を防止するために重要な工程である。
受け入れテストはさらに以下の4つのテストに分けられる。
・ユーザー受け入れテスト
・運用受け入れテスト
・契約による受け入れテストおよび規制による受け入れテスト
・アルファベータおよびベータテスト
2-5. ユーザー受け入れテスト
ユーザーが本番環境(または模擬環境)にてシステムの使用方法が想定と合致しているかを検証するテストである。
2-6. 運用受け入れテスト
運用担当者はシステムアドミニストレータ―による受け入れテストであり、性能テストや災害復旧などといった運用面に重点を置いている。
2-7. 契約による受け入れテストおよび規制による受け入れテスト
契約による受け入れテストは契約書に記載された受け入れ基準を遵守しているかを確認するテストのことを指し、ユーザーまたは独立したテスト担当者が実施することが多い。
規制による受け入れテストは法律や政府、安全基準などに合致しているかを確認するテストのことを指し、ユーザーまたは独立したテスト担当者が実施することが多いが規制機関が結果を証明または監査する場合もある。
両者の主な目的は契約または規制に準拠しているという信頼を積み重ねることである。
2-8. アルファベータおよびベータテスト
リリース前にユーザーや顧客、システムの運用者からフィードバックを受けるために実施する。
アルファテストは顧客やシステム運用者、独立したテストチームが開発チームの代わりに実施する。
ベータテストは顧客またはシステム運用者が自身の作業場で実施する。
ベータテストはアルファテストの後、またはアルファテストなしに実施することがある。
3. テストタイプ
テストタイプはソフトウェアシステムの特性を目的別にテストするための活動をまとめたものある。
3-1. 機能テスト
システムがユーザーの想定通りに実装されているかを検証するテストである。
3-2. 非機能テスト
システムがどのように上手く振る舞うかを検証するテストである。
性能テストやストレステスト、セキュリティテストなどがある。
3-3. ホワイトボックステスト
システムの内部構造や実装に着目して実施するテストである。
3-4. 変更関連のテスト
欠陥の修正やシステムの変更後に欠陥が修正さえたことや機能が正確に実装されたこと、悪影響が発生していないことを検証するためのテストであり、確認テストとリグレッションテストがある。
確認テストは欠陥が確実に修正されたことを確認するために欠陥を修正した後に再実行をし、新たな欠陥が発生していないかを検証するためのテストである。
リグレッションテストはテストを実行して修正や変更により、意図しない動作がないかどうかを検証するテストである。
3-5. テストタイプとテストレベル
すべてのテストタイプは全てのテストレベルで実行できる。
4. メンテナンス(保守)テスト
4-1. メンテナンスの必要理由
変更作業や移行作業が行われることがあるため。
4-2. メンテナンスの影響度分析
システムの変更により副作用及び影響が発生していないかを検証すること。
5. エピローグ
第2章ソフトウェア開発ライフサイクル全体を通してのテストを学習してみて、自分が今まで担当したことがなかったテスト分野の知識が身についた気がしました。
自分は実際の案件で結合テストおよびシステムテストしか経験したことがなかったため、コンポーネントテストや受入テストでどのようなことをどのように重点を置いて実施する中が一段階理解できたように感じました。