O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
池田 暁(長崎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
Próximos SlideShares
Carregando em…5
×

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

2.827 visualizações

Publicada em

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

Publicada em: Tecnologia
  • Seja o primeiro a comentar

「長崎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

×