見通しのよいテストの段階的詳細化の手法

Size: px

Start display at page:

Download "見通しのよいテストの段階的詳細化の手法"

ためひとさんきち
5 years ago
Views:

1 ソフトウェアテストシンポジウム 2013 JaSST 13: Japan Symposium on Software Testing 2013 見通しのよいテストの段階的詳細化の手法 - テストの網羅性確保の提案 - 吉岡克浩水野昇幸西康晴三菱電機株式会社設計システム技術センター兵庫県尼崎市塚口本町三菱電機株式会社通信機製作所兵庫県尼崎市塚口本町電気通信大学情報理工学研究科東京都調布市調布ヶ丘 Yoshioka.Katsuhiro@ab.MitsubishiElectric.co.jp Mizuno.Noriyuki@ah.MitsubishiElectric.co.jp あらまし段階的にテストを詳細化するテスト開発プロセスを構築したテストの網羅性向上のためにマトリクス形式を導入したがテストケースのばらつきや成果物が巨大化し作業性が悪化する課題があったそこでモデル化したとの組合せでテストアーキテクチャを決定し組合せ毎にテストを詳細化する手法を作成した手法の適用によりテスト密度向上と作業効率化を両立しテストケースのばらつきを抑制したキーワードテストアーキテクチャテスト観点マトリクスデシジョンテーブル Test Design by Stepwise Refinement -Approach to Test Coverage Improvement- Katsuhiro Yoshioka Noriyuki Mizuno Yasuharu Nishi Design Engineering Center, Mitsubishi Electric, Ltd., Communication Network Center, Mitsubishi Electric, Ltd., Department of Informatics,University of Electro-Communications Yoshioka.Katsuhiro@ab.MitsubishiElectric.co.jp Mizuno.Noriyuki@ah.MitsubishiElectric.co.jp Abstract We were established to refine the contents of the test in a stepwise manner "Test Development Process." By applying this process, the test design work can be done by dividing the unit of test context, we have improved the deterioration of working with the large test matrix for the conventional process. And we have improved both efficiency of test design and test density. Keyword Test Architecture, Test Item, Test Context, Test Viewpoint, Test Matrix, Decision Table 1. はじめに情報家電自動車産業機器などの工業製品のほとんどは機能や性能の多くを機器に組み込まれたソフトウェアで実現している市場競争の激化に伴う製品の高機能化により組込みソフトウェアはより大規模で複雑なものとなってきている一方で製品投入間隔の短縮により開発期間は短縮してきているこのような状況で弊社は納期遅延コスト超過によるプロジェクト崩れを抑制しつつ市場に高品質な製品を提供するために設計段階で品質作り込みを行う活動とテストの改善を推進してきた 1.1. 従来のテスト設計手法の課題従来のシステムテスト設計は仕様書から直接テスト手順書を作成しレビューでテストケースの妥当性を確認する作業であった ( 第 1 世代 ) テスト手順書は階層化 ( 主に大中小 ) した機能に対しテスト手順期待値を記述したものであり以下のような課題があった (1) テストケースの作成基準網羅基準がなくテストケースの粒度記載レベルのばらつきがでる (2) テストケースの羅列からは全体像が見えず何を網羅できているか分からないためレビューで漏れを検出できない (3) テストケースの数が多く限られた時間でレビューしきれないこれらの課題に対しテスト手順書作成の前に機能 ( 行 )xテスト観点( 列 ) のマトリクスでテストケースの洗い出し抜け漏れのチェックを行うゆもつよメソッド [1] を参考にした手法を導入した ( 第 2 世代 ) マトリクス手法の導入により大きなテスト観点の抜け漏れを抑制することはできたが新たな課題も見つかった本論文ではそれらの課題を明らかにし課題への対策 ( 第 3 世代 ) について記述する

