Más contenido relacionado
「長崎SWQuality&DevelopmentGathering2015」V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために
- 4. 自己紹介
4
• 名前:池田 暁(いけだ あきら)
• 所属:某製造業
ソフトウェア開発技術導入支援部門
• 職歴:入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、
現在は設計/テストツールの導入や、プロセス改善に関するコンサル
ティングなど。
• 社外活動
– 委員等
• 長崎IT技術者会 代表
• NPO法人ASTER(ソフトウェアテスト技術振興協会) 理事
• 日科技連SQiP運営委員会 運営委員
• 派生開発推進協議会(AFFORDD) 運営委員
• JaSST(ソフトウェアテストシンポジウム) 実行委員
• 日科技連・日本品質管理学会共同部会 SQuBOK策定部会 策定メンバ
• 日本品質管理学会・ACM 正会員
– 執筆活動(単行本)
• ISTQBシラバス準拠 ソフトウェアテストの基礎、センゲージラーニング、2008
• ソフトウェアテスト入門 押さえておきたい<<要点・重点>>、技術評論社、2008
• ソフトウェア品質知識体系ガイド―SQuBOK Guide、オーム社、2007
• マインドマップから始めるソフトウェアテスト、技術評論社、2007
- 6. XDDPにおけるテスト
• XDDPとは派生開発に特化した開発手法
– 変更・差分に注目して,新規開発プロセスと変更開発プロセスを
わける
– 変更要求仕様書+TM+変更設計書の通称3点セットが特徴的
• 詳しくは先ほどのSQuBOK読破会様の発表内容を参照下さい
©Akira Ikeda 6
• 実は,XDDPの本では,テストについてはあまり触れられ
ていない(テストに入る前に極限までバグの作り込みを減ら
す手法であるため)
• なので,何も考えていないと,テスト工程で混乱を招きやす
い(想定していないので当たり前であるが・・・)
XDDPでの開発の場合
対応したテストのプロセスもまた開発しておく必要があるが,
現実的にはそうなっていない!
(XDDPを採用しつつも,無理矢理V字モデルに取り込もうとするアプローチが多い多い状況からも明らか)
- 15. 慌てポイント2:どこへインプット?
• 新規開発ではドキュメント段階的詳細化されているた
め,テストレベルへのインプットが対応づけやすいが
,変更要求仕様書ではどのインプットになるのかわか
らない!
©Akira Ikeda 15
基本設計
構造設計
詳細設計
実装/机上テスト
コンポーネント
テスト
統合テスト
システムテスト
要件定義 受け入れテスト
システム仕
様書等…
構造仕様書
等…
詳細仕様書
等…
要件定義書
等…
実装/机上テスト
コンポーネント
テスト
統合テスト
システムテスト
変更設計要求仕様
定義・設計
受け入れテスト
TM
変更設計書
変更要求仕
様書
その他
設
計
レ
ベ
ル
と
テ
ス
ト
レ
ベ
ル
が
対
応
関
係
に
あ
る
の
で
ド
キ
ュ
メ
ン
ト
の
出
入
力
関
係
も
明
確
ド
キ
ュ
メ
ン
ト
も
異
な
る
し
,
対
応
関
係
も
不
明
無
理
矢
理
社
内
規
格
と
マ
ッ
チ
さ
せ
よ
う
と
し
て
プ
ロ
セ
ス
が
壊
れ
る
,
現
場
が
混
乱
す
る
(
新
規
開
発
プ
ロ
セ
ス
で
あ
る
V
モ
デ
ル
に
X
D
D
P
を
い
び
つ
に
取
り
込
む
,
そ
も
そ
も
誤
っ
た
ア
プ
ロ
ー
チ
)
?
- 18. 慌てポイント3:どこのテストレベル?
©Akira Ikeda 18
• まずは変更要求仕様書記述内容をざっくり仕分けよう
– 要求はシステムテスト
– 仕様は統合テスト(機能テスト)
• そのうえで,違和感があるところを個別に判断しよう
まずは,目付をできるように
しないと話が始まらないです
テンプレートにテストレベル対応
のためのルールを定めておくと,
テスト側で読み解きやすくなりま
す
テスト担当者側は,どうやったら
テストをしやすくなるか,テンプ
レートにフィードバックする必要
があります
ひとまず
システムテスト
に振り分け
ひとまず
統合(機能)テスト
に振り分け
※CQ出版サイト掲載「LED キューブ装置 ソフトウェア要求仕様書(USDM版)」 から引用
http://www.cqpub.co.jp/interface/download/contents.htm
- 20. 慌てポイント4:情報が足りません!
©Akira Ikeda 20
• 変更要求仕様書は変更・差分に集中したテストベースです
• 最低限以下の2つがないとテスト分析の難易度が上がります
– 派生開発元の各種仕様書
– スペックアウト資料 変更箇所・差分箇所をより深く
理解するためには周辺の仕様も
理解する必要があります
また,変更箇所だけではなく,その
周辺や関係する関数・機能やモジュ
ールもテストする必要があります
加えて機能縮退や非機能低下に関す
る欠陥を摘出するために全体に対す
るテストが欠かせません
必ず,既存ドキュメントをテストベ
ースとして押さえておきましょう!
システム仕
様書等…
構造仕様書
等…
詳細仕様書
等…
+ソフト全体が記述された仕様書
仕様の調査資料であるスペックアウト資料
変更要求仕様
※当然,今回あげたもの以外に必要と思われる
テストベースもインプットとしましょう