MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST'14東京(3)

 ソフトウェアテストシンポジウム'14東京の続きです。前回は、「テスト設計コンテスト'14 決勝大会前半(Shelly/ZUNDA/MKE98/FUSION)」の話でしたが、今回は「テスト設計コンテスト'14 決勝大会」後半(らくてす/TFC KA・RI・YA/ちょび)です。

 再度紹介しますが、特定非営利活動法人(NPO法人) ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)の公式サイトにテスト設計コンテストの資料が公開されていますので、参照下さい。

らくてす

方針

・工程定義

 Test.SSFの統合テストを想定
→テストベースから判断

業界標準

 ISO25010をベースにした。

仕様書の情報に閉じない

 仕様書に明記されていない情報を極力推測して補完

・成果物間のトレーサビリティをしっかりとる

仕様分析

・ふるまいを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を問題解決の道具として使えるようにならないと私自身としては学習面/適用面で難しいかなと思いました。

ちょび

コンセプト

・ユーザを意識
・現場で実践
・テスト上流から追って見通しを良くする
・リスクは別工程で実施

ステークホルダ分析

利用者以外

 SW品質特性

利用者

 利用時の品質特性

構造/データ/状態/イベント分析

・クラス図

 辞書的な役割

・状態遷移

 仕様の漏れを見つけた

リスク分析

・SWに関するリスクを分析

 利用者
 利用者以外

流れ

1.進め方

・狩野モデル
 当たり前品質
 無関心品質
 魅力品質

2.テスト全体の整理

・最上流のテストアーキテクチャ設計
 当たり前品質← 一元品質 →魅力品質

3.詳細なアーキテクチャ設計

・アクションリスト
 部品/ユースケース/状態

4.詳細なアーキテクチャ設計(2)

スープカレー
 交点:テスト観点
 縦軸:アクションリスト
 横軸:ステークホルダ分析/リスク分析

5.時間

 統合テストで実施するタイミングなど

工夫点

(1)CFDで人とシステムの関連が見通せた
(2)アクションリストを作って仕様を再構成した
(3)テストアーキテクチャマップを作って、全体を俯瞰
(4)シナリオの組み合わせをPictMasterで網羅的に仕様

[所感]

 これまで積み上げた実績をブラッシュアップされている印象がありました。また、狩野モデルを参考されたとのことですが、どのような効果があったか、さらに聞いてみたいと思いました。

講評

テストアーキテクチャ設計のレベルが高いチームが高得点

・どうしてそう分けたのか?

 それは、何がうれしいのか?

・ただ○○技法を使っているチームは、予選落ちしている。

 設計意図が説明できることがポイント


 次回は、クロージングパネル「テストエンジニアの育成による組織力・チーム力の向上 ~現場が幸せになる育成とは?また、エンジニア自身が成長するためには〜」です。