JaSST24'24 Kyushu 基調講演

2.8K Views

October 25, 24

スライド概要

2024年10月25日に沖縄で開催されたJaSST'24 Kyushu の基調講演資料です.

profile-image

クオリティアーツ代表/NaITE代表/ASTER理事/AFFORDD運営委員/Bizreach Software Quality Enabler、等。世の中に品質の技術で貢献するために活動中。 https://quality-arts.com/ https://naite.swquality.jp/ https://www.aster.or.jp/ https://affordd.jp/

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

一周まわって考える ソフトウェアテストへの マインドマップの利用 池田 暁 クオリティアーツ 代表 株式会社NDKCOM 執行役員 CTO NPO法人ASTER 理事,NaITE代表 2024/10/25(金)

2.

アジェンダ 1. 自己紹介 2. はじめに 3. マインドマップとは 4. 国内におけるテストへのマインドマップ利用のこれまで 5. テストへのマインドマップ利用の例(マインドマップ本より) 6. マインドマップを利用したテスト分析設計方法の一例 7. 発散で必要とする発想を考えてみよう 8. マインドマップを取り入れようとしたときに考えておくとよいこと 9. おわりに 2024/10/25 © Quality Arts,Akira Ikeda 2

3.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 1. 自己紹介 2024/10/25 © Quality Arts,Akira Ikeda 3

4.

プロフィール • 名前:池田暁(いけだあきら) • 主な所属: – クオリティアーツ(個人事業主) 代表 – 株式会社NDKCOM 執行役員CTO – NPO法人ASTER(ソフトウェアテスト技術振興協会) 理事 – 長崎IT技術者会(NaITE) 代表 – 公益財団法人長崎県産業振興財団 CO-DEJIMAスタートアップメンター – 筑波大学大学院後期博士課程 学生 • 出身: – 長崎県長崎市出身 • 信念: – 「ソフトウェア品質技術の力で世界を幸せに」 – 「利他,自責,有言実行」 – 「なければ作ればいいじゃない」 2024/10/25 © Quality Arts,Akira Ikeda 4

5.

業務経歴 • 日立グループ在籍時代 – 株式会社日立情報通信エンジニアリング株式会社 – 日立ハイテク ※情報通信,エンジニアリング ※医用 – 日立Astemo株式会社 ※自動車サプライヤ – そのほか,ソフトウェア革新部会ソフトウェアテストWG主査 • 日立グループ卒業してから – クオリティアーツ(個人事業主) – 株式会社ビズリーチ SQE(Software Quality Enabler) – 株式会社マネーフォワード – 株式会社NDKCOM CQO(Chief Quality Officer) 技術顧問を経て執行役員CTO(Chief Technology Officer) – その他,スタートアップ/ベンチャーや中小企業,大手製造業と幅広く支援活動 2024/10/25 © Quality Arts,Akira Ikeda 5

6.

最近の活動 • クオリティアーツ:https://quality-arts.com/ – スタートアップ・ベンチャーを含む企業に対するソフトウェア工学技術(特にソフトウェアテスト やQA分野)を中心にご支援 – ソフトウェア品質技術や開発技術の導入に関するコンサルティングや技術顧問,新人含む技術者 の教育や育成,全社レベルでの組織作り・プロセス改善など. – 開発プロセスの改善やソフトウェアテスト技術の向上,エンジニア組織構築等をご支援. • 実績(書けるもののみ) • 2023年 • 株式会社NDKCOM 技術顧問 • 大手電機メーカー ソフトウェアテスト指導者育成 • 大手電機メーカー 組織文化に関する社内講演会 • 大手ツールベンダー ソフトウェアテスト技術講演会 • 2022年 2024/10/25 • 株式会社NDKCOM 技術顧問 • 大手製造業 • SaaS系某社 QA技術に関する講演 ソフトウェアテスト技術に関する講演 © Quality Arts,Akira Ikeda 6

7.

最近の活動 • 株式会社NDKCOM :https://www.ndkcom.co.jp/ – 長崎市にある創業60年の老舗IT企業 – 技術顧問→執行役員CTOとしてご支援 – 二年間の成果 • 特別プロジェクトの立ち上げと力強い推進 • ソフトウェアテスト技術力向上のために ISTQB取得を推進,1年で九州初のプラチナ パートナーに!!! • エンジニアの発信力の向上のために,エンジ ニアBlogの立ち上げや学会(SS)での発表 • 1年でテスト設計コンテストU30クラス初参加 で準優勝!(昨年),今年も2チームが決勝 進出! ドンドン面白く,ドンドン強く,ドンドン価値を提供していくために エンジニアが楽しく,技術力を高め,成長しできる,最強の組織に全方位で変革中です! 2024/10/25 © Quality Arts,Akira Ikeda 7

8.

社外講演(本講演に関するもの一部) • 「一周まわって考えるソフトウェアテストへのマインドマップの利用」,JaSST’24 Kyushu,2024 • 「テスト設計技法その前に ~フェイスアップ,ブルドアップ,そしてマインドアッ プ」,JaSST’19 Hokkaido,2019 • 「単なる仕様チェックから卒業して技術力を向上するために ~最初に抑えたいキホン のキ~」,JaSST’18 Kyushu,2018 • 「ET2015スペシャルセッション C-5 「派生開発の問題解決セミナー2015」」,ET2015, 2015 • 「テスト設計へのマインドマップの適用の基本とTAME(Testing Aid using Mindmap Effectively)」,JaSST’09 Tokyo,2009 < 2008 The 1st Tianjin International Conference on Software Testing オープニングセッションにて> • 「体験しよう! マインドマップを使った仕様分析&テスト設計」,JaSST’08 Kyushu, 2008 • 「テストをもっと創造的に 分析・設計エクササイズ」,JaSST’08 Sapporo,2008 • 「テスト設計とその勘所 ~テスト設計へのマインドマップ活用法~」,ET2008,2008 • 「Using MindMap for Software Testing Activities」,2008 The 1st Tianjin International Conference on Software Testing(Tianjin,China),2008 • 「Using MindMap for Software Testing Activities」,2007 ASTA International Software testing conference(Seoul,Korea),2008 • その他,企業向け講演等,多数 <ET & Iot 2021 講演後 共同講演者たちと> 2024/10/25 © Quality Arts,Akira Ikeda 8

9.

主な著書・訳書,論文(一部) • 著書・訳書 – 共訳:実践ソフトウェアエンジニアリング 第9版(共訳),オーム社,2021 – 共著:SQuBOK Guide V3(共著),オーム社,2020 – 共著:[改訂新版]マインドマップから始めるソフトウェアテスト,技術評論 社,2019 – 共著:ソフトウェア品質知識体系ガイド―SQuBOK Guide V2,オーム社,2014 – 共著:Software Testing “ManiaX” vol.1 ~10,WACATE Books,2009~15 – 共訳:ISTQBシラバス準拠 ソフトウェアテストの基礎,センゲージラーニン グ,2008 – 共著:ソフトウェアテスト入門 押さえておきたい<<要点・重点>>,技術評論 社,2008 – 共著:ソフトウェア品質知識体系ガイド―SQuBOK Guide,オーム社,2007 – 共著:マインドマップから始めるソフトウェアテスト,技術評論社,2007 – その他,ソフトウェア・テストPRESS等テスト関連の雑誌やWeb媒体の連載等 • 特許 – 「車載向け統合テストケースのコードクローン解析に基づくテストケース効 率生成技術の開発」,情報処理学会,2020 2024/10/25 © Quality Arts,Akira Ikeda 9

10.

宣伝:実践ソフトウェアエンジニアリング(第9版) • 2021年12月1日に「実践ソフトウェアエンジニアリング (第9版)」の翻訳書を出版しました • 顧客に提供される最終的な品質はすべての要素の掛け算 で決まります.故に,全エンジニアが一般教養として 持っておくべき体系(のひとつ)です • 世界的にはITエンジニアを志す,大学生の一般教養的教 科書です ソフトウェアエンジニアリング・スタンダードの第9版 本書は米国においての第1版が発行(1982年)されて以来,世界45万部を超えるベ ストセラーの最新刊である第9版の邦訳書です.ソフトウェア同様,改良が続け られているソフトウェアエンジニアリングの「最良の手法」を解説している書籍 であり,現役のソフトウェアエンジニアならびに学生諸氏におすすめする1冊で す. 原書:Roger S. Pressman, Bruce R. Maxim, Software Engineering,McGraw-Hill, 2020 翻訳:西 康晴,水野 昇幸,池田 暁,井芹 久美子, 井芹 洋輝,, 岡澤 裕二, 金子 昌永, 衣笠 駿, 鈴木 一裕, 根本 紀之, 松尾 和昭, 山﨑 崇 2024/10/25 © Quality Arts,Akira Ikeda 10

11.

宣伝:8th長崎QDG • 日時:2025年2月7日(金) 10:00~18:30(予定) • 形態:オンサイトのみ • 場所:出島メッセ長崎(長崎市内) • プログラム(調整中) – 湯本 剛 氏: フリー株式会社,株式会社ytte Lab. – 水野 昇幸 氏: システムエンジニアリング – 末村 拓也 氏: Autify, Inc. – 苅田 蓮 氏: フリー株式会社 – 大西 建児 氏:株式会社株式会社ベリサーブ – 池田 暁 氏: クオリティアーツ 今回のメインテーマはソフトウェア品質・テストです! ランタンフェスティバルのど真ん中に盛大に開催します! 2024/10/25 © Quality Arts,Akira Ikeda 11

