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

テストは単体では存在せず、対象をを作り上げていく開発の一部 したがって、ソフトウェア開発ライフサイクルの中でのテストの位置づけを知ることが肝要

2.1.1 ソフトウェア開発とソフトウェアテスト

ソフトウェア開発ライフサイクルによらない良いテストの特徴

各開発活動に対応してテスト活動がある

• テストレベル: 全章「テストプロセス」のインスタンス

• 開発ライフサイクル上の開発レベルに対応している

  • コンポーネントからシステム、システムオブシステムズまで

各テストレベルには、そのレベル特有の目的がある

• 典型的な欠陥の例というものがある

テストレベルのテスト分析や設計は、対応する開発活動の間に開始する

• かつ、テスト実行直前ではなくできるだけ早い段階に開始するのが望ましい

  • Wモデル
  • シフトレフト

テスト担当者は要件と設計を定義および洗練する討議に参加し、作業成果物(要件、設計、ユーザストーリーなど)のドラフトができたらすぐにそのレビューに関与する

• 開発に積極的に関与し、テストベースの品質向上に貢献する

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

• 直前のフェーズの完了とともに次のフェーズが始まる

• ことになっているが、現実には前後のフェーズが重なることもある

  • シフトレフト

ウォーターフォール

(上流)  要求分析 -> 要件定義 -> 設計 -> コーディング -> テスト  (下流)

というような流れ

V字モデル

要求分析                             受け入れテスト
    ↓                                ↑
    要件定義                     システムテスト
        ↓                        ↑
        基本設計             (コンポーネント)統合テスト
            ↓                ↑
            詳細設計     コンポーネントテスト 
                ↓        ↑
                コーディング

• 左半分:「品質を作り込む工程」
• 右半分:「品質を確認する工程」

上流の活動とテストレベルの対応が明確になる

V&V: Verification & Validation

• Verification: 検証

  • correct/incorrect
  • 前工程の成果物との整合性や記述の十分性を確かめる

• Validation: 妥当性確認

  • valid/invalid
  • ユーザーの要求を満たしているか確かめる

デメリット

• 仕様変更に弱い
• システムテストで要件定義のもれが見つかったら？
• 基本設計、詳細設計、コードを修正し、コンポーネントテスト、コンポーネント統合テストを再度実行する必要がある

Wモデルとシフトレフト

要求分析                             受け入れテスト
    ↓                                ↑
    要件定義                     システムテスト
        ↓                        ↑
        基本設計             (コンポーネント)統合テスト
            ↓                ↑
            詳細設計     コンポーネントテスト 
                ↓        ↑
                コーディング

テスト活動は開発ライフサイクル後半でしか行わないように見えてしまう

実際にはそんなことはなく、テスト計画やテスト分析は上流で行うべき

テストレベルのテスト分析や設計は、対応する開発活動の間に開始する
テスト担当者は要件と設計を定義および洗練する討議に参加し、作業成果物(要件、設計、ユーザストーリーなど)のドラフトができたらすぐにそのレビューに関与する

要求分析 <-> テスト計画・設計                                                     受け入れテスト <-> デバッグ
            ↓                                                                        ↑
        要件定義 <-> テスト計画・設計                                     システムテスト <-> デバッグ
                    ↓                                                        ↑
                基本設計 <-> テスト計画・設計                     (コンポーネント)統合テスト <-> デバッグ
                            ↓                                        ↑
                        詳細設計 <-> テスト計画・設計     コンポーネントテスト <-> デバッグ
                                  ↓                        ↑
                                        コーディング

さらにテストベースの検証等も上流で行うとさらなるシフトレフトが実現される

インクリメンタル開発モデルとイテレーティブ開発モデル

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

• 何をインクリメントするの？
• feature(のまとまり)

featureとfunctionの違い

• function: 「メール機能」

• feature: 「メールにファイルを添付できる」

  • より具体的・特徴に着目している

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

何を繰り返すか: 固定のタイムボックス

• イテレーションという
• イテレーションの中で小さなシーケンシャル開発モデルでの開発を実施する

