テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう
•17 likes•9,106 views
Report
Share
テスト分析設計についてのワークショップの資料です。 http://swquality.jp/
More Related Content
What's hot
What's hot(20)
Similar to テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう
Similar to テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう(20)
![[Biz reach qa meetup] qa team_build](https://cdn.slidesharecdn.com/ss_thumbnails/bizreachqameetupqateambuild-190719053542-thumbnail.jpg?width=768&fit=bounds)
More from Akira Ikeda
More from Akira Ikeda(20)
Recently uploaded
Recently uploaded(12)
テスト分析・設計を体感しよう ～マインドマップを活用してテスト観点を発想しよう
- 1. ©Akira Ikeda 池田 暁 2015年4月7日 於 長崎ＩＴ技術者会 第2回勉強会 エセナ太田（東京大田区） テスト分析・設計を体感しよう ～マインドマップを活用して テスト観点を発想しよう
- 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月号 新刊紹介 マインドマップの活用法の研究と実践
- 4. ©Akira Ikeda 宣伝：長崎ＩＴ技術者会とは • 長崎出身や在住，かつて在住など，長崎になんらかの関わり や興味を持っている技術者の交流会 – ついこの前Facebookにグループを作りました。 • 長崎と付いていますが，中の人が長崎人なだけなので， どなたでも気軽にご参加いただけます – むしろしてください(^^; • オンラインの交流が中心ですが，長崎現地にかかわらず勉強 会活動を実施します
- 5. ©Akira Ikeda 宣伝：SWTest&devCamp(仮) • この夏に長崎市内にて勉強会を開催予定です – 日時：2015年8月12日 13:00～17:00（予定） – 場所：長崎市内（メルカ築町で検討中） – 当日の内容： • テスト関連の発表2件程度 • ディスカッション • 終了後懇親会有り – その他： • 遠方からお越しの方向けに，翌日13日にエクスカーションツアーを 予定しています。 是非，ご参加下さい！ （遠方からお越しの方は是非観光と合わせて！）
- 7. ©Akira Ikeda 設計とテストにおける思考の向き • テストを考えるとき，設計時とは違う思考パターンであるこ とを理解しておく（逆方向の思考である） – 設計は問題領域を狭めていく思考 – テストは問題領域を広げていく思考 要望や要求 要件 仕様 人間の世界 計算機の世界 計 算 機 世 界 へ の 転 写 （ 機 能 化 ） 問 題 領 域 の 特 定 ・ 具 体 化
- 10. ©Akira Ikeda テストすべきことの発想（認知） • テストすべき対象は「仕様として書かれていること」と「そ れ以外」 • 書かれていないことは思いつかなければならない • つまり，「それ以外」をどれだけ発想・認知できるかが勝負 それ以外 こう動かないべき （異常系） こう動くべき （正常系） 仕様書に書かれていることから テストすべきこと発想すれば良い（容易） 仕様書に書かれていないため， 思いつかなければならない 仕様領域に近いところは 比較的仕様書から発想しやすい 仕様から遠いところは 仕様書によらない発想が必要 これらの一連の行為として「テスト分析」 と「テスト設計」があり，テストすべき事 柄を発想して整理する手段として「テスト 観点」と「テスト分析設計手法」がある
- 11. ©Akira Ikeda テストにおける思考のまとめ • テストを考えるとき，設計時とは違う思考パターンであるこ とを理解しておく（逆方向の思考である） – 設計は問題領域を狭めていく思考 – テストは問題領域を広げていく思考 • テストは仕様化された事柄について，「仕様化されたものがその通 りに動くか」と「それ以外で何も起きないのか」と問題領域を広げ ていく • これらの一連の行為として「テスト分析」と「テスト設計」 がある • テストしなければならない事柄を具現化する一つの手段とし て「テスト観点」と「テスト分析設計手法」がある テストに取り組む場合，頭を切り換える必要がある 所謂「帽子のかぶり直し」である
- 13. ©Akira Ikeda テスト観点に関するよくある発言 • いわゆる「テスト漏れ」に対してその理由を聞くと， 「テストの観点が漏れていました」 という発言をよく聞く • テストの観点漏れを防ぐための対策に挙げられることが多い のは「テストレビューを充実します」という発言 • このときテストレビューの充実の意味は「テストレビューの 回数を増やします」だったり「時間を増やします」だったり 「有識者を増やします」であることが多い • しかしながらこれは後手後手の対策 • テストの観点漏れを防ぎたいのであればレビューで防ぐので はなく，その前に対策を打っておく必要がある • さて，あなたの現場では「テストの観点漏れに対してレビュ ー以外の手」を打っているだろうか？
- 14. ©Akira Ikeda 辞書を引いてみよう 観点とは • 発想［名］(スル) ① 物事を考え出すこと。新しい考えや思いつきを得ること。 また、その方法や、内容。 ② 芸術作品など、表現のもとになる考えを得ること。 ③ 音楽で、楽曲のもつ気分や情緒を緩急・強弱などによって表現 すること。 • 発想［名］(スル) ① あることを思いつくこと。また、その思いついた考え。思いつ き。 ② 考えを展開させたり、まとめたりして形をとらせること。 ③ 音楽で、楽曲の曲想・緩急・強弱などを表現すること。 発想 ＝ 思いつき(発散) ＋ まとめ(収束) + 表現 マインドマップで支援
- 15. ©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等、モデリングの重要性が認識されるようになった • テストも同じ道をたどりつつある
- 24. ©Akira Ikeda24 皆さんどのようにテストケースを作っていますか？（上級者の場合） 上級者 仕様書 テストケース テストケースを書く前に、思考を発散させながら、かつＭＥＣＥを意識し て考える。なので、初級者に比較してテストケースの抜けが少なくなる！ また、弱点をつくようなテストケースが作成できる！ 分析/設計を行う どんな音？ 押し方は？ タイミングは？ 類似ソフトは？ ユーザは？ 昔どうしたん だっけ？ 上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する ・テストを行うにあたって、テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」 「組織のノウハウ」など ・テスト観点の階層や関連、組み合わせを考える ・不適切な仕様（仕様バグ）は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して、重み付けや実行順番など考える などなど……
- 25. ©Akira Ikeda 発想整理検討すべきテストの「観点」 • テストには、様々な「観点」が必要だと言われている – Ostrandの4つのビュー • ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー – Myersの14のシステムテスト・カテゴリ • ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回 復、操作性、セキュリティ、サービス性、文書、手続き – ISO/IEC 9126の品質特性 • 機能性、信頼性、使用性、効率性、保守性、移植性 • テストの「観点」とは何だろう？ – テスト対象の持つ、テストすべき側面 – テスト対象が達成すべき性質 – テスト対象（及び含む世界）を、テストの立場からモデリングしたもの • テストする必要が無い側面は、モデリングする必要が無い • 達成する必要が無い性質は、モデリングする必要が無い – 抽象的で、階層構造を持つ • 同値分割の包括的なもの – やさしく書くと「なにをテストしよう」「どうテストしよう」といった ようなもの
- 28. ©Akira Ikeda 実に多くを考えることが必要であるが… 28 とりあえず、 テストケース表を使って考 えようかな？ どうせ最終的には エクセルの表に なるわけだし 考えているときは、メモ 紙にキーワードを書くく らいだ… メモで考えるのは 大 変 だから、 何かツールが必要だよね
- 29. ©Akira Ikeda 大・中・小項目型によるテスト設計の例 • 問題 – 以下はよくある大・中・小項目のエクセルフォーマットですが、 テスト観点を検討するにあたって何が問題でしょう？ 大項目 中項目 小項目 テストケース 機能レベル１ 機能レベル２ 機能レベル３ 機能レベル１０ 機能レベル１ 機能レベル８ 機能レベル９ 機能レベル１０ 機能 環境 データ 機能＋環境＋データ 機能 データ GUI 機能＋データ＋GUI 機能 データ 前提条件 機能＋データ 機能 状態 イベント 状態＋イベント テストカテゴリ 機能 データ 機能＋データ 組み合わせ 機能① 機能② 機能①×機能②
- 30. ©Akira Ikeda 大・中・小項目型テスト設計の問題点 • 詳細化のレベルが揃わない、詳細化に限界がある – 偏った詳細化をしてしまう、テストケース群ごとに詳細化の偏りにばらつく – 詳細化のレベルが最大3段階で固定される • 異なるテスト観点の組み合わせを詳細化だと考えてしまう – （例）機能＋環境＋データ、機能＋データ＋GUI • テスト設計で考慮する必要の無いものが入ってしまう – （例）機能＋データ＋前提条件 • パラメータや前提条件はテストケースで記述 • 異なるテスト観点にぶら下げているので網羅できない – （例）機能＋状態＋イベント • 本来は状態遷移網羅をすべき • 組み合わせテストを押し込んでしまう – n元表を使うべき • どんな観点に着目しているのか、全体の構造を俯瞰できない – ページを何枚もめくる必要がある テストケースの表現形式を使って分析・設計を行うのは難しい
- 31. ©Akira Ikeda 設計作業は、検討図を作成するが… • 設計作業では、プログラムコードを書く前にUMLやフローチャート ・PADなどを描いて、顧客要求をしっかり考え、設計観点を整理し、 モデル（構造）を作っていく • 作成されたモデルを基にプログラムコードとして実装していく • テストでは、プログラムコードに相当するテストケースを描く前に、 なんらかの図を描いて、テストにおける要求をしっかり考え、テスト 観点を整理し、モデル（構造）を作っているか？ • 作成されたテスト観点モデルを基にテストケースが実装されているか ？ テストケースの表現形式を使って分析・設計を 行うことは、 まるで、ソフトウェアの分析・設計をコードエ ディタで行っているようなもの！
- 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 自己紹介を書いてみましょう • テーマをしっかりと考える – イメージを頭の中に作ることを意識し，それを紙に転写する – 文字ではなくて絵で表現すること • メインブランチをまず考える – いきなり深堀をしない（ひとつのブランチを伸ばさない） – 全体のバランスを考えながら描いていく – バランスが悪いところは，もう少し考えてみる – 考えすぎずに描いていく • 思いついたらとりあえず描く • ブランチに紐づかないことでも，余白に描いておく – あとでつなげればよい – 発想が出なくなったら俯瞰してみる • 関係やグループを意識してみる • 他のブランチから発想する – イメージを入れる
- 42. ©Akira Ikeda 議事録を書いてみましょう • テーマをしっかりと考える – イメージを頭の中に作ることを意識し，それを紙に転写する – 文字ではなくて絵で表現すること • メインブランチは目次くらいがよい • ブランチはキーワードをのせる – 文章を書かない，文章は分割する • 深堀できなくても気にしない – 発想を得る目的 • デザインよりも記入を優先 – デザインはあとで強調できる
- 45. ©Akira Ikeda 仕様分析には３色ボールペンも活用！ • 仕様分析をマインドマップだけで行うのはかなり大変 – セントラルイメージやメインブランチがなかなか決まらない • まず仕様書を３色ボールペンでチェックし，マインドマップ を描く手がかりとする – 赤：客観的に「重要」な箇所 – 青：客観的に「まあまあ重要」な箇所 – 緑：主観的に「気になる」箇所 • チェックしている時点で，仕様の洩れや抜け， 間違いに気がつくことも多い – マインドマップを描く前に，テストベースの 品質向上できる – 仕様分析するに値する品質となっているかの チェックとしてもいいだろう
- 47. ©Akira Ikeda マインドマップを描く際に意識すべき 3つのポイント あ わ せ て ， 前 述 の 勘 所 と マ イ ン ド マ ッ プ の 特 性 を 上 手 く 生 か す 1. 仕様の把握と疑問点の洗い出し ・ 仕様の学習 ・ ウィークポイントの目付け ・ 疑問点の洗い出し 2. 発散思考の活用によるテスト観点の洗い出し ・ 少しでも多くの観点を挙げる ・ 挙がらなかったテスト観点に関するテストケースが 抜ける ・ 途中立ち止まって，自分に突っ込みを入れる ・ 「それだけ？」「そこ？」「まだあるやろ？」 ・ ブランチが伸びてないところは要注意 3. 洗い出されたテスト観点を整理する ・ テスト観点の階層関係 ・ テスト観点の重要度，優先度 ・ テスト観点間の関係