ソフトウェアテストプロセスに関する一考察－Ｖ ⇒ Ｗ ⇒ Ｖ３－

Size: px

Start display at page:

Download "ソフトウェアテストプロセスに関する一考察－Ｖ ⇒ Ｗ ⇒ Ｖ３－"

まなすえたけ
5 years ago
Views:

1 ソフトウェアテストプロセスに関する一考察ー V W V3 W ー小川秀人 ( 株式会社日立製作所 ) ソフトウェアテストシンポジウム 2007 東京 2007 年 1 月 30 日

2 モチベーション自己紹介 ( 主に ) 大規模組込みソフトウェアを対象とした開発技術の研究開発プロセス, アーキテクチャ, コーディング, テスト種々の製品やプロジェクトに対して技術開発導入問題意識違う組織に行くと, 言葉が違うまったく異なる言葉を使っているのならまだいい同じ言葉を違う意味で使うのはやめてくれ特にテスト関係は誰でも分かっている気になっている本当か? 長年の知識の積み重ね 20 年前からソフトを扱ってる人はそれでいい? テストは知識教育より経験 OJTという名の無作為? テストって, 何をするんでしたっけ?

3 目次 1. 問題提起と本研究の目的 2. 従来のテストプロセスモデル 3. 研究の目的 4. テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述 5. 調査 6. まとめ

4 1-1 質問どのようなプロセスでテストしていますか?

5 1-2 問題提起質問 : どのようなプロセスでテストしていますか? 何を答えようとしましたか? もし, ここにいる全員が, 同じ種類の回答をしようとしたのなら, 私は喜んで舞台を降りて, 食後のデザートと紅茶をいただきます. でも, 皆さんの回答を確認するだけで持ち時間が終わってしまうので, 残念ながら話を続けることにします. 疑問 : ソフトウェアテストに関して実施すべき活動内容は, 共通に理解されているでしょうか?

6 1-3 回答例 1 単体テスト, 結合テスト, システムテストの順に行なう Ⅴ 字モデルに従っている質問追加 : それらのテストの違いは何ですか? 単体テストは関数単位, 結合テストはコンポーネント単位単体テストはコンポーネント単位で, 結合テストは機能単位だ結合テストまではホワイトボックステストで, システムテストはブラックボックステスト結合テストまでは開発部, システムテストからは品質保証部システムテストは, ハードウェアも含む

7 1-4 回答例 2,3 テスト項目を設計し, 次にテスト環境を構築する. テスト対象ソフトをビルドし, テストを実施し, 発見した欠陥はというツールで管理し, 分析には信頼度成長曲線を用い人や組織によって, いろいろな回答があるみたいです

8 1-5 回答例の分類回答の視点例 1 テスト対象の粒度関数単位コンポーネント単位 2 テスト技法ブラックボックスホワイトボックス 3 テスト環境道具非実機環境実機環境運用環境 4 テスト実施組織ソフト開発部署品質保証部署 5 テスト作業手順テスト計画テスト項目設計テスト実施 6 管理対象ドキュメントテスト仕様書テスト手順書 7 管理ツールバグトラッキング進捗管理 8 テスト分析手法限界値境界値テストパステスト

9 1-6 現状の考察どの回答が正しい? どれが正しいとは言えないしかし, どの観点で話しているのか意識が統一できていなければ, 組織のプロセスとして議論が成り立たない. 実例 ( 実話を基にしたフィクションです ) A コンポーネント単位のテストを実施したのち, コンポーネントを組み合わせてシステムを構築しシステムテストを行っています. システムテストは, システムの状態遷移に基づいて B ちょっと待て. 状態遷移はシステムの内部仕様だから, それはホワイトボックステストだ. システムテストはブラックボックスだろう? 私ぎゃぼ

10 1-7 仮説と研究目的テストプロセスに関する共通理解がない議論が噛み合わない各々が違うことを想う部分最適化, 知識不足, 考慮不足全体で見ると漏れ, 無駄個別に頑張っても品質は上がらない ( むしろ下がる?) 改めて, テストとは何をすることか考え直してみようソフトウェアテストプロセスの再考

11 目次 1. 問題提起と本研究の目的 2. 従来のテストプロセスモデル 3. テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述 4. 調査 5. まとめ

12 2-1 従来プロセスモデル :V: 字モデルシステム設計システムテストソフトウェア設計統合テストレビュー等の上流での検証活動は? 詳細設計単体テストテストに関する活動は下流だけ? テストの計画や設計はいつやる? 実装