有名所

• RUP: ラショナル統一プロセス
• スクラム

• カンバン

  • イテレーティブ開発モデルに利用できるがイテレーションを強制しない
• スパイラル(プロトタイピング)

最初に「使用可能なソフトウェア」を提供するのが素早くなるのであって、顧客のすべての要求を実現するにはシーケンシャル開発同様数カ月〜数年かかる

インクリメンタル/イテレーティブ開発モデルとシフトレフト

イテレーションの中で小さなシーケンシャル開発モデルでの開発を実施する

実際にはそうでないこともある

• 要件定義、設計、コーディング、テストが一体
• ユニットテストと統合テストが並行して・繰り返し行われる
• システムテストや受け入れテストは単独のイテレーションとして実施される

短期間のイテレーションでテストをする/何度もするので、自動化テストやCI/CDによるデグレのタイムリー検出が望まれる

2.1.2 状況に応じたソフトウェア開発ライフサイクルモデル

状況次第

• プロジェクトのゴール
• 開発するプロダクトの種類
• ビジネス上の優先度
• 識別したプロダクトリスク
• 識別したプロジェクトリスク

テスト活動も当然状況次第になる

テストレベルやテスト活動の組み合わせ、再編成

• 市販ソフトウェア(COTS: commercial off-the-shelf)を組み込む場合、購入者による「相互運用性テスト」が必要(後述)

ソフトウェア開発ライフサイクルモデルの組み合わせ

なにか1つしか使えない、というわけではない

• UIはインクリメンタル/イテレーティブ、バックエンドはシーケンシャル
• 初期の試行フェーズはプロトタイピング、済んだらインクリメンタル
• IoTの開発対象ごとに変える

2.2 テストレベル

テストレベル: 全章「テストプロセス」のインスタンス

• 開発ライフサイクル上の開発レベルに対応している

  • コンポーネントからシステム、システムオブシステムズまで

テストレベルにより目的も違えば検出されるべき欠陥も異なる

• コードが正しく書けているか？
• 使いやすいか？

共通した目的

• 信頼の積み上げ

  • アジャイル開発等で絶えずソースコードに変更を加えるようになったことにより追加された概念
  • デグレのないことをリグレッションテストで確認する
• リスク軽減
• そのテストレベルで検出されるべき欠陥がより高レベルまで見逃されることの防止

2.2.1 コンポーネントテスト

テスト目的

• 機能的振る舞いの検証

• 非機能的振る舞いの検証

  • 性能もここで
  • システムテストで性能問題が発生すると手戻りが大きい
  • 【所感】その場合本番相当のデータの投入が必要

テストベース

• 詳細設計
• コード

• データモデル

  • 例: RDBのテーブル定義とかSQL文とか
• コンポーネント仕様

テスト対象

• コンポーネント、ユニット、またはモジュール
• コードとデータ構造
• クラス
• データベースモジュール

テストタイプ

• 機能テスト
• 非機能テスト
• ホワイトボックステスト(構造テスト)
• リグレッションテスト

テストで見つかる典型的な欠陥と故障

• correctでない機能
• データフローの問題
• correctでないコードとロジック
• 性能欠陥

欠陥マネジメントについては状況次第

• コンポーネントテストでは、開発担当者が欠陥を発見しだい即修正するのが一般的であり、正式に管理しないことが多い
• 握りつぶさずに報告することで根本原因分析やプロセス分析に活用できる
• スピード重視で管理しないという考えもある

テスト実行者(責務の割当)

開発担当者(+テスト担当者)

固有のアプローチ

アジャイル開発では自動テストスクリプトの作成から行うことがある(TDD)

• Kent BeckのXP発祥
• 他のアジャイル実装やシーケンシャル開発にも普及している

2.2.2 統合テスト

何を統合するの？

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

• コンポーネントテスト済だからといってビッグバン統合するのは結局非効率

  • 欠陥の特定・除去に時間がかかる