12.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 2. はじめに アブストラクトと伝えたいこと 2024/10/25 © Quality Arts,Akira Ikeda 12

13.

本講演のアブストラクト • 国内におけるマインドマップのテストへの利用について,初の公知情報は2006年にさかのぼります. • それから約18年,コミュニティ・現場問わずマインドマップの利用を見かけ,最新版であるISTQB FL シラバス(V4)にも用語が登場するに至っています.マインドマップの利用が普及している状況 です. • ただし,18年もたつと「周りが使っているからなんとなく見よう見まねで使っている.」という方 が多いのも事実,最近教示の希望が増えてきました. • 本講演では,話としては古いテストへのマインドマップの利用という話題を,特に最近QA業界に 入った方を意識して,一周まわって取り上げます. • 前提知識は必要ありません. • まずマインドマップそのものを簡単に解説し,国内におけるテスト適用への成り立ちや普及の歴史 を確認します.テストへの適用の基本やコツを紹介します.そして,あまり議論されない「発散」 において特に重要となる「発想」という行為について自らの経験から考えます. • ※注:本講演は,書籍「[改訂新版]マインドマップから始めるソフトウェアテスト」をベースとし ます. 2024/10/25 © Quality Arts,Akira Ikeda 13

14.

本日の聴講者層ターゲットと方針 ソフトウェアテストにマインドマップを利用することについて これから一周まわろうとしている方 一周まわったところで, この一周を振り返ってみたい方 一周まわったところで, 次の一周まわろうとしている人に伴走したい方 論理的な解説よりも,実業的な解説を重んじます 2024/10/25 © Quality Arts,Akira Ikeda 14

15.

一番伝えたいこと 思いつかなかったことはテストされない!!! マインドマップはテストでの分析設計に利用できる!!! 思いつくための“発想”という行為に向き合おう!!! ただ単にマインドマップという絵を描くのではなく, “発想”に もっと向き合ってみませんか? 2024/10/25 © Quality Arts,Akira Ikeda 15

16.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 3. マインドマップとは 2024/10/25 © Quality Arts,Akira Ikeda 16

17.

これ 2024/10/25 © Quality Arts,Akira Ikeda 17

18.

これ 2024/10/25 © Quality Arts,Akira Ikeda 18

19.

沢山書籍が出ています 写真は手持ちのものから トニー・ブザン氏が直 接・大きくかかわってい るものから一部. もちろんこれ以外にもた くさんあります. 2024/10/25 © Quality Arts,Akira Ikeda 19

20.

マインドマップとは? • トニー・ブザン氏により考え出された方法 – 脳の仕組みを取り入れたもので,思考に沿って描いていく – 図を取り入れる – 自分の深層意識にアクセスする Wikipediaによる解説 マインドマップ(英: mind map, mindmap)とは,トニー・ブザンが提唱する,思考の表現方法である[1].頭の中で考えている ことを脳内に近い形に描き出すことで,記憶の整理や発想をしやすくするもの. 描き方は,表現したい概念の中心となるキーワードやイメージを中央に置き,そこから放射状にキーワードやイメージを広げ, つなげていく.思考を整理し,発想を豊かにし,記憶力を高めるために,想像 (imagination) と連想 (association) を用いて思 考を展開する.この方法によって複雑な概念もコンパクトに表現でき,非常に早く理解できるとされる.人間の脳の「意味ネット ワーク」と呼ばれる意味記憶の構造(アラン・M・コリンズ(英語版),M・ロス・キリアン〈M. Ross Quillian〉ら)によく適合 しているので理解や記憶がしやすいといわれている[要出典]. しばしば「図解表現技法」や「ノート術」などと紹介されることがあるが,適切ではない.開発者のトニー・ブザンは,脳科学 や心理学の知見から,マインドマップを通してメンタルリテラシーの重要性を提唱している.メンタルリテラシーとは,簡単に言 えば頭の使い方であり,学び方を学ぶ力や,学んだことを活用する力を指す. 本来は紙とペンで描くものであるが,コンピュータ上で描くための専用ソフトウェアもいくつかある. 2024/10/25 © Quality Arts,Akira Ikeda 20

21.

マインドマップの特徴の一例 バードビュー MECE • 項目それぞれが重複することなく,全体集合として漏れがない 学習が容易 • 基本的なルールは単純で,紙とペンがあれば始められる 半構造 • フリーなルールであるために,柔軟に構造を変更可能 発想力が刺激される 思考の流れの見える化 2024/10/25 • 全体を俯瞰し易い • 他のイメージやワードとの関連から新たな発想が生まれやすい • 深層意識へのアクセスし,情報を引き出す • 中心から外に対して思考が放射的に広がる © Quality Arts,Akira Ikeda 21

22.

これ 2024/10/25 © Quality Arts,Akira Ikeda 22

23.

マインドマップのルール (引用・一部改変:『記憶力・発想力が驚くほど高まるマインドマップ・ノート術』ウィリアム・リード著/フォレスト出版/ 2005年) 1. 無地の紙を使う 2. 横長で使う 3. 中心から描く 4. テーマはイメージで描く 5. 1ブランチ=1ワード 6. ワードは単語で書く 7. ブランチは曲線で 8. 強調する 9. 関連付ける 10. 独自のスタイルで 11. 創造的に 12. 楽しむ! 2024/10/25 © Quality Arts,Akira Ikeda 23

24.

マインドマップの法則 (引用:『マインドマップ 最強の教科書』トニー・ブザン著,近田美紀子監,石原薫訳/小学館集英社プロダクション/2018年) 1. 無地の白い紙を,横長に使う.大き目の紙を使い,次から次へとサブ・ブランチを存分に展開 できるようにする. 2. 紙の真ん中にセントラル・イメージを描き,3色以上使ってテーマを絵で表す. 3. マインドマップ全体に,イメージ,シンボル,色分け,立体的表現を用いる. 4. キーワードを選び,読みやすい字(英語は大文字)で書き込む. 5. 言葉やイメージ(絵)は一つずつ個別のブランチに乗せる. 6. セントラル・イメージから放射状に,流れるようにブランチを描く.ブランチは,中心に近い ほど太く,外に向かうほど細かくする. 7. ブランチの長さはその上に記入する言葉やイメージ(絵)の長さとそろえる. 8. マインドマップ全体に色を使い,ブランチは自分なりの方法で色分けする. 9. マーカーで強調したり,矢印や接続線を使ったりして,関連する離れた項目同士を結び付ける. 10. 見やすさを意識する.スペース配分をよく考えた上で,ブランチの位置を決める.物と物の間 のスペースは,物自体と同じくらい大切な場合がある.森の樹々の間隔を思い浮かべてみよう. 脳は,木ではなく,この隙間を縫いながら,居場所や行く先を認識している. 2024/10/25 © Quality Arts,Akira Ikeda 24

25.

再掲:これ 2024/10/25 © Quality Arts,Akira Ikeda 25

26.

どんなところで使われているだろうか 企業での導入 •ルイ・ヴィトン,ディズニー,マイクロソフト,コカコーラ・IBM,国内大手… •ボーイング社 •飛行機のマニュアルを7mのマインドマップ化 •研修期間を2年から2週間に短縮,年間1000万ドルの削減 教育・医療 •フィンランドの小学校で基礎教育,国内でも教育活動 •精神病の治療に活用 スポーツ •日本サッカー協会の研修にて活用,元日本代表岡田監督も愛用 他の応用 •フォト・リーディング •発案者のポール・シーリィはマインドマップ愛用 2024/10/25 © Quality Arts,Akira Ikeda 26

27.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 4. 国内におけるテスト へのマインドマップ 利用のこれまで マインドマップ手法の生まれとこれまで 2024/10/25 © Quality Arts,Akira Ikeda 27

28.

国内のソフトウェア開発における利用 • 2000年ごろから利用が盛り上がり始めた • オブジェクト指向やXPが盛り上がり始めたタイミング – ノート術としての利用 – コミュニケーションツールとしての利用 – オブジェクト指向分析においての利用 • マインドマップで分析しそれをUML等に変換する,というような利用 • ようするに,設計前のモヤモヤしている領域のブレストを促進するためのツールとして利用がすす んだ • 当時,JUDE(現asth*)というPCツールもあり,それはマインドマップからUMLにシームレスに変換が 可能だった • テストへの利用の情報が出てくるようになったのは少し時期は離れているが,検討や実 践の時期はほぼ同じである 2024/10/25 © Quality Arts,Akira Ikeda 28

29.

マインドマップ手法の初出から現在 2006/5 2006/7 2007/1 JaSST’06 Osaka で三 色ボールペ ンとマイン ドマップを セットで発 表 マインド マップから 始めるテス ト設計…… 池田暁,鈴 木三紀夫 マインド マップから 始めるテス トケース設 計……池田 暁,鈴木三 紀夫 2007/6 テストPRESSの記事を大 幅加筆する形で発行 2024/10/25 © Quality Arts,Akira Ikeda 2019/4 12年ぶりの改版 29

