Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
©Akira Ikeda
池田 暁
2015年4月7日
於 長崎IT技術者会 第2回勉強会
エセナ太田(東京大田区)
テスト分析・設計を体感しよう
~マインドマップを活用して
テスト観点を発想しよう
©Akira Ikeda
2
自己紹介
• 名前:池田 暁(いけだ あきら)
• 所属:某製造業
ソフトウェア開発技術導入支援部門
• 職歴:入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、
現在は設計/テストツールの導入や、プロ...
©Akira Ikeda
• 書籍
– 「マインドマップから始めるソフトウェアテスト」,池田暁,鈴木三紀
夫,技術評論社,2007
– 「ソフトウェアテスト入門」,秋山浩一,池田暁ら,技術評論社,2008
• 関連記事等
– ソフトウェア・テス...
©Akira Ikeda
宣伝:長崎IT技術者会とは
• 長崎出身や在住,かつて在住など,長崎になんらかの関わり
や興味を持っている技術者の交流会
– ついこの前Facebookにグループを作りました。
• 長崎と付いていますが,中の人が長崎人...
©Akira Ikeda
宣伝:SWTest&devCamp(仮)
• この夏に長崎市内にて勉強会を開催予定です
– 日時:2015年8月12日 13:00~17:00(予定)
– 場所:長崎市内(メルカ築町で検討中)
– 当日の内容:
• テ...
©Akira Ikeda
テストにおける思考
テスト設計のお話に入る前に,ソフト設計とテストでは
思考のスタイルが異なることを確認します。これを意識
しておかないとうまくテスト観点の発想に苦労します。
(要求の勉強会ではないので,イメージで解説...
©Akira Ikeda
設計とテストにおける思考の向き
• テストを考えるとき,設計時とは違う思考パターンであるこ
とを理解しておく(逆方向の思考である)
– 設計は問題領域を狭めていく思考
– テストは問題領域を広げていく思考
要望や要求 ...
©Akira Ikeda
設計の思考
• 設計では要件を,計算機世界上で「こう動くべき」「こう動
かないべき」に分類・具体化・定義することで問題領域を狭
めていく(計算機の振る舞いを定義する→仕様化)
それ以外
こう動かないべき
(異常系仕様)...
©Akira Ikeda
テストの思考
• テストは仕様化された事柄について「その通りに動くか」を
確認するだけでは不十分で,「それ以外で何も起きないのか
」も確認せねばならない。
それ以外
こう動かないべき
(異常系)
こう動くべき
(正常系...
©Akira Ikeda
テストすべきことの発想(認知)
• テストすべき対象は「仕様として書かれていること」と「そ
れ以外」
• 書かれていないことは思いつかなければならない
• つまり,「それ以外」をどれだけ発想・認知できるかが勝負
それ以...
©Akira Ikeda
テストにおける思考のまとめ
• テストを考えるとき,設計時とは違う思考パターンであるこ
とを理解しておく(逆方向の思考である)
– 設計は問題領域を狭めていく思考
– テストは問題領域を広げていく思考
• テストは仕様...
©Akira Ikeda
テスト観点とは
「テスト分析」および「テスト設計」の開発プロセス上
の位置づけを確認しましょう。
©Akira Ikeda
テスト観点に関するよくある発言
• いわゆる「テスト漏れ」に対してその理由を聞くと,
「テストの観点が漏れていました」
という発言をよく聞く
• テストの観点漏れを防ぐための対策に挙げられることが多い
のは「テストレビ...
©Akira Ikeda
辞書を引いてみよう 観点とは
• 発想[名](スル)
① 物事を考え出すこと。新しい考えや思いつきを得ること。
また、その方法や、内容。
② 芸術作品など、表現のもとになる考えを得ること。
③ 音楽で、楽曲のもつ気分や...
©Akira Ikeda
テスト観点とは
• 最終的にテストケースを作り上げるために,持っておくべき
視点やテスト対象の性質など
• 切り口やといってもいい
• 視点を変えながら観点を見つける
• 視点とは直線的なものの見方
• 観点とは俯瞰的...
©Akira Ikeda
テストプロセスの確認
「テスト分析」および「テスト設計」の開発プロセス上
の位置づけを確認しましょう。
©Akira Ikeda© Akira Ikeda 17
開発プロセス(Vモデル)
基本設計
構造設計
詳細設計
実装/机上テスト
コンポーネントテスト
統合テスト
システムテスト
対応
対応
対応
要件定義 受け入れテスト
システム仕様
書
...
©Akira Ikeda
テストレベルごとの作業(一例)
© Akira Ikeda 18
第3世代
さらに概念と作業を分割。テストライフサイクルプロセスの考え方が普及。
テスト技法の議論は収束し,いかに戦略的なテストを行うかという議論。
分析...
©Akira Ikeda© Akira Ikeda 19
V字モデルへのマッピングイメージ
基本設計
構造設計
詳細設計
実装/机上テスト
実行→報告分析→設計→実装
コンポーネントテスト
実行→報告分析→設計→実装
統合テスト
実行→報告分析...
©Akira Ikeda
テスト観点ベースの
テスト分析設計概要
テスト観点ベースのテスト分析設計の概要を
©Akira Ikeda
ライフサイクル適用のイメージ
テスト分析 テスト設計 テスト実装 テスト実行
仕様の理解・整
理・検討・テス
ト観点の目付け
テスト観点の発
想・検討・整理
テスト設計結果
に従ってテスト
ケース作成(各
種テスト技法...
©Akira Ikeda
いきなりテストケースを書くのは限界
• 大規模ソフトウェアは、テストも手分けする必要が出てきた
– 数百万行コードのテストを一人で実施するはもはや無理だろう
• 分担するには、全体の構造とバランスが見える必要がある
–...
©Akira Ikeda23
皆さんどのようにテストケースを作っていますか?(初級者の場合)
仕様書 テストケース
初級者
(仕様例)
ボタンを押すと音が出る
(テストケース例)
ボタンを押すと音が出ることを確認
初級者の悩み
・テストケースの...
©Akira Ikeda24
皆さんどのようにテストケースを作っていますか?(上級者の場合)
上級者
仕様書 テストケース
テストケースを書く前に、思考を発散させながら、かつMECEを意識し
て考える。なので、初級者に比較してテストケースの抜け...
©Akira Ikeda
発想整理検討すべきテストの「観点」
• テストには、様々な「観点」が必要だと言われている
– Ostrandの4つのビュー
• ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー
– Myersの14のシステムテス...
©Akira Ikeda
(例)テストで考慮すべきテスト観点
•機能:テスト項目のトリガ
–ソフトとしての機能
•音楽を再生する
–製品全体としての機能
•走る
•パラメータ
–明示的パラメータ
•入力された緯度と経度
–暗黙的パラメータ
•ヘ...
©Akira Ikeda
(例)テストで考慮すべきテスト観点
•状態
–ソフトウェアの内部状態
•初期化処理中か安定動作中か
–ハードウェアの状態
•ヘッドの位置
•タイミング
–機能同士のタイミング
–機能とハードウェアのタイミング
•組み合...
©Akira Ikeda
実に多くを考えることが必要であるが…
28
とりあえず、
テストケース表を使って考
えようかな?
どうせ最終的には
エクセルの表に
なるわけだし
考えているときは、メモ
紙にキーワードを書くく
らいだ…
メモで考えるの...
©Akira Ikeda
大・中・小項目型によるテスト設計の例
• 問題
– 以下はよくある大・中・小項目のエクセルフォーマットですが、
テスト観点を検討するにあたって何が問題でしょう?
大項目 中項目 小項目 テストケース
機能レベル1 機能...
©Akira Ikeda
大・中・小項目型テスト設計の問題点
• 詳細化のレベルが揃わない、詳細化に限界がある
– 偏った詳細化をしてしまう、テストケース群ごとに詳細化の偏りにばらつく
– 詳細化のレベルが最大3段階で固定される
• 異なるテス...
©Akira Ikeda
設計作業は、検討図を作成するが…
• 設計作業では、プログラムコードを書く前にUMLやフローチャート
・PADなどを描いて、顧客要求をしっかり考え、設計観点を整理し、
モデル(構造)を作っていく
• 作成されたモデルを...
©Akira Ikeda
では、どういった記法がいいの?
じゃぁどういった
分析・設計ツールが
いいのだろうか…
じゃぁ、そのような特徴をもつ
発想支援ツール、
マインドマップを
使ってみたら?
テスト初期はモヤモ
ヤしてるから
試行錯誤できる...
©Akira Ikeda
マインドマップとは
マインドマップの基本についておさらいしましょう
©Akira Ikeda
説明に入る前に… 辞書を引いてみよう
• 発想[名](スル)
① 物事を考え出すこと。新しい考えや思いつきを得ること。
また、その方法や、内容。
② 芸術作品など、表現のもとになる考えを得ること。
③ 音楽で、楽曲のも...
©Akira Ikeda
マインドマップとは?
• トニー・ブザンにより考え出された図解技法
– 脳の仕組みを取り入れたもの
– 思考に沿って描いていく
– イメージ(図)を重要視する
– 発想力を生かす
– 自分の深層意識にアクセスする
Wi...
©Akira Ikeda
マインドマップの特徴
• マインドマップには以下のような特徴がある
– バードビュー
• 全体を俯瞰し易い
– 学習が容易
• 基本的なルールは単純で、紙とペンがあれば始められる
– 半構造
• フリーなルールであるた...
©Akira Ikeda
マインドマップは発散思考のツール
• マインドマップは発散思考(放射思考)のツールである
– 日本国内では、ノート術として広まってしまったため、議事録の
ためのツールと理解している人も多い(!)が、実際はブレーン
スト...
©Akira Ikeda
マインドマップの12のルール
1. 無地の紙を使う
2. 横長で使う
3. 中心から描く
4. テーマはイメージで描く
• 枠なし
• 縦横3~5センチ× 3~5センチ
• 3色以上で
5. 1ブランチ=1ワード
• ...
©Akira Ikeda
• マインドマップには二つのスタイルがある
– 自由記述型
• ルール無しに自由に描いていく
• ひたすら思考を発散させながら思いつくままに描いていく
– ブレーンストーミング向き
• 抽象レベルを特に意識しなくても良...
©Akira Ikeda
自己紹介を書いてみましょう
• テーマをしっかりと考える
– イメージを頭の中に作ることを意識し,それを紙に転写する
– 文字ではなくて絵で表現すること
• メインブランチをまず考える
– いきなり深堀をしない(ひとつ...
©Akira Ikeda
自己紹介マップの例
できるだけ視覚に訴えかける
ものにできるとよい。(イラ
スト苦手でもアイコンとかで
代用すればよい)
まずは,思いついた物は全部
書くところからはじめる。
くれぐれも気楽に!
©Akira Ikeda
議事録を書いてみましょう
• テーマをしっかりと考える
– イメージを頭の中に作ることを意識し,それを紙に転写する
– 文字ではなくて絵で表現すること
• メインブランチは目次くらいがよい
• ブランチはキーワードをの...
©Akira Ikeda
テスト分析設計演習
ではテスト分析設計を体験してみましょう
©Akira Ikeda
基本的な作業手順と範囲
テスト設計
テストベース
(仕様書)
テストケース
Mind Map
直接転記
しない
テスト実装
テスト設計に
マインドマップを適用する
分析と設計の成果物として
マインドマップが作成される
...
©Akira Ikeda
仕様分析には3色ボールペンも活用!
• 仕様分析をマインドマップだけで行うのはかなり大変
– セントラルイメージやメインブランチがなかなか決まらない
• まず仕様書を3色ボールペンでチェックし,マインドマップ
を描く手...
©Akira Ikeda
全体の作業イメージ
テスト設計
テストベース
(仕様書)
テストケース
Mind Map
テスト実装
テスト分析
(仕様分析)
仕様分析に
3色ボールペンも使う
仕様分析とテスト設計を
マインドマップで考える
マインド...
©Akira Ikeda
マインドマップを描く際に意識すべき
3つのポイント
あ
わ
せ
て
,
前
述
の
勘
所
と
マ
イ
ン
ド
マ
ッ
プ
の
特
性
を
上
手
く
生
か
す
1. 仕様の把握と疑問点の洗い出し
・ 仕様の学習
・...
©Akira Ikeda
マインドマップの例
©Akira Ikeda
では,いよいよ
個人&グループワークです
頭を柔らかくしてチャレンジ!
©Akira Ikeda
お疲れ様でした!
本日はほんのさわりでしたがいかがでしたか?
本来は半日はかかることを短縮したので雰囲気だけつか
めればOKです。
別途しっかりやりたいという場合はご相談下さいね。
Upcoming SlideShare
Loading in …5
×

テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう

6,665 views

Published on

テスト分析設計についてのワークショップの資料です。
http://swquality.jp/

Published in: Technology
  • You have to choose carefully. ⇒ www.HelpWriting.net ⇐ offers a professional writing service. I highly recommend them. The papers are delivered on time and customers are their first priority. This is their website: ⇒ www.HelpWriting.net ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi there! I just wanted to share a list of sites that helped me a lot during my studies: .................................................................................................................................... www.EssayWrite.best - Write an essay .................................................................................................................................... www.LitReview.xyz - Summary of books .................................................................................................................................... www.Coursework.best - Online coursework .................................................................................................................................... www.Dissertations.me - proquest dissertations .................................................................................................................................... www.ReMovie.club - Movies reviews .................................................................................................................................... www.WebSlides.vip - Best powerpoint presentations .................................................................................................................................... www.WritePaper.info - Write a research paper .................................................................................................................................... www.EddyHelp.com - Homework help online .................................................................................................................................... www.MyResumeHelp.net - Professional resume writing service .................................................................................................................................. www.HelpWriting.net - Help with writing any papers ......................................................................................................................................... Save so as not to lose
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❤❤❤ http://bit.ly/2Q98JRS ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ♥♥♥ http://bit.ly/2Q98JRS ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう

  1. 1. ©Akira Ikeda 池田 暁 2015年4月7日 於 長崎IT技術者会 第2回勉強会 エセナ太田(東京大田区) テスト分析・設計を体感しよう ~マインドマップを活用して テスト観点を発想しよう
  2. 2. ©Akira Ikeda 2 自己紹介 • 名前:池田 暁(いけだ あきら) • 所属:某製造業 ソフトウェア開発技術導入支援部門 • 職歴:入社後、組込みシステムの設計、ソフトウェア品質保証業務を経て、 現在は設計/テストツールの導入や、プロセス改善に関する業務に 従事。最近は変更・構成管理ツールの社内普及を担当。 • 社外活動 – 委員等 • 筑波大学 大学院 高度IT技術者育成コース 非常勤講師 • NPO法人ASTER(ソフトウェアテスト技術振興協会) 理事 • JaSST(ソフトウェアテストシンポジウム) 実行委員 • WACATE(ソフトウェアテストワークショップ) 実行委員長 • 日科技連・日本品質管理学会共同部会 SQuBOK策定部会 策定メンバ • 日本品質管理学会・ACM 正会員 – 執筆活動(単行本) • ISTQBシラバス準拠 ソフトウェアテストの基礎、センゲージラーニング、2008 • ソフトウェアテスト入門 押さえておきたい<<要点・重点>>、技術評論社、2008 • ソフトウェア品質知識体系ガイド―SQuBOK Guide、オーム社、2007 • マインドマップから始めるソフトウェアテスト、技術評論社、2007
  3. 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月号 新刊紹介 マインドマップの活用法の研究と実践
  4. 4. ©Akira Ikeda 宣伝:長崎IT技術者会とは • 長崎出身や在住,かつて在住など,長崎になんらかの関わり や興味を持っている技術者の交流会 – ついこの前Facebookにグループを作りました。 • 長崎と付いていますが,中の人が長崎人なだけなので, どなたでも気軽にご参加いただけます – むしろしてください(^^; • オンラインの交流が中心ですが,長崎現地にかかわらず勉強 会活動を実施します
  5. 5. ©Akira Ikeda 宣伝:SWTest&devCamp(仮) • この夏に長崎市内にて勉強会を開催予定です – 日時:2015年8月12日 13:00~17:00(予定) – 場所:長崎市内(メルカ築町で検討中) – 当日の内容: • テスト関連の発表2件程度 • ディスカッション • 終了後懇親会有り – その他: • 遠方からお越しの方向けに,翌日13日にエクスカーションツアーを 予定しています。 是非,ご参加下さい! (遠方からお越しの方は是非観光と合わせて!)
  6. 6. ©Akira Ikeda テストにおける思考 テスト設計のお話に入る前に,ソフト設計とテストでは 思考のスタイルが異なることを確認します。これを意識 しておかないとうまくテスト観点の発想に苦労します。 (要求の勉強会ではないので,イメージで解説します)
  7. 7. ©Akira Ikeda 設計とテストにおける思考の向き • テストを考えるとき,設計時とは違う思考パターンであるこ とを理解しておく(逆方向の思考である) – 設計は問題領域を狭めていく思考 – テストは問題領域を広げていく思考 要望や要求 要件 仕様 人間の世界 計算機の世界 計 算 機 世 界 へ の 転 写 ( 機 能 化 ) 問 題 領 域 の 特 定 ・ 具 体 化
  8. 8. ©Akira Ikeda 設計の思考 • 設計では要件を,計算機世界上で「こう動くべき」「こう動 かないべき」に分類・具体化・定義することで問題領域を狭 めていく(計算機の振る舞いを定義する→仕様化) それ以外 こう動かないべき (異常系仕様) こう動くべき (正常系仕様) 「 こ う 動 く べ き 」 「 こ う 動 か な い べ き 」 に 定 義 し て い く こ と で ( 仕 様 化 す る こ と で ) , 計 算 機 と し て 扱 う 問 題 領 域 を 狭 め て い く 設計とはここを決める事
  9. 9. ©Akira Ikeda テストの思考 • テストは仕様化された事柄について「その通りに動くか」を 確認するだけでは不十分で,「それ以外で何も起きないのか 」も確認せねばならない。 それ以外 こう動かないべき (異常系) こう動くべき (正常系) テストではむしろ「それ以 外」を扱うことが重要 こう動かないべき (異常系) こう動くべき (正常系) 「 仕 様 化 さ れ た こ と が そ の 通 り に 動 く か 」 に 加 え , 「 そ れ 以 外 で 何 も 起 き な い か 」 テ ス ト と し て 扱 う 問 題 領 域 を 広 げ て 探 索 し て い く 動作を確認するだけでは単な る動作チェックにとどまる
  10. 10. ©Akira Ikeda テストすべきことの発想(認知) • テストすべき対象は「仕様として書かれていること」と「そ れ以外」 • 書かれていないことは思いつかなければならない • つまり,「それ以外」をどれだけ発想・認知できるかが勝負 それ以外 こう動かないべき (異常系) こう動くべき (正常系) 仕様書に書かれていることから テストすべきこと発想すれば良い(容易) 仕様書に書かれていないため, 思いつかなければならない 仕様領域に近いところは 比較的仕様書から発想しやすい 仕様から遠いところは 仕様書によらない発想が必要 これらの一連の行為として「テスト分析」 と「テスト設計」があり,テストすべき事 柄を発想して整理する手段として「テスト 観点」と「テスト分析設計手法」がある
  11. 11. ©Akira Ikeda テストにおける思考のまとめ • テストを考えるとき,設計時とは違う思考パターンであるこ とを理解しておく(逆方向の思考である) – 設計は問題領域を狭めていく思考 – テストは問題領域を広げていく思考 • テストは仕様化された事柄について,「仕様化されたものがその通 りに動くか」と「それ以外で何も起きないのか」と問題領域を広げ ていく • これらの一連の行為として「テスト分析」と「テスト設計」 がある • テストしなければならない事柄を具現化する一つの手段とし て「テスト観点」と「テスト分析設計手法」がある テストに取り組む場合,頭を切り換える必要がある 所謂「帽子のかぶり直し」である
  12. 12. ©Akira Ikeda テスト観点とは 「テスト分析」および「テスト設計」の開発プロセス上 の位置づけを確認しましょう。
  13. 13. ©Akira Ikeda テスト観点に関するよくある発言 • いわゆる「テスト漏れ」に対してその理由を聞くと, 「テストの観点が漏れていました」 という発言をよく聞く • テストの観点漏れを防ぐための対策に挙げられることが多い のは「テストレビューを充実します」という発言 • このときテストレビューの充実の意味は「テストレビューの 回数を増やします」だったり「時間を増やします」だったり 「有識者を増やします」であることが多い • しかしながらこれは後手後手の対策 • テストの観点漏れを防ぎたいのであればレビューで防ぐので はなく,その前に対策を打っておく必要がある • さて,あなたの現場では「テストの観点漏れに対してレビュ ー以外の手」を打っているだろうか?
  14. 14. ©Akira Ikeda 辞書を引いてみよう 観点とは • 発想[名](スル) ① 物事を考え出すこと。新しい考えや思いつきを得ること。 また、その方法や、内容。 ② 芸術作品など、表現のもとになる考えを得ること。 ③ 音楽で、楽曲のもつ気分や情緒を緩急・強弱などによって表現 すること。 • 発想[名](スル) ① あることを思いつくこと。また、その思いついた考え。思いつ き。 ② 考えを展開させたり、まとめたりして形をとらせること。 ③ 音楽で、楽曲の曲想・緩急・強弱などを表現すること。 発想 = 思いつき(発散) + まとめ(収束) + 表現 マインドマップで支援
  15. 15. ©Akira Ikeda テスト観点とは • 最終的にテストケースを作り上げるために,持っておくべき 視点やテスト対象の性質など • 切り口やといってもいい • 視点を変えながら観点を見つける • 視点とは直線的なものの見方 • 観点とは俯瞰的なものの見方 • 0.視界を定める • 1。視座を定める • 2.視点を定める • 3.観点を見つける,発想する,整理する • テスト観点に基づいてテストケースは作られなければならな い
  16. 16. ©Akira Ikeda テストプロセスの確認 「テスト分析」および「テスト設計」の開発プロセス上 の位置づけを確認しましょう。
  17. 17. ©Akira Ikeda© Akira Ikeda 17 開発プロセス(Vモデル) 基本設計 構造設計 詳細設計 実装/机上テスト コンポーネントテスト 統合テスト システムテスト 対応 対応 対応 要件定義 受け入れテスト システム仕様 書 等… 構造仕様書 等… 詳細仕様書 等… 要件定義書 等… 主にレビュー技法により 欠陥を摘出 主にテスト技法により 欠陥を摘出
  18. 18. ©Akira Ikeda テストレベルごとの作業(一例) © Akira Ikeda 18 第3世代 さらに概念と作業を分割。テストライフサイクルプロセスの考え方が普及。 テスト技法の議論は収束し,いかに戦略的なテストを行うかという議論。 分析 実装設計 実行 報告 第1世代 特に準備なく場当たり的にテストを実行(モンキーテスト) テスト実行 第2世代 テストケースの作成と実行に概念と作業を分離。テスト技法が普及。 テストケース作成 テスト実行 ※注 世代は便宜上つけているものです
  19. 19. ©Akira Ikeda© Akira Ikeda 19 V字モデルへのマッピングイメージ 基本設計 構造設計 詳細設計 実装/机上テスト 実行→報告分析→設計→実装 コンポーネントテスト 実行→報告分析→設計→実装 統合テスト 実行→報告分析→設計→実装 システムテスト 対応 対応 対応 朱文字の工程は,実装後を待たずに着手で きるため,できるだけ前倒し作業を行うと よい システム仕様 書 詳細仕様書 構造仕様書
  20. 20. ©Akira Ikeda テスト観点ベースの テスト分析設計概要 テスト観点ベースのテスト分析設計の概要を
  21. 21. ©Akira Ikeda ライフサイクル適用のイメージ テスト分析 テスト設計 テスト実装 テスト実行 仕様の理解・整 理・検討・テス ト観点の目付け テスト観点の発 想・検討・整理 テスト設計結果 に従ってテスト ケース作成(各 種テスト技法を 利用) ここで使う発散思考を マインドマップでブーストしよう! この初期から中期までの作業で テスト観点を発想しなければならない テスト実装によ り作成されたテ ストケースを実 行し、ログを取 る
  22. 22. ©Akira Ikeda いきなりテストケースを書くのは限界 • 大規模ソフトウェアは、テストも手分けする必要が出てきた – 数百万行コードのテストを一人で実施するはもはや無理だろう • 分担するには、全体の構造とバランスが見える必要がある – 分割統治には、分割するための観点と戦略が必要である • テストで考えなければならないテスト観点も大きく増加している – システムの規模増大や複雑化により,考えなければならないテスト観点が大きく増 加している • 観点そのものを発想や,観点間の関連の洗い出しや組み合わせ,優先度や重要度など • 個人個人がいきなりテストケースを作成していくと、全体としてのバ ランスを取るのが難しい – 担当者が気になるところばかりたくさんテストケースが増える →偏り、抜け – 時間が来たのでテストケース作成は終了 → テストされない機能が出てくる • これらに対応するためにテスト設計という作業を行う – テスト設計とは平たく書くと、テストの戦略に影響を与えるテスト観点の抽出とそ の構造化である → 高度に発展させるとモデリング作業 – かつてソフトウェア設計もコード規模が大きくなったことで、構造化設計やオブジ ェクト指向設計、UML等、モデリングの重要性が認識されるようになった • テストも同じ道をたどりつつある
  23. 23. ©Akira Ikeda23 皆さんどのようにテストケースを作っていますか?(初級者の場合) 仕様書 テストケース 初級者 (仕様例) ボタンを押すと音が出る (テストケース例) ボタンを押すと音が出ることを確認 初級者の悩み ・テストケースのヌケが多い! ・異常系のテストケースが抜ける! ・機能を組み合せを考慮したテストケースがかけない! ・テスト技法の使いどころがわからない! ・組織で積み上げられたノウハウが活用できない! ・自分の経験が再利用できない! などなど…… ほぼ、転記 語尾を付け足して 完成させる…
  24. 24. ©Akira Ikeda24 皆さんどのようにテストケースを作っていますか?(上級者の場合) 上級者 仕様書 テストケース テストケースを書く前に、思考を発散させながら、かつMECEを意識し て考える。なので、初級者に比較してテストケースの抜けが少なくなる! また、弱点をつくようなテストケースが作成できる! 分析/設計を行う どんな音? 押し方は? タイミングは? 類似ソフトは? ユーザは? 昔どうしたん だっけ? 上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する ・テストを行うにあたって、テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」 「組織のノウハウ」など ・テスト観点の階層や関連、組み合わせを考える ・不適切な仕様(仕様バグ)は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して、重み付けや実行順番など考える などなど……
  25. 25. ©Akira Ikeda 発想整理検討すべきテストの「観点」 • テストには、様々な「観点」が必要だと言われている – Ostrandの4つのビュー • ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー – Myersの14のシステムテスト・カテゴリ • ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回 復、操作性、セキュリティ、サービス性、文書、手続き – ISO/IEC 9126の品質特性 • 機能性、信頼性、使用性、効率性、保守性、移植性 • テストの「観点」とは何だろう? – テスト対象の持つ、テストすべき側面 – テスト対象が達成すべき性質 – テスト対象(及び含む世界)を、テストの立場からモデリングしたもの • テストする必要が無い側面は、モデリングする必要が無い • 達成する必要が無い性質は、モデリングする必要が無い – 抽象的で、階層構造を持つ • 同値分割の包括的なもの – やさしく書くと「なにをテストしよう」「どうテストしよう」といった ようなもの
  26. 26. ©Akira Ikeda (例)テストで考慮すべきテスト観点 •機能:テスト項目のトリガ –ソフトとしての機能 •音楽を再生する –製品全体としての機能 •走る •パラメータ –明示的パラメータ •入力された緯度と経度 –暗黙的パラメータ •ヘッドの位置 –メタパラメータ •ファイルの大きさ –ファイルの内容 •ファイルの構成、内容 –信号の電気的ふるまい •チャタリング、なまり •プラットフォーム・構成 –チップの種類、ファミリ –メモリやFSの種類、速度、信頼性 –OSやミドルウェア –メディア •HDDかDVDか –ネットワークと状態 •種類 •何といくつつながっているか –周辺機器とその状態 •外部環境 –比較的変化しない環境 •場所、コースの素材 –比較的変化しやすい環境 •温度、湿度、光量、電源
  27. 27. ©Akira Ikeda (例)テストで考慮すべきテスト観点 •状態 –ソフトウェアの内部状態 •初期化処理中か安定動作中か –ハードウェアの状態 •ヘッドの位置 •タイミング –機能同士のタイミング –機能とハードウェアのタイミング •組み合わせ –同じ機能をいくつカブせるか –異なる機能を何種類組み合わせるか •性能 –最も遅そうな条件は何か •信頼性 –要求連続稼働時間 •GUI・操作性 –操作パス、ショートカット –操作が禁止される状況は何か –ユーザシナリオ、10モード –操作ミス、初心者操作、子供 •出荷先 –電源電圧、気温、ユーザの使い方 –言語、規格、法規 •障害対応性 –対応すべき障害の種類 •水没 –対応動作の種類 •セキュリティ –扱う情報の種類や重要度 –守るべきセキュリティ要件 実に多くの観点を漏れがないように発想し、関連/階層など関係を整理し、 観点の重み付け/優先度の設定など、多角的に検討しなければならない!
  28. 28. ©Akira Ikeda 実に多くを考えることが必要であるが… 28 とりあえず、 テストケース表を使って考 えようかな? どうせ最終的には エクセルの表に なるわけだし 考えているときは、メモ 紙にキーワードを書くく らいだ… メモで考えるのは 大 変 だから、 何かツールが必要だよね
  29. 29. ©Akira Ikeda 大・中・小項目型によるテスト設計の例 • 問題 – 以下はよくある大・中・小項目のエクセルフォーマットですが、 テスト観点を検討するにあたって何が問題でしょう? 大項目 中項目 小項目 テストケース 機能レベル1 機能レベル2 機能レベル3 機能レベル10 機能レベル1 機能レベル8 機能レベル9 機能レベル10 機能 環境 データ 機能+環境+データ 機能 データ GUI 機能+データ+GUI 機能 データ 前提条件 機能+データ 機能 状態 イベント 状態+イベント テストカテゴリ 機能 データ 機能+データ 組み合わせ 機能① 機能② 機能①×機能②
  30. 30. ©Akira Ikeda 大・中・小項目型テスト設計の問題点 • 詳細化のレベルが揃わない、詳細化に限界がある – 偏った詳細化をしてしまう、テストケース群ごとに詳細化の偏りにばらつく – 詳細化のレベルが最大3段階で固定される • 異なるテスト観点の組み合わせを詳細化だと考えてしまう – (例)機能+環境+データ、機能+データ+GUI • テスト設計で考慮する必要の無いものが入ってしまう – (例)機能+データ+前提条件 • パラメータや前提条件はテストケースで記述 • 異なるテスト観点にぶら下げているので網羅できない – (例)機能+状態+イベント • 本来は状態遷移網羅をすべき • 組み合わせテストを押し込んでしまう – n元表を使うべき • どんな観点に着目しているのか、全体の構造を俯瞰できない – ページを何枚もめくる必要がある テストケースの表現形式を使って分析・設計を行うのは難しい
  31. 31. ©Akira Ikeda 設計作業は、検討図を作成するが… • 設計作業では、プログラムコードを書く前にUMLやフローチャート ・PADなどを描いて、顧客要求をしっかり考え、設計観点を整理し、 モデル(構造)を作っていく • 作成されたモデルを基にプログラムコードとして実装していく • テストでは、プログラムコードに相当するテストケースを描く前に、 なんらかの図を描いて、テストにおける要求をしっかり考え、テスト 観点を整理し、モデル(構造)を作っているか? • 作成されたテスト観点モデルを基にテストケースが実装されているか ? テストケースの表現形式を使って分析・設計を 行うことは、 まるで、ソフトウェアの分析・設計をコードエ ディタで行っているようなもの!
  32. 32. ©Akira Ikeda では、どういった記法がいいの? じゃぁどういった 分析・設計ツールが いいのだろうか… じゃぁ、そのような特徴をもつ 発想支援ツール、 マインドマップを 使ってみたら? テスト初期はモヤモ ヤしてるから 試行錯誤できる 記法がいいな 整理するためには 全体を俯瞰 できなくちゃ できれば構造化 しやすいものが いいかも でも、発想力を刺激して くれるものでないと、 観点が抜けちゃう!
  33. 33. ©Akira Ikeda マインドマップとは マインドマップの基本についておさらいしましょう
  34. 34. ©Akira Ikeda 説明に入る前に… 辞書を引いてみよう • 発想[名](スル) ① 物事を考え出すこと。新しい考えや思いつきを得ること。 また、その方法や、内容。 ② 芸術作品など、表現のもとになる考えを得ること。 ③ 音楽で、楽曲のもつ気分や情緒を緩急・強弱などによって表現 すること。 • 発想[名](スル) ① あることを思いつくこと。また、その思いついた考え。思いつ き。 ② 考えを展開させたり、まとめたりして形をとらせること。 ③ 音楽で、楽曲の曲想・緩急・強弱などを表現すること。 発想 = 思いつき(発散) + まとめ(収束) + 表現 マインドマップで支援
  35. 35. ©Akira Ikeda マインドマップとは? • トニー・ブザンにより考え出された図解技法 – 脳の仕組みを取り入れたもの – 思考に沿って描いていく – イメージ(図)を重要視する – 発想力を生かす – 自分の深層意識にアクセスする Wikipediaによる解説 表現したい概念の中心となるキーワードやイメージを図の中央に置き、 そこから放射状にキーワードやイメージを繋げていくことで、発想を延ば していく図解表現技法。 この方法によって複雑な概念もコンパクトに表現でき、非常に早く理解 できるとされ、注目され始めている。 人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合して いるので、理解や記憶がしやすい。 また本来は紙とペンで描くものだが、コンピュータ上で描くための専用ソ フトウェアもいくつか存在する。
  36. 36. ©Akira Ikeda マインドマップの特徴 • マインドマップには以下のような特徴がある – バードビュー • 全体を俯瞰し易い – 学習が容易 • 基本的なルールは単純で、紙とペンがあれば始められる – 半構造 • フリーなルールであるために、柔軟に構造を変更可能 – プレイバック効果 • あとで、「なぜそう考えたか」「何を描いたか」などを思い出しや すい – 発想力が刺激される • 描いているうちに他の項目との関連などから新たな発想が生まれや すい • 自分の深層意識にアクセスし、情報を引き出す – 思考の流れが絵として表現される(見える化) • 中心から外に対して思考が放射的に広がる
  37. 37. ©Akira Ikeda マインドマップは発散思考のツール • マインドマップは発散思考(放射思考)のツールである – 日本国内では、ノート術として広まってしまったため、議事録の ためのツールと理解している人も多い(!)が、実際はブレーン ストーミングのような発散思考ツールの性格が強い • すでにあるものを整理するツールではない! – 思いつきを得る – 自分にとってモヤモヤとした、つかみ所のないものをイメージ・ 具象化する • 抽象度の高いものやまだ形のないものを検討することに大き な効果 – 収束するには別のツールを使うことをおすすめ – マインドマップはブレストツールと割り切ったほうが,作業上は 使いやすい
  38. 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. 39. ©Akira Ikeda • マインドマップには二つのスタイルがある – 自由記述型 • ルール無しに自由に描いていく • ひたすら思考を発散させながら思いつくままに描いていく – ブレーンストーミング向き • 抽象レベルを特に意識しなくても良い(いくらでも詳細化できる) • 発散した思考は,別プロセスで収束させる必要がある – テンプレート型 • メイン・ブランチ,ブランチのひな形を使う • ゆるやかなルールが存在していることが多い – 情報の分析や整理に使われることが多い(系統図っぽく使われる) • 抽象レベルが固定されることが多い • 思考がテンプレートに縛られるため,自由記述型に比べて発想力は 落ちる 自由記述かテンプレートか
  40. 40. ©Akira Ikeda 自己紹介を書いてみましょう • テーマをしっかりと考える – イメージを頭の中に作ることを意識し,それを紙に転写する – 文字ではなくて絵で表現すること • メインブランチをまず考える – いきなり深堀をしない(ひとつのブランチを伸ばさない) – 全体のバランスを考えながら描いていく – バランスが悪いところは,もう少し考えてみる – 考えすぎずに描いていく • 思いついたらとりあえず描く • ブランチに紐づかないことでも,余白に描いておく – あとでつなげればよい – 発想が出なくなったら俯瞰してみる • 関係やグループを意識してみる • 他のブランチから発想する – イメージを入れる
  41. 41. ©Akira Ikeda 自己紹介マップの例 できるだけ視覚に訴えかける ものにできるとよい。(イラ スト苦手でもアイコンとかで 代用すればよい) まずは,思いついた物は全部 書くところからはじめる。 くれぐれも気楽に!
  42. 42. ©Akira Ikeda 議事録を書いてみましょう • テーマをしっかりと考える – イメージを頭の中に作ることを意識し,それを紙に転写する – 文字ではなくて絵で表現すること • メインブランチは目次くらいがよい • ブランチはキーワードをのせる – 文章を書かない,文章は分割する • 深堀できなくても気にしない – 発想を得る目的 • デザインよりも記入を優先 – デザインはあとで強調できる
  43. 43. ©Akira Ikeda テスト分析設計演習 ではテスト分析設計を体験してみましょう
  44. 44. ©Akira Ikeda 基本的な作業手順と範囲 テスト設計 テストベース (仕様書) テストケース Mind Map 直接転記 しない テスト実装 テスト設計に マインドマップを適用する 分析と設計の成果物として マインドマップが作成される テスト分析 (仕様分析)
  45. 45. ©Akira Ikeda 仕様分析には3色ボールペンも活用! • 仕様分析をマインドマップだけで行うのはかなり大変 – セントラルイメージやメインブランチがなかなか決まらない • まず仕様書を3色ボールペンでチェックし,マインドマップ を描く手がかりとする – 赤:客観的に「重要」な箇所 – 青:客観的に「まあまあ重要」な箇所 – 緑:主観的に「気になる」箇所 • チェックしている時点で,仕様の洩れや抜け, 間違いに気がつくことも多い – マインドマップを描く前に,テストベースの 品質向上できる – 仕様分析するに値する品質となっているかの チェックとしてもいいだろう
  46. 46. ©Akira Ikeda 全体の作業イメージ テスト設計 テストベース (仕様書) テストケース Mind Map テスト実装 テスト分析 (仕様分析) 仕様分析に 3色ボールペンも使う 仕様分析とテスト設計を マインドマップで考える マインドマップではなく、 各種テスト技法を活用する 分析と設計の成果物として マインドマップが作成される #あわせてチェックが入った 仕様書も作成される
  47. 47. ©Akira Ikeda マインドマップを描く際に意識すべき 3つのポイント あ わ せ て , 前 述 の 勘 所 と マ イ ン ド マ ッ プ の 特 性 を 上 手 く 生 か す 1. 仕様の把握と疑問点の洗い出し ・ 仕様の学習 ・ ウィークポイントの目付け ・ 疑問点の洗い出し 2. 発散思考の活用によるテスト観点の洗い出し ・ 少しでも多くの観点を挙げる ・ 挙がらなかったテスト観点に関するテストケースが 抜ける ・ 途中立ち止まって,自分に突っ込みを入れる ・ 「それだけ?」「そこ?」「まだあるやろ?」 ・ ブランチが伸びてないところは要注意 3. 洗い出されたテスト観点を整理する ・ テスト観点の階層関係 ・ テスト観点の重要度,優先度 ・ テスト観点間の関係
  48. 48. ©Akira Ikeda マインドマップの例
  49. 49. ©Akira Ikeda では,いよいよ 個人&グループワークです 頭を柔らかくしてチャレンジ!
  50. 50. ©Akira Ikeda お疲れ様でした! 本日はほんのさわりでしたがいかがでしたか? 本来は半日はかかることを短縮したので雰囲気だけつか めればOKです。 別途しっかりやりたいという場合はご相談下さいね。

×