はじめに : JSTQB FLの学習内容・解釈・気づきを共有

JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)

今回の内容 : 第2章.ソフトウェア開発ライフサイクル全体を通してのテスト

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

テストの前に、ソフトウェア開発の活動・作業の全体像とテストの位置づけを理解する

ソフトウェア開発ライフサイクルモデル とは？
➡ ソフトウェアが完成するまでに行う活動・作業として、要求分析・要件定義、設計、コーディング、テストがある。ソフトウェア開発ライフサイクルモデルは、これら活動・作業の対応関係や時系列的関係を表したもの。代表的な開発モデルは↓

ソフトウェア開発モデル
- シーケンシャル開発モデル
  - 特徴
    - ソフトウェア開発の活動・作業をシーケンシャル(連続的)に行うプロセス
    - 基本的に、着手した活動・作業が完了・合意したあとで次の活動・作業に着手する
    - 開発期間が長く、プロダクト完成までに時間を要する
  - 代表
    - ウォーターフォールモデル (解釈：開発モデルの基本形)
      - 開発活動の順番を滝に例え、上流(品質を作り込む工程(要求分析、要件定義、基本設計、詳細設計))と下流(品質を確認する工程(テスト))で表した開発サイクルモデル。
      - 他の開発サイクルモデルの基本となる形。
    - V字モデル (解釈：ウォータフォールモデルの進化系。上流と下流の対応が明確になったモデル)
      - ウォーターフォールモデルを基本に変形したモデル
      - 上流(品質を作り込む工程(要求分析、要件定義、基本設計、詳細設計))を"V"の左側、下流(品質を確認する工程(テスト))を"V"の右側で表した開発サイクルモデル
      - 特徴
        
        上流の活動とテストレベルの対応が明確になるのが特徴（←ウォーターフォールモデルでは表せてなかった！）
        
        仕様が変更した場合も同様に、上流工程から手戻りが発生する
        
        開発中に仕様変更が多発するような開発に向かない
      - V字モデルでのテストの特徴
        
        工程後半に向かうほど、欠陥が見つかった場合の手戻りの工数が大きくなる
        
        後半のテスト工程で欠陥が見つかった場合に、対応する開発工程の活動・作業だけをやり直すだけで不十分
        
        後続開発工程で該当箇所も合わせて修正が必要
        
        修正が発生した開発工程に対応するテスト工程もやり直しが必要
        
        モデルだけ見ると、テスト活動が開発の後半に行われていると考えられてしまう
        
        本来は、上流工程で、テスト活動としてレビューによる検証を行う
        
        しかし、モデルに明示されていないため、テスト活動は上流で何もしないと勘違いされがち。
        
        ➡テスト活動の一部が上流工程と並行して行われることをモデルとして表したものが「Ｗモデル」
    - Wモデル (解釈：Ｖ字モデルの進化系。上流でもテストが絡むことを明示的に表したモデル)
      - V字モデルにおいて、テスト活動の一部が上流工程と並行して行われることをモデルとして表したもの
      - Wモデルのテストの特徴
        
        開発工程上流で、テスト活動からのフィードバッグにより、品質向上に貢献できる
        
        テスト作業の前倒しにより、開発期間の短縮
  - インクリメンタル開発/イテレーティブ開発モデル
    - 開発期間が短く、短期間でプロダクトを提供する開発モデル
    - イテレーティブ開発、インクリメンタル開発、イテレーティブ開発＋インクリメンタル開発
  - イテレーティブ開発 (解釈:Ｖ字を繰り返し回し、徐々に完全なプロダクトに近づけるモデル)
    - イテレーション（仕様化、設計、構築、テストのサイクル）を繰り返し回す。
    - 1回のイテレーションが完了すると、完全ではないが、何らかの動作するソフトウェアが出来上がるのが特徴
    - イテレーティブモデルの例
      - RUP(ラショナル統一プロセス) Ratinal Unified Process from IBM
        
        UMLを用いる
        
        開発のライフサイクル全体を包括できる方法
        
        イテレーションの期間は、２～３か月（長め）
      - スクラム
        
        アジャイル開発の手法の一つ
        
        スプリント(イテレーション)の期間は、数時間、数日から数週間（短め）
      - カンバン
        
        トヨタ生産方式をもとにしたソフトウェア開発方法論（「Kanban」）
        
        カンバンボードを使ってタスクの可視化、タスクの調整を行い、効率的に作業を進める
        
        イテレーションは必須ではない
        
        イテレーションの期間は、制限がなく、リリースする単位も自由度が高め
      - スパイラル(プロトタイピング)
        
        プロトタイプを開発初期段階で作成して、ユーザーからのフィードバッグを受けて、仕様を確定してから、本番開発を行う方法
        
        プロトタイプ自体は、本番開発時、破棄することや大幅変更することもある
  - インクリメンタル開発 (解釈:プロダクト全体を分割して、小単位で開発を行うモデル。)
    - 開発システムをフィーチャー単位で分割し、ソフトウェアのフィーチャー(機能(特徴))単位で開発(要件～テスト)を行い、足していく。
  - インクリメンタルモデル＋イテレーションモデル
    - ソフトウェアをフィーチャーごとに分割し、イテレーションを繰り返す。
    - テストの特徴
      - 各イテレーションごとにテストが実施される
      - 結果、テストが(シーケンシャルモデルに比べ)早い段階で行われる（シフトレフト)
      - イテレーションを短期間で完了させることと、何度もテストを繰り返すため、テストの自動化が必要

