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

MasaoApril's Library.

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

JaSST'14東京(2)

 ソフトウェアテストシンポジウム'14東京の続きです。前回は、「探索的テストを活用したシステム開発手法の提案」の話でしたが、今回は「テスト設計コンテスト'14 決勝大会」前半(Shelly/ZUNDA/MKE98/FUSION)です。

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

Shelly

コンセプト

 「思いやりのテストづくり」

テスト要求分析

アクティビティ

 プロダクト視点、プロジェクト視点での解釈

入力

 顧客要求、市場ニーズなど

テスター関係表

・縦軸
 テスト対象に関わる全ての人(各役割の担当者)
・横軸
 テストチームの人

テスト要求→テストアーキテクチャ方針を決定

 思考の視点/作成の視点/実行の視点

テスト分析アーキテクチャ

 6W2H/目的機能/目的機能に必要な機能的要素/機能のタイプ/...

テスト仕様アーキテクチャ

(1)テスト目的
 テストカテゴリ/検証内容/テストタイプなど
(2)テストの厚み
 テスト技法/影響度/発生可能性など

テストマッピングアーキテクチャ

・縦軸
 機能の役目
・横軸
 テストの内容

[所感]

 テスター関係表で各々の立ち位置のテスト対象に対する要求を整理した点は、「何のためにテストを実施するのか?」という目的が明確になり、「どのようにテストを実施すればよいか?」ということを検討する一助になると思いました。また、テストマッピングアーキテクチャで「何をどのようにテストを実施するのか」見通しが立てやすいと思いました。

ZUNDA

工夫したところ

コンセプト

(1)「実業務を意識したテスト設計」
(2)QCDを考慮

テスト設計までの流れ

・要求仕様
 USDMに近い
・ユーザ分析
・リスク分析
・前回優勝チームTETTANのテストの3層を試行
 自分たちで試行したが、合わなかったので使わなかった。
・不具合分析
 自分たちのシチュエーション
・インセンプションデッキ

工夫点

(1)開発を意識したテスト設計

・地方はテスター専任がいない
・開発者がどうテストをやるのか?
 開発フェーズと立ち位置を決めた。
→「できること」と「できないこと」が明確になる
・背景を設定した
・新規事業
 レンタルでなく、個人オーナーへの販売
・W字モデル
 機能仕様書ユースケース仕様書が提出された時点

(2)インセプションデッキ

・自分たちの立ち位置を明確にするため
 我々はなぜここにいる?
・やらないことリストを作る
 HWテスト

(3)開発初期と同様に分析モデルを作成

・クラス図のようなもの
 本来、開発者の分析モデルを照らし合わせる必要がある
・色分けしてテスト対象を決めている
 赤:対象外、黄:対象

(4)ユーザ分析に因子と水準の考え方を用いた

 不特定多数のユーザがいるので、ペルソナ分析は使わなかった

(5)ペットボトルとテストを楽にするビジネス提案

[所感]

 実業務を意識したこと、地方の開発現場の状況(テスト専任者がいない)を踏まえ、開発メンバーで「何をどのようにテスト実施すればよいか?」を検証するため、設計にどのようにフィードバックして製品品質をブラッシュアップするか検討していると思いました。テスト専任者が設計にフィードバックするための情報は何かを考えるきっかけになると思います。

MKE98

テスト工程のプロセスをPFDで表現

めざしたこと

 テスト観点の漏れを防ぐ

自力(がんばり)で気付くテスト観点に限界

顧客目的

・6W2H分析
 Why(目的)
 How(どのように)を主にテスト観点として抽出
・品質特性
 ISO9126
・過去不具合
 市場の自販機の不具合を調査
→人のいたずらといったアクティブノイズ
・システムの知識
 類似システム:ECU(Engine Control Unit)
・テスト観点一覧の作成

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

・システムの課題
 複数のCPUで統合してテストすると、バグ分析が大変。
・工夫
(1)CPUが補う機能をドライバ層→アプリ層→マネージャ層の順番でテスト
 下位層(ドライバ層)からテスト
(2)テストタイプBOX
 紙1枚で表現
(3)テスト要求一覧
 表で目的を明確化

[所感]

 「テスト実施漏れを防ぎたい」という問題点から、メンバーの知見を結集させて層として整理し、どの順序でテストを進めて小さな単位から不具合を検出していく道筋が明確だなと思いました。恐らくですが、前工程/後工程を日頃から意識されている点が成果物に出ていると思いました。

FUSION

実業務に適用できるテスト設計を構築

工夫

 PFD/マインドマップ
→要求-機能トレーサビリティマトリクス(TM)表の莫大化防止

テストアーキテクチャ(テストタイプ )

 TM、テストマップ、テスト対象外(単体テストなど)をテストタイプ一覧表にまとめた

テスト全体のプロセス(PFD)
テスト要件定義(機能抽出)

(1)機能抽出
 機能マインドマップ
(2)CPU間のDFD

[所感]

 メンバー全員が違う企業ということで、各自のコンテキストを合わせるため多少抽象的な印象があり、工夫するに至った経緯が明確になると、「目的」~「手段」の繋がりが見えてくると、工夫した点がさらに明確になると思いました。



次回は、「テスト設計コンテスト'14 決勝大会」後半(らくてす/TFC KA・RI・YA/ちょび)です。

お知らせ

 テスト設計コンテスト出場チームの有志で「勝手にテスコン'14大反省会(@愛知)」を企画されるようです。企画目的は、「テスト設計とは?」「テストアーキテクトとは?」といった疑問に対し、みんなで議論されるとのこと。

 テスト設計やテストアーキテクトについて興味や議論したい方は、下記URLから申込下さい。

http://kokucheese.com/event/index/158087/