　前回は、「TFC KA・RI・YA(東海代表)」「MKE98(東海代表、審査員推薦)」の2チームをまとめましたが、今回は「FUSION(関西代表)」「らくてす(東京代表)」の2チームです。

＜Fusion＞

テスト観点を目的別に作成

　切り口で分けた

機能抽出

　仕様書の項目にせず、CPUで分けた

テスト観点マインドマップ

　品質特性を切り口とした

　　観点を汎用化して洗い出した

機能分析一覧表

　いつ/どこで/何を/誰が/なぜ/誰に/どのように/どれくらいでテストを実施するか、目的を確認する。

テストタイプ整理

　テストタイプの優先順位決めするため

Q&A

Q1:用語の定義は？

A1:プロセス定義。テスト観点の定義は無いが、メンバー間で共有した。共有する方法として、1人が書いたものからすりあわせした。

Q2:テストプロセスはいつ決めた？

A2:最初に決めた。後付けではない。

Q3:テストタイプ整理で、「単機能テスト」→「機能間連携テスト」→「異常系テスト」→「セキュリティテスト」→「非機能要件テスト」と優先順位付けしたが、どのような決め方をしたか？

A3:順位を決めるのは難しいと思う。「異常系テスト」→「セキュリティテスト」→「非機能要件テスト」の優先順位付けは、経験ベースで検討した。もしかしたら、優先順位は同順で考えてもよかったと思う。

Q4:テストアーキテクチャのようなものが無いと言っていたが、「MKE98」や「TFC KA・RI・YA」の方法をやっていたら、どこが楽になる？

A4:要求と機能関係整理が楽になると思う。

Q5:仕様フィードバックシートの活用場面は？

A5:今回の開発で設計にフィードバックすることを想定した。

Q6:仕様フィードバックシートの指摘傾向は？

A6:仕様の抜けの指摘が多い傾向があった。

所感

　各メンバーが異なる開発現場のため、用語などの認識を合わせるのを苦労されたそうですが、上手くすりあわせできた事例だと思いました。以前、JaSST'14東京(2)に書いたとき、成果物がやや抽象的だなと思いましたが、出場チームの方の話を聞いて経緯を理解すると、成果物の理解が進みました。コンテキストを踏まえて成果物を見ると、自分の現場で使えそうなアイディアが浮かぶのではと思いました。

＜らくてす＞

CPM法(※1,※2,※3)から脱却したい

　マインドマップの第1階層：機能分割するか否かを決めるノウハウ蓄積

※1: 電気通信大学西研究室ホームページ掲載資料「テスト観点に基づくテスト開発方法論VSTePの概要」8枚目スライド
 ※2: しんすく(@snsk)氏のBlog >& STDOUT 「詳解コピー＆ペースト＆モディファイ法」
※3: @kz_suzuki氏のblog ソフトウェアの品質を学びまくる「コピー&ペースト&モディファイ法」の第二の側面

前提

統合テスト
業界標準にした理由：オレオレで決めず、メンバーで共有できるようにしたいため。
成果物のベースは、Word。必要に応じてExcelも。

テスト要求分析

　最初は、ステークホルダ分析を実施

(1)クラス図

　継承やhas-a関係の概念を整理。

(2)シーケンス図

　振る舞いを整理。なお、メッセージは、仮定した。

(3)テストレベル

　LV1：機能

　LV2：アクション(どちらかというと、アクティビティ)

　商品購入/保守担当/センサ

(4)品質特性

(5)テスト観点

　事前条件、事後条件

テストアーキテクチャ設計

(1)機能とアクション間の整理

　重複するテストケースを何とか解決したい。

(2)テストの包含関係と順番を検討

　因子が被るのを防止。

(3)リスク分析

　テスト要求から、リスク事象を検討。

(4)機能とアクションの関係を示した

　テスト十分性を与える指針。

テスト実行

　指針だけ決めた

Q&A

Q1:ステークホルダ分析を終わらせる基準は？

A1:SIerの場合、客先とシステムのスコープを決める。

Q2:機能とアクションのアクションは？

A2:商品購入者が起点でアクションなので、実体は機能でのテスト

Q3:シーケンス図を書いた理由は？

A3:起点は、人とセンサー。物の流れから、仕様を見える化。仕様を理解するためのもの。シナリオに沿って分割。

Q4:シーケンス図で、偽造判定や金額情報の受け取りは仕様書に無いけど、どう扱ったか？

A4:分かる範囲内で洗い出した。もしかしたら、非機能であるかもしれないが...

Q4':TFCやMKE98では、どう扱ったか？

A4':偽札か否かの判定で水準を分けた程度

所感

　テスト対象をクラス図やシーケンス図、状態遷移図で表現して整理されたということで、他メンバーとレビューやテスト仕様を検討するときに共通認識しやすいと思いました。また、テスト要求分析におけるUMLの活用例として参考になることが多いと思いますので、自分の現場でも試行してみようと思います。

最後に

　出場チーム及び参加者の話から、分析のアプローチが組み込み系とエンタープライズ系で傾向があることに気付いた。私は、組み込み系開発の領域で業務遂行しているが、エンタープライズ系開発を十分に理解していなかったため、分析のアプローチが組み込み系と違うのは何故か、興味がありました。

　アプローチとしては、

組み込み系：センサから考える
エンタープライズ系：人や業務から考える

であり、それぞれのアプローチで考えると新たな気付きが出て、設計者に仕様の不備をフィードバックして改善したり、テスト実施の時間効率の改善ができるのではと思います。

　また、現場の工夫が成果物に凝縮されていますので、工夫の足跡から問題の捉え方や問題解決に必要な技術や考えを学び、自分の現場での問題(課題)を少しでも解決できるように進めていこうと思います。