2 テスト設計手法課題 < 第 1 世代 > 作成基準が無くテストケース大中小の階層でテストがばらつくレビューで漏れ検項目を整理する出が困難限られた時間内でのレビューが難しい < 第 2 世代 > 2 章記載の課題が発生マトリクス手法の導入第 3 世代の手法 : 見通しの良いテストの段階的詳細化へ大中小項目整理テスト項目大項目中項目小項目タイマタイマ操作設定リセット ( 機能等 ) 図 1 テスト設計手法の変遷マトリクス手法テストで確認する性質 XX XX XX 2. マトリクス手法 ( 第 2 世代 ) 導入後の課題 2.1. 巨大なマトリクスになり作業性が悪いある工事に適用した結果では階層化した機能 :200 行 xテスト観点 :15 列の巨大マトリクスとなったその結果全体を俯瞰することが困難となりレビューや作業分担がし辛い状況となった 2.2. テスト観点の定義が不十分初期に導入したマトリクスでは標準のテスト観点とその説明文書を定義して展開したがドメイン共通で使用する狙いとしたためテスト観点の抽象度が高く作業担当者により解釈が異なる場合があり抽出結果にばらつきが出たまた記載の詳細度が個人任せであったため詳細に記載してテスト手順書と内容が重複したり逆に一部のキーワードのみの記載で中身が良く分からない資料になってしまうケースがあった 2.3. マトリクス作成後の作業が不明確マトリクスは仕様書からテストのポイントを抽出する作業に使用しテストケース作成のインプットとなる資料であるがテストケースに落とすまでに組合せやテスト準備手順を追加する方法は個人任せであったためテストケースの記載内容粒度が一定でなかった 3. 課題に対する対策 3.1. 課題の対策方針これら3つの課題に対し以下の対策方針を立てて解決に取り組んだ課題 1 巨大なマトリクスになり作業性が悪い 2 テスト観点の定義が不十分 3 マトリクス作成後の作業が不明確表 1 課題の対策方針対策方針マトリクスを見通しのよいサイズに分割するテスト観点を具体化するマトリクスからテストケースに落とす作業を具体化する対策 3.2 項に記載 3.3 項に記載 3.4 項に記載 3.2. とによるテスト全体の分割 (1) テストの全体を考えるにはテストの対象と非対象を明確にする必要があったマトリクス手法で扱っていた機能もその1つであるが実際にシステムテストで扱っていた対象はユースケース実運用シナリオシステム全体といった粒度の大きなものもあるこれらの例を表 2に示すシステムテストで扱うはインプット資料に記載があるものがベースであり客先 RFP システム要求仕様書からはユースケースや実運用シナリオに似た粒度の情報が抽出でき機能仕様書からは機能を抽出できることが多いしかしインプット資料の質量は客先プロジェクトごとに一様ではなくテスト設計時にすべてが開示されていないケースもあるそのためとして必要であれば上位仕様書作成者に提示を求めたりテスト設計者自らユースケース一覧や運用を想定したシナリオを作成するはプロジェクトによって要不要や重み付けを判断するだけでなく新しい項目を追加するといったテーラリングを可能としている表 2 の例概要 1 機能 S/W 要求仕様書の機能 2 ユースケース S/W 要求仕様書のユースケース ( 複数機能の連携 ) 3 実運用シナリオ運用で想定されるまとまった作業 ( 複数機能ユースケースの連携 ) 4 システム全体システム全体としての動作 5 利用シーン網羅的な条件で検証したい特定の状況 6 データデータ保守システム移行時の対象 7 プロトコルシーケンス信号 ( シーケンス信号 ) 8 状態状態定義状態遷移 (2) はテストで保証すべき性質の分類であり本手法ではテスト観点の上位に位置するテストの狙いを示すものである表 3にの例を示す手法の確立においてはの漏れ= 手法によるテスト漏れに繋がるための議論に時間をかけたに挙げた項目はマトリクス手法で用いていた項目をベースに不具合事例からシステムテストで検出すべき不具合を狙うを追加していった