製品・プロジェクトの状況に応じて最適な開発モデルを選択・組み合わせる
各開発モデルの特徴を理解して、製品・プロジェクトの状況に応じて最適なモデルを選択し、開発を進める。

目次へ戻る

テストレベル

一言にテストといっても、状況によってテスト目的や対象、検出したい欠陥は違うため、テストレベルという概念で系統的にまとめる。

テストを系統によって分別したものがテストレベル。ここでいう系統は、それぞれのテストレベルによって異なる。テスト目的、テストベース、テスト対象、テストタイプ、検出できる欠陥・故障、実行者、アプローチのこと。
テストレベル毎の、テスト目的、対象、検出できる欠陥・故障を抑えれば、それら以外のテストベースやテストタイプ、実行者、アプローチは、推測できそう。

テストレベル
- コンポーネントテスト（ユニットテスト、モジュールテスト）
  - 目的
    - テスト対象に内在する欠陥を検出するため
    - テスト対象の機能的・非機能的振る舞いが設計・仕様通りであることの検証
    - テスト対象の品質が信頼できるものであるかの確認(信頼の積み上げ)
  - テスト対象
    - コンポーネント(ユニット、モジュール)
    - コード・データ構造
  - 検出できる欠陥と故障
    - 正しくない機能
    - データフローの問題
    - 正しくないコードとロジック
- 統合テスト (コンポーネント統合テスト/システム統合テスト)
  - 目的　
    - インターフェースに内在する欠陥を検出するため
    - インターフェースの機能的・非機能的振る舞いが設計・仕様通りであることの検証
    - インターフェースの品質が信頼できるものであるかの確認(信頼の積み上げ)
  - テスト対象
    - インターフェース
    - API
    - サブシステム
    - データベース
    - インフラストラクチャー
  - 検出できる欠陥と故障
    - 正しくないデータ、データ不足
    - インターフェースの呼び出し順序の欠陥
    - インターフェースの不整合
    - コンポーネント/システム間のコミュニケーション故障
    - コンポーネント/システム間で渡されるデータの意味、単位、境界の欠陥
    - セキュリティ規制への非準拠
  - ポイント
    - 個々のコンポーネントの機能はテストしない (コンポーネントテストで実施済みのため)
    - ビッグバン統合(一気にコンポーネントを統合)しない (欠陥が混入しているコンポーネントの特定が困難になるため)
    - 統合戦略に合わせ段階的に統合をする
    - テスト実行者は、内部構造を理解し、統合の影響を理解できる必要がある
- システムテスト
  - 目的
    - テスト対象に内在する欠陥を検出するため
    - テスト対象の機能的・非機能的振る舞いが設計・仕様通りであることの検証
    - システムが完成し、期待通りに動作することの妥当性確認のため
    - システムが法的または、規制的要件、または標準を満たすことを確認
    - システム全体の品質が信頼できるものであるかの確認(信頼の積み上げ)
    - データ品質を検証するため
  - テスト対象
    - アプリケーション
    - ハードウェア/ソフトウェアシステム
    - オペレーティングシステム
    - テスト対象システム
    - システム構成及び構成データ
  - 検出できる欠陥と故障
    - 期待通りでないシステムの機能的・非機能的振る舞い
    - 正しくない制御フロー・データフロー
    - 本番環境でシステムが適切に動作しない
    - システムマニュアル・ユーザーマニュアル通りに、システムが動作しない
