先月、「勝手にテスコン'14大反省会(＠愛知)」に参加しました。

本企画に参加した「TFC KA・RI・YA(東海代表)」「MKE98(東海代表、審査員推薦)」「FUSION(関西代表)」「らくてす(東京代表)」の発表内容についてまとめました。

今回は、「TFC KA・RI・YA(東海代表)」「MKE98(東海代表、審査員推薦)」の2チームです。

はじめに

以前書いた、JaSST'14東京(2)やJaSST'14東京(3)と内容が重複する部分がありますが、今回は参加者からの質問に答える形で出場チームへ質問する機会がありましたので、参考になれば幸いです。

なお、私が誤解しているところもあると思いますので、ご指摘頂ければ幸いです。

＜TFC KA・RI・YA＞

問題点

・テストベースがカオス

・巨大マトリクス

・どこからテスト？

必要な情報をどう取り出す？

・巨大マトリクス

　分割する

・関連が分からない

　分割→関連を見える化

テストベース

下記3点で整理

(1)USDM

(2)DFD

(3)ハードウェア構成図

非機能

・品質特性

どれを実施するか評価するため、ポジションマップ

　軸：「視点」と「可変性」

新しいプロセス

・リスクを抽出

　ピンポイントテスト

3つの重要な観点

(1)誰のため？

(2)どうなってほしいか？

(3)聴いてもらうには？

機能

(1)設計～実行の分担を容易にする

(2)テストケースの単純化

　DFDで機能を分割→振る舞いの切れ目

(3)重複したテストケースの抑止

依存関係

非機能

(1)重要性や優先度付け

(2)ポジショニングマップを利用した理由

　ベースとして議論するため。いるいらないの判定。

(3)依存関係

　システムのレスポンスが分からないからここで検討した

Q&A

Q1:ピンポイント(テスト観点)の抽出は？

A1:方法論がないため、Q&Aで確認している。リスクは、無知見から。

Q2:DFDの機能分割。抽象度の設定の単位は？

A2:メンバーでの合意はとれていなかったが、ユースケース 仕様書から読み取った。段階的DFD。

Q3:非機能テストのやるやらないの評価は？

A3:副特性ごとにリスクを決めている

Q4:ユースケースの全体感は？

A4:データ or 制御をDFDで把握。

Q5:ユースケースの初めと終わりは？

A5:人系とセンサー系。ユーザーから始まりユーザーで終わる。

Q6:簡単に説明すると、どんな階層で切るか？

A6:機能分割。

Q7:なぜ、USDM？

A7:メンバーのスキルセットで適用しているメンバーがいるので、利用した。

所感

メンバーのスキルセットで、得意なところと問題解決を結びつけたところが印象的でした。また、理解しやすい単位に分割したり、流れを考えたりすることで、発生しうるリスク(不具合による開発進捗の遅れ)が特定しやすいと思いました。

＜MKE98＞

成果物(地域予選直後)

　テストケースの構造を十分検討できていないため、決勝戦までの課題となった。

狙い

・テスト実施漏れを無くしたい

・テストを効率的に進めたい

テスト観点

・マインドマップを書くと段々巨大になっていく

　不要なものを切ったりする

テスト対象

・各CPUから見ている

テストアーキテクチャ

・機能テストの依存性と必要なテスト(非機能テスト)

　仕様が変更されたときに、「テスト実施対象」「テスト非実施対象」を特定するための材料

レイヤーの位置づけ(イメージ)

(1)マネージメント層

　モジュール

(2)アプリケーション層

　1関数

(3)ドライバ

　1命令

Q&A

Q1:システム構造ベースを先に持ってきた理由は？

A1:テスト視点ではなく、構造化設計。

テストも設計もやる。プロセスは全体を考慮した。

ハードウェア構造や開発体制で、独立したテストチームがいないため、このような形になった。

Q2:テスト観点(アーキテクチャ部分)は？

A2:テスト要求一覧。

Q3:テストの厚みや十分性は？

A3:実際は厚みは薄くしているが、境界値を見る/見ないといった属性はまだ無い。

Q4:ドライバ層は、システムテスト？

A4:その通り。

所感

＜TFC KA・RI・YA＞チームがフラットな繋がり、つまりマクロな世界と捉えましたが、＜MKE98＞は深さの繋がり、つまりミクロな世界と捉えました。

次回は、「FUSION(関西代表)」「らくてす(東京代表)」のまとめです。