Contenu connexe
Similaire à テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう (20)
テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう
- 2. ©Akira Ikeda
2
自己紹介
• 名前：池田 暁（いけだ あきら）
• 所属：某製造業
ソフトウェア開発技術導入支援部門
• 職歴：入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、
現在は設計/テストツールの導入や、プロセス改善に関する業務に
従事。最近は変更・構成管理ツールの社内普及を担当。
• 社外活動
– 委員等
• 筑波大学 大学院 高度IT技術者育成コース 非常勤講師
• NPO法人ASTER（ソフトウェアテスト技術振興協会） 理事
• JaSST（ソフトウェアテストシンポジウム） 実行委員
• WACATE（ソフトウェアテストワークショップ） 実行委員長
• 日科技連・日本品質管理学会共同部会 SQuBOK策定部会 策定メンバ
• 日本品質管理学会・ACM 正会員
– 執筆活動（単行本）
• ISTQBシラバス準拠 ソフトウェアテストの基礎、センゲージラーニング、2008
• ソフトウェアテスト入門 押さえておきたい<<要点・重点>>、技術評論社、2008
• ソフトウェア品質知識体系ガイド―SQuBOK Guide、オーム社、2007
• マインドマップから始めるソフトウェアテスト、技術評論社、2007
- 3. ©Akira Ikeda
• 書籍
– 「マインドマップから始めるソフトウェアテスト」，池田暁，鈴木三紀
夫，技術評論社，2007
– 「ソフトウェアテスト入門」，秋山浩一，池田暁ら，技術評論社，2008
• 関連記事等
– ソフトウェア・テストPRESS
• vol.3 マインドマップから始めるテスト設計
• vol.4 マインドマップから始めるテストケース設計
• vol.5 紙上体験企画「マインドマップから始める
テストケース設計」実況セミナー
– Gihyo.jp
• ソフトウェアテストとマインドマップのちょっとイイ関係
（ http://gihyo.jp/book/pickup/2007/0065 ）
– 書評・書籍紹介
• 浅海智晴様（マイコミジャーナルに掲載）
– マインドマップでテスト仕様の理解を深めろ
（ http://journal.mycom.co.jp/articles/2007/07/26/mindmap/ ）
• 生井俊様（@ITに掲載）
– テスト工程の全体を知り、その勘所を理解するマインドマップの活用法
（ http://www.atmarkit.co.jp/im/news/books/ ）
• 日経SYSTEMS 2007年9月号 新刊紹介
マインドマップの活用法の研究と実践
- 10. ©Akira Ikeda
テストすべきことの発想（認知）
• テストすべき対象は「仕様として書かれていること」と「そ
れ以外」
• 書かれていないことは思いつかなければならない
• つまり，「それ以外」をどれだけ発想・認知できるかが勝負
それ以外
こう動かないべき
（異常系）
こう動くべき
（正常系）
仕様書に書かれていることから
テストすべきこと発想すれば良い（容易）
仕様書に書かれていないため，
思いつかなければならない
仕様領域に近いところは
比較的仕様書から発想しやすい
仕様から遠いところは
仕様書によらない発想が必要
これらの一連の行為として「テスト分析」
と「テスト設計」があり，テストすべき事
柄を発想して整理する手段として「テスト
観点」と「テスト分析設計手法」がある
- 14. ©Akira Ikeda
辞書を引いてみよう 観点とは
• 発想［名］(スル)
① 物事を考え出すこと。新しい考えや思いつきを得ること。
また、その方法や、内容。
② 芸術作品など、表現のもとになる考えを得ること。
③ 音楽で、楽曲のもつ気分や情緒を緩急・強弱などによって表現
すること。
• 発想［名］(スル)
① あることを思いつくこと。また、その思いついた考え。思いつ
き。
② 考えを展開させたり、まとめたりして形をとらせること。
③ 音楽で、楽曲の曲想・緩急・強弱などを表現すること。
発想 ＝ 思いつき(発散) ＋ まとめ(収束) + 表現
マインドマップで支援
- 17. ©Akira Ikeda© Akira Ikeda 17
開発プロセス（Vモデル）
基本設計
構造設計
詳細設計
実装/机上テスト
コンポーネントテスト
統合テスト
システムテスト
対応
対応
対応
要件定義 受け入れテスト
システム仕様
書
等…
構造仕様書
等…
詳細仕様書
等…
要件定義書
等…
主にレビュー技法により
欠陥を摘出
主にテスト技法により
欠陥を摘出
- 18. ©Akira Ikeda
テストレベルごとの作業（一例）
© Akira Ikeda 18
第3世代
さらに概念と作業を分割。テストライフサイクルプロセスの考え方が普及。
テスト技法の議論は収束し，いかに戦略的なテストを行うかという議論。
分析 実装設計 実行 報告
第1世代
特に準備なく場当たり的にテストを実行（モンキーテスト）
テスト実行
第2世代
テストケースの作成と実行に概念と作業を分離。テスト技法が普及。
テストケース作成 テスト実行
※注 世代は便宜上つけているものです
- 19. ©Akira Ikeda© Akira Ikeda 19
Ｖ字モデルへのマッピングイメージ
基本設計
構造設計
詳細設計
実装/机上テスト
実行→報告分析→設計→実装
コンポーネントテスト
実行→報告分析→設計→実装
統合テスト
実行→報告分析→設計→実装
システムテスト
対応
対応
対応
朱文字の工程は，実装後を待たずに着手で
きるため，できるだけ前倒し作業を行うと
よい
システム仕様
書
詳細仕様書
構造仕様書
- 21. ©Akira Ikeda
ライフサイクル適用のイメージ
テスト分析 テスト設計 テスト実装 テスト実行
仕様の理解・整
理・検討・テス
ト観点の目付け
テスト観点の発
想・検討・整理
テスト設計結果
に従ってテスト
ケース作成（各
種テスト技法を
利用）
ここで使う発散思考を
マインドマップでブーストしよう！
この初期から中期までの作業で
テスト観点を発想しなければならない
テスト実装によ
り作成されたテ
ストケースを実
行し、ログを取
る
- 22. ©Akira Ikeda
いきなりテストケースを書くのは限界
• 大規模ソフトウェアは、テストも手分けする必要が出てきた
– 数百万行コードのテストを一人で実施するはもはや無理だろう
• 分担するには、全体の構造とバランスが見える必要がある
– 分割統治には、分割するための観点と戦略が必要である
• テストで考えなければならないテスト観点も大きく増加している
– システムの規模増大や複雑化により，考えなければならないテスト観点が大きく増
加している
• 観点そのものを発想や，観点間の関連の洗い出しや組み合わせ，優先度や重要度など
• 個人個人がいきなりテストケースを作成していくと、全体としてのバ
ランスを取るのが難しい
– 担当者が気になるところばかりたくさんテストケースが増える →偏り、抜け
– 時間が来たのでテストケース作成は終了 → テストされない機能が出てくる
• これらに対応するためにテスト設計という作業を行う
– テスト設計とは平たく書くと、テストの戦略に影響を与えるテスト観点の抽出とそ
の構造化である → 高度に発展させるとモデリング作業
– かつてソフトウェア設計もコード規模が大きくなったことで、構造化設計やオブジ
ェクト指向設計、UML等、モデリングの重要性が認識されるようになった
• テストも同じ道をたどりつつある
- 25. ©Akira Ikeda
発想整理検討すべきテストの「観点」
• テストには、様々な「観点」が必要だと言われている
– Ostrandの4つのビュー
• ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー
– Myersの14のシステムテスト・カテゴリ
• ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回
復、操作性、セキュリティ、サービス性、文書、手続き
– ISO/IEC 9126の品質特性
• 機能性、信頼性、使用性、効率性、保守性、移植性
• テストの「観点」とは何だろう？
– テスト対象の持つ、テストすべき側面
– テスト対象が達成すべき性質
– テスト対象（及び含む世界）を、テストの立場からモデリングしたもの
• テストする必要が無い側面は、モデリングする必要が無い
• 達成する必要が無い性質は、モデリングする必要が無い
– 抽象的で、階層構造を持つ
• 同値分割の包括的なもの
– やさしく書くと「なにをテストしよう」「どうテストしよう」といった
ようなもの
- 29. ©Akira Ikeda
大・中・小項目型によるテスト設計の例
• 問題
– 以下はよくある大・中・小項目のエクセルフォーマットですが、
テスト観点を検討するにあたって何が問題でしょう？
大項目 中項目 小項目 テストケース
機能レベル１ 機能レベル２ 機能レベル３ 機能レベル１０
機能レベル１ 機能レベル８ 機能レベル９ 機能レベル１０
機能 環境 データ 機能＋環境＋データ
機能 データ GUI 機能＋データ＋GUI
機能 データ 前提条件 機能＋データ
機能 状態 イベント 状態＋イベント
テストカテゴリ 機能 データ 機能＋データ
組み合わせ 機能① 機能② 機能①×機能②
- 30. ©Akira Ikeda
大・中・小項目型テスト設計の問題点
• 詳細化のレベルが揃わない、詳細化に限界がある
– 偏った詳細化をしてしまう、テストケース群ごとに詳細化の偏りにばらつく
– 詳細化のレベルが最大3段階で固定される
• 異なるテスト観点の組み合わせを詳細化だと考えてしまう
– （例）機能＋環境＋データ、機能＋データ＋GUI
• テスト設計で考慮する必要の無いものが入ってしまう
– （例）機能＋データ＋前提条件
• パラメータや前提条件はテストケースで記述
• 異なるテスト観点にぶら下げているので網羅できない
– （例）機能＋状態＋イベント
• 本来は状態遷移網羅をすべき
• 組み合わせテストを押し込んでしまう
– n元表を使うべき
• どんな観点に着目しているのか、全体の構造を俯瞰できない
– ページを何枚もめくる必要がある
テストケースの表現形式を使って分析・設計を行うのは難しい
- 34. ©Akira Ikeda
説明に入る前に… 辞書を引いてみよう
• 発想［名］(スル)
① 物事を考え出すこと。新しい考えや思いつきを得ること。
また、その方法や、内容。
② 芸術作品など、表現のもとになる考えを得ること。
③ 音楽で、楽曲のもつ気分や情緒を緩急・強弱などによって表現
すること。
• 発想［名］(スル)
① あることを思いつくこと。また、その思いついた考え。思いつ
き。
② 考えを展開させたり、まとめたりして形をとらせること。
③ 音楽で、楽曲の曲想・緩急・強弱などを表現すること。
発想 ＝ 思いつき(発散) ＋ まとめ(収束) + 表現
マインドマップで支援
- 35. ©Akira Ikeda
マインドマップとは？
• トニー・ブザンにより考え出された図解技法
– 脳の仕組みを取り入れたもの
– 思考に沿って描いていく
– イメージ（図）を重要視する
– 発想力を生かす
– 自分の深層意識にアクセスする
Wikipediaによる解説
表現したい概念の中心となるキーワードやイメージを図の中央に置き、
そこから放射状にキーワードやイメージを繋げていくことで、発想を延ば
していく図解表現技法。
この方法によって複雑な概念もコンパクトに表現でき、非常に早く理解
できるとされ、注目され始めている。
人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合して
いるので、理解や記憶がしやすい。
また本来は紙とペンで描くものだが、コンピュータ上で描くための専用ソ
フトウェアもいくつか存在する。
- 36. ©Akira Ikeda
マインドマップの特徴
• マインドマップには以下のような特徴がある
– バードビュー
• 全体を俯瞰し易い
– 学習が容易
• 基本的なルールは単純で、紙とペンがあれば始められる
– 半構造
• フリーなルールであるために、柔軟に構造を変更可能
– プレイバック効果
• あとで、「なぜそう考えたか」「何を描いたか」などを思い出しや
すい
– 発想力が刺激される
• 描いているうちに他の項目との関連などから新たな発想が生まれや
すい
• 自分の深層意識にアクセスし、情報を引き出す
– 思考の流れが絵として表現される（見える化）
• 中心から外に対して思考が放射的に広がる
- 37. ©Akira Ikeda
マインドマップは発散思考のツール
• マインドマップは発散思考(放射思考)のツールである
– 日本国内では、ノート術として広まってしまったため、議事録の
ためのツールと理解している人も多い（！）が、実際はブレーン
ストーミングのような発散思考ツールの性格が強い
• すでにあるものを整理するツールではない！
– 思いつきを得る
– 自分にとってモヤモヤとした、つかみ所のないものをイメージ・
具象化する
• 抽象度の高いものやまだ形のないものを検討することに大き
な効果
– 収束するには別のツールを使うことをおすすめ
– マインドマップはブレストツールと割り切ったほうが，作業上は
使いやすい
- 38. ©Akira Ikeda
マインドマップの12のルール
1. 無地の紙を使う
2. 横長で使う
3. 中心から描く
4. テーマはイメージで描く
• 枠なし
• 縦横3～5センチ× 3～5センチ
• 3色以上で
5. 1ブランチ＝1ワード
• ブランチの上にワードを描く
• ブランチとワードは長さを揃える
6. ワードは単語で描く
• フレーズで書かない
• ワードの階層付け
7. ブランチは曲線で
• メイン・ブランチは…
• テーマイメージにつなげる
• サブ・ブランチをつなげる
• サブ・ブランチの太さを変化（太い→細い）させる
• 分岐は45度ほどの角度をつける
7. 強調する
• シンボルイメージを描く
• 3Dで描く（立体的に）
• 飾り文字をつける
• カラフルに描く
8. 関連付ける
• 矢印を使う
• 記号を使う
• アウトラインで囲む
9. 独自のスタイルで
• ブランチの強調の仕方，イ
メージの書き方など自分のス
タイルを発見しよう
10. 創造的に
• ユーモラスなイメージを使う
• 記憶をうながすように
11. 楽しむ！
William Reed著「記憶力・発想力は驚くほど高まるマイ
ンドマップ・ノート術」，フォレスト出版，から引用
- 39. ©Akira Ikeda
• マインドマップには二つのスタイルがある
– 自由記述型
• ルール無しに自由に描いていく
• ひたすら思考を発散させながら思いつくままに描いていく
– ブレーンストーミング向き
• 抽象レベルを特に意識しなくても良い（いくらでも詳細化できる）
• 発散した思考は，別プロセスで収束させる必要がある
– テンプレート型
• メイン・ブランチ，ブランチのひな形を使う
• ゆるやかなルールが存在していることが多い
– 情報の分析や整理に使われることが多い（系統図っぽく使われる）
• 抽象レベルが固定されることが多い
• 思考がテンプレートに縛られるため，自由記述型に比べて発想力は
落ちる
自由記述かテンプレートか
- 40. ©Akira Ikeda
自己紹介を書いてみましょう
• テーマをしっかりと考える
– イメージを頭の中に作ることを意識し，それを紙に転写する
– 文字ではなくて絵で表現すること
• メインブランチをまず考える
– いきなり深堀をしない（ひとつのブランチを伸ばさない）
– 全体のバランスを考えながら描いていく
– バランスが悪いところは，もう少し考えてみる
– 考えすぎずに描いていく
• 思いついたらとりあえず描く
• ブランチに紐づかないことでも，余白に描いておく
– あとでつなげればよい
– 発想が出なくなったら俯瞰してみる
• 関係やグループを意識してみる
• 他のブランチから発想する
– イメージを入れる