30.

JaSST’06 in Osakaでの発表 • そのころ,池田は何についてもメモを取ったり試行 錯誤をするときに,マインドマップ“も”使ってい た • その話をJaSST’06 Tokyo の情報交換会で鈴木三紀 夫さんもヘビーにマインドマップを使ってきたこと を知り話が盛り上がった • その場に,JaSST Osaka 実行委員である前畑さんが いらっしゃり,次のJaSST’06 in Osakaにて発表と いうことになった • この時に,初めて 「テストへのマインドマップの利用」 についての基本的な整理がなされ国内に発信 2024/10/25 © Quality Arts,Akira Ikeda 30

31.

ソフトウェア・テストPRESSでの記事公開 • JaSST’06 in Osaka の発表を元ネタとして,ソフトウェ ア・テストPRESS vol.3にて「マインドマップから始めるテ スト設計」を執筆 – 多くのテストエンジニアに技術が知られることになった • テストPRESS vol.3の記事が好評だったことをうけ, 「マインドマップから始めるテストケース設計」を執筆 – こちらも読者アンケートで好評 2024/10/25 © Quality Arts,Akira Ikeda 31

32.

マインドマップから始めるソフトウェアテスト • 2007年に発行したソフトウェアテストの書籍 – 2007年6月に技術評論社より – ソフトウェア・テストPRESS vol.3の記事をベースに 大幅加筆 • テスト初級者向けに次を解説 – テストの作業工程 – テストの思考過程 マップ ←これを見せることにマインド • ポイント – テスト技法ではなく,テストプロセスを学べる – テストでのマインドマップの利用例を学べる – ブックガイドにて今後のテストのスキルアップのため の情報を知ることができる 2024/10/25 © Quality Arts,Akira Ikeda 32

33.

12年後の「改訂新版」の出版 • 初版から約12年後の2019年4月13発売 – このときすでに絶版,復刊ドットコムでも復刊希望 • 改定のポイント – 基本的な構成は大きく変更しない • 初級者向けに,プロセスを優しく教えるというコンセプトは 変えず – コラムを入れ替え・追加 – 陳腐化した第III部を削除,旧第IV部を第III部として大幅 加筆修正 • ツールの情報を削除し,12年の間に蓄積されたりわかった, マインドマップをうまく利用・導入するためのノウハウやコ ツを紹介 – ブックガイドの更新 – その他,情報の追加,文章表現や用語の調整 • JSTQBやIEE829→IEEE29119からの影響により 2024/10/25 © Quality Arts,Akira Ikeda 33

34.

参考:改訂新版の概観 2024/10/25 © Quality Arts,Akira Ikeda 34

35.

マインドマップを始めるソフトウェアテストが 発行されてから変わったこと テスト技術者がテスト分析やテスト設計において,マインドマップを 使ってビジュアルコミュニケーションを取ることが当たり前となった マインドマップを使うことで自然と「テスト観点」という概念を意識す るようになった 一連のテストプロセス・テストライフサイクルが一般に認知され,テス トプロセスを整備する現場が増えた テストは楽しく創造的な技術であることが認知された 2024/10/25 © Quality Arts,Akira Ikeda 35

36.

JaSSTにおけるマインドマップ関連,言及された発表 MM本は 2007年 大企業に よる事例 全国各地 での チュート リアル開 始 コミュニ ティベー スでも進 む実践と その事例 ※現在,Webサイトから識別できるもののみ 開催回 タイトル 発表者 06 Osaka 三色ボールペンとマインドマップの活用 池田暁(日立ハイブリッドネットワーク) 鈴木三紀夫(TIS) - 08 Tokyo ソフトウエアテスト分析の方法- HAYST法とマインドマップを 使って- ※ベストスピーカー賞 永田 敦 (ソニー) 有 08 Sapporo テストをもっと創造的に 分析・設計エクササイズ 池田 暁(日立情報通信エンジニアリング) 鈴木 三紀夫(TIS) 有 08 Kyushu 体験しよう! マインドマップを使った仕様分析&テスト設計 池田 暁(日立情報通信エンジニアリング) - 09 Tokyo クロージングパネル ~テスト技法からテストメソドロジへの進化を目指して~ テスト設計へのマインドマップの適用の基本とTAME 池田 暁(日立情報通信エンジニアリング) 有 ソフトウエアテストとマインドマップ,そしてAgile Inspection 永田 敦 (ソニー) 有 マインドマップによる仕様分析と要因分析法の連携 上林 裕也 (建設システム) 有 TEF札幌テスト勉強会presents:実践テストプロセス 上田 和樹 (TEF札幌テスト勉強会) 高木 進也 (TEF札幌テスト勉強会) 有 マインドマップ活用によるシステムテストの改善 - 図解表現技法による理解の共有化と発想力の向上 - 坂本 正(NTTデータMSE) 有 有 「テスト脳を活性化!マインドマップを使ったテスト分析&テ スト設計」 池田 暁(日立情報通信エンジニアリング) 鈴木 三紀夫(TIS) - 09 Hokkaido 09 Tokai 2024/10/25 © Quality Arts,Akira Ikeda 資料 36

37.

JaSSTにおけるマインドマップ関連,言及された発表 ※現在,Webサイトから識別できるもののみ 以降,テ スト設計 コンテス トを中心 として普 及・実用 化 以降,新 規性があ る話題で はなく なった (普及し た) 開催回 タイトル 発表者 10 Tokyo 『スープカレー方式』によるシステムテスト分析と設計 上田 和樹 (TEF北海道テスト勉強会) - 使える「テスト設計テンプレート」を目指して 下前 真浩 (日本電気通信システム) 根間 才治 (NEC情報システムズ) 有 10 Shikoku 第三世代に突入したソフトウェアテスト 西 康晴 (電気通信大学) 有 10 Hokkaido マインドマップで始めるブレない目標作り 小田部 健 - 10 Tokai ソフトウェアテスト初心者集合! -皆んなの悩みに皆んなで答えるぐるぐるマインドマップ- 奥村 健二(TEF東海) 加子 勝茂(ぐるぐるマインドマップ) 有 11 Hokkaido 手書き派のためのマインドマップ 書き方6テクニック 小田部 健(小野測器) 有 テスト設計コンテストに参加してみた 水野 昇幸 有 11 Tokai 設計チームのテスト設計! あまがさきてすとくらぶ 有 12 Tokyo 設計チームでテストを考えよう! あまがさきてすとくらぶ(東海代表) 有 有 話題沸騰ポットの「可撓性」テスト チーム☆N☆テスコミュ 有 有 話題沸騰ポットをもっとつついてみた! めいしゅ館 有 有 JaSSTテスト設計コンテストに出場してみた! 名野 響(めいしゅ館) 有 テスト設計コンテスト参戦記 あまがさきてすとくらぶ 有 13 Niigata マインドマップを用いたテスト要求分析・設計エクササイズ 鈴木 三紀夫 (MRTコンサルティング) 有 13 tokai マインドマップをぐるぐるするワークショップ 加子 勝茂 ー 12 kansai 2024/10/25 © Quality Arts,Akira Ikeda 資料 37

38.

JaSST九 州でマイ ンドマッ プが扱わ れるのは 10年ぶり [改訂新 版]MM本 が出版 おそらく MMについ て私がお 話をする のは今回 で最後 JaSSTにおけるマインドマップ関連,言及された発表 ※現在,Webサイトから識別できるもののみ.14~17は割愛 開催回 タイトル 発表者 18 Kyushu ※長崎 単なる仕様チェックを卒業してテスト技術力を高めていくため に ~押さえておきたいキホンのキ~ 池田 暁(ASTER) 有 19 HokKaido テスト設計技法,その前に ~フェイスアップ,次にビルドアップ,その先にマインドアッ プ~ 池田 暁(ASTER) 有 体験しよう!テスト分析設計エクササイズ ~マインドマップを使ってテスト設計マインドアップ!(初心 者向け)~ 吉田 絵理(日本ナレッジ) 金丸 優介(日本ナレッジ) 岡野 麻子(NaITE) 角田 俊(NaITE) 池田 暁(ASTER) 有 一周まわって考えるソフトウェアテストへのマインドマップの 利用 池田 暁(クオリティアーツ) 公開 予定 24 Kyushu 種別/地域 北海道 基調講演・招待講演 1 チュートリアル 2 一般発表・ワークショップ 5 合計 8 2024/10/25 東北 新潟 東京 東海 資料 関西 四国 九州 2 1 0 1 © Quality Arts,Akira Ikeda 1 1 9 3 3 9 4 3 0 3 38

39.