3 カテゴリ品質特性表 3 の定義狙う不具合 1 論理性仕様不適合の動作仕様通りの結果にならない条件通りに動作が変化しない条件の裏 (else) で不正な動作をする 2 ユーザビリティ仕様不適合のユーザビリティ使いにくいUI ユーザ操作時のレスポンスが悪い表示の一貫性がない 3 性能仕様不適合の性能速度性能未達リソースの枯渇 4 保守性仕様不適合の保守性解析しにくいログ膨大な量のログ短時間で消えるログ更新しにくいマスタ更新時間がかかる装置交換が困難 5 信頼性オーバースペックな条件で発生する不具合 6 移行仕様不適合のデータ移行性旧バージョン別環境からのデータ移行が困難データの追加変更削除が困難依存性 7 組合せ仕様上影響がないはずの機能データ状態の組合せによる不具合 ( 直交表 HAYST 法の適用範囲 ) 8 環境 H/W 対向装置気温地域性など環境構成を変更して発生する不具合仕様不適合のもの ( 環境の違いに実装で対応しているもの ) 仕様上影響がないはずのもの非ロバスト 9 通常負荷通常負荷での動作不具合速度性能未達ロバスト性 10 意地悪意地悪操作による動作不具合ボタン連打同時押し同時実行回線切断などによる想定外の不具合 11 設計最大負荷設計最大負荷での動作不具合負荷に耐えられず動作が中断想定以上の性能劣化 12 過負荷過負荷での動作不具合リソース枯渇によるクラッシュ無応答フェールセーフ機能の動作不具合 13 連続運転連続運転での動作不具合想定以上のメモリ使用リソース使用性能劣化 (3) との組合せにを組合せることでどので何の性質を保証するテストをするというテストの構成を示す本手法ではこの組合せ表をテスト設計サマリ表と呼びその構成要素である1つ 1つの組合せをフレームと呼ぶ表 4はテスト設計サマリ表の例であるこの表は組合せをの有無で表示する単純な表であり全体を容易に俯瞰することができるテスト設計サマリ表で示す内容はテストの専門家でなくとも短時間の説明で理解可能であるそのためシステム設計者 S/W 設計者など関係者を交えてテストの範囲を議論して合意するツールとして適している表 4 テスト設計サマリ表の例品質特性論理性ユーザビリティ性能保守性 1 機能 2 ユースケース実運用シナリオ 3 フレームテスト観点の具体化と因子の抽出テスト構成が決定したら次は具体的にインプット仕様書から入力値イベントなどのテスト条件と振る舞い判定基準などのチェックポイントを抽出するまたテスト条件チェックポイントになり得る仕様書に記載された項目を因子因子の取り得る選択肢を水準と呼ぶ因子と水準の考え方は HAYST 法 [2] を参考にした (1) フレームごとのマトリクス定義従来のマトリクス手法ではテスト条件およびチェックポイントの抽出結果を1つ巨大マトリクスに記載していた本手法では作業者の分担やレビューをしやすくするためにフレームごとにマトリクステンプレートを分割して定義した表 5はフレームごとのマトリクステンプレートの対応イメージである表 5 フレーム毎のマトリクステンプレート NO テスト対象 ID 1.1 機能論理性環境 L E F-L-E 1.2 F 性能設計最大 P 負荷 ML F-P-ML 2.1 ユース論理性ケース L UC-L 2.2 UC ユーザビリティ U UC-U 2.3 保守性 MA UC-MA 各フレーム単位でテンプレートを用意機能論理性環境テンプレート :F-L-E 機能性能負荷テンプレート :F-P-ML (2) テスト観点マトリクスマトリクステンプレートは行見出しに具体化した列見出しにを具体化したテスト条件チェックポイントを持つ本手法ではこのマトリクスをテスト観点マトリクスと呼ぶ表 6は : 機能 : 論理性環境のテスト観点マトリクスの例である表 6 機能 x 論理性 x 環境のテスト観点マトリクスの例 ( テンプレート :F-L-E) テスト観点番号 F-L-E-01 F-L-E-02 F-L-E-03 F-L-E-04 F-L-E-05 F-L-E-06 F-L-E-07 F-L-E-08 給湯機能機能タイマセット機能タイマリセット機能タイマアラーム機能沸騰機能カルキ抜き機能保温機能列見出し : テスト条件チェックポイントモード設定機能環境環境ポットシリーズ ( ポット A ポット B) ポットシリーズ ( ポットA ポットB) ポットシリーズ ( ポットA) 外気温 ( 低温高温 ) 入力 / 参照値優先度なし水温なしテスト条件論理入力 / 参照状態ロック状態 ( ロック解除 ) 水量 ( 空適量満水超え ) 蓋センサ状態 (ON OFF) 給湯ボタン *1 温度制御状態 ( 保温沸押下騰アイドル ) エラー状態入力イベン中間値中ト間状態 #1 給湯不可能状態 (L1 L2 チェックポイント論理結果値振る舞い事後状態表示コード (L1 L2 給湯 ( 実施 / 非実施 ) 元の状態でエラーコードあること表示 (L1 L2 セルの中身 : テスト条件チェックポイントの因子と水準保温ランプ点灯保温状態なしなしなし保温状態沸騰ランプ消灯水温 ( 高温設定モード ( 高温節約ミルなしなし節約ミルなしなしク ) ク ) 行見出し : 具体化した

