Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
池田 暁(長崎IT技術者会)
V字モデルのテスト工程の
インプットがUSDMだった
ときに慌てないために
現実の話と本来どうあるべきかの議論
©Akira Ikeda 2
清水様の講義で,
すでに「USDMとはどういうもの」は学んだと思います
ただ,いざテスト担当者として利用するときに戸惑うときがあります
• あなたがテストチームのテスト担当者だっ...
アジェンダ
1. 自己紹介
2. [おさらい]XDDPにおけるテスト
3. ある日受け取ったテストベースがUSDM形式だったとき
• 慌てポイント1:そもそも慌てない
• 慌てポイント2:どこのインプット?
• 慌てポイント3:どこのテストレベ...
自己紹介
4
• 名前:池田 暁(いけだ あきら)
• 所属:某製造業
ソフトウェア開発技術導入支援部門
• 職歴:入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、
現在は設計/テストツールの導入や、プロセス改善に関するコンサル
...
[おさらい]
XDDPにおけるテスト
本題に入る前に,派生開発手法であるXDDPにおいて,
テストはどのように触れられているのかおさらいしまし
ょう
©Akira Ikeda 5
XDDPにおけるテスト
• XDDPとは派生開発に特化した開発手法
– 変更・差分に注目して,新規開発プロセスと変更開発プロセスを
わける
– 変更要求仕様書+TM+変更設計書の通称3点セットが特徴的
• 詳しくは先ほどのSQuBOK読破会様の...
新規開発/派生開発におけるテストの違い
新規開発
におけるテスト
開発要求
•ソフト全体に対する要求
テストベース
•テストベースは新規作成
•ミドルやライブラリ以外のプロダク
ト資産はなし
•テストの資産もなし
派生開発
におけるテスト
開発...
派生開発でのテストに対する要請
ソフトに対する
変更箇所をテストする
影響箇所ももれなく
テストする
全体に対しても
サイドエフェクトや
デグレがないように回帰テ
ストも実施
さらに非機能が低下してい
ないかのテストも必要!
©Akira Ik...
XDDPでのテストに対する要請
変更箇所をきちんと認識できること
• 変更要求仕様は変更要求仕様書+TMから認識できる
• 変更要求仕様書+TMを読めないとうまくいかない
変更が及ぼす影響範囲を識別できること
•TMやスペックアウト資料,アーキ...
ある日受け取った
テストベースが
USDM形式だったとき
では本題です。
テストベースがUSDM形式の変更要求仕様書だった場合
に慌てやすいポイントについて紹介します
©Akira Ikeda 10
慌てポイントの状況設定(再掲)
©Akira Ikeda 11
慌てポイントを紹介する上で,「置かれている状況」を設定します
かなり(好ましくない)現実を想定しています
できれば,皆さんもその状況を想像しつつ聞いて下さい
• あなたがテストチー...
ご紹介する慌てポイント
慌てポイント1:そもそも慌てない!
慌てポイント2:どこへインプット?
慌てポイント3:どこのテストレベル?
慌てポイント4:情報が足りません!
©Akira Ikeda 12
初めてUSDM形式の変更要求仕様書を受け取...
慌てポイント1:そもそも慌てない
• そもそもUSDM形式の変更要求仕様書を見たことが
ないので,何がどう書いてあるのか全くわからない!
• 見たことがあっても,読めるほど知らない!
©Akira Ikeda 13
• とりあえずUSDMについ...
慌てポイント1:そもそも慌てない
©Akira Ikeda 14
それでも不安だという方は,
まず以下の二つの書籍をゲットしよう!
慌てポイント2:どこへインプット?
• 新規開発ではドキュメント段階的詳細化されているた
め,テストレベルへのインプットが対応づけやすいが
,変更要求仕様書ではどのインプットになるのかわか
らない!
©Akira Ikeda 15
基本設計
構...
慌てポイント2:どこへインプット?
©Akira Ikeda 16
実装/
机上テスト
コンポーネント
テスト
統合テスト
システムテスト
変更設計要求仕様
定義・設計
受け入れテスト
TM
変更設計書
• 社内規格を簡単にはかえられない場合,...
慌てポイント3:どこのテストレベル?
• 変更要求仕様書が複数のテストレベルへインプットさ
れるけれど,変更要求仕様書の記載内容のどこがどの
テストレベルに対応しているのかわからない!
©Akira Ikeda 17
※CQ出版サイト掲載「LE...
慌てポイント3:どこのテストレベル?
©Akira Ikeda 18
• まずは変更要求仕様書記述内容をざっくり仕分けよう
– 要求はシステムテスト
– 仕様は統合テスト(機能テスト)
• そのうえで,違和感があるところを個別に判断しよう
まず...
慌てポイント4:情報が足りません!
• 変更要求仕様は変更に注目しているので,機能やソフ
ト全体の情報が存在ない
• 暗黙化されている情報が無いとテスト分析できない!
©Akira Ikeda 19
※CQ出版サイト掲載「LED キューブ装置 ...
慌てポイント4:情報が足りません!
©Akira Ikeda 20
• 変更要求仕様書は変更・差分に集中したテストベースです
• 最低限以下の2つがないとテスト分析の難易度が上がります
– 派生開発元の各種仕様書
– スペックアウト資料 変更箇...
慌てポイント4:情報が足りません!
©Akira Ikeda 21
実装/
机上テスト
コンポーネント
テスト
統合テスト
システムテスト
変更設計要求仕様
定義・設計
受け入れテスト
TM
変更設計書
既存テスト
ベース等
既存テスト
ウェア...
まとめ・議論
いかがでしたか?
最後にこのセッションを簡単にまとめます。
©Akira Ikeda 22
かなり困った現実の話をしました
©Akira Ikeda 23
清水様の講義や書籍で,
「本来どうあるべきか」を学ぶことは当たり前です
ただ,様々な状況下で,いびつとわかりつつも当座をしのぐために
いびつな対応しなければならない状況はあります(...
ディスカッションしよう!
本来どうすべき?
~抜本的に改善するために必要なこと
©Akira Ikeda 24
慌てポイント2で示した
そもそも「V字モデル」でいいのか
という疑問から,「本来XDDPでのテストとは?」を議論します
• 先ほどは...
Thank you!
お疲れ様でした
現実と理想,それぞれに何か一つでもヒントを得ていた
だき,派生開発を極めて開発をハッピーにしましょう!
(継続の議論については,懇親会でも!)
©Akira Ikeda 25
Upcoming SlideShare
Loading in …5
×

「長崎SWQuality&DevelopmentGathering2015」V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために

2,752 views

Published on

2015年8月12日開催の「長崎 SWQuality & Development Gathering 2015」のでの資料。
http://kokucheese.com/event/index/307158/

Published in: Technology
  • Be the first to comment

「長崎SWQuality&DevelopmentGathering2015」V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために

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

×