- 受け入れテスト
  - 受け入れテストの種類
    - ユーザー受け入れテスト
      - システムがビジネスで使えるか確認するテスト
      - ビジネスで使われる状況を想定した疑似本番環境で、ユーザーがシステムを実際に使用して、ニーズや要件に合致しているのかを確認する
    - 運用受け入れテスト
      - 運用担当者またはシステムアドミニストレータが行うテスト
      - 運用側面に焦点を置いたテスト。本番環境、疑似本番環境で実施する
    - 契約による受け入れテスト
      - カスタムメイドのソフトウェアを開発する場合に、契約書に記述された受け入れ基準に従って検証する
    - 規制による受け入れテスト
      - 政府、法律、安全基準などに合致しているかを検証
    - アルファテスト・ベータテスト
      - 市販ソフトウェアの回アhつの場合、実際にプロダクトを市場へリリースすする前に、将来のユーザーや既存顧客からフィードバッグを受けるために、行うテスト。
      - 通常は、アルファテスト➡ベータテストの順
  - テスト目的
    - テスト対象の機能的・非機能的振る舞いが設計・仕様通りであることの検証
    - システムが完成し、期待通りに動作することの妥当性確認のため
    - ※欠陥の検出は、受け入れテストの目的に含まれない
  - テスト対象
    - テスト対象システム
    - システム構成及び構成データ
  - 検出できる欠陥と故障
    - システムのワークフローがビジネス要件・ユーザー要件を満たさない
    - ビジネスルールが正しく実装されていない
    - システムが契約要件・規制要件を満たさない
    - セキュリティの脆弱性
    - 高負荷時の不適切な性能効率
    - 非機能特性の故障

目次へ戻る

テストタイプ

テストの実現手段の種類

テストレベルは、テスト目的、テストベース、テスト対象、テストタイプ、検出できる欠陥・故障、実行者、アプローチによってグルーピングしたテストの種類。テストを効率的にマネジメントするために、テストレベルというグループで扱う。
テストタイプは、テスト目的に焦点を当て区別したテストの種類。テストの実現手段の種類。
各テストタイプで、テストベース、適応するテストレベル、適応するテスト技法、カバレッジの集計方法、必要知識が異なる

テストタイプ
- ブラックボックステスト :システム/ソフトウェアの外部動作、ふるまいの評価
  - 機能テスト（WHAT(プログラム・システムが何をするか)を確認)
  - 非機能テスト(HOW(プログラム・システムがどのように動作するのか)を確認)
    - 性能テスト
    - 負荷テスト(ロードテスト)
    - ストレステスト
    - 使用性テスト
    - 相互運用性テスト
    - 保守性テスト
    - 信頼性テスト
    - 移植性テスト
    - セキュリティテスト
- ホワイトボックステスト :システムソフトウェアの内部構造や実装に基づいたテスト
- 変更部分のテスト :欠陥修正後に行う再テスト
  - 確認テスト :欠陥修正により、起因する故障が発生しなくなることを確認
  - リグレッションテスト :欠陥修正や変更により、別の欠陥が混入されていないことを確認

目次へ戻る

メンテナンステスト

ソフトウェア/システムの開発終了後に、発生する保守(メンテナンス)期間中に発生するテスト

メンテナンステストの目的
- メンテナンスによるソフトウェアの変更が正しく適応されていることを評価
- システムの変更していない部分への副作用を確認(リグレッションテスト)
メンテナンステストのタイミング
- ソフトウェアの変更作業
- ソフトウェアの運用環境(OS,データベース)の変化
- 対象ソフトウェアの破棄
メンテナンステストを確実に効率よく行うために
- 設計成果物とテストウェアのトレーサビリティを確立しておく
- ソフトウェアの保守性を高くする(コード構造を綺麗にしておく)
メンテナンステストの影響度分析が難しくなる状態
- 仕様が最新でないor存在しない
- テストケースが最新でないor存在しない
- テストベースとテストケースのトレーサビリティが確立されていない
- etc.

目次へ戻る

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

参考になれば幸いです。

目次へ戻る

はじめに : JSTQB FLの学習内容・解釈・気づきを共有

今回の内容 : 第2章.ソフトウェア開発ライフサイクル全体を通してのテスト

目次

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

テストの前に、ソフトウェア開発の活動・作業の全体像とテストの位置づけを理解する

テストレベル

一言にテストといっても、状況によってテスト目的や対象、検出したい欠陥は違うため、テストレベルという概念で系統的にまとめる。

テストタイプ

テストの実現手段の種類

メンテナンステスト

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

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