みなさん、こんにちは! ゆーすけです。
JSTQBの学習のススメ連載の4回目となります!
第3回目の掲載から半年以上空くことになり、その間に所属部署どころか会社が変わってしまいました……
▼1~3回のおさらいです!
1回目では、JSTQBってなんだろう?→Foundation Levelから始めよう  

2回目では、Foundation Levelの構成ってどうなっているんだろう? 

3回目では、テスト基礎について  

半年ぶりの今回は予告通り、ライフサイクル~静的テストについて書いていきます!
※予告では静的テストまで、と書いてましたが、ボリューム的に厳しかったです……

繰り返しになりますが、JSTQB Foundation Levelの構成は以下のようになっています。

1:テストの基礎
2:ソフトウェア開発ライフサイクル全体を通してのテスト  ←今回はココ
3:静的テスト
4:テスト技法
5:テストマネジメント
6:テスト支援ツール

ソフトウェアライフサイクルの構成としては

1) ソフトウェア開発ライフサイクルモデル
2) テストレベル
3) テストタイプ
4) メンテナンステスト

の4章構成でまとめられています。
これらの内容に関して、前回までと同様に自分なりに要約して書いていきたいと思います。

ソフトウェア開発ライフサイクルモデル

ソフトウェア開発ライフサイクルモデルを理解し、適切にテスト活動を行うことはテストにとって重要である。
つまり、「適切なテスト活動を行うためには、ソフトウェア開発ライフサイクルモデルを理解しなければいけない」という内容が述べられています。
ソフトウェア開発ライフサイクルモデルとは何か、という質問に対して、ある一定数の人は「ウォーターフォール」「V字モデル」「アジャイル/スクラム」という答えが出るように思いますが、FLシラバスではライフサイクルモデルとして下記種類で分類しています。

・シーケンシャルモデル
・インクリメンタル開発モデル
・イテレーティブ開発モデル

実は先にあげた開発ライフサイクルは、上記の大別された種類の中の一つ、ということが分かりますね。
せっかくなので、この機会にFLシラバスを読み込み、ウォーターフォール等ではなく、「シーケンシャルモデルのうちのウォーターフォール」のような上位概念から覚えておくと一つ踏み込んだ知識になっていくと思います。

それぞれの簡単な説明は以下のようになります。

>シーケンシャル
ウォーターフォールモデルやV字モデルのフェーズ進行型がイメージしやすいと思います。

>インクリメンタル
システムや機能を分割し、分割単位でシーケンシャルに開発を進めるモデルです。

>イテレーティブモデル
イテレーション(反復)で開発していくモデルとなります。
アジャイルやスクラムといったよく聞くものがここに該当しますね。
インクリメンタルとの最大の違いは、イテレーション毎に動作するソフトウェアが提供される、といった内容があげられます。

それぞれのモデルを簡単な図にすると下記のようなかたちとなります。
この辺はイメージでとらえた方がきっと分かりやすいと思います。

・シーケンシャル
ウォーターフォールを代表例とするように、工程を順次踏むため完成品が最後にできる
初期で仕様を固める必要があり、途中での仕様変更が困難

・インクリメンタル
部分単位で開発が進むため、パーツごとに完成品が出来ていくが、
全体完成品ができるのは最後

・イテレーティブ
フェーズごとに一旦動くかたちでリリースし、全体の作りこみを行っていく。
※それぞれのフェーズで枠組内のものは動く形になっているのでリリースはできる  

テストレベル

FLではテストレベルとして

・コンポーネントテスト
・統合テスト
・システムテスト
・受け入れテスト

の4つのレベルで定義しています。
ソフトウェア開発ライフサイクルモデルによって、それぞれのテストレベルとの関わり方、関与度合いが大きく異なってくるので、FLの段階でしっかり理解するようにしましょう。

テストレベルで使われる用語は資料によって揺らぐことがありますが、
コンポーネント→統合→システム→受け入れの順で行われます。

コンポーネントテスト:
ユニットテストといった方がもしかしたら聞きなじみがあるかもしれませんね。FLシラバスでは別の呼び方として「モジュールテスト」とも定義しています。
プログラムの部品(コンポーネント単位)をテスト対象とします。
部品の定義をプログラム単位(単体テスト)とするか機能テスト(単機能テスト)とするかはプロジェクト/プロダクトによって異なります。

JSTQB FL上では「単体テスト」という用語では説明されていませんが、テスト業務あるある?として、「単体テストの経験があります!」というエンジニアさんに対してヒアリングをすると、実際は単機能テストだった、ということがよくよくあります。
※一概にそうとは言い切れませんが、単体テストはホワイトボックス、単機能はブラックボックスの場合があるので、内容的には全然別軸の領域になります。