13 2-2 従来プロセスモデル :W: 字モデルタイプ A システム設計システムテストの設計システムテスト修正ソフトウェア設計統合テストの設計統合テスト修正テストの計画や設計は, システムの計画や設計と同時に行おう ( 直後に ) 詳細設計単体テストの設計実装単体テストデバグ修正

14 2-3 従来プロセスモデル :W: 字モデルタイプ B システム設計活動の検証フェーズごとに各活動の正しさを確認しようシステムテスト活動の検証ソフトウェア設計活動の検証統合テスト活動の検証詳細設計活動の検証単体テスト活動の検証実装活動の検証

15 2-4 従来プロセスモデル :IEEE Standards IEEE IEEE Standard for Software Test Documentation ソフトウェアテストに関連する文書を定義したものテスト計画書, テスト設計仕様書, テストケース仕様書, テスト手順仕様書, テスト送達書, テストログ, テスト事故報告, テストサマリ一連の文書とその内容がプロセスを示していると言える IEEE IEEE Standard for Software Verification and Validation ソフトウェアV&Vのプロセスを定義したものプロセス : 取得, 供給, 開発, 運用, 保守, 管理アクティビティ : 取得支援, 計画, 企画, 要求, 設計, 実装, テストなどタスク : ( 略 )

16 2-5 従来プロセスモデル :TPI: TPI (Test Process Improvement) テストプロセスの改善モデル組織の現行のテストプロセスの長所と短所を明らかにするための枠組みを提供するキーエリア : テスト戦略, テスト仕様化技術, テスト環境など20 レベル : テスト成熟度マトリクスによるレベル A~D チェックポイント : レベルを判断するための測定手段改善提案 : 改善のためのヒントアイデアキーエリアレベルテスト成熟度マトリクスチェックポイント改善提案

17 目次 1. 問題提起と本研究の目的 2. 従来のテストプロセスモデル 3. テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述 4. 調査 5. まとめ

18 3-1 テスト検証プロセスモデルの提案目的これまでに示したような様々な考え方を統合して, テストではこれだけのことをするんだよを共有したい. 目的ではないすべての組織に同じプロセスを適用したい. 組織のプロセスを評価してラベル付けしたい. 対象範囲テスト : 開発物を実行して欠陥を発見する行為検証 : すべての成果物を対象に, 活動の妥当性を確認する行為より良い名称があれば, 教えてください.

19 3-2 V3 モデルの提案名前の通り,3 つの V 字からなる (V1) 設計構築プロセス (V2) テストプロセス (V3) 検証プロセス要求分析システムテストの設計活動の検証システム結合システムテスト活動の検証基本設計結合テストの設計活動の検証ソフトウェア結合結合テスト活動の検証詳細設計単体テストの設計活動の検証ソフトウェア構築単体テスト活動の検証実装デバグ活動の検証

20 3-3 モデルの提案手順軸マスターテスト計画製品評価工程軸 ( 段階的詳細化 ) システムテスト計画結合テスト計画単体テスト計画システム設計ソフトウェア設計コンポーネント設計システムテスト設計結合テスト設計単体テスト設計システムテストケース結合テストケース単体テストケースシステムテスト手順結合テスト手順単体テスト手順システム結合ソフトウェア結合コンポーネント開発システムテスト実行結合テスト実行単体テスト実行システムテスト結果結合テスト結果単体テスト結果システムテスト評価結合テスト評価単体テスト評価工程軸 ( 段階的統合 ) テスト計画ソフト仕様テスト仕様ソフト実現テスト実施テスト評価

21 3-4 テストプロセスマップの作成 V3 モデルやモデルを踏まえ, テスト検証で行う活動とその関係性を網羅的に視覚化. プロセス : 設計構築, テスト, 検証アクティビティタスクテスト検証プロセス設計構築プロセステストプロセス検証プロセスアクティビティアクティビティアクティビティタスクタスクタスク