その他の団体での主だった発表や研究 コミュニティでの勉強会 •2006年から2010年にかけてかなりの数 SWEST •2007年,および2008年に,テスト観点の話題とセットで ET •「テスト設計とその勘所 ~テスト設計へのマインドマップ活用法~」,ET2008,2008 SQiP(SQiPライブラリ) •直交表とマインドマップを使った効果的なテスト設計 •浅尾 義則(アイエス情報システム) ,足立 達哉(オムロンアミューズメント) ,市川 正美(エス・キュー・シー) , 小澤 純(山武) ,成河 好信(日立システムアンドサービス) •https://www.juse.jp/sqip/library/shousai/?id=38 •短納期型開発プロジェクトのためのテスト手法 「FaRSeT(Flexible and Rapid Software Test)」の適用と効果 •上田 和樹(日本ナレッジ㈱) ,丹場順次(日本ナレッジ㈱) ,工藤修悟(日本ナレッジ㈱) •https://www.juse.jp/sqip/library/shousai/?id=398 •マインドマップを適用したソフトウェアテストプロセスの構築 •来海大輔 (イシダ) ,田中桂三 (オムロン) ,中嶋良秀 (ノーリツ) ,平岡岳 (リンクレア) ,村上仁 (ニコン) •https://www.juse.jp/sqip/library/shousai/?id=192 2024/10/25 © Quality Arts,Akira Ikeda 39

40.

ISTQBシラバスへのマインドマップの言及 Agile Tester のシラバスに初めて登場 •探索的テストで利用するとよいと書かれている FL V4でも,マインドマップに言及 •マインドマップを使うことはより当たり前となっていくと想像される WWでマインドマップは全員が持つべき基礎知識となった •今回,歴史と基本を知り,ワークショップにてきちんと身につけま しょう 2024/10/25 © Quality Arts,Akira Ikeda 40

41.

参考:海外でのマインドマップ for テスト • ASTERとして海外に新たなテスト手法として紹介したのは以下の二つ – 「Using MindMap for Software Testing Activities」,2007 ASTA International Software testing conference(Seoul,Korea),2008 • 鈴木三紀夫さんと池田の二人で発表 – 「Using MindMap for Software Testing Activities」,2008 The 1st Tianjin International Conference on Software Testing(Tianjin,China),2008 • 池田による単独 • 海外におけるマインドマップに関する研究や発表 – 池田が調べた限り,2007以前のものは見つけられない – 故に,本手法は日本発祥の手法と言ってもよいと考えられる – 現在もいくつかのイベントや学会での発表がされているよう – 注意:本格的なサーベイはできていません 2024/10/25 © Quality Arts,Akira Ikeda 41

42.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 5. テストへのマインド マップ利用の例 利用の例をいくつか眺めてみましょう 2024/10/25 © Quality Arts,Akira Ikeda 42

43.

マインドマップ本におけるテストプロセス (テストレベルごと) • 一部名称や順序等が異なることに注意 – ISTQBのジェネリックなプロセスには準拠していない – いち担当者が実際に手を動かすときのイメージに近い 形で構築している – テストとはなにか右も左もわからない新人レベルを意 識しているため • ISTQBベースでテストプロセスを構築している場合, エッセンスを再配置するとよいでしょう (テストプロセスの設計における,構成アクティビ ティの参考とする) 2024/10/25 © Quality Arts,Akira Ikeda 43

44.

仕様分析への利用例 • 要件定義書から,テストタイプを抜き出したり,発想したりすることに利用 2024/10/25 © Quality Arts,Akira Ikeda 44

45.

テスト計画への利用例 • テスト計画項目のうち,「アプローチ」の検討に利用 2024/10/25 © Quality Arts,Akira Ikeda 45

46.

テスト設計への利用例 • テストタイプの目的や要件,どのようなテストをすべきかの検討に利用 2024/10/25 © Quality Arts,Akira Ikeda 46

47.

テスト実装への利用例 • テスト設計の結果から,ローレベルテストケースとして必要となる具体的なパラメータ を検討に利用 2024/10/25 © Quality Arts,Akira Ikeda 47

48.

テスト実行への利用例 • テストケースの実行ログやインシデントレポートのメモを記録することに利用 2024/10/25 © Quality Arts,Akira Ikeda 48

49.

テスト報告への利用例 • テスト結果を報告するための,テストログやインシデントレポートを報告内容に適合す るように要約するために利用 2024/10/25 © Quality Arts,Akira Ikeda 49

50.

[少し寄り道] テストに必要 となる思考 「設計」と「テスト」,「チェック」と「テスト」を 分けて考えてみよう © Quality Arts,Akira Ikeda 2024/10/25 50

51.

ソフトウェア開発で必要となる基本的な思考 設計のための思考 テストのための思考 ※ご注意 様々な考え方があると思いますが, 本講演ではわかりやすさを重視して,このように単純化してお話しします 2024/10/25 © Quality Arts,Akira Ikeda 51

52.

設計とは問題領域を狭めていく行為 人間の世界 計算機の世界 問 題 領 域 の 特 定 ・ 具 体 化 ( ) 夢や要望,(初期の)要求 計 算 機 機世 能界 化へ の 転 写 要件 仕様 問題領域を狭めていく 2024/10/25 © Quality Arts,Akira Ikeda 52

53.

設計時の思考 設計では要件を,計算機世界上で「こう動くべき」「こう動かないべき」に分類・具体 化・定義することで問題領域を狭めていく(計算機の振る舞いを定義する→仕様化) 「 「 」 め計 に て算 定 こ こ い機 義 う う くと し 動 動 し てかく て いなべ 扱 くいき う こべ 問 とき 題で 領, 域 を 狭 」 2024/10/25 © Quality Arts,Akira Ikeda 仕様外 こう動かないべき (異常系仕様) こう動くべき (正常系仕様) 注意:わかりやすさを優先した図であって,ベン図 ではありません 53

54.

テスト時の思考 テストは仕様化された事柄について「その通りに動くか」を確認するだけでは不十分で, 「それ以外で何も起きないのか」も確認せねばならない. こう動くべき (正常系仕様) こう動かないべき (異常系仕様) こう動くべき (正常系仕様) 」 2024/10/25 それ以外(仕様外) 」 仕様を確認するだけでは 単なる動作チェック 「 「 こう動かないべき (異常系仕様) 問 に 題そ加仕 領れえ様 域以,が そ を外 の 広で 通 げ何 り ても に 探起 動 索き く しな か てい いか く © Quality Arts,Akira Ikeda テストではむしろ 「仕様外」を扱うことが重要 54

55.

テストすべきことの発想(認知) • チェックすべき対象は「仕様として書かれていること」,テストすべき対象は「仕様 外」と捉えるとわかりやすくなる • 仕様書に書かれていない「仕様外」をどれだけ発想・認知できるかが勝負 こう動かないべき (異常系仕様) 仕様領域に近いところは 比較的仕様書から発想しやすい と行 い間 うを こ読 とむ 」 仕様書に書かれていないため, 思いつかなければならない 「 仕様外 こう動くべき (正常系仕様) 仕様から遠いところは 仕様書によらない発想も必要 発想・探索 仕様書に書かれていることから チェックすべきこと発想すれば良い(容易) 2024/10/25 この仕様外に対応していくための1つの手段と して「テスト分析」と「テスト設計」があり, テストすべき事柄を発想して整理する手法と して「テスト分析設計手法」がある © Quality Arts,Akira Ikeda 55

56.

テスト設計技法(テスト観点ベース) 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法 ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェック ゆも豆 Tiramis ツリー (MM) テストカテゴリ分析を実施.機能はMM - TAME ツリー (MM) テスト設計思考の可視化とレビューによるテ スト観点の洗い出しおよび整理 - SEC BOOKS:高信頼化ソフトウェアのための開発手法ガイドブックから引用 https://www.ipa.go.jp/files/000005144.pdf マインドマップによる手法以外にもテスト観点ベースのテストの分析設計技法がある 複数の手法を試して自身の職場に適用できるものを活用しよう そのほかASTER主催テスト設計コンテストの資料も参考になる(http://aster.or.jp/business/contest.html) 2024/10/25 © Quality Arts,Akira Ikeda 56

57.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 6. マインドマップを利 用したテスト分析設 計方法の一例 マインドマップによるテスト分析設計の一例を紹介します (TAME) 2024/10/25 © Quality Arts,Akira Ikeda 57

58.

初級者あるある 仕様書等 テストケース 単なる転記 初級者 (仕様例) ボタンを押すと音が出る (テストケース例) ボタンを押すと音が出ることを確認 初級者の悩み 語尾を付け足して完成させる, ・テストケースのヌケが多い! 単なるチェック止まり! ・異常系のテストケースが抜ける! ・機能を組み合せを考慮したテストケースがかけない! ・テスト技法の使いどころがわからない! ・組織で積み上げられたノウハウが活用できない! ・自分の経験が再利用できない! などなど…… 2024/10/25 © Quality Arts,Akira Ikeda 58

59.

上級者の頭のなか 仕様書等 どんな音? 押し方は? タイミング は? 類似ソフト は? テストケース ユーザは? 昔どうしたん だっけ? いろいろ発想する 上級者 仕様書に書かれてい ないことも発想する 上級者はテスト観点を発想/検討したうえでテストケースを作成する ・本当にチェックすべき内容か見極める ・テストを行うにあたって,テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」「組織のノウハウ」etc... ・テスト観点の階層や関連,組み合わせを考える ・不適切な仕様(仕様バグ)は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して,重み付けや実行順番など考える などなど…… 2024/10/25 © Quality Arts,Akira Ikeda 59

