Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
テ ス ト 設 計 技 法 , そ の 前 に
~ フ ェ イ ス ア ッ プ ,
次 に ビ ル ド ア ッ プ ,
そ の 先 に マ イ ン ド ア ッ プ ~
池 田 暁
N P O 法 人 A S T E R 理 事
N a I T ...
自己紹介
2019/8/30 © Akira Ikeda 2
自己紹介
2019/8/30 © Akira Ikeda 3
自己紹介
2019/8/30 © Akira Ikeda 4
NPO法人ASTERやNaITE,SQiPやAFFORDD等に参画しています
情報通信系→医用系→自動車系と渡り歩いています
現在は社内のテストプロセス改善活動やテストチームを取りま...
NPO法人ASTERとは
2019/8/30 © Akira Ikeda 5
ソフトウェアテスト技術の普及振興に取り組んでい
るNPO
全国各地でJaSST(ソフトウェアテストシンポジウ
ム)やセミナーを開催しているほか,勉強会を支援
します
...
長崎出身や在住,かつて在住など,長崎になんらか
の関わりや興味を持っている技術者の交流会として
スタートしました
長崎とありますが,興味がある方はどなたでも気軽
にご参加いただけます
長崎現地にかかわらず,全国各地で勉強会やイベン
トを開催して...
マインドマップから始めるソフトウェアテストとは
• 2007年に発行したソフトウェアテストの書籍
– 2007年6月に技術評論社より
– ソフトウェア・テストPRESS vol.3~5の記事をベースに
大幅加筆
• テスト初級者向けに次を解説
...
マインドマップを始めるソフトウェアテストが
発行されてから変わったこと
• テスト技術者がテスト分析やテスト設計でマインドマップを使うことが当たり前となっ
た
– 勉強会に行くと当たり前のように使っている
• テストプロセス「分析」「計画」「設...
[改訂新版]がでました!
• 2019/4/13発売
• 池田 暁,鈴木 三紀夫 著
• 技術評論社,単行本(ソフトカバー): 224ページ
• 2,678円
2019/8/30 © Akira Ikeda 9
基本的な構成は大きく変更しない
...
参考:改訂新版の概観
2019/8/30 © Akira Ikeda 10
北海道との縁
を少し・・・
2019/8/30 © Akira Ikeda 11
北海道にて2年間育てていただきました
• 2年間,北海道情報大学大学院に所属
していました
• 視覚障害者の方向けのバスの音声時刻
表に関する研究に取り組みました
• 学部時代は,遠く,初めての土地で何
もわからないなか,北海道の方々に温
かく...
初回である,JaSST’06 Sapporo に
東京からの応援メンバーとして参画してました
2019/8/30 © Akira Ikeda 13
11年前に札幌でワークショップを行ないました
2019/8/30 © Akira Ikeda 14
11年前に札幌でワークショップを行ないました
2019/8/30 © Akira Ikeda 15
本日は北海道と北海道の技術者に
少しでも貢献したい
2019/8/30 © Akira Ikeda 16
私を学生として向かい入れ,
マインドマップに関連する技術交流の場を与えていただき,
叱咤激励をいただきながら育てていただいたことに感謝して...
はじめに
2019/8/30 © Akira Ikeda 17
JaSST’19 Hokkaido のテーマ(抜粋)
今年のテーマは
「マインドアップ ~テスト設計技法を知っていたら十分と思ってないかい?~」
です。
※"マインドアップ"は造語になります。"知力の向上","前へ向く気持ち"という思いを込め
...
JaSST’19 Hokkaido のテーマ(抜粋)
テスト設計技法には,基本的な技法から応用的な技法と,世の中には様々な技法が存在し
ます。
これらの技法を見聞きし,学んでみたものの,なかなか使う機会がない,使ったことがな
い,と嘆いていませ...
本セッションでのテーマ設定
2019/8/30 © Akira Ikeda 20
テスト設計技法を知っていたら十分と思っていないかい?
テスト設計技法以外のことをお話しする
技法を実務で適用するためには,事前にいくつか準備することがあります
技...
アブストラクトの再共有
• 日々の業務でテスト設計技法を上手く使えないと相談を受けることが少なくありません。
相談者は決して努力していないわけでは無く,テストに関する研修を受けたり,書籍を
読んで勉強をしたりしています。それにもかかわらずそのよ...
アブストラクトの再共有
• 本基調講演では,JaSST'19 Hokkaido のメインテーマである「マインドアップ」につな
げていくために「フェイスアップ」「ビルドアップ」という観点から,これまでの自
身の経験も交えながらお話しいたします。
...
Mind set!
あ な た が U P し た い マ イ ン ド と は ?
あなたが考えるマインドアップとは?
考えてみよう →付箋に書いてみよう
•どのようなマインドをアップしたいですか?
•どのようなマインドをアップすることが大切でしょう
か?
•などなど,マインドアップについて自分なりのイメージ
を持ちましょう
...
考えて
みよう!
本 題 に 入 る 前 に 頭 の 体 操 を し ま し ょ う
考えてみよう!
あなたは,ある日
プロ野球球団の投手として働くことになりました
あなたのミッションは試合の勝利に貢献することです
一日野球教室にて球種は教わりました
さて,それだけで試合に勝てるでしょうか?
2019/8/30 © Akira ...
【演習】考えてみよう!
• 勝つためにはどういった事が必要でしょうか?
• あなたが“投手として” やっておくべき事を考えてみましょう
2019/8/30 © Akira Ikeda 27
# やっておくべきこと 時期
1
2
3
4
5
第0部
まずは足下
ま ず は 実 務 で の テ ス ト 設 計 技 法 あ れ こ れ を
確 認 し ま し ょ う
【演習】なぜテスト設計技法を使いたいのか?
• 我々はなぜテスト設計技法を使いたいのでしょう?
• その理由をあらためて考えてみましょう
2019/8/30 © Akira Ikeda 29
# 使いたい理由
1
2
3
4
5
なぜテスト設計技法を使いたいのか
• テスト設計技法を使うと,妥当なテストケースにコントロールできる
– テストケースが減る:テストをやりすぎてたいた状況を改善
– テストケースが増える:これまでのテストケースが少なすぎた
• テスト設計技法を...
テストの研修を受けるが…
テスト設計技法をきちんと
理解できなかった
テスト設計技法は理解したが,
使いどころがわからない
2019/8/30 © Akira Ikeda 31
きちんと理解できなかった
• 目的意識を持って受講していない
– 改善したい課題を持っていないと表面的な理解にとどまってしまう
• 自分の業務のドメインへの適合度が低い
– 例えば,Web系エンジニアが,制御系エンジニア向けの研修の内容を理解す...
余談:書籍も同様
• テスト設計技法に関してだけではないが,書籍を読んでもよくわからないとか,難しいとか,読みにくいと思ったと
き,そのほとんどの場合は「その書籍を読むための実力が備わっていない」という原因がある
• 目的意識を持って読んでいな...
余談:ワタシ オシエテモラウヒト の害悪
• どれだけ目的を持って,課題に合致した研修を受けたとしても,
ワタシ オシエテモラウヒト という意識では何も身につかない
• 研修や勉強会では,自ら学び,講師から学び取るという強い意識が必要
• 申し...
使いどころがわからない
• 技法が解決できる課題を理解していない
– テスト設計技法は必ず解決したい課題があって生み出されたものである
• SQuBOKのトピック記述が参考になる
• テスト対象の理解が不十分である
– テスト対象を理解していな...
参考:SQuBOKにおけるトピックの構造
• 目的
• 方法
• 効果
• 留意点
• 関連知識領域/トピックス
• 参考文献
• 関連文献
2019/8/30 © Akira Ikeda 36
研修では,多くの場合,方法(手順)と直接的な効果...
足下を踏む固めることが大切
テスト設計技法をきちんと理解できなかった
• 目的意識を持って受講しよう
• 自分のドメインに適合している研修を選ぼう
• 前提知識を学び直そう
テスト設計技法は理解したが,使いどころがわからない
• 技法が解決でき...
余談:必殺技症候群に陥るべからず
• 見た目の派手さに憧れて,まだ身につけられない技法を学ぼうとする
– ホイミすら覚えていないのに,いきなりベホマやベホマズンを求める
※注:ホイミやベホマ,ベホマズンはドラゴンクエストに登場する呪文名,高度な...
第1部
Faceup
~ 顔 を 上 げ て ,
そ の 前 を 意 識 ~
テ ス ト 設 計 技 法 を 利 用 す る 前 に 必 要 な テ ス ト 分 析 ・ 設 計 と 確 認 し ,
や り か た の 一 例 と し て マ イ...
テスト設計技法
を使う前にある,
テスト分析・設計
テ ス ト 設 計 技 法 を 利 用 す る 前 準 備 で は
ど う っ た こ と に 取 り 組 め ば よ い で し ょ う か
2019/8/30 © Akira Ikeda ...
再掲:テスト設計技法は使うための前準備
1.技法が解決できる課題を理解しよう
2.テスト対象をよく理解しよう
3.テストの観点の全体像をまとめよう
2019/8/30 © Akira Ikeda 41
1.は研修や勉強にて解決が可能
2.および...
おさらい:V字モデルでのテストレベル
2019/8/30 © Akira Ikeda 42
システム設計
構造設計
詳細設計
実装/机上テスト
コンポーネントテスト
統合テスト
システムテスト
対応
対応
対応
要件定義 受け入れテスト
システ...
テストライフサイクルプロセスの例
2019/8/30 © Akira Ikeda 43
さらに概念と作業を分割。テストライフサイクルプロセスの考え方が普及。
いかに戦略的なテストを行うかという議論。
分析 実装設計 実行 報告
特に準備なく場当...
V字モデルへライフサイクルをマッピング
2019/8/30 © Akira Ikeda 44
システム設計
構造設計
詳細設計
実装/机上テスト
実行→報告分析→設計→実装
コンポーネントテスト
実行→報告分析→設計→実装
統合テスト
実行→報...
「[改訂新版]マインドマップから始めるソフトウェア
テスト」におけるプロセス
仕様分析
•どのような
テストを行
う必要があ
るのかを検
討
テスト計画
•仕様分析に
よって洗い
出された情
報を計画と
して作成す
る。
テスト設計
•テスト項...
ISTQBシラバスにおけるテストプロセス
テスト計画
•テストの目的と,
状況により課せら
れる制約内でテス
トの目的を達成す
るためのアプロー
チを定義する
テストのモニタリン
グとコントロール
•テスト計画書で定
義したテストモニ
タリング...
その他,参考になるテストプロセス
• Test.SSFのプロセス
– ASTERのサイトから参照可能
– [改訂新版]マインドマップから始めるソフトウェアの3章コラム「Test.SSFにおけるテストプロ
セス」
• ASTER智美塾で検討された...
テスト分析・設計の要素
• 先に挙げたようなテストプロセスや,国内で提案・導入が進むテスト分析設計手法に
よって,実施することや手順,分担は変わるが,概ね以下のようなことを実施する
2019/8/30 © Akira Ikeda 48
情報入手...
テスト分析・設計の要素
• 先に挙げたようなテストプロセスや,テスト分析設計手法によって,実施することや手
順,分担は変わるが,概ね以下のようなことを実施する
2019/8/30 © Akira Ikeda 49
情報入手
•テストベースを
入...
国内におけるテスト分析設計手法
手法名 表現方法 特徴 プロセス
NGT ツリー テスト全体をテスト観点で網羅 VSTeP
FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法
ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェッ...
コツ:実務を考慮してテストプロセスを設計すべし
• テスト分析設計は様々なプロセスパターンや手法があるが…
– 世の中には沢山の選択肢がありますが,現場の技術力や開発プロセス,社内規格・基準との
整合性などの関係で,そのままではうまく利用できな...
余談:アジャイル開発への対応はプラクティス目線
で
• テスト分析設計を工程と捉えると対応が難しくなる
– 特別なイテレーションやタイムボック,スプリントを設けるという発想になりやすいため
• テスト分析設計の要素を抑え,それを採用するアジャイ...
【演習】自分流のテスト分析設計を考えてみよう
• 実務の状況を踏まえ,自分流のテスト分析設計プロセスを考えてみよう
2019/8/30 © Akira Ikeda 53
プロセス やること 活用できる手法 成果物
テスト分析
テスト設計
テスト分析設計
方法の一例
~マインドマッ
プを活用する~
テ ス ト 分 析 設 計 方 法 一 例 と し て
マ イ ン ド マ ッ プ に よ る テ ス ト 分 析 設 計 を 紹 介 し ま す
2019/8/30 © Akira ...
テスト分析と設計が無い場合
2019/8/30 © Akira Ikeda 55
仕様書等 テストケース
初級者
(仕様例)
ボタンを押すと音が出る
(テストケース例)
ボタンを押すと音が出ることを確認
初級者の悩み
・テストケースのヌケが多い...
テスト分析と設計がある場合
2019/8/30 © Akira Ikeda 56
上級者
仕様書等 テストケース
テストケースを書く前に,思考を発散させながら,かつMECEを意識し
て考える.なので,初級者に比較してテストケースの抜けが少なくな...
実に多くを考えることが必要であるが…
2019/8/30 © Akira Ikeda 57
考えるっていっても
頭の中だけじゃ
大 変 だよな
とりあえず,
テストケース表を使って
考えようかな?
どうせ最終的には
エクセルの表になる
わけだし...
実に多くを考えることが必要であるが…
2019/8/30 © Akira Ikeda 58
表で観点を出す,
つまりブレストは
難しいな~
じゃぁ,そのような特徴をもつ
発想支援ツール,マインドマップを
使ってみたら?
試行錯誤できる
記法がい...
マインドマップの利用イメージ
2019/8/30 © Akira Ikeda 59
仕様書 テストケース
初級者
マインドマップを描くことで,
・単純な仕様の転記がなくなる
・仕様書に書かれていないことにも思考が誘導される
・「考える」行為を明...
テスト分析・設計にマインドマップを活用
2019/8/30 © Akira Ikeda 60
テストケースの品質に大きな影響を与え,
かつ,仕様外への発散思考が特に重要な
・テスト分析
・テスト設計
にマインドマップを使ってみよう
・マインドマ...
2019/8/30 © Akira Ikeda 61
マインドマップとは?
• トニー・ブザンにより考え出された図解技法
– 脳の仕組みを取り入れたもの
– 思考に沿って描いていく
– 図を取り入れる
– 自分の深層意識にアクセスする
2019/8/30 © Akira Ikeda 62
Wiki...
マインドマップの特徴の一例
•全体を俯瞰し易いバードビュー
•項目それぞれが重複することなく,全体集合として漏れがないMECE
•基本的なルールは単純で,紙とペンがあれば始められる学習が容易
•フリーなルールであるために,柔軟に構造を変更可能半...
済
2019/8/30 © Akira Ikeda 64
この例での「テスト分析」と「テスト設計」
2019/8/30 © Akira Ikeda 65
テスト分析 テスト設計 テスト実装 テスト実行
仕様等の理解・整
理・検討・テスト
観点の目付け
テスト観点の発
想・検討・整理,
テスト技法の適
...
開発作業とテスト作業のおおまかな対比イメージ
2019/8/30 © Akira Ikeda 66
ソフトウェア開発 テスト開発
要求分析
設計
実装
テスト分析
テスト設計
テスト実装
顧客要求を分析し,ソフトウェアとし
て実現可能か検討する...
テスト分析の作業と勘所(1)
設計仕様やテストへの要求の理解・整理・検討(純粋理解)
•知らないものはテストできない!
•設計仕様に関する思想や観点,構造や構成物を理解する
•どういったものを作ろうとしているかのイメージをつかむ
•設計者が特に...
テスト分析の作業と勘所(2)
仕様の抜け漏れの発見と修正へのアクション
• 仕様の欠陥を発見したら,設計部門にフィードバックし,仕様の高品質化をはか
る
• 仕様書の高品質化は即ちテストベースの高品質化であり,そこから生み出され
るテスト設計仕...
テスト設計の作業と勘所(1)
テスト観点の発想
•「なにをテストしよう」「どうテストしよう」が思いつかないと話が始まらない
•仕様書の分析結果や過去の経験,組織ノウハウから
•テストカテゴリの利用
•Myersの14のシステムテスト・カテゴリ
...
テスト設計の作業と勘所(2)
テスト観点の剪定・整理
• テスト観点には重要度や優先度が存在する
• 全てのテストは多くの場合やりきれないため,テスト観点に優先度をつける
• テストする必要のない観点や優先度・重要度の低い観点は切り落とす
• ...
余談:テスト観点に関するよくある発言
• いわゆる「テスト漏れ」に対してその理由を聞くと,
「テストの観点が漏れていました」
という発言をよく聞く
• テストの観点漏れを防ぐための対策に挙げられることが多いのは「テストレビューを充
実します」と...
済 済
2019/8/30 © Akira Ikeda 72
マインドマップ適用時の基本的な作業手順と範囲
2019/8/30 © Akira Ikeda 73
テスト設計
(観点モデルの作成)
テストベース
(仕様書等)
テストケース
Mind Map
直接転記
しない
テスト設計
(テスト技法の適用)...
マインドマップ適用時の基本的な作業手順と範囲
2019/8/30 © Akira Ikeda 74
テスト設計
(観点モデルの作成)
テストベース
(仕様書等)
テストケース
Mind Map
直接転記
しない
テスト分析
テスト分析にも
マイ...
コツ:テスト分析には3色ボールペンも活用しよう!
• テスト分析をマインドマップだけで行うのはかなり大変
– セントラルイメージやメインブランチがなかなか決まらない
• まず仕様書を3色ボールペンでチェックし,マインドマップを描く手がかりとする...
マインドマップ適用時の基本的な作業手順と範囲
2019/8/30 © Akira Ikeda 76
テスト設計
(観点モデルの作成)
テストベース
(仕様書等)
テストケース
Mind Map
直接転記
しない
テスト分析
テスト分析に
3色ボ...
マインドマップ適用時の基本的な作業手順と範囲
2019/8/30 © Akira Ikeda 77
テスト設計
(観点モデルの作成)
テストベース
(仕様書等)
テストケース
Mind Map
直接転記
しない
テスト分析
テスト分析と設計に
...
デモムービー
2019/8/30 © Akira Ikeda 78
マインドマップの例
2019/8/30 © Akira Ikeda 79
観点を思いつき,そこにテスト設計技法を適用している
メモや疑問
マインドマップの例
2019/8/30 © Akira Ikeda 80
マインドマップの例
2019/8/30 © Akira Ikeda 81
整理:マインドマップを使った全体の流れ
2019/8/30 © Akira Ikeda 82
テストケース
(仕様例)
・ボタンを押すと音が出る
(テストケース)
・
・
・
・
・
テスト分析・設計を導入して,単なる仕様チェックから卒業しよう...
再掲:国内におけるテスト分析設計手法
手法名 表現方法 特徴 プロセス
NGT ツリー テスト全体をテスト観点で網羅 VSTeP
FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法
ゆもつよメソッド 表形式 機能×テストタイプで網羅を...
コツ:テスト分析設計には思考に役立つ手法を複数
持っておくとよい
• 6つの帽子
– 帽子をかぶり直しながら考えることで思考の偏りを防ぐ
• 白:客観的,赤:直感的,青:肯定的,黒:創造的,黄:否定的,緑:管理的
• 6W2H
– 富士ゼロック...
コツ:テスト分析設計には思考に役立つ手法を複数
持っておくとよい
• 逆設定
– 前提を強制的に反転して考えてみる
– 仕様として書かれていることを“常識”としてとらえ,“非常識”から考えてみる
• 三銃士モデル
– 世界観,コンテキスト,実装...
コツ:マインドマップにこだわる必要なし
大切なのは,発想すること
• 探検ネット(花火)
– KJ法で利用される発想技法
– 見栄えはマインドマップとも似ている
• マンダラート
– 3*3のマス目の真ん中にテーマを書き,そこから残り8マスを埋...
コツ:マインドマップは発散,収束は別手法で
• マインドマップは思考の発散には向いているが,物事の整理にはあまり向いていない
• このため,収束プロセスは別の手法や記法を利用するのがよい
– マインドマップ → ツリー図
– マインドマップ →...
【演習】描いてみようマインドマップ
2019/8/30 © Akira Ikeda 88
【身近にある仕様書を元にしてマインドマップでテスト分析設計】
プロジェクト
への導入例(1)
あ る プ ロ ジ ェ ク ト へ の 導 入 事 例 を 紹 介 し ま す
892019/8/30 © Akira Ikeda
90
あるプロジェクトへの導入事例
仕様書
仕様書の品質が仕様分析やテスト分析を行うに至らない場合,設計部門に対し見直しを依頼
テスト設計技
法適用へ仕様書に多くの問題がある場合,再度見直しを依頼
テ
ス
ト
設
計
が
甘
い
場
合
,
再...
91
複数人によるテスト分析&テスト設計
全体の方向性の検討
分析&設計する上での意識あわせを
マインドマップを共有作成して行う
・大雑把な仕様やコンセプトの確認
・使用するテストベースの確認
・使用するテストカテゴリの確認
・スケジュール等,...
現場担当者に聞く,主な得られた効果
テスト観点の全体像が見える
•どこに重きを置くか,どことどこを組み合わせるかの検討が容易に
•観点ごとに担当者を決めるなど共同作業がやりやすくなる
2. テスト技法が適用し易くなる
•テスト観点ごとに,適用し...
現場担当者に聞く,その他の効果
1. 仕様書のレビュー効果
•違った観点からの分析により,仕様における漏れ抜けを発見
•設計部門が仕様書の見直しを行うことで,手戻りの減少
2. テスト戦略へのフィードバック
•テスト観点のモデリングを行うことで...
過去のJaSST北海道での関連事例
2019/8/30 © Akira Ikeda 94
過去のJaSST北海道での関連事例
2019/8/30 © Akira Ikeda 95
JaSSTのサイ
トは事例の宝
の山
• JaSSTにはマインドマップ
の適用事例の他,テスト
プロセスに関する沢山の
事例情報が掲載されてい
ます
• 是非宝探ししよう!
2019/8/30 © Akira Ikeda 96
プロジェクト
への導入例(2)
V O T D D に お け る マ イ ン ド マ ッ プ の 導 入 事 例 を 紹 介
し ま す
972019/8/30 © Akira Ikeda
あるVOTDDを採用したプロジェクトへの導入例
• VOTDDとは検証指向TDDのことで,TDDのテストコードの保守性やテストの網羅性の充実
を目的とした手法
2019/8/30 © Akira Ikeda 98
RED
GREENREFACT...
あるVOTDDを採用したプロジェクトへの導入例
•テスト設計を洗練する
•テスト設計の見直しを行なう
•テストの抜け漏れを防止する
•テスト設計の最適化
•テスト設計のレビュー効果によ
り,プロダクト仕様の欠陥や改
善点を抽出
VERIFY &...
テスト設計の全体像設計と共有のための
マインドマップ導入
課題
•VOTDDは開発者とテスト技術者が二人三脚で実施するが,テスト設計の観点や意図の共有
がテストコードのみではなかなか難しかった
対応
•テストコードの近くにテスト設計の観点や意図...
現場担当者に聞く,主な得られた効果
1. VERFY & DEBUG のスピードが向上した
•テストコードのそばにテスト設計があるため,すぐに参照できるようになった
2. テストコードの全体像が見えるようになった
•テストコードが増えると,全体...
ご参考:
テスト観点モデ
ルの作成ステッ
プ
実 導 入 の 経 験 か ら 例 を 紹 介 し ま す
1022019/8/30 © Akira Ikeda
現場適用での反省:初級者には一気にテスト観点モ
デルを完成させるのは難しかった
• 某プロジェクトにおいて,テスト初級担当者に対して,テスト設計のトライアルにチャ
レンジしたが,うまくいかなかった
• よくよくヒアリングしてみると,次のようなこ...
テスト観点モデルの作り方(その1)
• 初級者向けのテスト設計プロセスはCG制作プロセスにヒントを得て形式化
– 段階的にモデルを育てる(素のモデルに,プロジェクト制約や組織・ドメイン知識をまぶす
– モデルのレビューをきちんと入れる,テスト設...
初級者向けテスト観点モデルの作り方(その2)
• モデリング
– 仕様書等直接のテストベースを使って,自由な発想でテスト観点モデルを作成
• CG的には,生ポリゴンのモデルやワイヤフレームが出来上がるイメージ
• レンダリング
– モデルに対し...
初級者向けテスト観点モデルの作り方(その3)
• カメラテスト(プレビュー)
– レンダリング工程を経たテスト観点マインドマップについて公式レビューを行う
• レンダリング結果を様々なカメラから確認する。この時,カメラをどの位置や角度に置くのか...
コツ:テスト観点(ノウハウ)の蓄積
• テスト観点をためていくことでテスト設計でのノウハウを蓄積していくことができる
– エフェクトとフィルタというそれぞれの分類ごとにモジュールを作成してためる
• エフェクト,フィルタは(現在のところ)形式は...
コツ:あじさい問題
• テスト観点キーワードは便利だが,誰しもが同じイメージを持てるものまで落ちていないと,
メンバ間でモデルの認識がブレる
• 例えば,「あじさい」というキーワードがあったとして,読み手によりイメージが異なる
– 水色もあれば...
さらにその前
に考えておく
べきこと
テ ス ト 分 析 の 前 に ま だ や る べ き こ と は あ る の だ
2019/8/30 © Akira Ikeda 109
実際の所,それだけでよいのか
• 先ほどの話は十分な品質や目的にかなったテストベースがインプットされる前提になっ
ているが,現実問題としてテストベースの入手に関する問題がある
– 品質が悪く,テスト分析しようがない
– テストベースの量が足りな...
よりよいテストベースを入手するために
• 品質が悪いテストベースは受け入れない
– テストベース受け入れレビューを実施する
• ドキュメントとしての体を成していないものは受け入れない
• テストベースパッケージを定義して,構成管理をする
– 入...
開発レビューに参画する
• 開発レビューに参画して,仕様書の充実度を向上する
– 記述自体の充実度や正確性等に加えて,テストに役立つ情報も充実させる
• ただし記述を混ぜると可読性を悪くしてしまう場合があるので,別紙とするなど工夫が必要
– テ...
開発レビュー参画時の注意点
• 開発やドメインについての知識がないままにレビューに参画すると次のような事が起き
がち
– 発言できない
– 誤字脱字程度の指摘しかできず,煙たがられる
– 開発や技術等の背景を抑えられないまま斜め上のコメントをし...
そのほか,テストベースとして忘れがちな情報
• マスターテスト計画
– マスターテスト計画にテスト設計に関連する情報あり
• プロジェクト計画
– プロジェクト計画に,テストの方針として必要な情報が書かれていることが多い
• 上位の設計ドキュメ...
余談:雇用形態によるテストベースの入手の難易度
• 社員
– 基本的には全ての情報にアクセス可能
• 派遣社員
– 派遣先の機微な情報については非開示の場合が多い
• 請負社員
– 契約範囲の情報のみに限定される
• 契約以上の情報入手や相手先...
第1部のまとめ
2019/8/30 © Akira Ikeda 116
第1部のまとめ
テスト設計技法を適用する前の準備として,
テスト分析とテスト設計がある
テスト分析設計のやり方のひとつにマインド
マップを活用する方法がある
テスト分析の前にもさらに必要な準備もある
2019/8/30 © Akira Iked...
第2部
Buildup
~ 意 識 を 高 め よ う ,
鍛 錬 し よ う ~
テ ス ト 設 計 技 法 を 使 え る よ う に な る た め の
ガ イ ド と な る 情 報 を お 話 し し ま す
見つめ直そう
テストの意義
も う 一 度 , 「 な ぜ 我 々 は テ ス ト し な け れ ば な ら な
い の か 」 「 な ぜ テ ス ト 設 計 技 法 を う ま く 使 わ な け
れ ば な ら な い の か 」 を ...
ソフトウェアテストってなんだろう?
2019/8/30 © Akira Ikeda 120
ソフトウェアテストっ
てなんだろう?
•ソフトウェアをテストする
ことだと言うのは簡単だが
•ソフトウェアを動かして
みて,変な動きを確認す
ること?
...
ソフトウェアテストを行う意義
• バグ(不良)を発見することができる
– テストをやらないと,多くのバグは発見できない
– テストで発見したバグを開発者がデバッグすることで,品質が上がる
• ソフトウェアを利用者が安心して利用することができる
...
バグが与える影響 とある場面 ~お客様の立場~
• ある日スマホを買ってきたら,次のような現象が出た
– 電波の受信レベルは最高なのに,メッセージが送信できない
– メニューやメッセージが文字化けする
– アドレス帳に登録ができない,勝手にデー...
バグが与える影響 とある場面 ~メーカの立場~
• ゲームソフトの出荷後,フリーズなど致命的な問題が発見された
– 回収・交換する場合,どういう対応が必要になるのか
• ① ゲームソフトの回収
• ② バグの調査と分析
• ③ バグの修正
• ...
バグが与える影響 とある場面 ~メーカの立場~
– ① ゲームソフトの回収
• 10万本 × 送料700円 = 7,000万円
– ② バグの調査と分析~ ④ 修正されたバグについてのテスト
• 15人 × 時給2,000円 × 240時間 =...
(参考)「史上最悪のソフトウェアバグ」ワースト10
•マリナー1号は打ち上げ時に予定のコースを外れたが,これは飛行ソフトウェアのバグが原因だった。地上の管制センターは大
西洋上でロケットを破壊した。事後調査により,鉛筆で紙に書かれた数式をコンピ...
(参考)「史上最悪のソフトウェアバグ」ワースト10
•最初のインターネットワームとなった通称『モーリス・ワーム』は,バッファー・オーバーフローを悪用し,1日足らずで2000台から6000台のコンピューターに感染した。
原因となったのは,標準入出...
(参考)「史上最悪のソフトウェアバグ」ワースト10
•[ピング・オブ・デス,不正なピングパケットによる攻撃]分割送信されたIPパケットの再構成を行なうコードのチェックとエラー処理が不十分だったため,
インターネット上の好きな場所から不正な形式の...
ソフトウェアテストを行う意義
• ソフトウェア製品に
– バグが残っている(混入している)と,不快な気分になり,安心感もなくなり,不信感を持つ
– 混入したたった一つのバグが数億円の損害を与えるほか,ブランドに大きな影響を与えることも
ある
2...
ソフトウェアテストを行う意義
• たった一個のバグが,お客様に不利益を与えるどころか,企業の業績を左右することもある
• 場合によっては企業の倒産により職を失ったり,企業や社会に損害を与えたことで,個人に損
害賠償責任が発生することも
2019...
テスト設計技
法をもう一度
学ぼう
知 識 が 古 く な っ て い た り , 誤 っ た 理 解 だ っ た り す る か
も し れ ま せ ん
知 識 を 更 新 し ま し ょ う
2019/8/30 © Akira Ikeda ...
SQuBOKガイド V2に見るテストの設計技法
3.9 テストの技法
3.9.1 経験及び直感に基づいた技法
3.9.2 仕様に基づいた技法
3.9.3 コードに基づいた技法
3.9.4 フォールトに基づいた技法
3.9.5 利用に基づいた技法...
SQuBOKガイド V2に見るテスト設計技法
•アドホックテスト,探索的テスト
経験に基づいた技法
•ブラックボックステスト,同値分割,境界値分析/境界値テスト,デシジョンテーブルによるテスト,原因結果グラフ
によるテスト,状態遷移テスト,ラン...
SQuBOKガイド V2に見るテスト設計技法
•オブジェクト指向テスト,Webシステムのテスト,GUIテスト,サーバサイドのテスト,データベース
テスト,並行プログラムのテスト,プロトコル適格性テスト,実時間のテスト,モバイルアプリケー
ション...
テストの体系によってはレビュー技術は静的テスト
•ピアレビュー,インスペクション,チームレビュー,ペアプログラミング,ピ
アデスクチェック,パスアラウンド,ラウンドロビンレビュー,ウォークス
ルー,アドホックレビュー
レビュー方法
•形式手法に...
テスト設計技法は組み合わせる
2019/8/30 © Akira Ikeda 135
JaSST’12 Tokyo での「みんなで作
ろうテスト技法ポジショニング
マップ」
http://jasst.jp/symposium/jasst12to...
テスト設計技法を学ぶための書籍
はじめて学ぶソフトウェアテスト技法
•Lee Copeland 著/宗 雅彦 訳/日経BP社/2005年
•テスト技法と言えば,境界値テストしか思いつかない人が残念ながらいます。テストにはさまざまな
技法が存在し...
テストプロセス
改善モデルや資
格を利用しよう
実 務 で 活 用 で き る よ う に 技 術 力 を 向 上 す る に あ
た っ て は , ガ イ ド を 利 用 す る の も よ い で し ょ う
2019/8/30 © Ak...
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」
Prochain SlideShare
Chargement dans…5
×

JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」

1 474 vues

Publié le

2019年8月30日に札幌にて開催されたJaSST'19 Hokkaido での基調講演資料です。
http://jasst.jp/symposium/jasst19hokkaido/timetable.html#S1

Publié dans : Logiciels
  • -- DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT -- ......................................................................................................................... ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... (Unlimited)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Download or read that Ebooks here ... ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... Download Doc Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... .........................................................................................................................
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH } .........................................................................................................................
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Download or read that Ebooks here ... ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... Download Doc Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... .........................................................................................................................
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • (Unlimited)....ACCESS WEBSITE Over for All Ebooks ................ accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full EPUB Ebook here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full PDF EBOOK here { https://urlzs.com/UABbn }
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

JaSST'19 Hokkaido 「テスト設計技法、その前に ~フェイスアップ、次にビルドアップ、その先にマインドアップ~」

  1. 1. テ ス ト 設 計 技 法 , そ の 前 に ~ フ ェ イ ス ア ッ プ , 次 に ビ ル ド ア ッ プ , そ の 先 に マ イ ン ド ア ッ プ ~ 池 田 暁 N P O 法 人 A S T E R 理 事 N a I T E ( 長 崎 I T 技 術 者 会 ) 代 表 2 0 1 9 / 0 8 / 3 0 ( 金 ) 於 札 幌 市 教 育 文 化 会 館
  2. 2. 自己紹介 2019/8/30 © Akira Ikeda 2
  3. 3. 自己紹介 2019/8/30 © Akira Ikeda 3
  4. 4. 自己紹介 2019/8/30 © Akira Ikeda 4 NPO法人ASTERやNaITE,SQiPやAFFORDD等に参画しています 情報通信系→医用系→自動車系と渡り歩いています 現在は社内のテストプロセス改善活動やテストチームを取りまと めています テストに関する書籍を執筆したり, イベントや勉強会にて講師をしたり, コンテンツを作って公開したりしています その昔,2年間北海道・江別に住んでいました 今日は,思い出の土地で講演できてとても嬉しいです!
  5. 5. NPO法人ASTERとは 2019/8/30 © Akira Ikeda 5 ソフトウェアテスト技術の普及振興に取り組んでい るNPO 全国各地でJaSST(ソフトウェアテストシンポジウ ム)やセミナーを開催しているほか,勉強会を支援 します 全国各地でJSTQBによるテスト技術者認定資格試験 を運営しています その他,様々な調査活動や研究活動に取り組み, 様々なコンテンツを提供しています 是非ASTERの公式ページをご覧下さい! http://aster.or.jp/
  6. 6. 長崎出身や在住,かつて在住など,長崎になんらか の関わりや興味を持っている技術者の交流会として スタートしました 長崎とありますが,興味がある方はどなたでも気軽 にご参加いただけます 長崎現地にかかわらず,全国各地で勉強会やイベン トを開催しています SIG活動にも取り組み,「はじめてのバグ票システム ~導入実践ガイド」などを無料にて公開していま す! NaITEとは 2019/8/30 © Akira Ikeda 6 ■NaITE公式サイト http://naite.swquality.jp/ ■Facebookページ https://www.facebook.com/NagasakiITEngineers/ 是非ご参加ください! & 一緒に企画しましょう! http://naite.swquality.jp/
  7. 7. マインドマップから始めるソフトウェアテストとは • 2007年に発行したソフトウェアテストの書籍 – 2007年6月に技術評論社より – ソフトウェア・テストPRESS vol.3~5の記事をベースに 大幅加筆 • テスト初級者向けに次を解説 – テストの作業工程 – テストの思考過程 • ポイント – テスト技法ではなく,テストプロセスを学べる – テストでのマインドマップの応用例を学べる – ブックガイドにて今後のテストのスキルアップのための 情報を知れる 2019/8/30 © Akira Ikeda 7
  8. 8. マインドマップを始めるソフトウェアテストが 発行されてから変わったこと • テスト技術者がテスト分析やテスト設計でマインドマップを使うことが当たり前となっ た – 勉強会に行くと当たり前のように使っている • テストプロセス「分析」「計画」「設計」「実装」「実行」「報告」が一般的に認知さ れ, テストプロセスを整備する現場が増えた – 具体例から,具体的な活動として定義できるようになった • テストは楽しく想像的な技術であることが認知された – Excelチョメチョメからの脱却 2019/8/30 © Akira Ikeda 8
  9. 9. [改訂新版]がでました! • 2019/4/13発売 • 池田 暁,鈴木 三紀夫 著 • 技術評論社,単行本(ソフトカバー): 224ページ • 2,678円 2019/8/30 © Akira Ikeda 9 基本的な構成は大きく変更しない コラムを追加 陳腐化している第Ⅲ部を廃止し,旧第Ⅳ部を新第Ⅲ部として加筆修正する ブックガイドの情報を更新 その他,情報の追加や文章表現,用語の調整
  10. 10. 参考:改訂新版の概観 2019/8/30 © Akira Ikeda 10
  11. 11. 北海道との縁 を少し・・・ 2019/8/30 © Akira Ikeda 11
  12. 12. 北海道にて2年間育てていただきました • 2年間,北海道情報大学大学院に所属 していました • 視覚障害者の方向けのバスの音声時刻 表に関する研究に取り組みました • 学部時代は,遠く,初めての土地で何 もわからないなか,北海道の方々に温 かく付き合っていただきました • 江別に一人暮らししていましたが,札 幌にも良く買い物等にきていました 2019/8/30 © Akira Ikeda 12
  13. 13. 初回である,JaSST’06 Sapporo に 東京からの応援メンバーとして参画してました 2019/8/30 © Akira Ikeda 13
  14. 14. 11年前に札幌でワークショップを行ないました 2019/8/30 © Akira Ikeda 14
  15. 15. 11年前に札幌でワークショップを行ないました 2019/8/30 © Akira Ikeda 15
  16. 16. 本日は北海道と北海道の技術者に 少しでも貢献したい 2019/8/30 © Akira Ikeda 16 私を学生として向かい入れ, マインドマップに関連する技術交流の場を与えていただき, 叱咤激励をいただきながら育てていただいたことに感謝しています 本日は,そのご恩を少しでもお返しできるよう, 拙いながら,頑張ってお話ししたいと思います!
  17. 17. はじめに 2019/8/30 © Akira Ikeda 17
  18. 18. JaSST’19 Hokkaido のテーマ(抜粋) 今年のテーマは 「マインドアップ ~テスト設計技法を知っていたら十分と思ってないかい?~」 です。 ※"マインドアップ"は造語になります。"知力の向上","前へ向く気持ち"という思いを込め ています。 2019/8/30 © Akira Ikeda 18
  19. 19. JaSST’19 Hokkaido のテーマ(抜粋) テスト設計技法には,基本的な技法から応用的な技法と,世の中には様々な技法が存在し ます。 これらの技法を見聞きし,学んでみたものの,なかなか使う機会がない,使ったことがな い,と嘆いていませんか? 技法を実際に使用するためには,その技法の目的・用途を良く知る必要があります。 そして,それらの技法を実務で適用するためには,事前にいくつか準備することがありま す。 個人の暗黙知になっている場合もあれば,組織の形式知になっている場合もあります。 今回のシンポジウムでは,技法を適用する前に行うことはなにか?ということを考え,技 法を"知っている"から,"使える"という一つ上の段階にあがるための一助になれば幸いです。 2019/8/30 © Akira Ikeda 19
  20. 20. 本セッションでのテーマ設定 2019/8/30 © Akira Ikeda 20 テスト設計技法を知っていたら十分と思っていないかい? テスト設計技法以外のことをお話しする 技法を実務で適用するためには,事前にいくつか準備することがあります 技法を適用する前に行なうことはなにか? テスト設計技法を適用する前のことをお話しする ※”マインドアップ”は造語になります。 ”知力の向上”,”前へ向く気持ち”という思いを込めています。 スキルアップについても考えてみる
  21. 21. アブストラクトの再共有 • 日々の業務でテスト設計技法を上手く使えないと相談を受けることが少なくありません。 相談者は決して努力していないわけでは無く,テストに関する研修を受けたり,書籍を 読んで勉強をしたりしています。それにもかかわらずそのような悩みを持つ方がいらっ しゃいます。テスト設計技法を上手く使うためには,テスト設計技法そのものの理解を 深める以外に,事前にやっておくべきことや考慮すべきことがあります。テスト設計技 法を使う局面という足下だけを見ていても難しく,顔を上げてテストプロセス上の“それ 以前”,つまりテスト分析設計に目を向けることが大切です。そして,顔を上げるだけで はなく,テスト分析設計はもちろんテストそのものに取り組むための意識向上が必要と なります。それらに取り組む先で,テスト設計技法をうまく使うためのマインドが得ら れることでしょう。 2019/8/30 © Akira Ikeda 21
  22. 22. アブストラクトの再共有 • 本基調講演では,JaSST'19 Hokkaido のメインテーマである「マインドアップ」につな げていくために「フェイスアップ」「ビルドアップ」という観点から,これまでの自 身の経験も交えながらお話しいたします。 • 「フェイスアップ」パートでは,テスト設計技法を上手く使うために,テストプロセ スの視点から,事前に取り組むべきことについて,2019年4月に発行した「[改訂新 版]マインドマップから始めるソフトウェアテスト」をベースにお話します。 • 「ビルドアップ」パートでは,テスト設計技法を使えるエンジニアになるため/育て るために活用できる技術やコミュニティ等を紹介し,今後どのように取り組んでいく べきかを考えます。 • 90分という短い時間ですが,一緒に「その先のマインドアップ」の姿を捉えましょ う! 2019/8/30 © Akira Ikeda 22
  23. 23. Mind set! あ な た が U P し た い マ イ ン ド と は ?
  24. 24. あなたが考えるマインドアップとは? 考えてみよう →付箋に書いてみよう •どのようなマインドをアップしたいですか? •どのようなマインドをアップすることが大切でしょう か? •などなど,マインドアップについて自分なりのイメージ を持ちましょう 共有してみよう •同じテーブルの方と共有しましょう 2019/8/30 © Akira Ikeda 24
  25. 25. 考えて みよう! 本 題 に 入 る 前 に 頭 の 体 操 を し ま し ょ う
  26. 26. 考えてみよう! あなたは,ある日 プロ野球球団の投手として働くことになりました あなたのミッションは試合の勝利に貢献することです 一日野球教室にて球種は教わりました さて,それだけで試合に勝てるでしょうか? 2019/8/30 © Akira Ikeda 26
  27. 27. 【演習】考えてみよう! • 勝つためにはどういった事が必要でしょうか? • あなたが“投手として” やっておくべき事を考えてみましょう 2019/8/30 © Akira Ikeda 27 # やっておくべきこと 時期 1 2 3 4 5
  28. 28. 第0部 まずは足下 ま ず は 実 務 で の テ ス ト 設 計 技 法 あ れ こ れ を 確 認 し ま し ょ う
  29. 29. 【演習】なぜテスト設計技法を使いたいのか? • 我々はなぜテスト設計技法を使いたいのでしょう? • その理由をあらためて考えてみましょう 2019/8/30 © Akira Ikeda 29 # 使いたい理由 1 2 3 4 5
  30. 30. なぜテスト設計技法を使いたいのか • テスト設計技法を使うと,妥当なテストケースにコントロールできる – テストケースが減る:テストをやりすぎてたいた状況を改善 – テストケースが増える:これまでのテストケースが少なすぎた • テスト設計技法を使うと,テストケースの偏りを改善できる – 組み合わせテストなどにおいて,満遍なテストケースのパターン配置が得られる • テスト設計技法を使うと,テストケースを自信を持って提案できる – 「頑張って考えました」ではなく,「こういった論理に基づいて作成しました」と説明でき ると,テストケースの存在の根拠が強まる • 根拠が薄いテストはやる意味があるのか? • その他の効果を期待できる – テスト設計技法を使うと,仕様の抜け漏れを発見できる – 仕様を多角的に理解できる(仕様を理解するためにテスト設計技法を使える) • その他… 2019/8/30 © Akira Ikeda 30
  31. 31. テストの研修を受けるが… テスト設計技法をきちんと 理解できなかった テスト設計技法は理解したが, 使いどころがわからない 2019/8/30 © Akira Ikeda 31
  32. 32. きちんと理解できなかった • 目的意識を持って受講していない – 改善したい課題を持っていないと表面的な理解にとどまってしまう • 自分の業務のドメインへの適合度が低い – 例えば,Web系エンジニアが,制御系エンジニア向けの研修の内容を理解するのは苦労する • 課題や事例,設問などの例が,自分のドメインとあっていないなど • 講師の略歴が適合してしない可能性もある • 前提知識が不足している – 数学の知識,ソフトウェア開発の知識,プログラミングの知識,ドメインの知識,その他… • 例えば,制御フローテストでは,グラフを知っておく必要がある • 例えば,状態遷移テストでは,グラフに加え行列を知っておく必要がある • 例えば,ランダムテストであれば,確率統計の知識が必要だろう • 例えば,サーバ・クライアント方式のテストは,開発方式の知識がないと理解が難しい • 例えば,ローカライゼーションテストは,その国の言語や文化,法律などを知っておく必要がある • などなど… 2019/8/30 © Akira Ikeda 32
  33. 33. 余談:書籍も同様 • テスト設計技法に関してだけではないが,書籍を読んでもよくわからないとか,難しいとか,読みにくいと思ったと き,そのほとんどの場合は「その書籍を読むための実力が備わっていない」という原因がある • 目的意識を持って読んでいない – 改善したい課題を持っていないと表面的な理解にとどまってしまう • 自分の業務のドメインへの適合度が低い – 例えば,Web系エンジニアが,制御系エンジニア向けの書籍の内容を理解するのは苦労する • 課題や事例,設問などの例が,自分のドメインとあっていないなど • 著者の略歴が適合してしない可能性もある • 読むための前提知識が不足している – 数学の知識,ソフトウェア開発の知識,プログラミングの知識,ドメインの知識,その他… • 例えば,制御フローテストでは,グラフを知っておく必要がある • 例えば,状態遷移テストでは,グラフに加え行列を知っておく必要がある • 例えば,ランダムテストであれば,確率統計の知識が必要だろう • 例えば,サーバ・クライアント方式のテストは,開発方式の知識がないと理解が難しい • 例えば,ローカライゼーションテストは,その国の言語や文化,法律などを知っておく必要がある • などなど… 2019/8/30 © Akira Ikeda 33
  34. 34. 余談:ワタシ オシエテモラウヒト の害悪 • どれだけ目的を持って,課題に合致した研修を受けたとしても, ワタシ オシエテモラウヒト という意識では何も身につかない • 研修や勉強会では,自ら学び,講師から学び取るという強い意識が必要 • 申し込んだ時点で安心してしまい,お客さん気分になることは避けよう – お客さん気分になると,その研修の達成基準が「どれだけもてなされたか」「いい気分に なったか」となってしまう – 俗に言う「勉強会温泉」状態になってしまう • 参加者は,そのような状況になるとスキルアップは望めなくなるため,意識を変えよう • 管理者は,このようなワタシオシエテモラウヒトという意識を持っていたり,勉強会温 泉に浸かるのが目的という部下は候補から外すか,意識を変革させる必要がある (研修や勉強会に業務として参加するのは,工数とお金を消費する!) 2019/8/30 © Akira Ikeda 34
  35. 35. 使いどころがわからない • 技法が解決できる課題を理解していない – テスト設計技法は必ず解決したい課題があって生み出されたものである • SQuBOKのトピック記述が参考になる • テスト対象の理解が不十分である – テスト対象を理解していなければ,そもそもどのような技法を使えるかも思いつかない • 仕様を読んでない(眺めただけ) • 仕様の範囲や,仕様と仕様のつながりを理解していない • 仕様が書かれた思想や背景を抑えていない • 仕様として書かれていない暗黙の仕様に気がついていない • その他,テストに求められる要求や制約などを抑えていない • 仕様を理解した上で,どのようなテストをすべきかという観点をまとめていない • 全体像がないと仕様を一行一行読み進めながら都度テストケースを作ろうという悪手に陥る – コピー&ペースト程度のテストケースしか生み出されない(そもともテスト設計技法が適用されない) – 仕様記述上のキーワードと一致したテスト設計技法しか思いつかない 2019/8/30 © Akira Ikeda 35
  36. 36. 参考:SQuBOKにおけるトピックの構造 • 目的 • 方法 • 効果 • 留意点 • 関連知識領域/トピックス • 参考文献 • 関連文献 2019/8/30 © Akira Ikeda 36 研修では,多くの場合,方法(手順)と直接的な効果だけが示されることが多い 目的を押さえにくいので,使いどころがピンとこないということになる また,設計技法について知っているから使えるようになるためにはその場の解説だけでは難しく, 現実的には複数の文献や論文などの情報もあたる必要がある
  37. 37. 足下を踏む固めることが大切 テスト設計技法をきちんと理解できなかった • 目的意識を持って受講しよう • 自分のドメインに適合している研修を選ぼう • 前提知識を学び直そう テスト設計技法は理解したが,使いどころがわからない • 技法が解決できる課題を理解しよう • テスト対象をよく理解しよう • テストの観点の全体像をまとめよう 2019/8/30 © Akira Ikeda 37 まずは足下固め,加えて,前準備に取り組もう もう一度足下を確認して, 不十分ならば踏み固めよう! 前準備が大切! (本日の本題)
  38. 38. 余談:必殺技症候群に陥るべからず • 見た目の派手さに憧れて,まだ身につけられない技法を学ぼうとする – ホイミすら覚えていないのに,いきなりベホマやベホマズンを求める ※注:ホイミやベホマ,ベホマズンはドラゴンクエストに登場する呪文名,高度な呪文は高レベルにならないと習得できない • そのテストでは使う必要がない設計技法も無理やり適用しようとしてしまう – 技法は知ってしまうと使いたくなる • ブームが過ぎたので使わなくなる – テスト技術にもブームがあるが,過ぎ去ると興味を失い利用しなくなる 2019/8/30 © Akira Ikeda 38 技法を沢山知っておくのは必要であるが, 着実に身につけ, 真っ当に利用し, 生かし続けることが重要である
  39. 39. 第1部 Faceup ~ 顔 を 上 げ て , そ の 前 を 意 識 ~ テ ス ト 設 計 技 法 を 利 用 す る 前 に 必 要 な テ ス ト 分 析 ・ 設 計 と 確 認 し , や り か た の 一 例 と し て マ イ ン ド マ ッ プ 活 用 例 を 紹 介 し ま す
  40. 40. テスト設計技法 を使う前にある, テスト分析・設計 テ ス ト 設 計 技 法 を 利 用 す る 前 準 備 で は ど う っ た こ と に 取 り 組 め ば よ い で し ょ う か 2019/8/30 © Akira Ikeda 40
  41. 41. 再掲:テスト設計技法は使うための前準備 1.技法が解決できる課題を理解しよう 2.テスト対象をよく理解しよう 3.テストの観点の全体像をまとめよう 2019/8/30 © Akira Ikeda 41 1.は研修や勉強にて解決が可能 2.および3.は近年テストプロセスで対応が進んでいる
  42. 42. おさらい:V字モデルでのテストレベル 2019/8/30 © Akira Ikeda 42 システム設計 構造設計 詳細設計 実装/机上テスト コンポーネントテスト 統合テスト システムテスト 対応 対応 対応 要件定義 受け入れテスト システム仕様書 等… 詳細仕様書 等… 構造仕様書 等… 要件定義書 等… 対応
  43. 43. テストライフサイクルプロセスの例 2019/8/30 © Akira Ikeda 43 さらに概念と作業を分割。テストライフサイクルプロセスの考え方が普及。 いかに戦略的なテストを行うかという議論。 分析 実装設計 実行 報告 特に準備なく場当たり的にテストを実行(モンキーテスト) テスト実行 テストケースの作成と実行に概念と作業を分離。テスト技法が普及。 テストケース作成 テスト実行 現在は概ねこのようなプロセス
  44. 44. V字モデルへライフサイクルをマッピング 2019/8/30 © Akira Ikeda 44 システム設計 構造設計 詳細設計 実装/机上テスト 実行→報告分析→設計→実装 コンポーネントテスト 実行→報告分析→設計→実装 統合テスト 実行→報告分析→設計→実装 システムテスト 対応 対応 対応 システム仕様書 詳細仕様書 構造仕様書
  45. 45. 「[改訂新版]マインドマップから始めるソフトウェア テスト」におけるプロセス 仕様分析 •どのような テストを行 う必要があ るのかを検 討 テスト計画 •仕様分析に よって洗い 出された情 報を計画と して作成す る。 テスト設計 •テスト項目 を洗い出し, テスト項目 の組み合わ せをテスト 仕様として まとめてい きます。こ こでテスト 設計技法を 適用します。 テスト実装 •テスト仕様 書の内容に 基づいて, 実行可能な レベルのテ ストケース を作成して いきます。 テスト実行 •テストケー スを実行す るとともに, その結果を 記録してい きます。ま た,バグが 発見された 場合,その 情報をイン シデントレ ポート(バ グ票)とし て発行しま す。 テスト報告 •テストの終 了後,テス トの実施結 果を基に, テストリー ダやプロ ジェクトマ ネージャ向 けに報告書 を作成しま す。 2019/8/30 © Akira Ikeda 45 使う使う準備
  46. 46. ISTQBシラバスにおけるテストプロセス テスト計画 •テストの目的と, 状況により課せら れる制約内でテス トの目的を達成す るためのアプロー チを定義する テストのモニタリン グとコントロール •テスト計画書で定 義したテストモニ タリングのメトリ クスを使用して, テスト計画書の内 容と実際の進捗を 継続的に比較する テスト分析 •テスト可能な フィーチャーを識 別し,テスト条件 を決めるためにテ ストベースを分析 する •何をテストするか, テストアイテムの 確定 テスト設計 •テスト条件を高位 レベルテストケー ス,高位レベルテ ストケースのセッ ト,およびその他 のテストウェアへ 落とし込む •どうテストするか, 高位テストケース を作成する,ここ でテスト技法を利 用する テスト実装 •テスト実行に必要 なテストウェアを 作成,および/ま たは完成させる •実行可能な完全な テストケースを作 成する テスト実行 •テスト実行スケ ジュールに従って テストスイートを 実行する テスト完了 •完了したテストの 全活動のデータを 集め,プロジェク トから得たこと, テストウェア,お よびその他の関連 する情報すべてを まとめる 2019/8/30 © Akira Ikeda 46 使う使う準備 現在,国際的にも分析と設計に取り組むのは必須
  47. 47. その他,参考になるテストプロセス • Test.SSFのプロセス – ASTERのサイトから参照可能 – [改訂新版]マインドマップから始めるソフトウェアの3章コラム「Test.SSFにおけるテストプロ セス」 • ASTER智美塾で検討されたプロセス – これまでのJaSSTでの発表資料が参照可能 • テスト設計コンテストのプロセス – テスト設計コンテストのチュートリアル資料などで参照可能 2019/8/30 © Akira Ikeda 47
  48. 48. テスト分析・設計の要素 • 先に挙げたようなテストプロセスや,国内で提案・導入が進むテスト分析設計手法に よって,実施することや手順,分担は変わるが,概ね以下のようなことを実施する 2019/8/30 © Akira Ikeda 48 情報入手 •テストベースを 入手する 情報理解 •入手したテスト ベースを読み込 む(純粋理解) •テストベースを テストの立場で 読み込む(テス トとして理解) テスト観点の全体 像策定 •読み込んだ内容 を元にテストを モデル化 •テスト戦略の 策定 •テストの観点 の全体像を検 討,モデル化 (文書化) テスト設計技法適 用 •テスト設計技法 を割り付け,利 用してテスト ケースを作成 テスト分析 テスト設計 テスト実装 テスト分析 テスト設計 テスト実装 テスト分析 テスト設計
  49. 49. テスト分析・設計の要素 • 先に挙げたようなテストプロセスや,テスト分析設計手法によって,実施することや手 順,分担は変わるが,概ね以下のようなことを実施する 2019/8/30 © Akira Ikeda 49 情報入手 •テストベースを 入手する 情報理解 •入手したテスト ベースを読み込 む(純粋理解) •テストベースを テストの立場で 読み込む(テス トの視点で理 解) テスト観点の全体 像策定 •読み込んだ内容 を元にテストを モデル化 •テスト戦略の 策定 •テストの観点 の全体像を検 討,モデル化 (文書化) テスト設計技法適 用 •テスト設計技法 を割り付け,利 用してテスト ケースを作成 テスト設計技法を利用する前の準備として, 朱文字のようなことを実施しておく必要がある
  50. 50. 国内におけるテスト分析設計手法 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法 ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェック ゆも豆 Tiramis ツリー (MM) テストカテゴリ分析を実施。機能はMM - TAME ツリー (MM) テスト設計思考の可視化とレビューによるテ スト観点の洗い出しおよび整理 - 2019/8/30 © Akira Ikeda 50 SEC BOOKS:高信頼化ソフトウェアのための開発手法ガイドブックから引用 https://www.ipa.go.jp/files/000005144.pdf マインドマップによる手法以外にもテスト観点ベースのテストの分析設計技法がある 複数の手法を試して自身の職場に適用できるものを活用しよう そのほかASTER主催テスト設計コンテストの資料も参考になる(http://aster.or.jp/business/contest.html)
  51. 51. コツ:実務を考慮してテストプロセスを設計すべし • テスト分析設計は様々なプロセスパターンや手法があるが… – 世の中には沢山の選択肢がありますが,現場の技術力や開発プロセス,社内規格・基準との 整合性などの関係で,そのままではうまく利用できない場合がある • 基本的なテストプロセスやアクティビティへの知識がない • 社内で定めている開発規格や基準がテストを考慮していない,改訂する必要がある • 業界標準への準拠が必須である – 医用系はFDA,オートモーティブ系はA-SPICEに準拠していることを求められる • ビジネス形態によっては,開発・テストプロセスをカスタマイズできない – 顧客先プロセスに準拠することが契約の場合など – 開発プロセスを変えられない,納品成果物が規定されている,etc… 2019/8/30 © Akira Ikeda 51 世の中のプロセスや手法をテンプレートとして, 必要に応じ,テストプロセスを設計するという考え方が重要
  52. 52. 余談:アジャイル開発への対応はプラクティス目線 で • テスト分析設計を工程と捉えると対応が難しくなる – 特別なイテレーションやタイムボック,スプリントを設けるという発想になりやすいため • テスト分析設計の要素を抑え,それを採用するアジャイル開発のフレームワークやプラ クティスに導入する – 例えば,ストーリーカードにテスト分析・設計の要素を加える – 例えば,プロダクトバックログにテスト分析・設計の要素を加える – 例えば,TDDをVOTDDで実践する – Etc… 2019/8/30 © Akira Ikeda 52
  53. 53. 【演習】自分流のテスト分析設計を考えてみよう • 実務の状況を踏まえ,自分流のテスト分析設計プロセスを考えてみよう 2019/8/30 © Akira Ikeda 53 プロセス やること 活用できる手法 成果物 テスト分析 テスト設計
  54. 54. テスト分析設計 方法の一例 ~マインドマッ プを活用する~ テ ス ト 分 析 設 計 方 法 一 例 と し て マ イ ン ド マ ッ プ に よ る テ ス ト 分 析 設 計 を 紹 介 し ま す 2019/8/30 © Akira Ikeda 54
  55. 55. テスト分析と設計が無い場合 2019/8/30 © Akira Ikeda 55 仕様書等 テストケース 初級者 (仕様例) ボタンを押すと音が出る (テストケース例) ボタンを押すと音が出ることを確認 初級者の悩み ・テストケースのヌケが多い! ・異常系のテストケースが抜ける! ・機能を組み合せを考慮したテストケースがかけない! ・テスト技法の使いどころがわからない! ・組織で積み上げられたノウハウが活用できない! ・自分の経験が再利用できない! などなど…… 単なる転記 語尾を付け足して 完成させる,単なる チェック止まり! ※チェックとテストの違いについて は,本資料最後にある「参考スライ ド」を参照下さい
  56. 56. テスト分析と設計がある場合 2019/8/30 © Akira Ikeda 56 上級者 仕様書等 テストケース テストケースを書く前に,思考を発散させながら,かつMECEを意識し て考える.なので,初級者に比較してテストケースの抜けが少なくなる! また,弱点をつくようなテストケースが作成できる! いろいろ発想する どんな音? 押し方は? タイミング は? 類似ソフト は? ユーザは? 昔どうしたん だっけ? 上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する ・テストを行うにあたって,テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」「組織のノウハウ」など ・テスト観点の階層や関連,組み合わせを考える ・不適切な仕様(仕様バグ)は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して,重み付けや実行順番など考える などなど…… 仕様書に書かれてい ないことも発想する
  57. 57. 実に多くを考えることが必要であるが… 2019/8/30 © Akira Ikeda 57 考えるっていっても 頭の中だけじゃ 大 変 だよな とりあえず, テストケース表を使って 考えようかな? どうせ最終的には エクセルの表になる わけだし ただ,テストケースの表現形式を使ってテスト設計を行うのは難しい
  58. 58. 実に多くを考えることが必要であるが… 2019/8/30 © Akira Ikeda 58 表で観点を出す, つまりブレストは 難しいな~ じゃぁ,そのような特徴をもつ 発想支援ツール,マインドマップを 使ってみたら? 試行錯誤できる 記法がいいな 整理するためには 全体を俯瞰 できなくちゃ でも,発想力を刺激し てくれるものでないと, 観点が抜けちゃう! できれば構造化 しやすいものが いいかも
  59. 59. マインドマップの利用イメージ 2019/8/30 © Akira Ikeda 59 仕様書 テストケース 初級者 マインドマップを描くことで, ・単純な仕様の転記がなくなる ・仕様書に書かれていないことにも思考が誘導される ・「考える」行為を明確に実行できる マインドマップを描く
  60. 60. テスト分析・設計にマインドマップを活用 2019/8/30 © Akira Ikeda 60 テストケースの品質に大きな影響を与え, かつ,仕様外への発散思考が特に重要な ・テスト分析 ・テスト設計 にマインドマップを使ってみよう ・マインドマップの概要 ・マインドマップの適用を見据えた テスト分析&テスト設計の作業と勘所 ・マインドマップを使った作業手順 を説明します テスト分析・設計の1つのやり方として紹介します
  61. 61. 2019/8/30 © Akira Ikeda 61
  62. 62. マインドマップとは? • トニー・ブザンにより考え出された図解技法 – 脳の仕組みを取り入れたもの – 思考に沿って描いていく – 図を取り入れる – 自分の深層意識にアクセスする 2019/8/30 © Akira Ikeda 62 Wikipediaによる解説 表現したい概念の中心となるキーワードやイメージを図の中央に置き,そこから放射状にキー ワードやイメージを繋げていくことで,発想を延ばしていく図解表現技法。 この方法によって複雑な概念もコンパクトに表現でき,非常に早く理解できるとされ,注目さ れ始めている。 人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合しているので,理解や記憶 がしやすい。 また本来は紙とペンで描くものだが,コンピュータ上で描くための専用ソフトウェアもいくつか 存在する。
  63. 63. マインドマップの特徴の一例 •全体を俯瞰し易いバードビュー •項目それぞれが重複することなく,全体集合として漏れがないMECE •基本的なルールは単純で,紙とペンがあれば始められる学習が容易 •フリーなルールであるために,柔軟に構造を変更可能半構造 •描いているうちに他の項目との関連などから新たな発想が生まれやすい •深層意識へのアクセスし,情報を引き出す発想力が刺激される •中心から外に対して思考が放射的に広がる思考の流れの見える化 2019/8/30 © Akira Ikeda 63 これらの特徴を上手く生かそう♪
  64. 64. 済 2019/8/30 © Akira Ikeda 64
  65. 65. この例での「テスト分析」と「テスト設計」 2019/8/30 © Akira Ikeda 65 テスト分析 テスト設計 テスト実装 テスト実行 仕様等の理解・整 理・検討・テスト 観点の目付け テスト観点の発 想・検討・整理, テスト技法の適 用 詳細テストケー ス・スクリプト等 の作成(適切な フォーマットに表 現) テストケースの作成 テストの実行 作業/概念で分ける ここにマインドマッ プを使うぞ! テスト実装に より作成され たテストケー スを実行し, ログを取る テスト報告 テストの結果や ログを整理し, 当該テストレベ ルでのテスト活 動を評価する ※注意 本講演ではテスト観点の発想はテ スト設計で行ないますが, 他の手法ではテスト分析で行なう 場合もあります。
  66. 66. 開発作業とテスト作業のおおまかな対比イメージ 2019/8/30 © Akira Ikeda 66 ソフトウェア開発 テスト開発 要求分析 設計 実装 テスト分析 テスト設計 テスト実装 顧客要求を分析し,ソフトウェアとし て実現可能か検討する 分析結果に基づいて,設計モデルの作 成や仕様の決定を行う モデルや仕様に基づいて,プログラム 言語を使ってプログラムコードとして 実装する テストベースを分析し,どのようなテスト が実現可能か検討する テスト観点を発想,モデル化し,テスト設 計技法を適用する テストケースフォーマットを使って詳細テ ストケースやテストスクリプトとして実装 する テスト実行 プログラム テストケース 設 計 仕 様 書 が 主 な テ ス ト ベ ー ス と な る
  67. 67. テスト分析の作業と勘所(1) 設計仕様やテストへの要求の理解・整理・検討(純粋理解) •知らないものはテストできない! •設計仕様に関する思想や観点,構造や構成物を理解する •どういったものを作ろうとしているかのイメージをつかむ •設計者が特に重要と考える部分は,テストでも重要度が高いことがほとんど •顧客先でどのように利用されるのか •テストへの要求や制約,品質目標等の認識 テスト設計の手がかりを作る(テストの視点で理解) •テストすべき“要求”や“要件”,“仕様”や“機能” •ソフトウェアのウィークポイントの目付け •過去のテストの経験からひっかかるところ,気配を感じるところ •テストタイプの候補抽出 •その他の疑問点 •疑問が生じる箇所は仕様がこなれていない可能性がある 2019/8/30 © Akira Ikeda 67 テスト分析 テスト設計
  68. 68. テスト分析の作業と勘所(2) 仕様の抜け漏れの発見と修正へのアクション • 仕様の欠陥を発見したら,設計部門にフィードバックし,仕様の高品質化をはか る • 仕様書の高品質化は即ちテストベースの高品質化であり,そこから生み出され るテスト設計仕様やテストケースの高品質化に寄与する • 良い仕様書からは,良いコードと良いテストケースが生まれる • 欠陥以外でも,疑問を生じたことは積極的に問い合わせる テスト戦略へのフィードバック • 分析結果の情報をテストの戦略や計画に反映 2019/8/30 © Akira Ikeda 68 テスト分析 テスト設計 仕様が理解できなかったり抜け漏れが多い場合,開発者に見直しを要請する テスト分析の作業はある意味においてテストの立場からのレビュー行為でもある どれだけ正しい仕様を深く理解できるかも良いテスト設計への鍵
  69. 69. テスト設計の作業と勘所(1) テスト観点の発想 •「なにをテストしよう」「どうテストしよう」が思いつかないと話が始まらない •仕様書の分析結果や過去の経験,組織ノウハウから •テストカテゴリの利用 •Myersの14のシステムテスト・カテゴリ •ボリューム,ストレス,効率,ストレージ,信頼性,構成,互換性,設置,回復,操 作性,セキュリティ,サービス性,文書,手続き •ISO/IEC 25010の品質特性 •システム/ソフトウェア製品品質 •機能適合性,性能効率性,互換性,使用性,信頼性,セキュリティ,保守性,移植性 •利用時の品質 •有効性,効率性,満足性,リスク回避性,利用状況網羅性 •組織に蓄積されたガイドワード •テスト設計を進めるなかで得られる新たな発想 2019/8/30 © Akira Ikeda 69 テスト設計テスト分析
  70. 70. テスト設計の作業と勘所(2) テスト観点の剪定・整理 • テスト観点には重要度や優先度が存在する • 全てのテストは多くの場合やりきれないため,テスト観点に優先度をつける • テストする必要のない観点や優先度・重要度の低い観点は切り落とす • 切り落としたテスト観点とその理由は記録に残しておくこと • 無秩序に発想したテスト観点を整える • 観点の階層や観点間の関連を検討する テスト設計技法の適用 • 観点モデルの観点要素に対して対応するテスト設計技法をアサインし,実行する テスト戦略へのフィードバック • テスト設計結果の情報をテストの戦略や計画に反映 2019/8/30 © Akira Ikeda 70 テスト設計テスト分析 ここでどれだけテスト観点を発想できるかがテスト設計の鍵 しかし,テスト観点をただ洗い出すだけでは不十分 テスト観点の剪定を行い階層や関連関係を整理する
  71. 71. 余談:テスト観点に関するよくある発言 • いわゆる「テスト漏れ」に対してその理由を聞くと, 「テストの観点が漏れていました」 という発言をよく聞く • テストの観点漏れを防ぐための対策に挙げられることが多いのは「テストレビューを充 実します」という発言 • このときテストレビューの充実の意味は「テストレビューの回数を増やします」だった り「時間を増やします」だったり「有識者を増やします」であることが多い • しかしながらこれは後手後手の対策 • テストの観点漏れを防ぎたいのであればレビューで防ぐのではなく,その前に対策を 打っておく必要がある • さて,あなたの現場では「テストの観点漏れに対してレビュー以外の手」を打っている だろうか? 2019/8/30 © Akira Ikeda 71
  72. 72. 済 済 2019/8/30 © Akira Ikeda 72
  73. 73. マインドマップ適用時の基本的な作業手順と範囲 2019/8/30 © Akira Ikeda 73 テスト設計 (観点モデルの作成) テストベース (仕様書等) テストケース Mind Map 直接転記 しない テスト設計 (テスト技法の適用) テスト設計に マインドマップを適用する 分析と設計の成果物として マインドマップが作成される テスト分析 マインドマップではなく, 各種テスト技法を活用する テスト実装
  74. 74. マインドマップ適用時の基本的な作業手順と範囲 2019/8/30 © Akira Ikeda 74 テスト設計 (観点モデルの作成) テストベース (仕様書等) テストケース Mind Map 直接転記 しない テスト分析 テスト分析にも マインドマップを適用する テスト設計 (テスト技法の適用) テスト実装
  75. 75. コツ:テスト分析には3色ボールペンも活用しよう! • テスト分析をマインドマップだけで行うのはかなり大変 – セントラルイメージやメインブランチがなかなか決まらない • まず仕様書を3色ボールペンでチェックし,マインドマップを描く手がかりとする – 赤:客観的に「重要」な箇所 – 青:客観的に「まあまあ重要」な箇所 – 緑:主観的に「気になる」箇所 • チェックしている時点で,仕様の洩れや抜け, 間違いに気がつくことも多い – マインドマップを描く前に,テストベースの 品質向上できる – テスト分析するに値する品質となっているかの チェックとしてもいいだろう 2019/8/30 © Akira Ikeda 75 • テストの思考を意識したルールでも良い – 赤:「こう動くべき」な箇所 – 青:「こう動かないべき」な箇所 – 緑:「それ以外」な箇所
  76. 76. マインドマップ適用時の基本的な作業手順と範囲 2019/8/30 © Akira Ikeda 76 テスト設計 (観点モデルの作成) テストベース (仕様書等) テストケース Mind Map 直接転記 しない テスト分析 テスト分析に 3色ボールペンも使う テスト設計 (テスト技法の適用) テスト実装
  77. 77. マインドマップ適用時の基本的な作業手順と範囲 2019/8/30 © Akira Ikeda 77 テスト設計 (観点モデルの作成) テストベース (仕様書等) テストケース Mind Map 直接転記 しない テスト分析 テスト分析と設計に マインドマップを適用する 分析と設計の成果物として マインドマップが作成される テスト分析に 3色ボールペンを使う マインドマップではなく, 各種テスト技法を活用する テスト設計 (テスト技法の適用) テスト実装
  78. 78. デモムービー 2019/8/30 © Akira Ikeda 78
  79. 79. マインドマップの例 2019/8/30 © Akira Ikeda 79 観点を思いつき,そこにテスト設計技法を適用している メモや疑問
  80. 80. マインドマップの例 2019/8/30 © Akira Ikeda 80
  81. 81. マインドマップの例 2019/8/30 © Akira Ikeda 81
  82. 82. 整理:マインドマップを使った全体の流れ 2019/8/30 © Akira Ikeda 82 テストケース (仕様例) ・ボタンを押すと音が出る (テストケース) ・ ・ ・ ・ ・ テスト分析・設計を導入して,単なる仕様チェックから卒業しよう! ・テストケースは仕様を単純に転記しない ・仕様に書かれていないことも考える ・ベースとなる仕様を深く理解するために三色ボールペンを使う ・テスト観点を発想するためにマインドマップを使う ・発想したものからテストしなければならないものをまとめる ・テストの全体像をまとめ,テスト設計技法を適用してテストケースを作る 考えてみよう! マインドマップを描く 単なる転記は絶対ダメ! 疑問や不明点は確認 仕様書を読む ⇔ 作成・ 修正 仕様書
  83. 83. 再掲:国内におけるテスト分析設計手法 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法 ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェック ゆも豆 Tiramis ツリー (MM) テストカテゴリ分析を実施。機能はMM - TAME ツリー (MM) テスト設計思考の可視化とレビューによるテ スト観点の洗い出しおよび整理 - 2019/8/30 © Akira Ikeda 83 SEC BOOKS:高信頼化ソフトウェアのための開発手法ガイドブックから引用 https://www.ipa.go.jp/files/000005144.pdf マインドマップによる手法以外にもテスト観点ベースのテストの分析設計技法がある 複数の手法を試して自身の職場に適用できるものを活用しよう そのほかASTER主催テスト設計コンテストの資料も参考になる(http://aster.or.jp/business/contest.html)
  84. 84. コツ:テスト分析設計には思考に役立つ手法を複数 持っておくとよい • 6つの帽子 – 帽子をかぶり直しながら考えることで思考の偏りを防ぐ • 白:客観的,赤:直感的,青:肯定的,黒:創造的,黄:否定的,緑:管理的 • 6W2H – 富士ゼロックス秋山浩一さんのHAYST法で利用されている視点 • 開発者(Why, What, Howto),ユーザー(When, Where, Who),お客様のお客様(Whom, How much) • 強制類推法 – 刺激ワードを無理に組み合わせて発想を促す – 鈴木三紀夫さんの意地悪漢字やHAZOPのガイドワードなども使える – 組織によってはテスト観点キーワード集なども利用すると良い • 類語置換法 – 思いついたキーワードを類語に置き換えてみると違った発想が得られる – 一度書き上がったマインドマップに出現しているテスト観点キーワードを,類語辞典を使っ て置き換える 2019/8/30 © Akira Ikeda 84
  85. 85. コツ:テスト分析設計には思考に役立つ手法を複数 持っておくとよい • 逆設定 – 前提を強制的に反転して考えてみる – 仕様として書かれていることを“常識”としてとらえ,“非常識”から考えてみる • 三銃士モデル – 世界観,コンテキスト,実装 • CIBFW – 電気通信大学西康晴先生による観点 – 条件(Condition),テスト対象(test Item),ふるまい(Behaviour),嫌なこと(things Faulty or hazardous),世界(World) 2019/8/30 © Akira Ikeda 85
  86. 86. コツ:マインドマップにこだわる必要なし 大切なのは,発想すること • 探検ネット(花火) – KJ法で利用される発想技法 – 見栄えはマインドマップとも似ている • マンダラート – 3*3のマス目の真ん中にテーマを書き,そこから残り8マスを埋めるように発想する – [改訂新版]マインドマップから始めるソフトウェアテストにコラムあり • はちのすボード – 基本的にはマンダラートと同じ – ハニカム構造のボードを使って発想を広ていく 2019/8/30 © Akira Ikeda 86
  87. 87. コツ:マインドマップは発散,収束は別手法で • マインドマップは思考の発散には向いているが,物事の整理にはあまり向いていない • このため,収束プロセスは別の手法や記法を利用するのがよい – マインドマップ → ツリー図 – マインドマップ → クラス図 – マインドマップ → NGT – マインドマップ → FV表 – マインドマップ → テスト観点マトリクス – マインドマップ → 連関図 – マインドマップ → ネットワークモデル – マインドマップ → KJ法で収束 – Etc… 2019/8/30 © Akira Ikeda 87
  88. 88. 【演習】描いてみようマインドマップ 2019/8/30 © Akira Ikeda 88 【身近にある仕様書を元にしてマインドマップでテスト分析設計】
  89. 89. プロジェクト への導入例(1) あ る プ ロ ジ ェ ク ト へ の 導 入 事 例 を 紹 介 し ま す 892019/8/30 © Akira Ikeda
  90. 90. 90 あるプロジェクトへの導入事例 仕様書 仕様書の品質が仕様分析やテスト分析を行うに至らない場合,設計部門に対し見直しを依頼 テスト設計技 法適用へ仕様書に多くの問題がある場合,再度見直しを依頼 テ ス ト 設 計 が 甘 い 場 合 , 再 度 見 直 し 仕様分析 & テスト設計(複数人での作業) テストの立場からの分析を, テスト設計を意識して行う 初期チェック以上に詳細に分 析を行う。 テスト観点を列挙し,階層化 や重要度・優先度付けを行う ほか,観点間の関連を洗い出 して表現する。 仕様に対する 疑問点が生じたら, 分析に戻る 仕様の分析が 終了したら, テスト設計を行う 仕様書の分析 テスト設計 まず,仕様書が仕様分析対象のレベルに達しているか,全体をざっくりチェックする このときツールとして,3色ボールペンを利用 初期分析 仕様分析 は 開始OK か? OK レビュー実施 合格か? 合格 資料のひとつとし てマインドマップ を利用 2019/8/30 © Akira Ikeda
  91. 91. 91 複数人によるテスト分析&テスト設計 全体の方向性の検討 分析&設計する上での意識あわせを マインドマップを共有作成して行う ・大雑把な仕様やコンセプトの確認 ・使用するテストベースの確認 ・使用するテストカテゴリの確認 ・スケジュール等,テスト計画の内容 etc… それぞれの 分析&設計結果を集約 複数人で作成した分析&設計結果のマッ プをひとつのマップに集約する ・集約過程におけるレビュー効果 ・ノウハウの水平展開(教育効果) ・テスト分析&設計と戦略の意識統一 etc… 複数人それぞれで 分析&設計 ベテラン 新人 他部門の有識者 複数人で分析&設計を行うことによって, 多角的な検討を行う ・ベテランや新人 ・ドメインごとのエキスパート ・他部門の有識者 etc… 分 析 & 設 計 の 指 針 結 果 の 集 約 2019/8/30 © Akira Ikeda
  92. 92. 現場担当者に聞く,主な得られた効果 テスト観点の全体像が見える •どこに重きを置くか,どことどこを組み合わせるかの検討が容易に •観点ごとに担当者を決めるなど共同作業がやりやすくなる 2. テスト技法が適用し易くなる •テスト観点ごとに,適用し易いテスト技法をマッピング •テスト観点・テストタイプと関連している技法を選択できる 3. 担当者における,テスト意図の見える化 •各担当者の思考の流れが描かれることで,結果に対する理由が見やすくなる •なぜそのテスト観点なのか •なぜその階層関係なのか •他人の意図が見えるだけではなく自分の意図も見える •セルフレビューができる 4. テストに対する意識とモチベーションの向上 •テストは設計されるものであるという認識 •目に見える成果物が絵で描かれるため,楽しい •クリエイティブな活動をしているという誇り 2019/8/30 © Akira Ikeda 92
  93. 93. 現場担当者に聞く,その他の効果 1. 仕様書のレビュー効果 •違った観点からの分析により,仕様における漏れ抜けを発見 •設計部門が仕様書の見直しを行うことで,手戻りの減少 2. テスト戦略へのフィードバック •テスト観点のモデリングを行うことで,戦略をもったテスト計画が作成可能に •テスト観点の重要度からテスト実行スケジュールを検討するなど 3. テストケースの増減 •増えたところ •そもそも抜けていたテスト観点や組み合わせに従ったテストケースが増加 →テストの洩れの防止 •減ったところ •テスト観点の重要度・優先度づけにより,無駄に作りすぎていたテストケースの削減 →テストの効率化 4. テスト担当者のスキルアップ •ベテランの描いたマップを参照することで,自分にない“観点”の獲得 •ビギナーの思考が見えることで,適切なアドバイスができる 2019/8/30 © Akira Ikeda 93
  94. 94. 過去のJaSST北海道での関連事例 2019/8/30 © Akira Ikeda 94
  95. 95. 過去のJaSST北海道での関連事例 2019/8/30 © Akira Ikeda 95
  96. 96. JaSSTのサイ トは事例の宝 の山 • JaSSTにはマインドマップ の適用事例の他,テスト プロセスに関する沢山の 事例情報が掲載されてい ます • 是非宝探ししよう! 2019/8/30 © Akira Ikeda 96
  97. 97. プロジェクト への導入例(2) V O T D D に お け る マ イ ン ド マ ッ プ の 導 入 事 例 を 紹 介 し ま す 972019/8/30 © Akira Ikeda
  98. 98. あるVOTDDを採用したプロジェクトへの導入例 • VOTDDとは検証指向TDDのことで,TDDのテストコードの保守性やテストの網羅性の充実 を目的とした手法 2019/8/30 © Akira Ikeda 98 RED GREENREFACTOR RED GREEN VERIFY & DEBUG REFACTOR ・TEST ・PRODUCT 拡張 TDDのサイクル VOTDDのサイクル
  99. 99. あるVOTDDを採用したプロジェクトへの導入例 •テスト設計を洗練する •テスト設計の見直しを行なう •テストの抜け漏れを防止する •テスト設計の最適化 •テスト設計のレビュー効果によ り,プロダクト仕様の欠陥や改 善点を抽出 VERIFY & DEBUG の 追加 •テストコードを改善する •テストコードの保守性を高める REFACTOR へのTEST の追加 2019/8/30 © Akira Ikeda 99 RED GREEN VERIFY & DEBUG REFACTOR ・TEST ・PRODUCT VOTDDのサイクル
  100. 100. テスト設計の全体像設計と共有のための マインドマップ導入 課題 •VOTDDは開発者とテスト技術者が二人三脚で実施するが,テスト設計の観点や意図の共有 がテストコードのみではなかなか難しかった 対応 •テストコードの近くにテスト設計の観点や意図を置く(記入しておく) •できればコメントではなくて,全体像を概観できると良い •テストコードの近くにマインドマップを置いておくことで,テストコードの全体像の設計 や把握を助ける 解決策 •このVOTDDでは,DoxyGenを使っていたため,テストコードの近くにマインドマップを コードとして置いた •マインドマップはPlantUML で記述 •開発者はもともとPlantUMLでプロダクトモデルを描いていたため,導入障壁も低かった 2019/8/30 © Akira Ikeda 100
  101. 101. 現場担当者に聞く,主な得られた効果 1. VERFY & DEBUG のスピードが向上した •テストコードのそばにテスト設計があるため,すぐに参照できるようになった 2. テストコードの全体像が見えるようになった •テストコードが増えると,全体として何をテストしたいのかがわからなくなる •マインドマップがあることで,テストコードを全件追わずとも全体像が見えるようになった 3. 開発者がよりテストを意識するようになった •導入前はテスト観点モデルはテスト技術者のみの情報になりがちであった •テストコードの近くに見えることで,開発者がよりよいテストを考えるように意識誘導された 4. テスト技術者の貢献がコードに示されるようになった •VOTDDだと,テスト技術者の貢献はテストコードに反映されるが,その維持主体は開発者であるため テスト技術者の貢献がわかりづらかった •開発者が(主には)扱わないテスト設計が,開発者と同じ土俵であるコードという形で見えるように なるため,開発者に評価されやすくなった 2019/8/30 © Akira Ikeda 101
  102. 102. ご参考: テスト観点モデ ルの作成ステッ プ 実 導 入 の 経 験 か ら 例 を 紹 介 し ま す 1022019/8/30 © Akira Ikeda
  103. 103. 現場適用での反省:初級者には一気にテスト観点モ デルを完成させるのは難しかった • 某プロジェクトにおいて,テスト初級担当者に対して,テスト設計のトライアルにチャ レンジしたが,うまくいかなかった • よくよくヒアリングしてみると,次のようなことが“実践では”問題となっていた – マインドマップに慣れていなかった – マインドマップを使って考えろといわれても,何をどういった順番で考えれば良いかわから ない – マインドマップを描いたとしても,先輩達が望む,組織のこれまでの知見などが反映されて いない • 初級者に「マインドマップでテスト設計して」といっても難しい テスト観点モデルを作成する際の手順を 初級者向けに形式化して ステップbyステップで進められるようにした 2019/8/30 © Akira Ikeda 103
  104. 104. テスト観点モデルの作り方(その1) • 初級者向けのテスト設計プロセスはCG制作プロセスにヒントを得て形式化 – 段階的にモデルを育てる(素のモデルに,プロジェクト制約や組織・ドメイン知識をまぶす – モデルのレビューをきちんと入れる,テスト設計書フォーマットと対応づける モデリング •テストベースから自由な発想でテスト観点を発想 レンダリン グ •レンダリング指示書に従い,テスト観点モデルに対して以下を実施 •エフェクト(制約情報やドメイン観点)を追加 •フィルタ(観点や関連,リスク順位や重要度等の強弱)を反映 カメラテス ト •レンダリング結果に対し公式レビューを実施,テスト観点絵図として確定 ファイナラ イズ •テスト観点絵図を所定のテスト設計書フォーマット(テンプレート)に焼き込み 2019/8/30 © Akira Ikeda 104
  105. 105. 初級者向けテスト観点モデルの作り方(その2) • モデリング – 仕様書等直接のテストベースを使って,自由な発想でテスト観点モデルを作成 • CG的には,生ポリゴンのモデルやワイヤフレームが出来上がるイメージ • レンダリング – モデルに対し,レンダリング指示書に従い,「エフェクト」と「フィルタ」を追加・適用し全体を 調整 • エフェクトとはそのプロジェクトが持つ固有の情報や観点で,プロジェクト制約や製品ドメイン観点など – CG的には,テクスチャやフォグとか光源とかパーティクルやオブジェクトを追加するイメージ • フィルタとはテスト観点や関連が持つ属性の強弱を調整するもので,テスト観点の強度や関連の太さ,リ スクの強弱といったものを調整 – CG的には,明るさやコントラストを調整したりセピア風やキャンバス風に変換したり,被写界深度を設定したりと いったイメージ – レンダリング指示書ではどのエフェクト・フィルタを適用するのか,どういった順番かといったこ とを指定する • なお,このエフェクトとフィルタはそれぞれ「エフェクトモジュール」と「フィルタモジュール」として 別途作成,これらモジュールを独立性高く作成することで再利用がきくようになる(例:FPGAコントロー ラ観点エフェクト,組込み系汎用エフェクト,高信頼性サーバ向けリスクフィルタ) 2019/8/30 © Akira Ikeda 105
  106. 106. 初級者向けテスト観点モデルの作り方(その3) • カメラテスト(プレビュー) – レンダリング工程を経たテスト観点マインドマップについて公式レビューを行う • レンダリング結果を様々なカメラから確認する。この時,カメラをどの位置や角度に置くのかが重 要。このカメラとは即ちレビューの方針や観点。また,基本的に通常のレビューと同じく様々なメ ンバで構成されることが望ましい • ファイナライズ – テスト観点絵図(マインドマップ)を組織で規定されたフォーマットやテンプレートに焼き 込み(移しかえ) • このとき,焼きこみに失敗しないように注意すると共に,ちゃんと焼き込めたかの確認が必要 2019/8/30 © Akira Ikeda 106
  107. 107. コツ:テスト観点(ノウハウ)の蓄積 • テスト観点をためていくことでテスト設計でのノウハウを蓄積していくことができる – エフェクトとフィルタというそれぞれの分類ごとにモジュールを作成してためる • エフェクト,フィルタは(現在のところ)形式は規定していない – エフェクトは基本的にキーワードレベル • キーワード一覧の体を取る(構造も持たせる場合はツリーやマインドマップ) • エフェクトに記載されるキーワードは過去のテスト観点モデルから抽出,整理したもの • その他,過去の欠陥情報からも抽出可能 • 品質特性や規格は独立してエフェクトとしても良い – フィルタは方針を表す文章レベル(キーワード抽出しても良い) • フィルタはプロジェクト情報や製品戦略,品質目標や部門方針などから導かれる • その他,リスク分析情報からも • その他,テスト観点キーワードリストやテスト観点・テストタイプ・技法対応表などを 整備するのも良い 2019/8/30 © Akira Ikeda 107
  108. 108. コツ:あじさい問題 • テスト観点キーワードは便利だが,誰しもが同じイメージを持てるものまで落ちていないと, メンバ間でモデルの認識がブレる • 例えば,「あじさい」というキーワードがあったとして,読み手によりイメージが異なる – 水色もあれば,紫もあり,白もあれば,桃色もある • 土壌のアルミニウムイオンにより変わる – 花や葉の形が異なる • 植物分類学上,さらに分類がある • テスト設計にマインドマップを使うことの意図のひとつに「本来のマインドマップのようにビ ジュアルを多用することにより,より具体的なイメージでテスト観点を共有する」ことがある – マインドマップを使ったとしても,キーワードベースだと,イメージのブレが発生しやすい – イラストや図表を多用することで,イメージのブレを押さえ込む • あじさいの絵があれば具体的なイメージとなるし,キーワードに色をつけるだけでも色情報をつけられる • テスト観点キーワードリストのようなものはたんなるリストだと使い物にならないことに注意す る 2019/8/30 © Akira Ikeda 108
  109. 109. さらにその前 に考えておく べきこと テ ス ト 分 析 の 前 に ま だ や る べ き こ と は あ る の だ 2019/8/30 © Akira Ikeda 109
  110. 110. 実際の所,それだけでよいのか • 先ほどの話は十分な品質や目的にかなったテストベースがインプットされる前提になっ ているが,現実問題としてテストベースの入手に関する問題がある – 品質が悪く,テスト分析しようがない – テストベースの量が足りない,そもそもない – テスト分析がしっかり行えないと言うことは,後に続くテスト設計や実装も行えないという 事である(テスト設計技法では解決できない) • この問題を解決しないかぎり,そもそもテストプロセスだけの改善ではらちが空かない し,未来永劫同じ問題を抱え続ける 2019/8/30 © Akira Ikeda 110 システム設計 実行→報告分析→設計→実装 システムテスト 対応 システム仕様書 ここの品質に 大きな影響を受ける
  111. 111. よりよいテストベースを入手するために • 品質が悪いテストベースは受け入れない – テストベース受け入れレビューを実施する • ドキュメントとしての体を成していないものは受け入れない • テストベースパッケージを定義して,構成管理をする – 入手すべきテストベースを事前に識別する • 入手すべきは対応する仕様書だけではないはず,十分な量(種類)を確保する – パッケージとその構成物は,構成管理を実施して常に最新の情報を得る • テストプロセス中にテストベースに変更がかかることは(現実として)よくある 2019/8/30 © Akira Ikeda 111 システム設計 実行→報告分析→設計→実装 システムテスト 対応 システム仕様書 受け入れ レビュー テストベースパッケージの構成,構成管理
  112. 112. 開発レビューに参画する • 開発レビューに参画して,仕様書の充実度を向上する – 記述自体の充実度や正確性等に加えて,テストに役立つ情報も充実させる • ただし記述を混ぜると可読性を悪くしてしまう場合があるので,別紙とするなど工夫が必要 – テスタビリティ視点からの指摘 • その仕様はテスト可能か,テストしやすいか,いくつかの手段があるか,テストのための機能はあ るか,etc… – 過去の欠陥から,設計にフィードバック • 欠陥を作り込んだ・作りやすい仕様や構造についてフィードバックし,設計変更してもらう – テスト分析の前倒し • テスト分析に入る前に,先行で仕様などについて学習の機会となる 2019/8/30 © Akira Ikeda 112 システム設計 実行→報告分析→設計→実装 システムテスト 対応 システム仕様書 受け入れ レビュー テストベースパッケージの構成,構成管理 仕様レ ビュー参画
  113. 113. 開発レビュー参画時の注意点 • 開発やドメインについての知識がないままにレビューに参画すると次のような事が起き がち – 発言できない – 誤字脱字程度の指摘しかできず,煙たがられる – 開発や技術等の背景を抑えられないまま斜め上のコメントをしてしまう – このような状況になると,いずれ参加を拒否されるようになってしまう • 開発レビューに有効に参画するには – 相手の土俵に乗る – 開発やドメインの知識を仕入れておく – 仕様や設計方式にも(テストの知識を生かして)コメントする – 開発者と同等のレビューの技術を持っておく – また,開発レビューに参画する場合,テスト担当者も工数を確保しておく必要がある 2019/8/30 © Akira Ikeda 113
  114. 114. そのほか,テストベースとして忘れがちな情報 • マスターテスト計画 – マスターテスト計画にテスト設計に関連する情報あり • プロジェクト計画 – プロジェクト計画に,テストの方針として必要な情報が書かれていることが多い • 上位の設計ドキュメントや要求 – 仕様の内容によっては,上位の情報が必要になる場合もある • 各クラス仕様の他に,全体クラス図が必要,等 • 用語集,規約等 – 当該プロジェクトで利用される用語や規約などはテストベースを読み解くために必要となる • 打ち合わせメモ,QAシート – 直接仕様書等に記載されないテストに関す情報が存在する場合がある • 先行・後行テストレベルでの情報 – 先行するテスト設計や実行結果の情報によって,テスト設計に影響がある場合がある – 後行するテストレベルで実行するテストが,納品のために確認テストとして必要な場合がある 2019/8/30 © Akira Ikeda 114
  115. 115. 余談:雇用形態によるテストベースの入手の難易度 • 社員 – 基本的には全ての情報にアクセス可能 • 派遣社員 – 派遣先の機微な情報については非開示の場合が多い • 請負社員 – 契約範囲の情報のみに限定される • 契約以上の情報入手や相手先へのアクセスは法律にふれる場合がある • 前もって,入手できるように手配しておこう – 請負契約の場合は特に重要になる • 事前に請負契約の開示情報に盛り込んでおく必要がある • このためには日頃から営業部門や調達部門等とのコミュニケーションが必要 2019/8/30 © Akira Ikeda 115
  116. 116. 第1部のまとめ 2019/8/30 © Akira Ikeda 116
  117. 117. 第1部のまとめ テスト設計技法を適用する前の準備として, テスト分析とテスト設計がある テスト分析設計のやり方のひとつにマインド マップを活用する方法がある テスト分析の前にもさらに必要な準備もある 2019/8/30 © Akira Ikeda 117
  118. 118. 第2部 Buildup ~ 意 識 を 高 め よ う , 鍛 錬 し よ う ~ テ ス ト 設 計 技 法 を 使 え る よ う に な る た め の ガ イ ド と な る 情 報 を お 話 し し ま す
  119. 119. 見つめ直そう テストの意義 も う 一 度 , 「 な ぜ 我 々 は テ ス ト し な け れ ば な ら な い の か 」 「 な ぜ テ ス ト 設 計 技 法 を う ま く 使 わ な け れ ば な ら な い の か 」 を 考 え て み よ う 2019/8/30 © Akira Ikeda 119
  120. 120. ソフトウェアテストってなんだろう? 2019/8/30 © Akira Ikeda 120 ソフトウェアテストっ てなんだろう? •ソフトウェアをテストする ことだと言うのは簡単だが •ソフトウェアを動かして みて,変な動きを確認す ること? •処理速度が速いかどうか 試すこと? etc… テストの経験は豊富な はず •今までの人生,散々テスト を受けてきたはず •学校の定期テスト,大学 受験,車やバイクの免許, 入社試験 •つまり,皆さんはテストの プロ でも,説明するのは案 外難しい •改めて考えてみると漠然と していませんか? •だから,テストを行うこと の意義も理解しにくいし, 定義も理解できない •意義とイメージがつかめれ ば,テストの重要性も理解 できる
  121. 121. ソフトウェアテストを行う意義 • バグ(不良)を発見することができる – テストをやらないと,多くのバグは発見できない – テストで発見したバグを開発者がデバッグすることで,品質が上がる • ソフトウェアを利用者が安心して利用することができる – 変な動きをしないからこそ毎日継続的に使い続けられる – テストは,実際に使う立場になって行うことが重要 • 自らお金を払って買ってもいいと思える製品を作るという意識 • テストは,お客様に安心感という価値を提供する 2019/8/30 © Akira Ikeda 121 ソフトウェアテストを行なう意義 「ソフトウェアテストを行うと,ソフトウェアが作られていく過程で入り込んでしまう“バグ” を発見することができ,そのバグを開発者が修正することによって,ソフトウェアをお客様が安 心して利用することができるようになる.」(Akira Ikeda, Mikio Suzuki, 2019)
  122. 122. バグが与える影響 とある場面 ~お客様の立場~ • ある日スマホを買ってきたら,次のような現象が出た – 電波の受信レベルは最高なのに,メッセージが送信できない – メニューやメッセージが文字化けする – アドレス帳に登録ができない,勝手にデータが消える – 目覚ましを設定しているのに,時間通りにアラームが鳴らない – 操作中に無反応になったり,勝手に電源が落ちる • どう思うでしょうか? – あきれる,イライラする,腹が立つ – 場合によってはクレーム電話 – 最悪,同じメーカのものは二度と買わないかもしれない – さらに,同じメーカの全然別の製品も買わないかもしれない 2019/8/30 © Akira Ikeda 122 ソフトウェアにバグが残っている(混入している)と, 不快な気分になり,安心感もなくなり,不信感を持つ
  123. 123. バグが与える影響 とある場面 ~メーカの立場~ • ゲームソフトの出荷後,フリーズなど致命的な問題が発見された – 回収・交換する場合,どういう対応が必要になるのか • ① ゲームソフトの回収 • ② バグの調査と分析 • ③ バグの修正 • ④ 修正されたバグについてのテスト • ⑤ 新しいバージョンの製品の生産 • ⑥ 新しいバージョンのお客様への送付 • 以下の例で考えてみる – 出荷本数:10万本,回収費用:1本700円 – ②~④にかかる人数:15人(時給2000円) – ②~④にかかる時間:1ヵ月(8h×30d=240h) – 生産費用:1本500円,送付費用:1本700円 2019/8/30 © Akira Ikeda 123
  124. 124. バグが与える影響 とある場面 ~メーカの立場~ – ① ゲームソフトの回収 • 10万本 × 送料700円 = 7,000万円 – ② バグの調査と分析~ ④ 修正されたバグについてのテスト • 15人 × 時給2,000円 × 240時間 = 720万円 – ⑤ 新しいバージョンの製品の生産 • 10万本 × 一本あたり500円 = 5,000万円 – ⑥ 新しいバージョンのお客様への送付 • 10万本 × 送料700円 = 7,000万円 – ①~⑥までの合計 • 7,000万円 + 720万円 + 5,000万円 + 7,000万円 = 約2億円! • このほか,損害賠償や,新聞/TV広告,電話窓口の設置などのコスト • コスト以外にも,不買運動や風評被害,最近なら批判Blogなどブランドに影響 2019/8/30 © Akira Ikeda 124 たった一つのバグが数億円の損害を与えるほか ブランドに大きな影響を与えることもある!
  125. 125. (参考)「史上最悪のソフトウェアバグ」ワースト10 •マリナー1号は打ち上げ時に予定のコースを外れたが,これは飛行ソフトウェアのバグが原因だった。地上の管制センターは大 西洋上でロケットを破壊した。事後調査により,鉛筆で紙に書かれた数式をコンピューターのコードに置き換えるときにミスが 起き,これが原因でコンピューターが飛行コースの計算を誤ったことが判明した。 1962年7月22日――火星探査機『マリナー1号』: •シベリアを横断するガス・パイプラインの管理に旧ソ連が購入したカナダ製のコンピューターシステムに,米中央情報局(CIA)の スパイがバグを仕掛けたことがあるという。旧ソ連は当時,米国の機密技術を密かに購入しようと――または盗み出そうと――し ており,このシステムを入手したのもその一環だった。だが,計画を察知したCIAはこれを逆手にとり,旧ソ連の検査は問題な く通過するが,いったん運転に入ると機能しなくなるように仕組んだとされる。この結果起きたパイプライン事故は,核爆発以 外では地球の歴史でも最大規模の爆発だったという。 1982年――旧ソ連のガス・パイプライン: •複数の医療施設で放射線治療装置が誤作動し,過大な放射線を浴びた患者に死傷者が出た。セラック25は2種類の放射線――低エ ネルギーの電子ビーム(ベータ粒子)とX線――を照射できるよう,既存の設計に「改良」を加えた治療装置だった。セラック25で は電子銃と患者の間に置かれた金属製のターゲットに高エネルギーの電子を打ち込み,X線を発生させていた。セラック25のも う1つの「改良」点は,旧モデル『セラック20』の電気機械式の安全保護装置をソフトウェア制御に置き換えたことだった。ソ フトウェアの方が信頼性が高いとの考えに基づく判断だった。 •しかし,技術者たちも知らなかった事実があった――セラック20およびセラック25に使われたOSは,正式な訓練も受けていない プログラマーが1人で作成したもので,バグが非常にわかりにくい構成になっていたのだ。「競合状態」と呼ばれる判明しにく いバグが原因で,操作コマンドを素早く打ち込んだ場合,セラック25ではX線用の金属製ターゲットをきちんと配置しないまま 高エネルギーの放射線を照射する設定が可能になっていた。これにより少なくとも5人が死亡し,他にも重傷者が出た。 1985〜1987年――セラック25: 2019/8/30 © Akira Ikeda 125 WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用
  126. 126. (参考)「史上最悪のソフトウェアバグ」ワースト10 •最初のインターネットワームとなった通称『モーリス・ワーム』は,バッファー・オーバーフローを悪用し,1日足らずで2000台から6000台のコンピューターに感染した。 原因となったのは,標準入出力ライブラリー・ルーチン内の「gets()」という関数のコードだ。「gets()」関数はネットワーク越しにテキストを1行取得するように設計され た。しかし,残念ながら「gets()」関数は入力を制限するようには作られていない。そのため,あまりにも大きな入力があった場合には,接続可能なあらゆるマシンをワー ムが占拠する元凶になった。 •プログラマーは「gets()」関数を使用コードから排除することで問題に対処しているが,C言語の標準入出力ライブラリーからこれを削除することは拒否しており,この関 数は現在も存在している。 1988年――バークレー版UNIX(BSD)のフィンガーデーモンによるバッファー・オーバーフロー •ケルベロスは暗号を使ったセキュリティーシステムだが,乱数発生器に与えるシード(種)が適切でなく,真にランダムな乱数が生成されていなかった。その結果,ケルベロ スによる認証を用いているコンピューターについて,非常に簡単な方法で侵入可能な状態が8年間にわたって続いた。このバグが実際に悪用されたかどうかは,今も定かで はない。 1988〜1996年――『ケルベロス』の乱数生成アルゴリズム •米AT&T社の長距離電話用交換機『4ESS』を制御する最新版のソフトウェアにバグが入りこんだ。このため,4ESSは隣接するマシンの1つから,ある特定のメッセージを受 け取るとクラッシュするようになってしまった――そしてそのメッセージとは,クラッシュした交換機が復帰した際に,隣接する交換機に送信するものだった。 •ある日,ニューヨークの交換機がクラッシュし再起動した。するとそれが原因で隣接する複数の交換機がクラッシュし,これらの交換機が再起動すると隣接する複数の交 換機がさらにクラッシュし,この現象が延々と続いた。しばらくすると,114台の交換機が6秒ごとにクラッシュと再起動を繰り返すようになった。この影響でおよそ6万 人の人々が9時間にわたって長距離通話サービスを利用できなくなった。修復のため,技術者たちは1つ前のソフトウェアをロードした。 1990年1月15日―― 米AT&T社のネットワーク停止 •米インテル社が大々的に売り出したPentiumチップが,特定の浮動小数点数の除算で誤りを引き起こした。たとえば,4195835.0/3145727.0を計算させると,正しい答え の1.33382ではなく1.33374となる。0.006%の違いだ。 •実際にこの問題の影響を受けるユーザーはごくわずかだったが,ユーザーへの対応から,同社にとって悪夢のような事態につながった。概算で300万〜500万個の欠陥チッ プが流通していた状況で,インテル社は当初,高精度のチップが必要だと証明できる顧客のみをPentiumチップの交換対象とした。しかし,最終的にインテル社は態度を改 め,不満を訴えるすべてのユーザーのチップ交換に応じた。この欠陥は結局,インテル社に約4億7500万ドルの損害を与えた。 1993年――インテル社製『Pentium』(ペンティアム)による浮動小数点数の除算ミス 2019/8/30 © Akira Ikeda 126WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用
  127. 127. (参考)「史上最悪のソフトウェアバグ」ワースト10 •[ピング・オブ・デス,不正なピングパケットによる攻撃]分割送信されたIPパケットの再構成を行なうコードのチェックとエラー処理が不十分だったため, インターネット上の好きな場所から不正な形式のピングパケットを飛ばすことで,さまざまなオペレーティング・システム(OS)をクラッシュさせることが できた。影響が最も顕著に現れたのはウィンドウズ搭載マシンで,この種のパケットを受け取ると,「死のブルー・スクリーン」と呼ばれる青い画面を表 示して動作が停止してしまう。しかしこのバグを利用した攻撃は,ウィンドウズのみならず,マッキントッシュやUNIXを使ったシステムにも多くの被害を もたらした。 1995年/1996年――『Ping of Death』 •欧州宇宙機関の開発したロケット,アリアン5には,『アリアン4』で使われていたコードが再利用されていた。しかし,アリアン5ではより強力なロケッ トエンジンを採用したことが引き金となり,ロケットに搭載された飛行コンピューター内の計算ルーチンにあったバグが問題を起こした。エラーは64 ビットの浮動小数点数を16ビットの符号付き整数に変換するコードの中で起こった。アリアン5では加速度が大きいため,64ビット浮動小数点で表現され る数がアリアン4のときよりも大きくなってオーバーフローが起こり,最終的には飛行コンピューターがクラッシュしてしまった。 •フライト501では,最初にバックアップ・コンピューターがクラッシュし,それから0.05秒後にメイン・コンピューターがクラッシュした。その結果,エ ンジンの出力が過剰になり,ロケットは打ち上げ40秒後に空中分解してしまった。 1996年6月4日――『アリアン5』フライト501 •米マルチデータ・システムズ・インターナショナル社(本社ミズーリ州)が製作した治療計画作成用ソフトウェアを使っていたパナマの国立ガン研究所で, 放射線治療で照射する放射線量の計算を誤る一連の事故が起きた。 •マルチデータ社のソフトウェアでは,健康な組織を放射線から守るための「ブロック」と呼ばれる金属製のシールドの配置を,コンピューターの画面上 に描いて決めるようになっていた。しかし,同社のソフトウェアではシールドが4個しか使えなかったにもかかわらず,パナマ人の技師たちはこれを5個 使いたいと考えた。 •技師たちは,真ん中に穴を持つ1個の大きなシールドとして,5個のシールドをまとめて表示させれば,ソフトウェアをだますことができることを発見し た。だが,そうした配置にした場合,穴の描き方によってこのソフトウェアが返す計算結果が違ってくることにはまったく気づいていなかった。ある方向 に向けて描くと正しい照射量が計算されるが,違う方向に描くと必要な照射量の最大2倍の量を推奨してきたのだ。 •少なくとも8人の患者が死亡し,さらに20人が過剰照射によって深刻な健康被害を受けたとみられている。技師たちは,コンピュータによる計算結果を手 作業で再チェックする法的義務を負っていたため,殺人罪で起訴されることになった。 2000年11月――パナマ国立ガン研究所 2019/8/30 © Akira Ikeda 127 WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用
  128. 128. ソフトウェアテストを行う意義 • ソフトウェア製品に – バグが残っている(混入している)と,不快な気分になり,安心感もなくなり,不信感を持つ – 混入したたった一つのバグが数億円の損害を与えるほか,ブランドに大きな影響を与えることも ある 2019/8/30 © Akira Ikeda 128 ソフトウェアテストを行なう意義 「ソフトウェアテストを行うと,ソフトウェアが作られていく過程で入り込んでしまう“バグ” を発見することができ,そのバグを開発者が修正することによって,ソフトウェアをお客様が安 心して利用することができるようになる.」(Akira Ikeda, Mikio Suzuki, 2019) はて? なんだか意義が足りないような・・・?
  129. 129. ソフトウェアテストを行う意義 • たった一個のバグが,お客様に不利益を与えるどころか,企業の業績を左右することもある • 場合によっては企業の倒産により職を失ったり,企業や社会に損害を与えたことで,個人に損 害賠償責任が発生することも 2019/8/30 © Akira Ikeda 129 ソフトウェアテストにしっかりと取り組むということは, バグというモンスターから 実際のお客様のみならず,企業や社会, そして自分や家族を守ることでもある ソフトウェアテストを行なう意義 「 ソフトウェアテストを行うと,ソフトウェアが作られていく過程で入り込んでしまう “バグ”を発見することができ,そのバグを開発者が修正することによって,ソフト ウェアをお客様が安心して利用することができるようになる。 また,リリース・出荷後にバグが出ないことで,ソフトウェアの回収や修正などに必 要なコストを抑制し,企業のイメージ低下,ひいては倒産を防ぐことができる。」 (Akira Ikeda, Mikio Suzuki, 2019) テストはお客様,企業双方にメリットがある! このための武器の1つとして,テスト設計技法やテスト分析設計技法があるということ
  130. 130. テスト設計技 法をもう一度 学ぼう 知 識 が 古 く な っ て い た り , 誤 っ た 理 解 だ っ た り す る か も し れ ま せ ん 知 識 を 更 新 し ま し ょ う 2019/8/30 © Akira Ikeda 130
  131. 131. SQuBOKガイド V2に見るテストの設計技法 3.9 テストの技法 3.9.1 経験及び直感に基づいた技法 3.9.2 仕様に基づいた技法 3.9.3 コードに基づいた技法 3.9.4 フォールトに基づいた技法 3.9.5 利用に基づいた技法 3.9.6 ソフトウェアの形態に基づいた技法 3.9.7 組み合わせの技法 3.9.8 リスクに基づいた技法 3.9.19 テスト技法の選択と組み合わせ 3.9.10 テスト自動化技法 2019/8/30 © Akira Ikeda 131 テスト技法はホワイトボックスと ブラックボックスだけではない!
  132. 132. SQuBOKガイド V2に見るテスト設計技法 •アドホックテスト,探索的テスト 経験に基づいた技法 •ブラックボックステスト,同値分割,境界値分析/境界値テスト,デシジョンテーブルによるテスト,原因結果グラフ によるテスト,状態遷移テスト,ランダムテスト,モデルベース土テスト,要因分析技法【富士通】,CFD技法 仕様に基づいた技法 •ホワイトボックステスト,制御フローテスト,データフローテスト,データフローテスト,トランザクションフロー テスト コードに基づいた技法 •エラー推測テスト,ミューテーションテスト フォールトに基づいた技法 •運用プロファイルによるテスト,ローカライゼーションテスト,ユーザ環境シミュレーションテスト,整合性確認テ スト 利用に基づいた技法 2019/8/30 © Akira Ikeda 132
  133. 133. SQuBOKガイド V2に見るテスト設計技法 •オブジェクト指向テスト,Webシステムのテスト,GUIテスト,サーバサイドのテスト,データベース テスト,並行プログラムのテスト,プロトコル適格性テスト,実時間のテスト,モバイルアプリケー ションのテスト ソフトウェアの形態に基づいた技法 •直交配列表(実験計画法)を用いたテスト,All-pair法を用いたテスト 組み合わせの技法 •テストマネジメントにおけるリスクベースドテスト,テスト設計におけるリスクベースドテスト リスクに基づいた技法 •機能的なテスト設計と非確定的なテスト設計の組み合わせ テスト技法の選択と組み合わせ •- テスト自動化技法 2019/8/30 © Akira Ikeda 133
  134. 134. テストの体系によってはレビュー技術は静的テスト •ピアレビュー,インスペクション,チームレビュー,ペアプログラミング,ピ アデスクチェック,パスアラウンド,ラウンドロビンレビュー,ウォークス ルー,アドホックレビュー レビュー方法 •形式手法に基づくレビュー,インタフェース分析,複雑度分析,パストレース, ラン・スルー,制御フロー分析,アルゴリズム分析,モジュール展開,七つの 設計原理(富士通),静的解析 仕様・コードに基づいた技法 •ソフトウェアFMEA,FMECA,FTA(フォールトの木解析),EMEA(エラーモー ド故障解析),CFIA(IBM),PQデザインレビュー(日立) フォールトに基づいた技法 2019/8/30 © Akira Ikeda 134
  135. 135. テスト設計技法は組み合わせる 2019/8/30 © Akira Ikeda 135 JaSST’12 Tokyo での「みんなで作 ろうテスト技法ポジショニング マップ」 http://jasst.jp/symposium/jasst12to kyo/pdf/S10.pdf 技法にはカバー できる範囲があ る。 組み合わせて, 網羅性を上げる
  136. 136. テスト設計技法を学ぶための書籍 はじめて学ぶソフトウェアテスト技法 •Lee Copeland 著/宗 雅彦 訳/日経BP社/2005年 •テスト技法と言えば,境界値テストしか思いつかない人が残念ながらいます。テストにはさまざまな 技法が存在します。この本は多くの技法を取り上げ,演習問題を通して学ぶことができます。 ソフトウェアテスト実践ワークブック •Rex Black 著/成田光彰 訳/日経BP社/2005年 •この本もテスト技法を演習を通して学ぶことができます。特長は,仮想のプロジェクト事例を使って, さまざまなテスト技法を紹介していることです。テスト技法を実際のプロジェクトに適用するヒント が得られます。 ソフトウェアテスト技法ドリル テスト設計の考え方と実際 •秋山浩一 著/日科技連出版社/2010年 •ソフトウェアテストを点・線・面・立体でとらえ,例題を交えながら丁寧に解説しています。テスト 設計技法をガッチリと学びたいときに最適です。 2019/8/30 © Akira Ikeda 136 「[改訂新版]マインドマップ]から始めるソフトウェアテスト」から引用
  137. 137. テストプロセス 改善モデルや資 格を利用しよう 実 務 で 活 用 で き る よ う に 技 術 力 を 向 上 す る に あ た っ て は , ガ イ ド を 利 用 す る の も よ い で し ょ う 2019/8/30 © Akira Ikeda 137

×