• 体系的な統合戦略にもとづいて段階的に統合するのが主流

  • システムアーキテクチャーで分離
  • 機能的タスクで分離
  • トランザクション処理シーケンスで分離

システム統合テスト

システムテスト実行後、または最中に実施

下記のような要素との相互処理とインタフェースに焦点

• パッケージ
• マイクロサービス
• 外部組織が提供するWebサービス

テスト目的

• インタフェースの機能的振る舞いの検証
• インタフェースの非機能的振る舞いの検証
• インタフェースの品質の積み上げ

テストベース

• ソフトウェア設計とシステム設計
• シーケンス図
• インタフェースと通信プロトコルの仕様
• ユースケース

• アーキテクチャ

  • コンポーネントレベル
  • システムレベル
• ワークフロー
• 外部インタフェース定義

テスト対象

• サブシステム
• データベース

• インフラストラクチャ

  • プラットフォームとアプリケーションとのインタフェースもこれにあたるか
• インタフェース
• API
• マイクロサービス

テストタイプ

• 機能テスト
• 非機能テスト
• ホワイトボックステスト(構造テスト)
• リグレッションテスト

テストで見つかる典型的な欠陥と故障

共通

• 正しくないデータ、データ不足、正しくないデータエンコーディング

  • 【例】 B2B管理画面で新規作成・永続化するデータが不足していてB2Cクライアント側で出てこない

• インタフェース不整合

  • 【例】 APIのスキーマが合わない
• インタフェース間のコミュニケーション故障

• インタフェース間のコミュニケーション故障の処理不在、不適切な処理

  • 【例】try-catchのcatchが足りてない的な話

• インタフェース間で渡されるデータの意味、単位、境界の正しくない思い込み

  • 【例】在庫の数量変更を要求するAPIで正負の意味がわかりづらい、とか

システム統合テスト

• システム間で一貫性のないメッセージ構造
• 必須のセキュリティ規制への非準拠

テスト実行者(責務の割当)

• コンポーネント統合テスト: 開発担当者
• システム統合テスト: テスト担当者

固有のアプローチ

• 統合だけに集中する

  • コンポーネント統合テストならコンポーネントテスト、システム統合テストならシステムテストでカバー済の個々の機能はテストしない
• アーキテクチャを踏まえて統合戦略と統合テスト戦略を計画しておくことで、テストの効率が最大になる順序で構築できる

2.2.3 システムテスト

テスト目的

• システムの機能的振る舞いの検証
• システムの非機能的振る舞いの検証
• システムの全体的な品質に対する信頼の積み上げ

テストベース

• システム要求仕様
• ソフトウェア要求仕様
• ユースケース
• エピックまたはユーザーストーリー
• システム振る舞いのモデル
• 状態遷移図
• システムマニュアルおよびユーザーマニュアル
• リスク分析レポート(リスクベースドテスト)

【所感】ユースケース駆動モデリングのアプローチとも合致する(ユースケースがユーザマニュアル、ひいてはテストケースになる)

テスト対象

• アプリケーション
• HW/SWシステム
• OS
• SUT: テスト対象システム
• システム構成および構成データ

【所感】これまでコンポーネントテストでもテスト対象をSUTと呼んでいたが、test objectと呼ぶほうが適切そうだ…

テストタイプ

• 機能テスト
• 非機能テスト

• ホワイトボックステスト(構造テスト)

  • 「システムテストのホワイトボックステストを行うことはできない」わけではない
  • 画面遷移図等を用いて構造ベースのテストを行うことは可能
• リグレッションテスト

ほか、「SEC BOOKS：高信頼化ソフトウェアのための開発手法ガイドブック」による分類多数

https://www.ipa.go.jp/sec/publish/tn10-005.html

テストで見つかる典型的な欠陥と故障

• 正しくない計算
• 正しくない(incorrect)、または期待通りでない(invalid)機能的/非機能的振る舞い
• システム内の正しくない制御フローまたはデータフロー
• E2Eの機能的タスクを適切かつ完全に実行できない
• システム環境でシステムが適切に動作しない
• システムマニュアルおよびユーザーマニュアルに記載されている通りにシステムが動作しない