60.

実に多くを考えることが必要であるが… 考えるっていっても 頭の中だけじゃ 大 変 だよな とりあえず, テストケース表を使って 考えようかな? どうせ最終的には エクセルの表になる わけだし 2024/10/25 © Quality Arts,Akira Ikeda 60

61.

大・中・小項目型によるテスト設計の例 • 問題 – 以下はよくある大・中・小項目のエクセルフォーマットですが,テスト観点を検討するにあ たって何が問題でしょう? 大項目 中項目 小項目 テストケース 機能レベル1 機能レベル2 機能レベル3 機能レベル10 機能レベル1 機能レベル8 機能レベル9 機能レベル10 機能 環境 データ 機能+環境+データ 機能 データ GUI 機能+データ+GUI 機能 データ 前提条件 機能+データ 機能 状態 イベント 状態+イベント テストカテゴリ 機能 データ 機能+データ 組み合わせ 機能① 機能② 機能①×機能② 2024/10/25 © Quality Arts,Akira Ikeda 61

62.

大・中・小項目型テスト設計の問題点 詳細化のレベルが揃わない,詳細 化に限界がある 異なるテスト観点の組み合わせを 詳細化だと考えてしまう • 偏った詳細化をしてしまう,ばらつく • 詳細化のレベルが最大3段階で固定される • (例)機能+環境+データ,機能+データ+GUI テスト設計で考慮する必要の無い ものが入ってしまう • (例)機能+データ+前提条件 異なるテスト観点にぶら下げてい るので網羅できない • (例)機能+状態+イベント • パラメータや前提条件はテストケースで記述 • 本来は状態遷移網羅をすべき 組み合わせテストを押し込んでし まう • n元表を使うべき どんな観点に着目しているのか, 全体の構造を俯瞰できない • ページを何枚もめくる必要がある コードエディタを使って, ソフトウェア設計をして いるようなものである! テストケースの表現形式を使ってテスト設計を行うのは難しい 2024/10/25 © Quality Arts,Akira Ikeda 62

63.

どうやらテストケース表ではだめらしい 表で観点を出す, つまりブレストは 難しいな 試行錯誤できる 記法がいいな できれば構造化 しやすいものが いいかも 整理するためには 全体を俯瞰 できなくちゃ でも,発想力を刺激し てくれるものでないと, 観点が抜けちゃう! じゃぁ, マインドマップを使ってみたら? 2024/10/25 © Quality Arts,Akira Ikeda 63

64.

マインドマップの利用イメージ 仕様書 テストケース マインドマップを描く 初級者 マインドマップを描くことで, ・「考える」行為を明確に実行できる,単純な仕様の転記がなくなる ・仕様書に書かれていないことにも思考が誘導される ・マインドマップの特性により,思考の発散がブーストされる ・描いたものをセルフレビューできる,他の人に意見をもらいやすくなる 2024/10/25 © Quality Arts,Akira Ikeda 単なる転記では なくなる ,etc… 64

65.

テスト分析・設計にマインドマップを活用 テストケースの品質に大きな影響を与え, かつ,仕様外への発散思考が特に重要な ・テスト分析 ・テスト設計 にマインドマップを使ってみよう ・マインドマップの概要 ・マインドマップの適用を見据えた テスト分析&テスト設計の作業と勘所 ・マインドマップを使った作業手順 を説明します テスト分析・設計のひとつのやり方として紹介します 2024/10/25 © Quality Arts,Akira Ikeda 65

66.

2024/10/25 © Quality Arts,Akira Ikeda 66

67.

再掲:マインドマップとは? • トニー・ブザンにより考え出された表現方法 – 脳の仕組みを取り入れたもので,思考に沿って描いていく – 図を取り入れる – 自分の深層意識にアクセスする Wikipediaによる解説 マインドマップ(英: mind map, mindmap)とは,トニー・ブザンが提唱する,思考の表現方法である[1].頭の中で考えている ことを脳内に近い形に描き出すことで,記憶の整理や発想をしやすくするもの. 描き方は,表現したい概念の中心となるキーワードやイメージを中央に置き,そこから放射状にキーワードやイメージを広げ, つなげていく.思考を整理し,発想を豊かにし,記憶力を高めるために,想像 (imagination) と連想 (association) を用いて思 考を展開する.この方法によって複雑な概念もコンパクトに表現でき,非常に早く理解できるとされる.人間の脳の「意味ネット ワーク」と呼ばれる意味記憶の構造(アラン・M・コリンズ(英語版),M・ロス・キリアン〈M. Ross Quillian〉ら)によく適合 しているので理解や記憶がしやすいといわれている[要出典]. しばしば「図解表現技法」や「ノート術」などと紹介されることがあるが,適切ではない.開発者のトニー・ブザンは,脳科学 や心理学の知見から,マインドマップを通してメンタルリテラシーの重要性を提唱している.メンタルリテラシーとは,簡単に言 えば頭の使い方であり,学び方を学ぶ力や,学んだことを活用する力を指す. 本来は紙とペンで描くものであるが,コンピュータ上で描くための専用ソフトウェアもいくつかある. 2024/10/25 © Quality Arts,Akira Ikeda 67

68.

再掲:マインドマップの特徴の一例 バードビュー MECE • 全体を俯瞰し易い • 項目それぞれが重複することなく,全体集合として漏れがない 学習が容易 • 基本的なルールは単純で,紙とペンがあれば始められる 半構造 • フリーなルールであるために,柔軟に構造を変更可能 発想力が刺激される • 描いているうちに他の項目との関連などから新たな発想が生まれやすい • 深層意識へのアクセスし,情報を引き出す 思考の流れの見える化 • 中心から外に対して思考が放射的に広がる これらの特徴を上手く生かそう♪ 2024/10/25 © Quality Arts,Akira Ikeda 68

69.

こういったもの 2024/10/25 © Quality Arts,Akira Ikeda 69

70.

済 2024/10/25 © Quality Arts,Akira Ikeda 70

71.

この講演での「テスト分析」と「テスト設計」 テストケースの作成 テストの実行 作業/概念で分ける 仕様分析 仕様等の理解・整 理・検討・テスト観 点やテストタイプの 目付け テスト設計 テスト観点や手テ ストタイプの発 想・検討・整理, テスト技法の適用 ここにマインドマッ プを使うぞ! 2024/10/25 テスト実装 テスト実行 テスト報告 詳細テストケース・ スクリプト等の作成 (適切なフォーマッ トに表現) テストケースを 実行し,ログを 取,バグ報告 テストの結果やロ グを整理し,当該 テストレベルでの テスト活動を評価 する ※注意 本講演ではテスト観点の発想はテ スト設計で行ないますが, 他の手法ではテスト分析で行なう 場合もあります. © Quality Arts,Akira Ikeda 71

72.

仕様分析の作業と勘所(1) 仕様分析 テスト設計 設計仕様やテストへの要求の理解・整理・検討(純粋理解) • 知らないものはテストできない! • 設計仕様に関する思想や観点,構造や構成物を理解する • どういったものを作ろうとしているかのイメージをつかむ • 設計者が特に重要と考える部分は,テストでも重要度が高いことがほとんど • 顧客先でどのように利用されるのか • テストへの要求や制約,品質目標等の認識 テスト設計の手がかりを作る(テストの視点で理解) • テストすべき“要求”や“要件”,“仕様”や“機能” • ソフトウェアのウィークポイントの目付け • 過去のテストの経験からひっかかるところ,気配を感じるところ • テストタイプの候補抽出 • その他の疑問点 • 疑問が生じる箇所は仕様がこなれていない可能性がある 2024/10/25 © Quality Arts,Akira Ikeda 理解が二種類 あることに気 を付けて! 72

73.

テスト分析の作業と勘所(2) 仕様分析 テスト設計 仕様の抜け漏れの発見と修正へのアクション •仕様の欠陥を発見したら,設計部門にフィードバックし,仕様の高品質化をはかる •仕様書の高品質化は即ちテストベースの高品質化であり,そこから生み出されるテスト設計仕様やテストケースの 高品質化に寄与する •良い仕様書からは,良いコードと良いテストケースが生まれる •欠陥以外でも,疑問を生じたことは積極的に問い合わせる テスト戦略へのフィードバック •分析結果の情報をテストの戦略や計画に反映 仕様が理解できなかったり抜け漏れが多い場合,開発者に見直しを要請する テスト分析の作業はある意味においてテストの立場からのレビュー行為でもある どれだけ正しい仕様を深く理解できるかも良いテスト設計への鍵 2024/10/25 © Quality Arts,Akira Ikeda 73

74.

テスト設計の作業と勘所(1) 仕様分析 テスト設計 テスト観点の発想 • 「なにをテストしよう」「どうテストしよう」が思いつかないと話が始まらない • 仕様書の分析結果や過去の経験,組織ノウハウから • テストカテゴリの利用 • Myersの14のシステムテスト・カテゴリ • ボリューム,ストレス,効率,ストレージ,信頼性,構成,互換性,設置,回復,操作性,セキュリ ティ,サービス性,文書,手続き • ISO/IEC 25010の品質特性 • システム/ソフトウェア製品品質 • 機能適合性,性能効率性,互換性,使用性,信頼性,セキュリティ,保守性,移植性 • 利用時の品質 • 有効性,効率性,満足性,リスク回避性,利用状況網羅性 • 組織に蓄積されたガイドワード • テスト設計を進めるなかで得られる新たな発想 2024/10/25 © Quality Arts,Akira Ikeda 74