22 テストプロセスマップの作成テストプロセスマップの作成テストプロセスマップの作成システム適格性確認テストシステム結合設計プロセス検証アクティビティテストアクティビティシステム要求分析システム設計ソフトウェア要求分析ソフトウェア方式設計ソフトウェア詳細設計プログラミングコンポーネントテストソフトウェア結合テストソフトウェア適格性確認テストシステム結合テスト製品コンセプト開発システム要求分析と定義プロジェクト計画製品コンセプトの検証システム要求定義の検証プロジェクト計画の検証システム適格性確認テストの計画テスト検証のマスター計画システム設計システム設計の検証システム適格性確認テストの設計システム結合計画システム結合テストの計画システム結合テストの設計ソフトウェア要求分析と定義ソフトウェア要求定義の検証ソフトウェア適格性確認テストの計画ソフトウェア適格性確認テストの設計システム結合計画の検証ソフトウェア適格性確認テストの準備ソフトウェア方式設計ソフトウェア詳細設計ソフトウェア方式設計の検証ソフトウェア詳細設計の検証ソフトウェア結合テストの計画ソフトウェア結合テストの設計プログラミングソースコードの検証コンポーネントテストの計画コンポーネントテストの設計コンポーネントテストの環境構築テストアクティビティコンポーネントテストの実施コンポーネントテストおよびコンポーネントの評価ソフトウェア結合テスト計画の見直しソフトウェア結合計画ソフトウェア結合計画の検証ソフトウェア結合テストの準備ソフトウェア結合テストの実施ソフトウェア結合テストおよびソフトウェア結合の評価ソフトウェア適格性確認テスト計画の見直しソフトウェア適格性確認テストの実施ソフトウェア適格性確認テストおよびソフトウェア適格性の評価システム結合テストの準備システム結合テスト計画の見直しシステム結合テストの実施システム結合テストおよびシステム結合の評価システム適格性確認テストシステム適格性確認テストの準備システム適格性確認テスト計画の見直しシステム適格性確認テストの実施システム適格性確認テストおよびシステム適格性の評価システム適格性確認テストの環境構築システム結合テストの環境構築ソフトウェア的確性確認テストの環境構築コンポーネントテストソフトウェア結合テストソフトウェア適格性確認テストシステム結合テストシステム適格性確認テストテスト計画コンポーネントテストソフトウェア結合ソフトウェア適格性確認テスト総括総括テスト検証活動の総括検証アクティビティソフトウェア結合の検証システム結合の検証開発活動の総括構築プロセスシステム結合ソフトウェア結合ソフトウェア適格性評価システム適格性評価開発総括コンポーネント評価工程工程構成管理手順の検証コンポーネント評価の検証ソフトウェア適格性評価の検証システム評価適格性の検証製品出荷判定出荷製品品質の評価出荷物件の検証製品出荷製品戦略策定 / 受注戦略 / 契約書の検証戦略ソフトウェア結合テストの環境構築 3-5 プロセスマップ ( 全体図 )

23 適格性確認テストソフトウェア要求分析フトウェアソフトウェアソフトウェア結合テスト方式設計ソフトウェア詳細設計ンポーネントテストプログラミング 3-6 ソテストプロセスマップの作成プロセスマップ ( 詳細図 ; 部分 ) ソフトウェア要求分析と定義ソフトウェア適格性確認テストの計画ソフトウェア適格性確認テスト計画の策定ソフトウェア適格性確認テストのレビューソフトウェア適格性確認テストの設計ソフトウェア適格性確認テストの設計ソフトウェア適格性確認テストケースの作成ソフトウェア適格性確認テストのレビューソフトウェア適格性確認テストの環境構築ソフトウェア適格性確認テスト環境の構築ソフトウェア適格性確認テスト手順の策定ソフトウェア結合計画ソフトウェア結合テストの計画ソフトウェア結合テスト計画の策定ソフトウェア結合テスト計画のレビューソフトウェア方式設計ソフトウェア結合テストの設計ソフトウェア結合テストの設計ソフトウェア結合テストケースの作成ソフトウェア結合テスト設計のレビューソフトウェア結合テストの環境構築コソフトウェア結合テスト環境の構築ソフトウェア結合テスト手順の策定ソフトウェア詳細設計コンポーネントテストの計画コンポーネントテスト計画の策定コンポーネントテスト計のレビュープログラミングコンポーネントテストの設計コンポーネント結合テストの設計コンポーネントテストケースの作成コンポーネントテスト設のレビューコンポーネントテストの環境構築コンポーネント結合テスト環境の構築コンポーネントテスト手順の策定

24 3-7 テストプロセスの記述プロセスマップを作っても当初の課題は解決していないテストプロセスに関する共通理解がないアクティビティやタスクの内容を定義する必要がある何をもって定義するか? テスト対象物や, テスト技法, テスト環境などをベースとした定義だけでは組織や製品での違いが大きくて, 共通認識が持ちづらいこういうテスト検証と言いたいこういうとは? テスト検証の観点例 : ソフトウェア結合テストの観点例ソフトウェア結合計画に基づいて結合されたソフトウェアが, 整合性をもって動作可能例 : ソフトウェア適格性確認テストの観点例 : 結合されたソフトウェアが, ソフトウェア要求定義にて定義されたすべての機能および非機能要求を満たす

