探索的テストの適用事例 - まずは 探索的テストをやろまい!! - 三菱電機メカトロニクスソフトウエア株式会社 都築将夫 0/19 アジェンダ 現状分析 改善策立案 探索的テストの特徴 弱みの克服 探索的テストの強みを生かす 成果 & 効果 今後の課題 1/19
現状 担当製品のソフトウェア 規模 : 肥大 ( ライン数 : 数 10KL 数 100KL) 構造 : 複雑 ( サイクロマティック複雑度 :10 程度 数 100 程度 ) 差分開発第 2 世代の完了時点で 母体開発からの潜在バグが残存 作り込み作り込み作り込み テスト テスト テスト 2/19 分析 なぜ 潜在バグが残ってしまうのか? ハードウェア資源の解放ミス など 時間軸でのタイミングなど 潜在バグの検出 : 困難 テスト条件の記述 : 困難 バグ検出ができない 潜在バグとして残存 ( ムダに細かい ) テストケースを選定 選定したテストケース : 不適切 選定基準は人によってバラバラ 3/19
改善策立案 全ケースをテスト実行 : ムリ しかし 潜在バグが存在すると思われるところはテストすべき 手順に従ってテスト実行 スクリプトテストで可能な限り潜在バグの検出 スクリプトテストでは困難な潜在バグを見つけたい テストの限界を超えたい 想像力を働かせるテスト を失敗を恐れず やらまいか! 覚悟完了 探索的テストをやろまい!! 4/19 探索的テストの特徴 強み 1. テスト仕様の記述工数が軽減 2. 少ない手数で多くのテストケースを実行可能 3. テスト実行時のマンネリ感が解消 弱み 1. テスト実行の網羅性に欠ける 2. テスト実行内容がアドホックになりがち 3. テスト内容の記述に迷う ( 記述の粒度をどの程度書くべきか ) 5/19
弱みの克服 弱み網羅性アドホック記述 1-1 1-3 1-4 2-1 2-2 2-3 3-1 3-2 実施した施策 テスト実行モデルを整理 1-2 テスト仕様の5 要素洗い出し テスト テスト実行マトリクスの作成 分析 テスト実行マトリクスの最適化 製品自体の弱点を特定 羅針盤によるアドホック抑止 テスト結果の記録 テスト仕様の記載項目を定型化 [ ][ 設定 ][ 構成 ]: 共通事項に フェーズ テスト設計 テスト実装 6/19 テスト実行モデルを整理 ( 施策 1-1) 弱み : 網羅性 [ ][ ]: テスト実行の網羅性を確保 [ 設定 ][ 構成 ]: テスト条件の見落とし防止 [ ] : 確認項目の見落とし防止 構成 / 設定 ( テスト環境 ) ( ソフトウェア内部処理 ) / 外乱 ( に含む ) ( テスト実行 / 異常 & 異常環境 ) ( テスト表示結果 ) 7/19
テスト実行マトリクスの作成 テスト仕様の 5 要素洗い出し ( 施策 1-2) テストの着眼点を明確にするため 外部仕様書 ( 詳細仕様書 ) マニュアル テスト仕様書 から 機能に対する [ ][ ][ ][ 設定 ][ 構成 ] の要素を整理 機能設定構成 データ転送スイッチ押下データ保護完了ランプ ( 該当なし ) モード 弱み : 網羅性 エラー復帰リセットボタン押下再起動エラーランプエラー復帰有効 ( 該当なし ) 8/19 ( 施策 1-3) [ ][ ] の要素を機械的に展開 機能 要素 データ転送スイッチ押下データ保護完了ランプ ( 該当なし ) モード エラー復帰リセットボタン押下再起動エラーランプエラー復帰有効 ( 該当なし ) 機能設定構成通信開始定期通信イベント発生時通信相手機器 R メモリ通信経路断線検出 9/19 弱み : 網羅性 [ ] の要素を縦に展開[ ] の要素を横に展開 R メモリ
テスト実行マトリクスの最適化 ( 施策 1-4) [ ][ ] の要素をコンパクトに整理 機グルーピングする器と ( 例 : 通信 H/W ) 定期通信イベント発生時通信相手機器 R メモリ通信経路断線検出 相手 通通信信開終始了 R テスト実行できん! メモリ テストケースが膨大で 限られた時間内に 重複を解消 マトリクスの最適化 定期通信イベント発生時通信相手機器 H/W 通信経路断線検出 通信開始 ( 例 :R メモリ メモリ ) 弱み : 網羅性 通信状態表示通信テスト 通信履歴表示限られた時間内にテスト実行可能だがね! メモリ 10/19 製品自体の弱点を特定 ( 施策 2-1) BT に登録された 過去のインシデントレポートを把握 過去のテスト報告書を把握 定期通信イベント発生時通信相手機器 H/W 通信経路断線検出 通信開始 メモリ 11/19 弱み : アドホック 製品自体の弱点を テスト実行候補として選定
テスト仕様の記載項目を定型化 ( 施策 3-1) 従来 : テスターによってまちまち ( 数 10~ 数 100 枚 ) 今回 : シンプルに記述できた!(1 枚で収まった ) 1 - の組み合わせ H/W vs 日付 11'/11/11 名前 都築将夫 H/W 機能 の ピンを (1) 番地のメモリ 短絡させる (2) エラー LED 点灯状態 弱み : 記述 通信開始 メモリ 構成 / 設定 送信データ : 応答データ : 構成 設定 結果 定期通信イベント発生時通信相手機器 H/W 通信経路断線検出 構成 パターン 構成図 パターン ZZ 復帰モード 設定 設定値 / 設定内容 α β γ 通信モード - X Y Z Δ 備考 (/W ver. など ) 12/19 [ ][ 設定 ][ 構成 ]: 共通事項に ( 施策 3-2) [ ][ 設定 ][ 構成 ] の要素一覧を各テストケースの共通事項とする テストケースの作成 & メンテナンス効率の改善を考慮した < 一覧 > 設定 < 一覧 > 稼働 LED エラー LED 通信開始信号 X 通信停止信号 Y 信号 Z エラー復帰完了信号 ζ 復帰モード 設定 テストケース < 共通事項 > 値 / 状態 消灯 点滅 - 点灯 消灯 点滅 - 点灯 0000h 開始前 0001h 開始指示 0011h 開始準備中 h 通信開始 0000h 停止前 0001h 停止指示 0011h 停止準備中 h 停止完了 0000h 終了前 0001h 終了指示 0011h 終了準備中 h 0000h 復帰前 - - 0011h 復帰準備中 h 復帰完了 設定値 / 設定内容 α β γ 通信モード - X Y Z 13/19 Δ 構成 パターン 構成 < 一覧 > 弱み : 記述 構成図 パターン ZZ
55羅針盤によるアドホック抑止 ( 施策 2-2) テスト実行マトリクスからテスト実行候補を選定し テストチャータとして機能 通インシデントレポートから信開製品自体の弱点と判定 始 テストケース No.31 定期通信イベント発生時通信相手機器 H/W 通信経路断線検出 メモリ 87 1 2 3 4 5 6 7 8 9 31 32 33 34 55 86 88 89 90 91 92 93 103 104 14/19 テストの目的を明記したもの テスト実施法のアイデアを含む場合もある 引用元 :TQB テスト技術者資格制度用語集日本語版 Version 2.0.J02 スクリプトテスト実施済みで半年以上市場バグ無し テスト実行しない セルの数値は テストケースの通し番号 弱み : アドホック テスト結果の記録 ( 施策 2-3) テスト結果を記録し テスト実行のトレーサビリティを確保 定期通信イベント発生時通信相手機器 H/W 通信経路断線検出 通信開 始 通信終 了 故障検 出 1 2 3 4 7 8 5 6 9 31 32 34 33 88 89 90 91 92 93 103 104 メモリ 1 - の組み合わせ 31 H/W vs 日付 11'/11/11 名前 都築将夫 H/W 機能 の ピンを (1) 番地のメモリ 短絡させる (2) エラー LED 点灯状態 構成 / 設定 + 送信データ : 応答データ : 構成 弱み : アドホック 設定 + 結果 (1) 送信データ : を送信中に のピンを短絡後 番地に (h) エラーが格納された (2) エラー LEDが赤色で点滅した (3) 応答データがテスト結果を ではなく と並びが逆になった (N) 記録 備考 (/W ver. など ) Ver. 15/19
探索的テストの強みを活かす 毎朝のブリーフィングでテスト実行順を決定 [ 第 1 段階 ] [ 第 3 段階 ] 定期通信イベント発生時通信バグ発生時のリスクが相手機器 H/W 大きいものからテスト実行 通信経路断線検出 通信開始 相手機器 第 2 段階の結果から 同じを他のでテスト と通信 [ 第 2 段階 ] 第 1 段階でバグが出たを他のでテスト [1] 87 1 2 3 4 5 6 7 8 9 31 32 33 34 55 86 88 89 90 91 92 93 103 104 16/19 メモリ [3] [2] 成果 6.0 バグ密度では 0.35 0.30 0.25 0.20 0.15 0.10 0.05 0.00 [1] [2] 派生第 1 世代派生第 2 世代今回 ( 開発中 ) バグ検出効率では [ バグ密度 ] =[ バグ件数 ]/[ 規模 ] 微増 ( 1.2 倍程度 ) 品質自体に変化なし [1] と [2] を比較 5.0 4.0 3.0 2.0 1.0 0.0 5 倍!! [1] [2] 潜在バグ 7 件検出!! 派生第 1 世代派生第 2 世代今回 ( 開発中 ) [ バグ検出効率 ] =[ バグ件数 ]/[ テスト工数 ] 5 倍向上 効果 : 大幅に!! 17/19
効果 定量的効果 1. テスト仕様の記述を改善 テスト仕様 1 件が数 10~ 数 100 枚が 1 枚に収まった!! 2. バグ検出効率の改善 5 倍バグ検出能力!! 定性的効果 3. テスターとしての勘 ( バグの嗅覚 ) が鋭くなる テストに関するノウハウの継承により テスターのテスト力向上!! 18/19 今後の課題 探索的テストのバグ検出効果を他プロジェクトで確認する 他の製品にも探索的テストを水平展開する プロジェクトリーダに提言する どの現場でも探索的テストを適用できるよう さらにシンプルな方法を考え 実践する 探索的テストガイドラインとしてまとめる 19/19
< ご清聴ありがとうございました > 20/19