75.

テスト設計の作業と勘所(2) 仕様分析 テスト設計 テスト観点の剪定・整理 • テスト観点には重要度や優先度が存在する • 全てのテストは多くの場合やりきれないため,テスト観点に優先度をつける • テストする必要のない観点や優先度・重要度の低い観点は切り落とす • 切り落としたテスト観点とその理由は記録に残しておくこと • 無秩序に発想したテスト観点を整える • 観点の階層や観点間の関連を検討する テスト技法の適用 • 観点モデルの観点要素に対して対応するテスト技法をアサインし,実行する テスト戦略へのフィードバック • テスト設計結果の情報をテストの戦略や計画に反映 ここでどれだけテスト観点を発想できるかがテスト設計の鍵 しかし,テスト観点をただ洗い出すだけでは不十分 テスト観点の剪定を行い階層や関連関係を整理する 2024/10/25 © Quality Arts,Akira Ikeda 75

76.

済 2024/10/25 © Quality Arts,Akira Ikeda 済 76

77.

マインドマップ適用時の基本的な作業手順と範囲 テスト設計に マインドマップを適用する テスト分析 テストベース (仕様書等) テスト設計 (観点モデルの作成) 直接転記 しない テスト設計 (テスト技法の適用) テスト実装 テストケース 2024/10/25 Mind Map 分析と設計の成果物として マインドマップが作成される マインドマップではなく, 各種テスト技法を活用する © Quality Arts,Akira Ikeda 77

78.

テスト分析には3色ボールペンも活用しよう! • テスト分析をマインドマップだけで行うのはかなり大変 – セントラルイメージやメインブランチがなかなか決まらない • まず仕様書を3色ボールペンでチェックし,マインドマップを描く手がかりとする – 赤:客観的に「重要」な箇所 – 青:客観的に「まあまあ重要」な箇所 – 緑:主観的に「気になる」箇所 • チェックしている時点で,仕様の洩れや抜け, 間違いに気がつくことも多い – マインドマップを描く前に,テストベースの 品質向上できる – テスト分析するに値する品質となっているかの チェックとしてもいいだろう • 特に「純粋理解」において重要 2024/10/25 © Quality Arts,Akira Ikeda 78

79.

マインドマップ適用時の基本的な作業手順と範囲 テスト分析と設計に マインドマップを適用する テスト分析 テストベース (仕様書等) 直接転記 しない テスト設計 (観点モデルの作成) テスト分析に 3色ボールペンも使う テスト設計 (テスト技法の適用) テスト実装 テストケース 2024/10/25 Mind Map 分析と設計の成果物として マインドマップが作成される マインドマップではなく, 各種テスト技法を活用する © Quality Arts,Akira Ikeda 79

80.

マインドマップの例 メモや疑問 観点を思いつき,そこにテスト技法を適用している 2024/10/25 © Quality Arts,Akira Ikeda 80

81.

マインドマップの例 2024/10/25 © Quality Arts,Akira Ikeda 81

82.

マインドマップの例 2024/10/25 © Quality Arts,Akira Ikeda 82

83.

整理:マインドマップを使った全体の流れ 疑問や不明点は確認 テストケース 仕様書 仕様書を読む 作成・ 修正 ⇔ マインドマップを描く 単なる転記は絶対ダメ! (テストケース) (仕様例) ・ボタンを押すと音が出る ・ ・ ・ ・ ・ マインドマップを適用して,単なる仕様チェックから脱却する ・テストケースは仕様を単純に転記しない ・仕様に書かれていないことも考える ・テストベースを深く理解するために三色ボールペンを使う ・テスト観点を発想するためにマインドマップを使う ・発想したものからテストしなければならないものをまとめる ・テストの全体像をまとめ,テスト技法を適用してテストケースを作る 2024/10/25 © Quality Arts,Akira Ikeda 考えてみよう! 83

84.

あるプロジェクトへの導入事例 仕様書 仕様分析 は 開始OK か? 初期分析 まず,仕様書が仕様分析対象のレベルに達しているか,全体をざっくりチェックする このときツールとして,3色ボールペンを利用 OK 仕様書の品質が仕様分析やテスト分析を行うに至らない場合,設計部門に対し見直しを依頼 仕様書の分析 テストの立場からの分析を, テスト設計を意識して行う 初期チェック以上に詳細に分 析を行う. 仕様の分析が 終了したら, テスト設計を行う テスト設計 テスト観点を列挙し,階層化 や重要度・優先度付けを行う 仕様に対する ほか,観点間の関連を洗い出 疑問点が生じたら, して表現する. 分析に戻る 仕様書に多くの問題がある場合,再度見直しを依頼 2024/10/25 © Quality Arts,Akira Ikeda テスト設計が甘い場合, 再度見直し 仕様分析 & テスト設計(複数人での作業) 資料のひとつとし てマインドマップ を利用 レビュー実施 合格か? 合格 テスト技法適 用へ 84

85.

複数人によるテスト分析&テスト設計 全体の方向性の検討 複数人それぞれで 分析&設計 それぞれの 分析&設計結果を集約 ベテラン 結果の集約 分析&設計の指針 新人 他部門の有識者 分析&設計する上での意識あわせを マインドマップを共有作成して行う ・大雑把な仕様やコンセプトの確認 ・使用するテストベースの確認 ・使用するテストカテゴリの確認 ・スケジュール等,テスト計画の内容 etc… 2024/10/25 複数人で分析&設計を行うことによって, 多角的な検討を行う ・ベテランや新人 ・ドメインごとのエキスパート ・他部門の有識者 etc… © Quality Arts,Akira Ikeda 複数人で作成した分析&設計結果のマッ プをひとつのマップに集約する ・集約過程におけるレビュー効果 ・ノウハウの水平展開(教育効果) ・テスト分析&設計と戦略の意識統一 etc… 85

86.

現場担当者に聞く,主な得られた効果 1. テスト観点の全体像が見える • どこに重きを置くか,どことどこを組み合わせるかの検討が容易に • 観点ごとに担当者を決めるなど共同作業がやりやすくなる 2. テスト技法が適用し易くなる • テスト観点ごとに,適用し易いテスト技法をマッピング • テスト観点・テストタイプと関連している技法を選択できる 3. 担当者における,テスト意図の見える化 • 各担当者の思考の流れが描かれることで,結果に対する理由が見やすくなる • なぜそのテスト観点なのか • なぜその階層関係なのか • 他人の意図が見えるだけではなく自分の意図も見える • セルフレビューができる 4. テストに対する意識とモチベーションの向上 • テストは設計されるものであるという認識 • 目に見える成果物が絵で描かれるため,楽しい • クリエイティブな活動をしているという誇り 2024/10/25 © Quality Arts,Akira Ikeda 86

87.

現場担当者に聞く,その他の効果 1. 仕様書のレビュー効果 • 違った観点からの分析により,仕様における漏れ抜けを発見 • 設計部門が仕様書の見直しを行うことで,手戻りの減少 2. テスト戦略へのフィードバック • テスト観点のモデリングを行うことで,戦略をもったテスト計画が作成可能に • テスト観点の重要度からテスト実行スケジュールを検討するなど 3. テストケースの増減 • 増えたところ • そもそも抜けていたテスト観点や組み合わせに従ったテストケースが増加 →テストの洩れの防止 • 減ったところ • テスト観点の重要度・優先度づけにより,無駄に作りすぎていたテストケースの削減 →テストの効率化 4. テスト担当者のスキルアップ • ベテランの描いたマップを参照することで,自分にない“観点”の獲得 • ビギナーの思考が見えることで,適切なアドバイスができる 2024/10/25 © Quality Arts,Akira Ikeda 87

88.

再掲:テストの設計技法(テスト観点ベース) 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法 ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェック ゆも豆 Tiramis ツリー (MM) テストカテゴリ分析を実施.機能はMM - TAME ツリー (MM) テスト設計思考の可視化とレビューによるテ スト観点の洗い出しおよび整理 - SEC BOOKS:高信頼化ソフトウェアのための開発手法ガイドブックから引用 https://www.ipa.go.jp/files/000005144.pdf マインドマップによる手法以外にもテスト観点ベースのテストの分析設計技法がある 複数の手法を試して自身の職場に適用できるものを活用しよう そのほかASTER主催テスト設計コンテストの資料も参考になる(http://aster.or.jp/business/contest.html) 2024/10/25 © Quality Arts,Akira Ikeda 88

89.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 7. 発散で必要とする発 想を考えてみよう 極めて経験的,主観的な考えを述べます 2024/10/25 © Quality Arts,Akira Ikeda 89

90.

