![見出し画像](https://assets.st-note.com/production/uploads/images/73288005/rectangle_large_type_2_0c62982bbf599a8eb3194b9f512538e3.png?width=800)
ソフトウェア開発ライフサイクル全体を通してのテスト|JSTQB FLシラバスをイラストベースでまとめてみた2
はじめまして、QAエンジニアの富永です。
本記事ではJSTQB FL(Foundation Level)の概要を初心者向けにまとめていきたいと思います。
JSTQB FLシラバスをイラストベースでまとめてみた1「テストの基礎」
JSTQB FLシラバスをイラストベースでまとめてみた 3「静的テスト」
JSTQB FLシラバスをイラストベースでまとめてみた 4 「テスト技法」
第2回目は「ソフトウェア開発ライフサイクル全体を通してのテスト」です。
JSTQB FL(Foundation Level)とは
JSTQB FL(Foundation Level)とは、ソフトウェアテスト技術者の入門的な資格です。
「テストとは」から始まって「具体的なテスト技術」まで学ぶことが出来ます。
資格試験は年に2回あり、だいたい8月と2月に行われています。
合格率が50%前後なので、テストを初めて学ぶ方にも十分可能性がある資格試験となっています。
ちなみに筆者は勉強を始めて3か月ほどで取得しました。
2.1 ソフトウェア開発ライフサイクルモデル
・シーケンシャル開発モデル:一度に実装
→ウォーターフォールやV字モデルなど
・イテレーティブ開発モデルとインクリメント開発モデル:複数回に分けて実装
→ラショナル統一プロセス、スクラムなど
開発モデルイメージ
![](https://assets.st-note.com/img/1646095819416-m7OkmlzXf8.png?width=800)
2.2 テストレベル
テストレベルとは「開発活動に対する」テストのまとまり
V字モデルとテストレベル
![](https://assets.st-note.com/img/1646095833617-zRYhLtf20k.png?width=800)
①コンポーネントテスト(別名:単体テスト、モジュールテスト、ユニットテスト)
→プログラムした本人がチェック
![](https://assets.st-note.com/img/1646095854381-ExtStquqwp.png)
※コンポーネント:独立してテストできる、システムの最小構成単位
②統合テスト
コンポーネントまたはシステム間のやり取りに焦点を当てたテスト
・コンポーネント統合テスト
コンポーネント間のやり取りに焦点を当てる
→主に開発担当者が行う
![](https://assets.st-note.com/img/1646095870680-QIWSPBg9AO.png?width=800)
・システム統合テスト
システム間のやり取りに焦点を当てる(システムテストの後に行う)
→主にテスト担当者が行う
![](https://assets.st-note.com/img/1646095884629-pSREf1WuwS.png?width=800)
③システムテスト
システムとは、ユーザーのニーズを埋めるもの
つまり、ほぼ完成状態のものをテストする
→主にテスト担当者が確認
![](https://assets.st-note.com/img/1646095899814-zi9UaxgJJQ.png)
④受け入れテスト
より本番に近い環境でテストを行う、最終テストのようなもの
業務システムであれば、実際に業務が回るかということを確認する
→主にお客様(ユーザー)が確認
![](https://assets.st-note.com/img/1646095914923-7qxTxRPXd0.png)
2.3 テストタイプ
テストタイプとは「ソフトウェアシステムの特性」に着目したテストのまとまり
ここでの特性とは、計算システムの計算機能(機能)、計算速度(非機能)など
①機能テスト
特性:機能(仕様通りに動くか(システムが「何を」すべきか)を確認)
例:計算をする、表示する
![](https://assets.st-note.com/img/1646095929281-hx1pIBQEgP.png)
②非機能テスト
特性:非機能(システム(機能)が「どのように」振る舞うか)
例:高速に、安全に
![](https://assets.st-note.com/img/1646095943269-Z9zxMSq7kE.png)
③ホワイトボックステスト
特性:システムの内部
システムの内部を見て仕様通りか確認する。
![](https://assets.st-note.com/img/1646095957713-bqg8zNvNci.png)
④変更関連のテスト(確認テスト、リグレッションテスト)
特性:変更した箇所
・確認テスト
欠陥修正後に確実に欠陥が修正されたかを確認するテスト
![](https://assets.st-note.com/img/1646095970418-J0OItObxUR.png)
・リグレッションテスト(回帰テスト)
プログラムの一部分を変更したことで他の箇所に不具合が出ていないかを確認する
![](https://assets.st-note.com/img/1646095985650-VzOijeffGg.png?width=800)
2.4 メンテナンステスト
運用中に見つかった欠陥の修正や、新機能の追加などを行ったときに必要になるテスト
内容は変更関連のテストとほぼ同じ、違う点は運用中かどうか
変更が正しく適用されているかの確認、変更していない箇所に影響が出ていないか確認
![](https://assets.st-note.com/img/1646096014211-0SK48JoBWz.png?width=800)
執筆者プロフィール:富永和尚
ソフトウェア第三者検証企業で2年間テストエンジニアとして、多数のプロジェクトでテスト実行、設計を経験し、SHIFTへ入社。
SHIFTではWEB系のテスト案件をこなした後、別案件の案件管理者としてマネジメントなどを行っている。
もっとテストの面白さを知ってほしいと思いブログ執筆を行っている。
最近の趣味は映画鑑賞と散歩。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/