4 図 2 テスト条件チェックポイントの詳細化の例テンプレート ( 表 2) 概要 1 機能 S/W 要求仕様書の機能 2 ユースケース S/W 要求仕様書のユースケース ( 複数機能の連携 ) 3 実運用シナリオ運用で想定されるまとまった作業 ( 複数機能ユースケースの連携 ) 4 システム全体システム全体としての動作 5 利用シーン網羅的な条件で検証したい特定の状況 6 データデータ保守システム移行時の対象 7 プロトコルシーケンス信号 ( シーケンス信号 ) 8 状態状態定義状態遷移テンプレート ( 表 3) カテゴリ品質特性狙う不具合 1 論理性仕様不適合の動作仕様通りの結果にならない条件通りに動作が変化しない条件の裏 (else) で不正な動作をする 2 ユーザビリティ仕様不適合のユーザビリティ使いにくいUI ユーザ操作時のレスポンスが悪い表示の一貫性がない 3 性能仕様不適合の性能速度性能未達リソースの枯渇 4 保守性仕様不適合の保守性解析しにくいログ膨大な量のログ短時間で消えるログ更新しにくいマスタ更新時間がかかる装置交換が困難 5 信頼性オーバースペックな条件で発生する不具合 6 移行仕様不適合のデータ移行性旧バージョン別環境からのデータ移行が困難データの追加変更削除が困難依存性 7 組合せ仕様上影響がないはずの機能データ状態の組合せによる不具合 ( 直交表 HAYST 法の適用範囲 ) 8 環境 H/W 対向装置気温地域性など環境構成を変更して発生する不具合仕様不適合のもの ( 環境の違いに実装で対応しているもの ) 仕様上影響がないはずのもの非ロバスト 9 通常負荷通常負荷での動作不具合速度性能未達ロバスト性 10 意地悪意地悪操作による動作不具合ボタン連打同時押し同時実行回線切断などによる想定外の不具合 11 設計最大設計最大負荷での動作不具合負荷に耐えられず動作が中断想負荷定以上の性能劣化 12 過負荷過負荷での動作不具合リソース枯渇によるクラッシュ無応答フェールセーフ機能の動作不具合 13 連続運転連続運転での動作不具合想定以上のメモリ使用リソース使用性能劣化フレーム毎マトリクステンプレート ( 表 5) 機能論理性環境テンプレート :F-L-E 機能性能負荷テンプレート :F-P-ML テンプレート毎のテスト条件チェックポイントはツリー形式で検討 ( 図 2) テンプレートの作成 (SEPG が担当検討実施 ) 1 テンプレートを参考にテスト設計サマリ表を作成テスト目品質特性的ユーザ論理性性能保守性ビリティ機能 1 ユースケース 2 実運用シナリオ 3 2 実施するテスト 4 を定義合意する開発にあわせて担当者が対象をテスト設計サマリ表 ( 表 4) カスタマイズ可能 3 テンプレートを選択活用してテスト観点マトリクス作成担当者が詳細化した対象を記載テスト観点番号 F-L-E-01 F-L-E-02 F-L-E-03 F-L-E-04 F-L-E-05 F-L-E-06 F-L-E-07 F-L-E-08 給湯機能機能タイマセット機能タイマリセット機能タイマアラーム機能沸騰機能カルキ抜き機能保温機能モード設定機能環境環境ポットシリーズ ( ポットA ポットB) ポットシリーズ ( ポットA ポットB) ポットシリーズ ( ポットA) 外気温 ( 低温高温 ) 入力 / 参照値優先度テスト条件論理入力 / 参照状態ロック状態 ( ロック解除 ) 水量 ( 空適量満水超え ) 蓋センサ状態 (ON OFF) *1 温度制御状態 ( 保温沸騰アイドル ) エラー状態入力イベン中間値中ト間状態 #1 給湯不給湯ボタン押可能状態下 (L1 L2 チェックポイント論理結果値振る舞い事後状態表示コード (L1 L2 保温ランプ点なし灯保温状態なしなしなし水温沸騰ランプ消灯水温 ( 高温なし設定モード ( 高温節約ミルク ) なしなしなし節約ミルク ) 給湯 ( 実施 / 非実施 ) 元の状態でエラーコードあること表示 (L1 L2 4 各テスト観点マトリクスに従って因子を抽出するテスト観点マトリクス ( 表 6) 現場担当者の作業保温状態なし図 3 テスト範囲の決定 ~ テストマトリクス作成の流れ ( テンプレートと実作業の関係 ) テスト観点マトリクスのテスト条件チェックポイントの定義はごとに狙う不具合を検出するために何を入力 ( テスト条件 ) として何を確認する ( チェックポイント ) かを作業者に分かりやすく示す必要があるそこで NGT/VSTeP[3] におけるテスト観点抽出方法を参考に論理性テスト性能テストユーザビリティテストといったごとにテスト条件とチェックポイントを有識者で洗い出してマインドマップで整理し枝の関係は何か (has-a/ is-a) 漏れはないかをチェックしたマトリクスの段階で因子をテスト条件チェックポイントに分類することでテストケース作成のインプットとして両方がそろっていることを確認するまたテスト観点マトリクスは因子の抽出に特化し因子の組合せは次の作業で行うこれには抽出作業と組合せ作業で頭の切り替えによる作業効率の低下を防ぎ組合せで数が増える前なので類似パターンの抽出レビューを容易化する狙いがあるテスト観点マトリクス作成までの作業におけるテンプレートと実際の関係を図 3 に記載するテンプレートは SEPG により事前に作成及び準備された状況で担当者はテンプレートを活用しテーラリング検討を行いながらテスト観点マトリクスを作成する

