JaSST'14東京(3)
ソフトウェアテストシンポジウム'14東京の続きです。前回は、「テスト設計コンテスト'14 決勝大会前半(Shelly/ZUNDA/MKE98/FUSION)」の話でしたが、今回は「テスト設計コンテスト'14 決勝大会」後半(らくてす/TFC KA・RI・YA/ちょび)です。
再度紹介しますが、特定非営利活動法人(NPO法人) ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)の公式サイトにテスト設計コンテストの資料が公開されていますので、参照下さい。
らくてす
仕様分析
・ふるまいをUMLで表現
クラス図とシーケンス図
テストレベル
・シーケンス図で決めた
LV1:機能
LV2:アクション
テスト目的を品質特性でまとめた
・○○性
テスト対象の決定
センサ
・テストLV2
テスト観点
・5W2Hをベース
テスト要求
・テストレベルと品質特性のマトリクス
テストアーキテクト
テスト要求間の関係整理
・因子(機能、アクション)を整理
リスク分析
・テスト優先度
テスト対象(LV1) ← 関連 → テスト目的 + リスクを考慮したテスト優先度
・デジションテーブル
・テスト詳細設計
(1)機能テスト:状態遷移テスト+デジションテーブル
→機能のライフサイクルを考慮した
(2)非機能テスト:テスト要求ごとにテスト観点に基づいて作成
テスト実装
・テストアーキテクチャに基づいて実行順序を整理した
テストレベル、タイプ、リスクによる優先度
[所感]
工程定義としてTest.SSF、業界標準に準拠したプロセスとしてJIS X 25010を用いて説明されていたため、他社との共通認識しやすいと思いました。また、タスクを分解しており、「何を」実施するのか明瞭だなと感じました。
TFC KA・RI・YA
方針
・ぐちゃぐちゃなテストベースをきれいに
・巨大マトリクスは×
・関連がわからないのは×
実践
ぐちゃぐちゃなテストベースから必要な情報を下記で整理
(1)USDM
機能仕様を整理
(2)DFD
機能間の関連を整理
(3)HW部品を整理
H/W構成図
USDM+DFD→テストアイテムを割り当てる
非機能観点+機能軸のテストアイテム
[所感]
メンバーの共通の悩みである「ぐちゃぐちゃなテストベース」「巨大マトリクス」を先行研究及びメンバーが普段適用している技術を用いて、問題を分割して解決されていると思いました。USDMで機能仕様を整理されましたが、USDMを問題解決の道具として使えるようにならないと私自身としては学習面/適用面で難しいかなと思いました。
ちょび
コンセプト
・ユーザを意識
・現場で実践
・テスト上流から追って見通しを良くする
・リスクは別工程で実施
流れ
1.進め方
・狩野モデル
当たり前品質
無関心品質
魅力品質
2.テスト全体の整理
・最上流のテストアーキテクチャ設計
当たり前品質← 一元品質 →魅力品質
5.時間
統合テストで実施するタイミングなど
工夫点
(1)CFDで人とシステムの関連が見通せた
(2)アクションリストを作って仕様を再構成した
(3)テストアーキテクチャマップを作って、全体を俯瞰
(4)シナリオの組み合わせをPictMasterで網羅的に仕様
[所感]
これまで積み上げた実績をブラッシュアップされている印象がありました。また、狩野モデルを参考されたとのことですが、どのような効果があったか、さらに聞いてみたいと思いました。