ご注意 • この章については,池田個人の,これまでのマインドマップ利用経験からくる, 経験的・主観的な解説です なんらかの学における整理を基盤とはしていませんのでご注意ください • 経験・主観から, マインドマップ利用初級者のみなさんが ほぼ全員最初に躓く 「発想とは何か」 を乗り越えるヒントをお伝えできればと思います 2024/10/25 © Quality Arts,Akira Ikeda 90

91.

私が良く受ける質問 テスト設計へのマインドマップの利用について,毎回と言っていいほど受ける質問に以下 のようなものがあります. – マインドマップを描こうとしても筆がとまってしまいます – うまくブランチを伸ばせません – 紙いっぱい使えません – 絵を描くのが苦手です – もっと発散したいのですが,思いつくことが苦手です – 抜け漏れがないように新たな発想を得たいのですが… – そもそも発想というものが 良く分かりません… 2024/10/25 © Quality Arts,Akira Ikeda 91

92.

マインドマップを使えば発想が豊かになるのか •答え:なりません • 残念ながら, 普段から発想が苦手な人が マインドマップを使ったとたんに発想豊かな人には 変身できることはありません • 発想というものは 「自分の中になかった新しいことをふと思いつくこと」 ということで理解されているが,果たしてそれは本当なのだろうか… • そもそも発想という行為とは…? そこで,発想って???について,考えてみた 2024/10/25 © Quality Arts,Akira Ikeda 92

93.

池田がこれまでの経験から意識している 発想に関する一連の流れ • 発想が行われるのは「内界」,それは仕事として使うためには「外界」に出す必要がある 内界 外界 モデリングした情報を発信 ・日本語 ・マインドマップ ・etc 記憶 2024/10/25 発想・発散 収束・見え る化 © Quality Arts,Akira Ikeda 定義化 (外界) 利用 (外界) 93

94.

「発想」についての経験的理解 池田のこれまでの経験から, 「思いついた」というのは,本当は「思い出した」,である • 「すっかり忘れていたものを「ハッ」と思いだしたこと」を, 新たな概念を思いついたと誤解している – 思い出す以外には,思い出している知識と知識をつなげたり組み合わせたりして, 新たな概念(+α概念)を思いつくこと(≒作り出すこと)は可能 • マインドマップを描いているとき,あれもあったな,これもあったなという 思い付きはすでに自分の中にあるものを思い出しているだけである • つまりマインドマップは,知っていたが忘れてしまったと思っている 知識や情報を深層から引っ張り出したり,表化した知識と知識を 結合させて+α概念とすることを,促進してくれるツールである これを理解していないと,うまくいかない!!! 2024/10/25 © Quality Arts,Akira Ikeda 94

95.

ならば,どうやって発想豊かになるか 発想は「忘れていたと思っていた自分のなかにある情報や知識」が源泉であるならば, 発想を豊かにするためにはその源泉を豊かにすしかない • テストの文脈で,源泉を豊かにするために – まず最低限の知識・情報として • 過去起こった事実(不正や障害,欠陥やエラー,ミス) • プロダクトやドメインに関する知識・情報 • ソフトウェアサイエンスおよびエンジニアリングの知識・情報 • 組織としての知(組織が積み上げてきた情報やノウハウ,コツ) – その他,それらによらない多様な知識・情報・経験も必要 • つまり,日々,あらゆるものに興味を持って生きることが大切 • 次の3つを徹底し,大切にする – いろんな人と話す – いろんな本を読む – いろんな体験をする 2024/10/25 © Quality Arts,Akira Ikeda 95

96.

再掲:テスト設計の作業と勘所(1) テスト分析 テスト設計 テスト観点の発想 • 「なにをテストしよう」「どうテストしよう」が思いつかないと話が始まらない • 仕様書の分析結果や過去の経験,組織ノウハウから • テストカテゴリの利用 • Myersの14のシステムテスト・カテゴリ • ボリューム,ストレス,効率,ストレージ,信頼性,構成,互換性,設置,回復,操作性,セキュリ ティ,サービス性,文書,手続き • ISO/IEC 25010の品質特性 • システム/ソフトウェア製品品質 • 機能適合性,性能効率性,互換性,使用性,信頼性,セキュリティ,保守性,移植性 • 利用時の品質 • 有効性,効率性,満足性,リスク回避性,利用状況網羅性 • 組織に蓄積されたガイドワード • テスト設計を進めるなかで得られる新たな発想 2024/10/25 © Quality Arts,Akira Ikeda 96

97.

発想をより促進するための思考法の利用 アドホック 6つの帽子 6W2H 強制類推法 2024/10/25 • 心赴くままに,風吹くままに... • 帽子をかぶり直しながら考えることで思考の偏りを防ぐ • 白:客観的,赤:直感的,青:肯定的,黒:創造的,黄:否定的, 緑:管理的 • 富士ゼロックス秋山浩一さんのHAYST法で利用されている視点 • 開発者(Why, What, Howto),ユーザー(When, Where, Who), お客様のお客様(Whom, How much) • 刺激ワードを無理に組み合わせて発想を促す • 鈴木三紀夫さんの意地悪漢字やHAZOPのガイドワードなども使える © Quality Arts,Akira Ikeda 97

98.

発想をより促進するための思考法の利用 類語置換法 逆設定 三銃士モデル CIBFW 2024/10/25 • 思いついたキーワードを類語に置き換えてみると違った発想が得られる • 一度書き上がったマインドマップに出現しているテスト観点キーワードを, 類語辞典を使って置き換える • 前提を強制的に反転して考えてみる • 仕様として書かれていることを“常識”としてとらえ, “非常識”から考えてみる • 世界観,コンテキスト,実装 (過去にJaSSTでも発表有) • 故電気通信大学西康晴先生による観点 • 条件(Condition),テスト対象(test Item),ふるまい(Behaviour), 嫌なこと(things Faulty or hazardous),世界(World) © Quality Arts,Akira Ikeda もちろん,このほかにもたくさん 98

99.

池田がこれまでの経験から意識している 発想に関する一連の流れ モデリング(内界から外界へ) 発想の源泉を豊かに 発想法と思考法の活用 見える化・言語化 記憶 (内界) 発想・発散 (内界) 収束・見える化 (内界→外界) 2024/10/25 © Quality Arts,Akira Ikeda 99

100.

池田がこれまでの経験から意識している 発想に関する一連の流れ モデリング(内界から外界へ) 発想の源泉を豊かに 発想法と思考法の活用 見える化・言語化 記憶 (内界) 発想 (内界) 見える化 (内界→外界) 3色ボールペンが支援できる マインドマップが支援できる 2024/10/25 © Quality Arts,Akira Ikeda 100

101.

発想についての経験的な見地からの整理 発想における「思いついた」は「思い出した」である • 思い出すためには,記憶されていなければならない • 効率的に思い出すためには,発想法と思考法が必要 • 思い出したものを自己・他者認識し,洗練させるためには見える化が必要 初級者が発想を豊かにするためには,まず次をチャレンジするとよい • 発想のもととなる「記憶」の総量を増やす • 実務的にはこれが支配的だろうと思う • マインドマップそのもののきちんと学ぶ • 案外公式トレーニングを受けていない人が多い • マインドマップと組み合わせる思考法をいくつか学ぶ • これも案外学んでなかったり,意識していない 2024/10/25 © Quality Arts,Akira Ikeda 101

102.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 8. マインドマップを取り 入れようとしたときに 考えておくとよいこと マインドマップ本やこれまでいただいた質問への 回答を整理・列挙します 2024/10/25 © Quality Arts,Akira Ikeda 102

103.

マインドマップ活用のノウハウやコツ その1:マインドマップは中間成果物の位置づけくらいから • マインドマップを実際に業務で使いたくなったとき「よーし,これから作る文書は全部マインドマップで描 くぞ!」という意気込みを持ちがちだが, まずは中間成果物のためのツールという位置づけから始めるとよい その2:マインドマップを描くことを目的としない • 描くときには,何を目的として描くのかを強く意識して取り組むことが重要 • ついつい忘れがちになりそうな人は,「このマインドマップの目的」というブランチを作成すると良い(余 白に書くのもよい) • 公式な文書では,最初に「本文書の目的」として,文書の概要と目的を書く場合が多いですが,同様なこと をマインドマップでも適用するわけであり その3:きれいに描きすぎるな • マインドマップを描き慣れてくると,きれいに描いてやろうという気持ちが芽生えてくるが,いどんなにき れいなマインドマップを描いたとしても,そこに発想や気づきが何も描かれていなければ意味がない 2024/10/25 © Quality Arts,Akira Ikeda 103

104.

マインドマップ活用のノウハウやコツ その4:チーム内へのマインドマップ普及はじわじわと • マインドマップに慣れていない人にとっては,その仕上がりや作っている最中の姿は奇抜・奇妙に見える • いきなり標準ツールにすることを宣言してしまうと,慣れていないメンバーからの反発を招くこともある その5:マインドマップを利用することの理解を得る • ひとつ前のトピックに似ていまりが,マインドマップを描いていると,それをよく知らない人から「遊んでいる」と誤解される場合 がある.職場でスケッチブックを広げ,サインペンで絵を描いているとなると,そういった誤解を受けても仕方がない部分がある • プロジェクトマネージャや新人を指導する立場にあるベテランは,そのような誤解を受けないように,周囲の人たちに対し事前に根 回しをしておくなど,サポートする必要がある その6:初級者とベテランのコミュニケーションに活用しよう • マインドマップには思考の流れが図として描かれるため,順を追って見ていくことで,それを描いた人が何をどう考えたのかを掴み やすくなる.この性質を新人や部下の指導に活かすことができる • 初級者の思考が見える化されるので,ベテランが初級者の考えを理解しやすくなり,初級者もベテランに自分の考えを伝えやすくな る その7:マインドマップを否定してはならない • マインドマップは描いた人それぞれの思考の流れが表現されます • その人のマインドが表現されたマインドマップを否定することは人格否定にもなりかねない場合がある 2024/10/25 © Quality Arts,Akira Ikeda 104