5 3.4. テスト観点マトリクス作成後の作業 (1) テストケースの作成テスト観点マトリクスでテスト条件とチェックポイントの因子を抽出した後は因子毎に同値分割表を用いて具体的な入力値と期待値を決定する次に原因結果グラフデシジョンテーブル等を用いて入力値と期待値の組合せを作成しテストケースとする表 7 はデシジョンテーブルの作成例であるテスト観点マトリクスの1 行のデータが1つのデシジョンテーブルに対応する表 7 デシジョンテーブルの作成例入力条件 #1 #2 #3 #4 #5 #6 #7 1. ロック状態 1 ロック解除 - 2. 水量 1 適量 ( 水位センサ1~4がONの状態 ) 空満水 ( 満水センサがONの状態 ) 蓋センサ 1 ON( 閉じる状態 ) - 2 OFF( 開く状態 ) 状態 1 保温状態沸騰状態アイドル状態期待結果 #1 #2 #3 #4 #5 #6 #7 1. 振る舞い 1 給湯実施給湯非実施 - 2. エラーコード表示 1 L1( ロック中 ) L2( 給湯不可水量 ) L3( 蓋空き ) L4( 給湯不可状態 ) なし (2) テスト手順の作成テストケースにテスト実施における準備作業などのテスト手順を追加しテスト手順書にまとめる ( 表 8) このとき同じ入力条件や事後条件に着目しテスト手順の集約を図る F-L-E-01-#1-01 F-L-E-01-#2-01 給湯ボタン表 8 テスト手順書の作成例テスト項目テスト項目開始状態番号共通手順 -01 共通手順保温状態にするロック状態給湯非実施水量空状態給湯非実施水なしコンセント抜け蓋空き保温状態ロック解除テスト手順 1) ポットに水を適量注ぐ 2) コンセントを挿す 3) 蓋を閉める 4) 沸騰するまで待つ 5) カルキ抜き完了まで待つ 6) 温度が安定 ( 保温温度 ±2 ) するまで待つ 1) 共通手順 -01 を実施する 2) ロックボタンを押してロック状態にする 3) 給湯ボタンを押す保温状態 1) 共通手順 -01を実施するロック解除 2) 水量を空にする 3) 給湯ボタンを押すテスト規格 6) 保温状態であること 2) ロック状態であること 3) 給湯非実施エラーコード表示 L1 備考 3) 給湯非実施水量の変化はデエラーコード表示 L2 バッガで状態変化させる必要ありもしくはポットの蓋を空けずに水量を減らす治具が必要 4. テスト開発プロセスの構築マトリクスを抽出とした一連のテスト作業を現場に適用するためにテスト開発プロセスとしてガイドライン化した図 4にテスト開発プロセスの全体像を示すガイドラインに則って作業を実施することでの組合せからテストケースまで定型作業で段階的にテストを詳細化することができるまたテスト設計サマリ表が示す全体像から段階的に成果物をレビューすることによりポイントが絞れ効率的に漏れ誤りを検出できる 5. 実施結果本論文執筆時点 ( '12/9 月 ) において 2 件の通信 S/W に本手法を適用した適用工事 2 件はテスト実装を終えたところでテスト実施はこれからであるため今回はテスト成果物について組織標準との比較を行い良好な結果を得た ( 表 9) 表 9 手法適用効果 ( 組織標準比 ) (1) テスト密度 ( テストケース数 / 開発量 KL) (2) テスト成果物作成時間 ( 作業時間 / 開発量 KL) (3) テストケース1 件あたりの作成時間 (4) テストケース1 件あたりのレビュー時間工事 1 工事 2 平均 252% 150% 201% 92% 79% 86% 37% 53% 45% 36% 85% 60% (1) テスト密度 ( テストケース数 / 開発量 KL) テスト密度は 2 工事平均で組織標準比で 201% となり増加した (2) テスト成果物作成時間 ( 作業時間 / 開発量 KL) テスト成果物作成時間は組織標準比 86% となり短縮した (3) テストケース1 件あたりの作成時間テストケース作成時間は組織標準比 45% となり大きく短縮した (4) テストケース1 件あたりのレビュー時間テストケースレビュー時間は組織標準比 60% となり短縮した

