読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

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

勝手にテスコン'14大反省会(1)

TestDesignContest

先月、「勝手にテスコン'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(関西代表)」「らくてす(東京代表)」のまとめです。