105.

マインドマップ活用のノウハウやコツ その8:マインドマップは何枚でも描こう • 誰がマインドマップは1枚でないといけないと言ったのか? 納得いくまで何枚でも描こう その9:手描きかツールか • 好き好きではあるが,池田の場合は発想・発散は手描き収束はツールというように使い分けることが多い • 手描きは描いているときにその描きき触り感が五感を刺激してくれるように感じるし,気分がノったときには筆跡にそれが残る. ツールだと手癖でDELETEキーで消してしまいがちで,それは発想を捨てるという行為である • 収束のような整えていく作業や思考は,ブランチの入れ替え等が楽なツールが良いと思っている その10:自由記述かテンプレートか • 必要に応じて選べばよい • 自由記述型 • ひたすら思考を発散させながら思いつくままに描いていく • 抽象レベルを特に意識しなくても良い(いくらでも詳細化できる) • テンプレート型 • メイン・ブランチ,ブランチのひな形を使う • 情報の分析や整理,カテゴリ型テスト向き(ISO25010品質特性など) • 思考がテンプレートに縛られるため,自由記述型に比べて発想力は落ちる.抽象レベルが固定されることも多い 2024/10/25 © Quality Arts,Akira Ikeda 105

106.

マインドマップ活用のノウハウやコツ その11:マインドマップは発散,収束は別手法で • 収束プロセスは別の手法や記法を利用するのがよい • マインドマップ → UML,UML test plofile • マインドマップ → NGT • マインドマップ → FV表 • マインドマップ → テスト観点マトリクス • マインドマップ → KJ法 • Etc… その12:大切なのは発想すること • マインドマップにこだわる必要は“まったく”ない.自分と相性がよい手法を使ってもよい • 探検ネット(花火) • KJ法で利用される発想技法で,見栄えはマインドマップとも似ている • マンダラート • 3*3のマス目の真ん中にテーマを書き,そこから残り8マスを埋めるように発想する • [改訂新版]マインドマップから始めるソフトウェアテストにコラムあり • はちのすボード • 基本的にはマンダラートと同じ,ハニカム構造のボードを使って発想を広げていく 2024/10/25 © Quality Arts,Akira Ikeda 106

107.

(参考)あじさい問題 • テスト観点キーワードは便利だが,誰しもが同じイメージを持てるものまで落ちていないと, メンバ間でモデルの認識がブレる • 例えば,「あじさい」というキーワードがあったとして,読み手によりイメージが異なる – 水色もあれば,紫もあり,白もあれば,桃色もある • 土壌のアルミニウムイオンにより変わる – 花や葉の形が異なる • 植物分類学上,さらに分類がある • テスト設計にマインドマップを使うことの意図のひとつに「本来のマインドマップのようにビ ジュアルを多用することにより,より具体的なイメージでテスト観点を共有する」ことがある – マインドマップを使ったとしても,キーワードベースだと,イメージのブレが発生しやすい – イラストや図表を多用することで,イメージのブレを押さえ込む • あじさいの絵があれば具体的なイメージとなるし,キーワードに色をつけるだけでも色情報をつけられる • テスト観点キーワードリストは,たんなるキーワード集だと使い物にならない 2024/10/25 © Quality Arts,Akira Ikeda 107

108.

1. 2. 3. 4. 5. 6. 7. 8. 9. 自己紹介 はじめに マインドマップとは 国内におけるテストへのマインドマップ利用のこれまで テストへのマインドマップ利用の例(マインドマップ本より) マインドマップを利用したテスト分析設計方法の一例 発散で必要とする発想を考えてみよう マインドマップを取り入れようとしたときに考えておくとよいこと おわりに 9. おわりに 2024/10/25 © Quality Arts,Akira Ikeda 108

109.

本講演のアブストラクト • 国内におけるマインドマップのテストへの利用について,初の公知情報は2006年にさかのぼります. • それから約18年,コミュニティ・現場問わずマインドマップの利用を見かけ,最新版であるISTQB FL シラバス(V4)にも用語が登場するに至っています.マインドマップの利用が普及している状況 です. • ただし,18年もたつと「周りが使っているからなんとなく見よう見まねで使っている.」という方 が多いのも事実,最近教示の希望が増えてきました. • 本講演では,話としては古いテストへのマインドマップの利用という話題を,特に最近QA業界に 入った方を意識して,一周まわって取り上げます. • 前提知識は必要ありません. • まずマインドマップそのものを簡単に解説し,国内におけるテスト適用への成り立ちや普及の歴史 を確認します.テストへの適用の基本やコツを紹介します.そして,あまり議論されない「発散」 において特に重要となる「発想」という行為について自らの経験から考えます. • ※注:本講演は,書籍「[改訂新版]マインドマップから始めるソフトウェアテスト」をベースとし ます. 2024/10/25 © Quality Arts,Akira Ikeda 109

110.

一番伝えたいこと 思いつかなかったことはテストされない!!! マインドマップはテストでの分析設計に利用できる!!! 思いつくための“発想”という行為に向き合おう!!! ただ単にマインドマップという絵を描くのではなく, “発想”と それを大切にするマインドマップという理論に もっと向き合ってみませんか? 2024/10/25 © Quality Arts,Akira Ikeda 110

111.

池田が考えるマインドマップの本質 • あくまで池田の経験的感覚という前置きにて, – マインドマップは“理論” – マインドマップは“脳”における記憶や発想を最大限に活用しようという理論 – たんにマインドマップのルールだけ知ってても本当の効果は得られない • 当たり前ですが,ソフトウェテストにマインドマップをきちんと利用するためには, – マインドマップそのものをきちんと知りましょう(トレーニングを受けよう!!!) • PCツールだけ知ってても役にも何にもたちません – マインドマップ描くことに習熟しましょう(身に着けよう!!!) – そのうえで,テストプロセスやアクティビティのどこに使うかを考えましょう • いきなり,ここからPCツールでやろうとするから効果がでない ぜひ“発想”そのものにもっともっと向き合い, マインドマップという脳科学理論を知ってください 2024/10/25 © Quality Arts,Akira Ikeda 111

112.

再掲:マインドマップとは? • トニー・ブザンにより考え出された表現方法 – 脳の仕組みを取り入れたもので,思考に沿って描いていく – 図を取り入れる – 自分の深層意識にアクセスする Wikipediaによる解説 マインドマップ(英: mind map, mindmap)とは,トニー・ブザンが提唱する,思考の表現方法である[1].頭の中で考えている ことを脳内に近い形に描き出すことで,記憶の整理や発想をしやすくするもの. 描き方は,表現したい概念の中心となるキーワードやイメージを中央に置き,そこから放射状にキーワードやイメージを広げ, つなげていく.思考を整理し,発想を豊かにし,記憶力を高めるために,想像 (imagination) と連想 (association) を用いて思 考を展開する.この方法によって複雑な概念もコンパクトに表現でき,非常に早く理解できるとされる.人間の脳の「意味ネット ワーク」と呼ばれる意味記憶の構造(アラン・M・コリンズ(英語版),M・ロス・キリアン〈M. Ross Quillian〉ら)によく適合 しているので理解や記憶がしやすいといわれている[要出典]. しばしば「図解表現技法」や「ノート術」などと紹介されることがあるが,適切ではない.開発者 のトニー・ブザンは,脳科学や心理学の知見から,マインドマップを通してメンタルリテラシーの重 要性を提唱している.メンタルリテラシーとは,簡単に言えば頭の使い方であり,学び方を学ぶ力や, 学んだことを活用する力を指す. 本来は紙とペンで描くものであるが,コンピュータ上で描くための専用ソフトウェアもいくつかある. 2024/10/25 © Quality Arts,Akira Ikeda 112

113.

最後に • 2012年くらいから,ほとんどチュートリアル等が開かれなくなりました – これは国内のテストエンジニアにおいて,いったんの普及を見たということです • ここ10年くらいでテストの道に足を踏み入れた方々は,どうぞこの講演をきっかけに テストにおけるマインドマップの利用という手法・技術に真正面に向き合っていただき たいです • このあと,現場で積極実践したり社内普及を先導している現役バリバリエンジニアによ るワークショップ(演習)が実施されます • ぜひ,この機会に基本を身につけて,業務に生かしていただければ幸いです • また,今後さらに技術発展いただいたり,実践事例が共有されたらと願っています 2024/10/25 © Quality Arts,Akira Ikeda 113

114.

2024/10/25 © Quality Arts,Akira Ikeda 114