テスト実行者(責務の割当)

• 組織所属のテスト担当者
• 独立したテストチーム

固有のアプローチ

• 仕様にしたがって行うので、仕様やユーザーストーリーに欠陥があると偽陽性/偽陰性を招く

  • テスト担当者が仕様を洗練(リファインメント)することでこれを軽減する

• 最終的なターゲットまたは本番環境に準じた環境でテストすることが望ましい

  • 環境関連の故障も発見したいため:

• HW/SWシステム
• OS
• システム構成および構成データ

• システムテストの結果をリリース判定に用いることがある

2.2.4 受け入れテスト

リリース直前だけではない

誰が受け入れるの？

ユーザー受け入れテスト

本番や模擬本番環境にてユーザーがシステムを実際に使用し妥当性検証する

運用受け入れテスト

本番や模擬本番環境にて下記のような焦点でテストする

• バックアップ/リストア
• インストール/アンインストール/アップグレード
• 災害復旧
• ユーザーマネジメント
• メンテナンスタスク
• データロードと移行
• セキュリティの脆弱性
• 性能

例外的・困難な状況になってもシステムを適切な稼動状態に維持できるという信頼を積み上げるため

契約による受け入れテスト

請負契約のやつ

規制による受け入れテスト

• 問題領域によるさまざまな基準 — 政府、法律、安全基準等の規制に準拠しているという信頼の積み上げのために行う

アルファ/ベータテスト

• 市販ソフトウェア(COTS)において実施
• 将来のユーザーや既存の顧客からフィードバックを受けるために行う
• アルファテストの場合、開発組織の外部で独立したテストチームがシミュレーションや実際のオペレーションにより行う
• アルファテスト:内部受け入れテストとも
• ベータテスト:外部受け入れテストとも

テストベース

• ビジネスプロセス
• ユーザー要件またはビジネス要件
• 規制、法的契約、標準
• ユースケースおよびユーザーストーリー
• システム要件
• システムドキュメントまたはユーザードキュメント
• インストール手順
• リスク分析レポート

運用受け入れテストの場合さらに:

• バックアップ/リストア手順
• 災害復旧手順
• 非機能要件
• 運用ドキュメント
• デプロイメント指示書およびインストール指示書
• 性能目標
• データベースパッケージ
• セキュリティ標準または規制

テスト対象

• SUT
• システム構成および構成データ
• 完全に統合されたシステムのビジネスプロセス
• リカバリーシステムおよびBCP用ホットサイト
• 運用プロセスおよびメンテナンスプロセス
• 書式
• レポート
• 既存または変換した本番運用データ

テストで見つかる典型的な欠陥と故障

欠陥の発見を目的としない

大量に見つかるようなら前のテストレベルに戻る

• システムのワークフローがビジネス要件またはユーザー要件を満たさない
• ビジネスルールが正しく実装されていない
• システムが契約要件または規制要件を満たさない
• セキュリティの脆弱性、高負荷時の負荷季節な性能効率、サポート対象プラットフォームでの不適切な操作などの非機能特性の故障

テスト実行者(責務の割当)

• ユーザー受け入れテスト

  • 顧客
  • ビジネスユーザー

• 運用受け入れテスト

  • 運用担当者
  • システムアドミニストレーター

• 契約による受け入れテスト

  • ユーザー
  • 独立したテスト担当者

• 規制による受け入れテスト

  • ユーザー
  • 独立したテスト担当者
  • 規制機関(証明・監査が必要な場合)

• アルファ/ベータテスト

  • 潜在的な顧客
  • 既存の顧客
  • システム運用者
  • (アルファテストの場合)独立したテストチーム

固有のアプローチ

ライフサイクルモデルの最後とは限らない

• 市販ソフトウェア(COTS)を組み込むときはインストール時や統合時点で購入者が行う

  • 【補】Learning Tests (by Jim Newkirk)
• 機能拡張を外注した場合、システムテストの前に拡張部分の受け入れテストを実施する