25 3-8 テストプロセスの記述項目アクティビティ記述の場合記述項目他の標準との関係目的内容対象タスク補足事項対応する設計構築アクティビティ対応する検証アクティビティ概要社内外の他標準での対応するアクティビティや工程等アクティビティを実施する目的活動内容テストや検証の対象物含まれるタスク群他のアクティビティとの関係や注意事項等, 理解の助けとなる情報テストや検証の元となる設計構築アクティビティ設計構築やテストを検証する検証アクティビティ

26 3-9 テストプロセスの記述例ソフトウェア結合テストの設計アクティビティ他の標準との関係フレームワーク 98 (SLCP) ソフトウェア結合のためのテスト要求事項の定義目的ソフトウェア結合テストを設計し, テスト内容が必要充分であることを確認する対象ソフトウェア活動内容ソフトウェア結合テストを実施するため, 一連のテスト, テストケースを作成するタスク作成したテストをレビューし, ソフトウェア結合テスト計画で定義したテストスコープに対して必要充分なテスト内容であることを確認する 1. ソフトウェア結合テストの設計 2. ソフトウェア結合テストケースの作成 3. ソフトウェア結合テスト設計のレビュー 4. ソフトウェア結合テスト設計とソフトウェア方式設計とのトレーサビリティ分析 5. ソフトウェア結合テストのリスク分析 6. ソフトウェア結合テストのハザード分析対応する設計構築アクティビティソフトウェア方式設計対応する検証アクティビティソフトウェア方式設計の検証 ( 実際の記述よりも簡略化しています )

27 3-10 テストプロセスの記述例ソフトウェア結合テストの設計内容ソフトウェア結合テストを設計するテスト設計に含む項目は, 組織の標準として規定しておくべきである設計すべき主な項目 : テスト設計仕様 ID テストする機能の定義テストアプローチテストケース ( テスト項目の一覧 ) 機能の合否判定基準 ( 実際の記述よりも簡略化しています ) テストする観点テストする観点は, ソフトウェア結合テスト計画で規定されているはずであるソフトウェア適格性確認テストでテストすべき主な観点 : ソフトウェア結合計画に基づいて結合されたソフトウェアが, 整合性をもって動作可能である結合ソフトウェアの機能性が, ソフトウェア適格性確認テストを実施できるだけのものある機能性には, 機能要件, 性能要件のほかに, 標準への適合性, 処理結果の正確性の観点を含むソフトウェアが, 時間および資源を効率的に使用するテスト形態主に次のようなテストを行なう : 正確性テスト, 境界条件テスト, 性能テスト, 構成テスト, インストールテスト ( 略 )

28 目次 1. 問題提起と本研究の目的 2. 従来のテストプロセスモデル 3. テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述 4. 調査 5. まとめ

29 4-1 調査疑問本当にテストプロセスに対する理解の相違があるのだろうか? 記述したテストプロセスで, 共通理解を確立できるのだろうか? 調査アンケートを通して, 意識調査. 対象者数 :14 名少数のため, 以降の内容は参考程度にご理解ください後述のアンケートを, プロセス記述を読む前と後で回答. 各自の関係するプロジェクトの現状とあるべき姿. プロセス記述による意識の変化.

30 4-2 質問内容各プロジェクトに関する質問 1. 次のそれぞれに当てはまる工程を答えよ. コンポーネントテスト, ソフトウェア結合テスト, ソフトウェア適格性確認テスト, システム結合テスト, システム適格性確認テスト 2. テスト計画は, プロジェクト全体とテスト工程のそれぞれ立てていますか? 3. テスト設計とテストケース設計の区別はありますか? 4. ソフトウェア適格性確認テストとソフトウェア結合テストの区別はありますか? テストプロセス定義を読んだ後での質問 1. 工程定義に関する認識の変化はあったか? 2. テスト計画に関する認識の変化はあったか? 3. テスト設計とテストケース設計に関する認識の変化はあったか? 4. ソフトウェア適格性確認テストとソフトウェア結合テストに関する認識の変化はあったか?

31 4-3 調査結果 (1) 工程定義に対する質問それぞれに当てはまる工程を答えよこの質問のポイント工程名にとらわれず, 各工程の意味が理解できているか? 各組織の工程を一般化された説明に対応付けて理解できるか曖昧になっていることを自覚しているか? どの工程が該当するのか悩み, 人による認識のズレがないよう, 定義する必要性を感じたどの工程が該当するのか悩み, 定義が不明確であることに問題を感じた特に何も感じなかった

32 4-4 調査結果 (2) テスト計画に対する質問テスト計画は, プロジェクト全体とテスト工程のそれぞれ立てていますか? この質問のポイントここでは, IEEE 的な定義を採用. 単なる日程計画や, 不良摘出予定数などの数値目標だけではない各テストのスコープや, テストアプローチ, 終了条件など意味的な定義が重要プロジェクト計画としてのテスト計画と, 各テストの計画という 2 つが混合して使われているように思われるが以前の認識と異なり, 現状の変革が必要であると感じた以前の認識と異なり, テスト計画についての新たな視点を得た以前のテスト計画についての認識と変わらない意味が理解できなかったプロジェクト全体と各テスト工程のテスト計画を立てるべき

33 4-5 調査結果 (3) テスト設計とテストケースに対する質問テスト設計とテストケース設計の区別はありますか? この質問のポイントここでは,IEEE 的な区別を採用. テスト設計 : テスト項目集合の設計テストケース : 各テスト項目の具体化違いの有無や, 必要性を認識しているか? これまで意識していなかった違いがあることを認識した以前から違いを認識しているテスト設計とテストケース作成の工程を分けるべき同一工程内でそれぞれを意識すべき

34 4-6 調査結果 (4) ソフトウェア適格性確認テストとソフトウェア結合テストについての質問ソフトウェア適格性確認テストとソフトウェア結合テストの区別はありますか? この質問のポイントここでは,SLCPやIEEE 的な区別を採用. ソフトウェア適格性確認テスト : 要求に対する適格性の確認ソフトウェア結合テスト : 結合したソフトウェアの妥当性の確認違いの有無や, 必要性を認識しているか? 区別を実践する必要を感じたこれまで意識していなかった違いがあることを認識した以前から違いを認識している区別する必要性が感じられない適格性テストと結合テストの工程を分けるべき同一工程内でそれぞれを意識すべき

35 4-7 調査結果の考察サンプル数が少ないため, 数値の妥当性は不明. アンケートとして改めてテストプロセスを問われることで, 理解の曖昧さや不足を認識する工程名はプロセス定義としては不充分異なる概念や意図の区別が, プロセスの検討で重要概念や意図の区別が, 作業工程の分割と一致するとは限らない作業工程を細分化することが得策ではないプロセス理解が品質に与える影響は未調査プロセスマップや記述が, 新たな知見を与えられるしかし, 広大なプロセスを著作物の学習で理解するのは困難アンケートを通した理解がヒントに

36 目次 1. 問題提起と本研究の目的 2. 従来のテストプロセスモデル 3. テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述 4. 調査 5. まとめ

37 5-1 まとめソフトウェアテストプロセスの現状プロセスに関する共通理解がないことが, 品質低下の一因になっていると仮定従来ソフトウェアテストプロセスモデルの紹介テスト検証プロセスモデルの提案 V3モデルモデルプロセスマッププロセス記述テスト検証プロセスモデルに基づく現状調査

38 5-2 まとめテストプロセス理解に曖昧性や相違が存在プロセスマップやプロセス記述が理解を促進今後の課題プロセスの実適用, 洗練化効果的な運用方法の検討アンケートを通した理解促進がヒントになるかも CMMIでの自分たちでのアプレイザルも? プロセスを定義すること自体にはあまり意味がありませんあれ? なぜ? なに? が大切当たり前と思っていることが, 当たり前じゃないことに気付くことから隣の隣の人と話をしてみましょう

39 ソフトウェアテストプロセスに関する一考察ー V W V3 W ーご清聴ありがとうございましたソフトウェアテストシンポジウム 2007 東京 2007 年 1 月 30 日

テスト設計コンテスト

テスト設計コンテスト 17 話題沸騰ポット (GOMA-1015 型 ) テスト設計目次 Page 2/25 1. はじめにチーム紹介チームの立ち位置テスト設計の流れ 2. テスト要求分析テスト要求分析の流れ仕様把握と機能要求分析非機能要求分析因子水準表 3. テストアーキテクチャ設計アーキテクチャ設計の流れテストアーキテクチャ全体俯瞰図機能アーキテクチャ非機能アーキテクチャシステム全体俯瞰図 4.

ソフトウェアテストプロセスに関する一考察 － Ｖ ⇒ Ｗ ⇒ Ｖ３ －

ソフトウェアテストプロセスに関する一考察－Ｖ ⇒ Ｗ ⇒ Ｖ３－