6 ユーザ論理性ビリティ性能環境機能 UC テスト設計サマリ表によるの組合せと全体の分割検討機能論理性環境機能性能負荷ユースケースユーザビリティ選択フレーム毎テスト観点マトリクスの選択入力条件 #1 #2 テスト条件チェックポイント 1 蓋センサ 1 センサON - 番号機能環境結果値 2 センサOFF - - F-L- 因子 A 因子 X 組合せ 2 給湯ボタン押下時間給湯手順 E-01 ( 水準 ) ( 水準 ) 検討 1 100ms 未満 - - 追加 2 100ms 以上 - 期待結果 #1 #2 1 給湯 1 給湯実施急騰非実施 - テスト観点マトリクスによる因子の抽出因子組合せを検討しデシジョン ( 例 ) 機能論理性環境マトリクステーブル作成手順書へ展開テストケース ( 手順書 ) テスト分析テスト方式設計テスト詳細設計テスト実装図 4 テスト開発プロセス全体像 (5) テストケースの質抽出したテストケースの質を評価するために同一の機能に以前の設計手法と今回の設計手法を適用し結果を比較して論理的な組合せの抜け重複の確認を行った表 10 以前の設計手法と今回の手法の比較機能 1 機能 2 機能 3 合計ケースA: テスト数 ( 以前の設計手法 ) 10 評価 :7 件の抜け 2 評価 :2 件の抜け 20 評価 :3 件の抜け 1 件冗長あり 32 評価 :12 件の抜けケースB: テスト数 ( 今回の設計手法 ) 16 評価 :1 件の抜け 5 評価 :1 件冗長あり 18 評価 : 抜け無し 39 評価 :1 件の抜け表 11 プロセス単位のヒアリング結果対象プロセス / 担当者ヒアリング結果テスト分析全体の俯瞰性が良い関係者で合意を取りながら作業が出来た大きな範囲でテストを行う対象の抜けを見つけることが出来た早期に目標とする品質を考えることが出来たテスト方式設計レビュー観点がシンプル抽出すべき項目が分かりやすく比較的単純で作業に集中できる因子を抜き出すまでが目標となるため作業の終了判断基準が明確だったフレーム単位で担当者を分担することが出来た結果としてマネジメントがやりやすかった全体が見えやすいことから抽象化するポイントを発見しやすくテスト実装 ~ 実施時の作業効率化につながったテスト詳細設計テスト実装入出力のレビュー組合せのレビューに分割して考えることが出来たためレビューがやりやすい全てのデシジョンテーブルをレビュー出来た事前に因子を抜き出していたことにより CFD による組合せ検討がやりやすかったケース A が以前の設計手法を用いた結果ケース B が今回の設計手法を用いた結果であるケース A において組合せによる抜けが発生しているという状況が確認できた上記のように今回の設計手法を用いることで論理的な検討が改善できることが判断できるまた担当者に手法に対するヒアリングを行った結果においても手法の狙いに適合する結果が得られていることを確認出来た ( 表 11) 6. 考察次に 2 項に挙げた課題に対する対策結果を記載する ( 課題 1) 巨大なマトリクスになり作業性が悪いマトリクスをフレーム毎に分割したため最も大きいマトリクスの列数で従来のものより半減 (15 8) したヒアリングでは全体の見通しがよくなり因子の抽出作業が実施しやすくなったという結果が出ており定量データではテスト成果物作成時間の低減に表れているものと思われる

