jstqb_02_title

【JSTQB Foundation Levelのシラバス2項について】

皆さん、こんにちは。
今回は前回に引き続き、JSTQB Foundationのシラバスの解説を行っていきたいと思います。
今回は、以下の項目について、私の見解も含めて、述べていきたいと思います。

「記事内目次」
2.ソフトウェア開発ライフサイクル全体を通してのテスト
2_2テストレベル
2.3テストタイプ
2.4メンテナンス(保守)テスト

 

■2.ソフトウェア開発ライフサイクル全体を通してのテスト

jstqb_02_image01
JSTQBのシラバスでは、以下の開発ライフサイクルについて、述べられています。
・シーケンシャル開発モデル
・イテレーティブ開発モデル
・インクリメンタル開発モデル

   □シーケンシャル開発モデル

シーケンシャル開発モデルでは、主に以下2つのモデルについて述べられています。
・ウォーターフォールモデル
・V字モデル

ウォーターフォールモデル」では、ソフトウェア開発プロセス「例:要件分析、設計、コーディング、テスト等」を順次実行する活動となっています。
V字モデル」では、開発プロセス全体にテストプロセスが統合されています。
jstqb_02_image02

左側の開発工程に対して、右側のテスト工程があります。
主に従来の開発モデル、以前まで主流だったモデルと認識しています。
大規模なソフトウェア、組込み系システム(銀行、金融システムなど)で採用されている開発モデルと認識しています。

 

 □イテレーティブ開発モデル

jstqb_02_image03

イテレーション(反復)」を行う開発モデルです。
グループにしたフィーチャー群を、一連のサイクルの中で一緒に仕様化、設計、構築、テストを実施します。
以下の種類のモデルがあります。

・ラシュナル統一プロセス(RUP)

イテレーションは、他と比べて長期(例:2カ月~3か月)になる傾向があります。
こちらはIBM社ラショナルブランドのオブジェクト指向型ソフトウェア開発プロセス、及びその製品のことを指します。

・スクラム


jstqb_02_image04

イテレーションは、他と比べて短期(例:数時間、数日、数週間)になる傾向があります。
フィーチャーの増分は、わずかな機能強化、いくつかの新しいフィーチャーなど小さくなる傾向です。
アジャイルソフトウェア開発手法の一つでもあります。
スクラム開発における反復の単位をスプリントと呼びます。
最近のスマートフォンアプリ開発、Webサービス開発などは、こちらの開発手法を取られているケースが増えてきています。

・カンバン


jstqb_02_image05

イテレーションの期間の長さなど固定されていません。完了時に単一の機能強化やフィーチャーをリリース、また複数のフィーチャーをリリースすることもあります。

・スパイラル(プロトタイピング)


jstqb_02_image06

シラバスでは、増分を試行しながら追加すると記載されています。
設計とプロトタイピングを繰り返していく開発手法となります。

 

   □インクリメンタル開発モデル

jstqb_02_image07

システムを分割し、分割単位ごとに要件の確定、設計、構築、テストを行います。
これは、ソフトウェアのフューチャーが徐々に増加していきます。

 

■2_2テストレベル

jstqb_02_image08
JSTQB Foundation Levelのテストレベルは以下のテストレベルが述べられています。
・コンポーネントテスト
・統合テスト
・システムテスト
・受け入れテスト

 

□2.2.1 コンポーネントテスト

コンポーネントテスト(ユニットテスト)は、個別にテスト可能なコンポーネントに焦点をあてます。
シラバスでは、コンポーネントテストの目的、テストベース、テスト対象、典型的な欠陥と故障、アプローチと責務について述べられています。
ソフトウェアのテストでは、主にソフトウェアの開発者が実施するケースがほとんどだと思います。
このテストでは、コードの記述ミスなど抽出し、適時その対応となることが一般的と考えます。

□2.2.2 統合テスト

コンポーネントテスト同様にテストベースや、テスト対象等が記述されています。
また、統合テストでは、コンポーネント統合テスト、システム統合テストの異なる2つのレベルについて述べられています。

・コンポーネント統合テスト

統合するコンポーネント間の相互処理とインターフェースに焦点をあててテストします。
このレベルでも、主にソフトウェア開発者が実施するケースとの認識です。

・システム統合テスト

システム、パッケージ、マイクロサービス間の相互処理とインターフェースに焦点をあててテストします。
こちらは、テスト担当者がテストを実施するケースがあると認識しています。

複雑なソフトウェアによっては、内部結合テスト、外部結合テストなど分かれてテストを実施するケースもあります。

 

□2.2.3 システムテスト

システムテストでは、統合的なソフトウェアの振る舞いや機能に焦点をあてて、テストを行います。
案件、プロジェクトによっては、開発、テスト担当者はこのレベルまでのテストを行い、その後の受け入れテストはクライアント、ユーザー側で実施といったケースもあります。
システムテストでは、設計仕様、機能仕様をベースとした機能テストの他、非機能テストを含めたテストを実施するのも、ソフトウェアの品質向上につながります。

 

□2.2.4受け入れテスト

受け入れテストでは、システムテスト同様にシステムやプロダクト全体の振る舞いや能力に焦点をあてます。
受け入れテストの形態として、以下が挙げられます。
・ユーザー受け入れテスト
・運用受け入れテスト
・契約による受け入れテスト及び規制による受け入れテスト
・アルファテスト及びベータテスト

