********************************************************************** セッションS4-b 分科会 午後1 テーマ :テストの戦略を立ててみるテスト Return! コーディネータ:片山 徹郎 氏(宮崎大学) 講師 :池田 暁 氏(日立情報通信エンジニアリング) 森 孝夫 氏(三栄ハイテックス) 日時 :2008/9/5 13:30〜15:00 参加人数 :約20名 ********************************************************************** ■ 導入 テストは,技法を用いて実施する前に,戦略を立てた上で技法を用いて 行わないと,なかなか成果が上がらない. テスト戦略と言うのは全体で何を設計するのか?何を考えるか?が重要である. 今回はマインドマップを利用して思考の表化,見える化を行ってみる. ------------------------------ 講師への交代 片山氏 → 森氏 ------------------------------ ■ はじめに <参加者全体へ質問> テストケース設計をした事がある人は,会場にどれぐらいいますか? ある/ないで挙手をしてみてください. <回答> 「無い」の方に手を挙げる人が多い. ■ 例題:Myersの三角形 ======================== <演習: Myersの三角形> 以下のテストをするのに必要と思われるケースをすべてあげよ. ※.詳細は配布冊子のP196に載っています. 〜〜 5分間のシンキングタイム 〜〜 <グループAの回答> 整数ではない値 負の数 数字で無いデータ 0 整数で無い数字を入れるのを3つのうちに一個 2等辺三角形の1辺 2辺の和が残りの1辺より小さい数 <参加者全体へ質問> グループAのどれもかなり抽象的ですが,他の班で 「辺の長さが3の時,4の時,5の時・・・」 と言ったように具体的な値で設計した人いますか? <回答> 参加者の少数が挙手. <講師からの模範解答> この演習問題には14個のテストケースがある. 平均的なプログラマは7,8個ほど回答した. 尚,模範解答には抽象的解答も含まれる. しかし,テストには具体的な数値が必要になる. 今回は多少抽象的に,テスト観点を中心にテストの全体を設計する方法を 学ぶ. ==================================== ■ テスト戦略とは テスト戦略は,全体として何をテストするかの構想である. テストケースは,入力と結果である. いきなりテストケースを作ると,1つのことに凝り固まってしまったテストが できてしまう為,全体のバランスを取ることが重要である. また,現在のソフトウェアのようにテストが巨大になってくると複数メンバでの テストケース設計の分担が必要である. つまり,テスト設計をするだけでは難しく,だからこそ戦略が必要になる. 戦略を立てる為には,何を設計すればいいのか考える必要がある. ■ 何をテストすればいいのか? 基本は要求に対して盛れなくテストできるか?を考える. 仕様書に書いていなくとも,動きを予想し,分析をし,テストをする.また, Myersが提唱するシステムテストのモデルもあり,これを利用するのも手である. <Myersの14のシステムテスト・カテゴリ> ボリューム,ストレス,効率,ストレージ,信頼性,構成,互換性, 設置,回復,操作性,セキュリティ,サービス性,文書,手続き しかし,上記の14個をテストすればいいわけではなく,対象によっては 14個以上の時もあれば14個以下の時もある. 最終的には,自分でどんなテストをすべきか考える必要がある. ■ テスト観点の導入 テストで狙うところ,テスト設計の時に考慮すべきところを考える. <例:境界値テスト> ある値の項目に対して境界の部分を狙って行うテスト. これはあくまでも部分的なテストであり,全体のテスト像を挙げている わけではない. 観点の抽出.ここが重要となる. ソフトに対するいろんな観点を持ってテストを設計すべきである. ■ 代表的な4つのテスト観点 ・User-view → ユーザは何するのかを考える. ・Spec-view → 仕様を考える. ・Fault-view → 起こしたいバグを考える. ・Design-view → 設計やソースコードを考える. ■ 組み込みのテストで考慮すべきテストの観点 <最も機能すべき観点> ・機能:テスト項目のトリガ ・パラメータ ・プラットフォーム・構成 ・外部環境. ・その他 −状態 −タイミング −組み合わせ −性能 −信頼性 −GUI・操作性 −出荷先 −障害対応性 −セキュリティ これらのような非常に多くの観点を網羅的に列挙する必要がある. ■ テスト観点のモデリングによるテスト戦略立案 ・テスト戦略というフェーズは暗黙的に行われることが多い. ・テスト観点のモデリングを行ってテスト戦略を立案すべきである. ・今回はテスト分析モデリングにトライする. テスト戦略のモデリングは普段から考える事が多いが,excelによる表形式の テストシートでは狙いが分からない. テスト戦略を明示的に立てることで狙いを表化すべきである. ■ テスト設計を,分析と設計(と実装)に分ける テスト設計 → テスト実施の流れのうち,テスト設計を詳細化し,分析,設計, 実装のフェーズに分ける. ※.予稿集のP197 スライド11を参照. ・テスト分析 → テストの観点の抽出や整理を行う.(これまでに話してきた内容) ・テスト設計 → 抽象思考,本質思考が必要である.これはテスト特有なモノではなく 設計にも通じるものである. ■ テスト分析モデル作成を支える4つの思考技術 ・連想 → 思いつきでガンガン出す. ・階層化 → 抽象化,モデリングをする.(抽象度を上げながらグルーピングして整理) ・集合論 → 観点,部分的基準の捉え方を階層構造のモノから見る. ・目的思考 → 目的に対して機能やテスト項目に漏れが無いかを考える. ■ テスト分析モデル作成の2つのアプローチ ・トップダウン型 → 上位からの連想型.欧米系. おもむろにテスト観点を挙げて詳細化していく. ・ボトムアップ型 → 思いつくところからテストケースを具体的に書いていく. いくつか集まったところで抽象化を行い,テスト観点を導き出す. しかし,実際は真ん中付近から入る事が多い. ■ 検証とは突っ込みである ・それだけ?〜だけ? → テスト観点やテスト量などを疑う. ・そこ? → 本当に重要なポイントなのか?を疑う. ・ひとことでいうと? → まとめると何を言いたいのか?簡素化する.(命名を行う際に効果的) ■ 質問 <参加者Aの質問> ボトムアップでは,観点に抜けが生じやすいのでは? 講師の方はどうしているのか? <講師の回答> 仕様書を読んで重要そうな単語を抜き出す. そこからヒントを得て,「それだけ?」と「そこ?」といった突っ込みを 使い,検証をして抜けを探し出す. 大抵の仕様書は,冒頭にはテスト観点を含んでいない為,真ん中付近を読み, テスト観点を探ることが多い. ------------------------------ 講師の交代 森氏 → 池田氏 ------------------------------ ■ テスト分析モデル テスト分析モデルには4つほど有名なモデルがある. ・NGT → 階層構造を作り,そこから関連付けてネットワーク図のように仕上げる. ・マインドマップ → 中心から線を引いて関連する項目をドンドン挙げていく. ・ゆもつよメソッド → 表形式.(機能とテストカテゴリ) ・HAYST法(FV表) → 機能に対して検証内容,使うテスト技法,を並べる. ■ 4つの技法の特色 ・NGT → 階層関係と,その関連,関係を検討しやすい ・マインドマップ → ブレインストーミング的な検討に強い ・ゆもつよメソッド → テストカテゴリに今までのノウハウを使いやすい ・HAYST法(FV表) → 機能に対応した観点を使いやすい マインドマップ → NGT の流れで使うと漏れが少なく見やすい. 今回は導入としてマインドマップを使う. <参加者全体へ質問> マインドマップを知っている人 → 過半数 仕事で使っている人 → その1/3 テストで使っている人 → ごく少数 ■ マインドマップの基本 ・トニー・ブザンが発端 −脳の仕組み −思考に沿って書いていく ・用意するもの −紙とカラーペン −できれば12色以上のペン ■ ビデオでデモ(自己紹介) ====================== ここで,マインドマップを利用した自己紹介についてのビデオを見る. ==================================== ■ マインドマップのスタイル マインドマップには2つのスタイルがある. ・自由記述型 自由記述型は,方向性を見出していく段階での利用に向いた,マインド マップを1から(中心から)自分で取り掛かるスタイルである. ・テンプレート型 テンプレート型は,方向性が決まった段階での利用に向いた,マインド マップを書く前から,中心とノードがテンプレとして用意されている スタイルである. ■ ビデオでデモ(分析→設計) ===================== ここで,マインドマップを利用してテストケースを作る内容のビデオを見る. <概要> 1.仕様をチェック!! → 気になるポイントを抽出. 2.マインドマップ → マインドマップで自己レビュ. 視覚化していることで発想の経緯が表化しやすい. 3.マインドマップからテストケース作り ==================================== ■ マインドマップにおける分析時の注意点 ・思考を際限なく発散させない ・マインドマップは客観的にはかかれない → 他人と違うことは当たり前. ・マインドマップを書くことを目的化しない → 汚くても沢山の気づきがあったほうがよい. ■ ビデオでデモ(共有作業) ====================== マインドマップは文章を書くのではなく,お絵描きなのでマトリックスを 入れても構わない. 思考の流れを他人が追えるので, ・書いた人間は結論の説明付けが楽 ・指摘する人間は間違えた結論でも,どこで間違えたのか?がわかり, 的確な指摘ができる といった特徴もある. ==================================== ------------------------------ 10分間の休憩 この後,後半へ・・・ ------------------------------