7 ( 課題 2) テスト観点の定義が不十分毎に抽出すべき項目を細分化しマトリクスの列見出しに定義したヒアリングでは抽出すべき因子が分かりやすく作業しやすいという結果が出ており定量データのテスト成果物作成時間の低減と因子の網羅度向上によるテスト密度向上に表れている表 10 の比較結果からテスト設計漏れが低減したことも確認できたまたレビューにおいてもポイントが明確になりレビューがしやくなったという意見がありレビュー効率向上に繋がったと思われる文献 [1] 湯本剛, テストの上流設計, ソフトウェアテスト PRESS Vol.10, pp.1-25, Sep [2] 秋山浩一, ソフトウェアテスト技法ドリル, 日科技連出版社,2010. [3] 西康晴,JaSST 09 東京テスト観点に着目したテスト開発プロセス (VSTeP) の概要 ( 課題 3) マトリクス作成後の作業が不明確マトリクスに記載する内容を因子の列挙 ( テスト方式設計 ) とし以降の因子組合せ作業 ( テスト詳細設計 ) テスト手順を足してテスト手順書を作成する作業 ( テスト実装 ) を定義したこれにより各成果物はガイドラインで定めた手法で一貫性を持って作成されテストケースにおける粒度のばらつきは見られなかった成果物作成効率化の面ではテスト方式設計において因子が具体的な入力値を含まない粒度であるため類似パターンの流用が多く行え貢献が大きかったまた方式設計の類似パターンはテスト詳細設計も流用でき更に効率化できたレビュー効率化の面では従来はテスト手順書で因子因子組合せテスト手順のすべてをレビューしていたのに対し段階的に詳細化する成果物毎にポイントを絞ってレビューすることができレビュー効率が向上したことがヒアリング定量データの両方で確認できたまた従来テストケース全件のレビューが実施できていない工事もあったが今回の 2 工事はいずれも 100% レビューを実施できた 7. 今後の取り組み (1) テスト実施結果のフィードバックテスト開発プロセスの適用は 1 順目の途中でありテスト実施結果の不具合情報を分析し手法へのフィードバックを行う (2) テストの網羅度の定義テスト設計結果の中身の良否を判断するために何らかの基準に対する網羅度などの定義が必要である (3) テスト実装 ~ 実施における効率化の実施今回のプロセス上では改善対象外となっているテスト実装からテスト実施フェーズに対して効率的な方法を検討実践する (4) 展開拡大手法の検討メンバを中心に主要工事での展開拡大を進めていく

テスト設計コンテスト

テスト設計コンテストでこパン 462 1/2X 1/8 チーム紹介だよチーム名いしえもんリーダーあずにゃん ODA 発表者ばやしこいいだぬきでこパン 462 は入社 2 年目 ~4 年目のテスト経験の浅いひよっこチーム普段の業務ではシステムテストを担当している今回はテスト設計技術向上のためコンテスト参加を決めたでこパン 462 2/8 テスト設計の流れ次は機能観点の説明! 話題沸騰ポット (GOMA-1015