ユーザー受け入れテストは、ユーザーが実際にソフトウェアを使ってみて、ユーザーの要求通りに動作しているかのテストとなります。
私の経験談ではありますが、金融システムのテスト業務に携わっていた際、ユーザー受け入れテストをテスト担当者だった私が行い、ユーザーがそのテスト結果のエビデンスを確認し、OK判定をするケースがありました。

運用受け入れテストでは、運用担当者等が運用環境でユーザー向けにシステムを適切な稼働状態に維持できていることを示すものとなっています。
実際にシステム、ソフトウェアを使用し、正常に運用できること、また外的要因等で、システム、ソフトウェアが使用不能となった場合は、その旨をアラートを出すなどの観点もチェック対象になると考えます。

契約、規約による受け入れテストでは、契約時または規約に記述されている内容に対して、その基準を満たしているかのテストとなります。

アルファテスト、ベータテストは、オンラインゲーム等で実際のユーザーがプレイし、その際に不具合等あればその開発本にレポートを提出などが一般的と考えます。
開発側で再現できない状況や環境で、ユーザーが不具合、欠陥を検出し、それを対応することで品質を上げることにもつながります。

 

■2.3テストタイプ

jstqb_02_image09

テストタイプは、以下の内容がシラバスに記述されています。
・機能テスト
・非機能テスト
・ホワイトボックステスト
・変更部分のテスト
・テストタイプとテストレベル

 

□2.3.1 機能テスト

機能テストは、すべてのテストレベルで実行でき、仕様通りに、システム、ソフトウェアが機能しているかを確認するテストです。
仕様書、設計書の情報を基にテスト設計したテストケースに沿ってテストを行うのが一般的と認識しています。

 

□2.3.2 非機能テスト

非機能テストは、機能テスト以外の領域に焦点をあてて行うテストを行う傾向があります。
ランダムテストや、モンキーテストなど該当する認識です。
昨今のスマートフォンのアプリ開発では、ソフトウェア仕様書が無いことも多く、ランダムテストをメインで行って、アプリの品質を上げていくといったこともあります。
過去私が携わったアプリ開発では、同様に仕様書が無いため、ランダムテストをメインに行い、ランダムテストで実施した内容をケース化し、テストに臨んでいました。

 

□2.3.3 ホワイトボックステスト

ホワイトボックステストは、システム、ソフトウェアの内部構造に基づいてテストを行います。
主に、コンポーネントテストレベルで、実施されるテストとの認識です。
プログラムコードを実行した際に、内部的に問題が無いかを確認します。
開発者側で主に実施されるテストタイプです。

 

□2.3.4 変更部分のテスト

変更部分のテストでは、以下二つのテストについて、シラバスでは記述されています。

・確認テスト

欠陥を修正、その欠陥によりテスト判定で不合格となったテストケースを新しいソフトウェアバージョンで確認するテストです。
欠陥発生後、バグトラックシステムにインシデントとしてチケットを登録し、そのチケット内容を修正したソフトウェアバージョンで再度テストを実施し、問題が無ければチケットをCloseといった一連の流れが該当します。

・リグレッションテスト

欠陥の修正及び変更により、その該当部分以外に影響を及ぼすケースがあります。
そのような影響がないか確認するためのテストがリグレッションテストとなります。
回帰テストとも呼ばれます。

 

□2.3.5 テストタイプとテストレベル

こちらでは、各テストタイプ、テストレベルについての一例が述べられています。
私の経験上、テストタイプ、テストレベルの関係は以下が多い傾向でした。

jstqb_02_image10

 

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

jstqb_02_image11
こちらのテストは、システム、ソフトウェアをリリース後に対象となるテストとなります。
すでに世に出回っているシステム、ソフトウェアは、メンテナンス(保守)テストが実施されています。

□2.4.1メンテナンスが必要となる理由

システム、ソフトウェアの修正、緊急変更、データベースのアップデート、欠陥や脆弱性に対するパッチ対応などが主に上げられます。
他にも、OSや別プラットフォームへの移行対応、またはアプリケーションの廃棄対応なども含まれます。

 

□2.4.2 メンテナンスの影響度分析

メンテナンスの影響度分析では、メンテナンスで行った変更内容を評価し、変更結果、変更による副作用、変更に影響するシステム、ソフトウェア領域を識別します。
メンテナンス変更後、副作用や影響がないか確認するため、リグレッションテストを行うこともあります。

 

■最後に

いかがでしたでしょうか。
今回はJSTQB Foundation Levelのシラバス「2.ソフトウェア開発ライフサイクル全体を通してのテスト」について、私なりの知見、経験談を併せて記述させていただきました。
前回と同様、JSTQB Foundation Levelのシラバスでは、システム、ソフトウェアの広領域にわたって適用できる知識体系なため、ざっくりとした内容となっており、一度読んだだけでは、しっくり把握できないと思います。
こちらに関しては、シラバスを繰り返し読む、また実際に携わっている案件、プロジェクトに置き換えてみる等されると、より理解が深まると思います。

私も理解が不十分なところも正直あります。
そういった部分は、今後、システムテスト、ソフトウェアテストに関する書籍をご紹介し、知識を深めていきたいと考えています。

最後まで、読んで頂きありがとうございました。
次回は、引き続きJSTQB Foundation Levelのシラバス「3.静的テスト」について述べたいと思います。
宜しくお願いします。

サイトトップへ
https://susakiworks.com/

ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
JSTQV_FN_ver4

この記事が気に入ったら
いいね ! しよう

Twitter で
jstqb_02_title
最新情報をチェックしよう!