この辺、顧客と会話するうえでもお互いの認識が相違したまま進んでしまい、後々トラブルになりかける、ということがあります。
FLシラバスの段階で用語を正しく理解するのに併せて、相手の使っている用語がどういった意図で使われているのか、というレベルまで考えられるようにしておくと、ちょっと気の利くエンジニアとして評価されていくかもしれません。

統合テスト:
結合テストと呼ばれることもあります。
コンポーネントテスト済みのものを結合して、一つの機能単位になったものを対象としてテストを行います。
フェーズによっては内部結合テストと外部結合テストに分けて実施されることがあります。
また、結合テストも、何を内結するのか、何を外結するのか、でテスト内容が大きく変わってくるので、それぞれ以下のようなパターンがある、という認識もしておくとよいと思います。

システムテスト:
結合テスト済みのものをすべて併せて、システムとして完結したものを対象としてテストを行います。
個別の機能テストは前フェーズまでで終わっている前提なので、業務シナリオテストやシステム結合フェーズでしかできない非機能テストの比率が多くなります。
ただ、システムテストフェーズでも単機能、結合テストレベルの不具合が多く検出されることがありますので、そういった場合は、

「今出ている不具合はシステムテストで出るべき不具合なのか、それとも前工程でのテストおよびプロセスに問題があるから残存として残っているのか」
まで考えられるようになると、テストエンジニアとして大きく成長していけると思います。

受け入れテスト:
システムテストまでは開発側で行われるテストで、受け入れテストは実際に使用するユーザー(顧客)側が実施するテストになります。
初期要求通りになっているかの確認を行い、顧客側でしか行えないシナリオテストを行う場合があります。

それぞれのテストレベルは以下の記事でも説明していますので併せて確認いただけるのもよいと思います。

>コンポーネントテスト

>統合テスト

>システムテスト

>受け入れテスト

テストタイプ

テストタイプは、

・機能テスト
・非機能テスト
・ホワイトボックステスト
・変更関連のテスト
・テストタイプとテストレベル

に関してまとめられています。

機能テストとは『システムが「何を」すべきか』を確認すること、
非機能テストは『システムが「どのように上手く」振る舞うのか』という旨の説明がされており、JSTQBの場合、非機能テストは上位レベルであるAdvanced Levelのテクニカルテストアナリストでその詳細がまとめられています。

ホワイトボックステスト:
出入力ではなく、内部構造に着目したテストになります。
分岐のあるプログラムに対して、分岐網羅率(カバレッジ)などを考慮してテストを行います。

変更関連のテスト:
不具合修正、機能追加などを行った際、変更箇所以外に影響を来たしていないかを確認するテストとなります。
回帰テスト(リグレッションテスト)とも呼ばれることがあります。

こちらもブログでまとめている記事がありますので、よければそちらにも目を通してもらえると幸いです!

>ホワイトボックステスト

>変更関連のテスト

テストタイプとテストレベルでは、全てのテストタイプは、全てのテストレベルで適用できる、という内容が記載されております。
このテストレベルでは、これは出来ない!みたいな偏った考えにならないようにしっかりとFLの段階でテストレベルおよびテストタイプは身につけましょう。

メンテナンス(保守)テスト

テストは本番リリースだけで終わらず、本番リリース後の保守フェーズでも必要になることが記載されています。

需要拡大における変更処理や、OS、ソフトのアップデート、欠陥修正や脆弱性脅威への対応や、プラットフォーム変更等の対応が必要になることがあり、これらは
性能効率性、互換性、信頼性、セキュリティ、移植性といったような非機能要件として分類されます。またメンテナンスには影響分析が必要になりますが、状況によって影響分析が適切にできないケースが記載されているので、しっかりと把握、意識したうえで日々のテスト活動を行うことが大事だと言えます。

次回

当初はライフサイクル~静的テストまでまとめる予定でしたが、ライフサイクルで述べられているのはかなり重要項目ばかりなので、第4回目はライフサイクルまとめのみで終了したいと思います。
次回は静的テストまとめをしますので、もしよければ次回を見ていただけると嬉しいです!

シリーズ一覧

JSTQB学習のススメ #1 〜JSTQBとは〜
JSTQB学習のススメ #2 〜Foundation〜
JSTQB学習のススメ #3 〜Foundation〜
帰ってきた JSTQB学習のススメ #4 〜Foundation〜
JSTQB学習のススメ #5 〜Foundation〜
JSTQB学習のススメ #6 〜Foundation〜

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!
AGESTのサービスやソリューションのお問い合わせページはこちらです。

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST