Recommended
Recommended
More Related Content
More from Akira Ikeda
More from Akira Ikeda (20)
Recently uploaded
Recently uploaded (9)
「長崎SWQuality&DevelopmentGathering2015」V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために
- 2. 現実の話と本来どうあるべきかの議論 ©Akira Ikeda 2 清水様の講義で， すでに「ＵＳＤＭとはどういうもの」は学んだと思います ただ，いざテスト担当者として利用するときに戸惑うときがあります • あなたがテストチームのテスト担当者だったとします • すでにガチガチなＶ字モデルがあるとことに，開発工 程にＸＤＤＰを適用しようとしているらしい • テスト工程に入ったあなたが受け取ったテストベース はUSDM形式の変更要求仕様書でした • USDM形式の変更要求仕様書は見るのも初めてです こんな状況下でまず最初に遭遇する慌てポイント4つについて 紹介します。 その後，清水様のアドバイスもいただきながら，「ＸＤＤＰで のテストは本来どうあるべきか」を皆様と議論します。 困った！（泣）
- 3. アジェンダ 1. 自己紹介 2. [おさらい]ＸＤＤＰにおけるテスト 3. ある日受け取ったテストベースがＵＳＤＭ形式だったとき • 慌てポイント１：そもそも慌てない • 慌てポイント２：どこのインプット？ • 慌てポイント３：どこのテストレベル？ • 慌てポイント４：情報が足りません！ 4. まとめ・議論 ©Akira Ikeda 3
- 4. 自己紹介 4 • 名前：池田 暁（いけだ あきら） • 所属：某製造業 ソフトウェア開発技術導入支援部門 • 職歴：入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、 現在は設計/テストツールの導入や、プロセス改善に関するコンサル ティングなど。 • 社外活動 – 委員等 • 長崎ＩＴ技術者会 代表 • NPO法人ASTER（ソフトウェアテスト技術振興協会） 理事 • 日科技連SQiP運営委員会 運営委員 • 派生開発推進協議会（AFFORDD） 運営委員 • JaSST（ソフトウェアテストシンポジウム） 実行委員 • 日科技連・日本品質管理学会共同部会 SQuBOK策定部会 策定メンバ • 日本品質管理学会・ACM 正会員 – 執筆活動（単行本） • ISTQBシラバス準拠 ソフトウェアテストの基礎、センゲージラーニング、2008 • ソフトウェアテスト入門 押さえておきたい<<要点・重点>>、技術評論社、2008 • ソフトウェア品質知識体系ガイド―SQuBOK Guide、オーム社、2007 • マインドマップから始めるソフトウェアテスト、技術評論社、2007
- 6. ＸＤＤＰにおけるテスト • ＸＤＤＰとは派生開発に特化した開発手法 – 変更・差分に注目して，新規開発プロセスと変更開発プロセスを わける – 変更要求仕様書＋ＴＭ＋変更設計書の通称３点セットが特徴的 • 詳しくは先ほどのSQuBOK読破会様の発表内容を参照下さい ©Akira Ikeda 6 • 実は，ＸＤＤＰの本では，テストについてはあまり触れられ ていない（テストに入る前に極限までバグの作り込みを減ら す手法であるため） • なので，何も考えていないと，テスト工程で混乱を招きやす い（想定していないので当たり前であるが･･･） ＸＤＤＰでの開発の場合 対応したテストのプロセスもまた開発しておく必要があるが， 現実的にはそうなっていない！ （XDDPを採用しつつも，無理矢理Ｖ字モデルに取り込もうとするアプローチが多い多い状況からも明らか）
- 9. ＸＤＤＰでのテストに対する要請 変更箇所をきちんと認識できること • 変更要求仕様は変更要求仕様書＋ＴＭから認識できる • 変更要求仕様書＋ＴＭを読めないとうまくいかない 変更が及ぼす影響範囲を識別できること •ＴＭやスペックアウト資料，アーキテクチャ，モデルから識別できる •影響範囲技術やツールがないとうまくいかない 全体の機能・非機能の劣化が起きていないことを確認できること •既存テストケースの再利用により機能・非機能の劣化は確認できる •回帰テストの技術がないとうまくいかない →回帰テストの話題は次のセッション！ ©Akira Ikeda 9 変更箇所を テスト！ 影響範囲も テスト！ デグレの テスト！ 非機能も テスト！ 今回は一つ目の要請での主要なテストベースとなる USDM形式の変更要求仕様を“初めて”受け取った時に 慌てないためのとっかかりの話をします。 慣れていないと この時点で 慌てやすい！
- 10. ある日受け取った テストベースが USDM形式だったとき では本題です。 テストベースがUSDM形式の変更要求仕様書だった場合 に慌てやすいポイントについて紹介します ©Akira Ikeda 10
- 11. 慌てポイントの状況設定（再掲） ©Akira Ikeda 11 慌てポイントを紹介する上で，「置かれている状況」を設定します かなり(好ましくない)現実を想定しています できれば，皆さんもその状況を想像しつつ聞いて下さい • あなたがテストチームのテスト担当者だったとします • すでにガチガチなＶ字モデルがあるところに，開発工 程にＸＤＤＰを適用しようとしているらしい • テスト工程に入ったあなたが受け取ったテストベース はUSDM形式の変更要求仕様書でした • USDM形式の変更要求仕様書は見るのも初めてです こんなカオスな状況で最初に遭遇するであろう慌てポイント4 つを紹介します。 その後，清水様のアドバイスもいただきながら，「ＸＤＤＰで のテストは本来どうあるべきか」を皆様と議論します。 困った！（泣）
- 13. 慌てポイント１：そもそも慌てない • そもそもＵＳＤＭ形式の変更要求仕様書を見たことが ないので，何がどう書いてあるのか全くわからない！ • 見たことがあっても，読めるほど知らない！ ©Akira Ikeda 13 • とりあえずＵＳＤＭについての本とか記事を読んでおこう – 見たことがあると，落ち着いて考えられます • 落ち着いてＵＳＤＭでの変更要求仕様書の位置づけとか構造とかを眺 められるようにする 皆様はすでに清水様のＵＳＤＭの講義＆演習を受けている ので，もう慌てることはないと思います ただし，より落ち着いて対処できるように復習しておきま しょう！
- 15. 慌てポイント２：どこへインプット？ • 新規開発ではドキュメント段階的詳細化されているた め，テストレベルへのインプットが対応づけやすいが ，変更要求仕様書ではどのインプットになるのかわか らない！ ©Akira Ikeda 15 基本設計 構造設計 詳細設計 実装/机上テスト コンポーネント テスト 統合テスト システムテスト 要件定義 受け入れテスト システム仕 様書等… 構造仕様書 等… 詳細仕様書 等… 要件定義書 等… 実装/机上テスト コンポーネント テスト 統合テスト システムテスト 変更設計要求仕様 定義・設計 受け入れテスト ＴＭ 変更設計書 変更要求仕 様書 その他 設 計 レ ベ ル と テ ス ト レ ベ ル が 対 応 関 係 に あ る の で ド キ ュ メ ン ト の 出 入 力 関 係 も 明 確 ド キ ュ メ ン ト も 異 な る し ， 対 応 関 係 も 不 明 無 理 矢 理 社 内 規 格 と マ ッ チ さ せ よ う と し て プ ロ セ ス が 壊 れ る ， 現 場 が 混 乱 す る （ 新 規 開 発 プ ロ セ ス で あ る Ｖ モ デ ル に Ｘ Ｄ Ｄ Ｐ を い び つ に 取 り 込 む ， そ も そ も 誤 っ た ア プ ロ ー チ ） ?
- 16. 慌てポイント２：どこへインプット？ ©Akira Ikeda 16 実装/ 机上テスト コンポーネント テスト 統合テスト システムテスト 変更設計要求仕様 定義・設計 受け入れテスト ＴＭ 変更設計書 • 社内規格を簡単にはかえられない場合，まずは一番違和感の内容 に3点セットとテストレベル対応付け，ドキュメント入力先を決 めておこう（ただし，あくまで期間限定対処的に） 本来ＶモデルとXDDPでの開発プロ セスやテストプロセスのあり方は別 物。派生開発の場合はXDDPに合わ せてテストプロセスを開発する必要 があります！ それをわかった上で，関係者と対処的な プロセスでテストすることを関係者間（ PM・開発部門・テスト部門・QA部門等 ）で合意することが大切 その際，平行してテストプロセス設計を 実施して，次回のプロジェクトであるべ き姿にしよう！ 変更要求仕 様書 ※本例はあくまでも状況設定に従った例です 絶対にこれを鵜呑みにしないように！
- 17. 慌てポイント３：どこのテストレベル？ • 変更要求仕様書が複数のテストレベルへインプットさ れるけれど，変更要求仕様書の記載内容のどこがどの テストレベルに対応しているのかわからない！ ©Akira Ikeda 17 ※CQ出版サイト掲載「LED キューブ装置 ソフトウェア要求仕様書(USDM版）」 から引用 http://www.cqpub.co.jp/interface/download/contents.htm ?
- 18. 慌てポイント３：どこのテストレベル？ ©Akira Ikeda 18 • まずは変更要求仕様書記述内容をざっくり仕分けよう – 要求はシステムテスト – 仕様は統合テスト（機能テスト） • そのうえで，違和感があるところを個別に判断しよう まずは，目付をできるように しないと話が始まらないです テンプレートにテストレベル対応 のためのルールを定めておくと， テスト側で読み解きやすくなりま す テスト担当者側は，どうやったら テストをしやすくなるか，テンプ レートにフィードバックする必要 があります ひとまず システムテスト に振り分け ひとまず 統合(機能)テスト に振り分け ※CQ出版サイト掲載「LED キューブ装置 ソフトウェア要求仕様書(USDM版）」 から引用 http://www.cqpub.co.jp/interface/download/contents.htm
- 19. 慌てポイント４：情報が足りません！ • 変更要求仕様は変更に注目しているので，機能やソフ ト全体の情報が存在ない • 暗黙化されている情報が無いとテスト分析できない！ ©Akira Ikeda 19 ※CQ出版サイト掲載「LED キューブ装置 ソフトウェア要求仕様書(USDM版）」 から引用 http://www.cqpub.co.jp/interface/download/contents.htm そもそも トグルスイッチ の仕様は？ システム動作 モードって？ LEDは？ 通信仕様？ 表示仕様？
- 20. 慌てポイント４：情報が足りません！ ©Akira Ikeda 20 • 変更要求仕様書は変更・差分に集中したテストベースです • 最低限以下の2つがないとテスト分析の難易度が上がります – 派生開発元の各種仕様書 – スペックアウト資料 変更箇所・差分箇所をより深く 理解するためには周辺の仕様も 理解する必要があります また，変更箇所だけではなく，その 周辺や関係する関数・機能やモジュ ールもテストする必要があります 加えて機能縮退や非機能低下に関す る欠陥を摘出するために全体に対す るテストが欠かせません 必ず，既存ドキュメントをテストベ ースとして押さえておきましょう！ システム仕 様書等… 構造仕様書 等… 詳細仕様書 等… ＋ソフト全体が記述された仕様書 仕様の調査資料であるスペックアウト資料 変更要求仕様 ※当然，今回あげたもの以外に必要と思われる テストベースもインプットとしましょう
- 21. 慌てポイント４：情報が足りません！ ©Akira Ikeda 21 実装/ 机上テスト コンポーネント テスト 統合テスト システムテスト 変更設計要求仕様 定義・設計 受け入れテスト ＴＭ 変更設計書 既存テスト ベース等 既存テスト ウェア等 加えて，既存テストベース のインプット関係も決めて おくとよいでしょう そのほか，インプット対象 としては既存のテストウェ アも考えられます（回帰テ ストに利用するテストケー スなど） 変更要求仕 様書 さらに言うと 「テストケースも派生開発対 象である」ことを認識してお く必要があるのです > → 了解！ 少し柔らか目ですね。 ※本例はあくまでも状況設定に従った例です 絶対にこれを鵜呑みにしないように！
- 24. ディスカッションしよう！ 本来どうすべき？ ～抜本的に改善するために必要なこと ©Akira Ikeda 24 慌てポイント２で示した そもそも「Ｖ字モデル」でいいのか という疑問から，「本来XDDPでのテストとは？」を議論します • 先ほどはＸＤＤＰとしてはかなりいびつな話をしました • しかし，いつまでもいびつな形ではいけません • 本来の，よりよいＸＤＤＰの考え方やプロセスに移行すべき • その中で，開発とテストのプロセスを一体となって改善をす すめなければなりません