幅広なテスト分析ができるようになろう

幅広なテスト分析ができ
るようになろう

自己紹介
山口寛子（WACATE実行委員会）3年目？
（もう覚えていない）
金融系SIerで金融系ではないSIをやっている
SN：べにちどり（@scarletplover）

いきなりワーク
WEBシステムで以下のようなおみくじシステムがあります。
システムテストとして、自分ならどんなテストをするか、考えてみて下さい。
・占い画面に生年月日と性別を入力し、
「占う」ボタンを押下
・結果画面に遷移し、独自の占いロジックを用いた以下の判定結果を画面に表示させる。
大吉・吉・中吉・小吉・凶
・サーバのデータベースに占ったときの入力情報・占い結果等のデータが収集される。
・入力情報・占い結果等のデータは顧客の所有する訪問者分析システムへ日次で連携される。

いきなりワーク
制限時間は５分！！！！

あくる日のAさんの解答
１．入力チェック（必須チェック・属性チェック・桁数チェック）
①生年月日
②性別
２．独自の占いロジックのテスト
３．占い結果画面への遷移テスト
４．サーバのデータベースに占いの結果が登録されていること。
５．訪問者分析システムへのデータ連携ができること。

⇒ ⇒ ⇒あくる日のAさんの現場
顧客からのクレーム・・・
１．ブラウザの戻るボタンを押下したら落ちた。
２．大量のユーザに同時接続されると落ちた。
３．占い結果データベースに登録されている内容にアクセス日時がな
く、詳細なユーザ分析ができない。

Aさんみたいにならないために・・・

このセッションの目的
初心者
テスト分析を知ってもらう！
中堅
機能ベースのテスト分析から脱却！
ベテラン
他の人のテスト分析結果を覗いてみる！
みんなで幅広なテスト分析ができるようになろう

目次
はじめに（済）
テスト分析とは
テスト分析をやってみよう
テスト対象分析
テスト要求分析
最後に
※実際とは若干ちがう可能性がございます。

テスト分析とは
•「テストベースとテスト目的の定義を分析するプロセス。」
JSTQB用語集より
•何をテストするか決定するため、すなわち、テスト条件を決めるために、テストのベースとなるドキュメント
を分析する。テスト条件は、一つ、あるいは、複数のテストケースで検証できる項目やイベントとして定義す
る。(例えば、機能、トランザクション、品質特性、構造的要素など) テストベースを分析する。
ISTQB Foundation Level シラバス日本語版
•テスト対象を理解してテストすべきこと（JSTQB 用語集では、これをテスト条件と呼びます）を明確にしてい
きます。
テストツールまるわかりガイド（入門編）

ようするに
「テストをするために、
何をテストするかを決めること」

テスト
計画
テスト
分析
テスト
設計
テスト
実装
テスト
実行
レポート
・評価
終了
作業
ココ

「テストをするために、何をテストするかを決めること」
⇒テスト設計の前にテスト分析をすると。。
①テストのぬけもれ防止
「戻る」ボタンetc・・・
②テストのやりすぎ防止
執拗な実施内容チェック・・・
③テスト対象とテスト要求の紐付け
なんのために実行しているテストかを把握

あくる日のAさんの現場
１．ブラウザの戻るボタンを押下したら落ちた。
２．大量のユーザに同時接続されると落ちた。
→→→WEBシステム特有
３．占い結果データベースに登録されている内容にアクセス日時がな
く、詳細なユーザ分析ができない。
→→→ （潜在的な）ユーザの要件

とっても大事なプロセスなんです！！！

ここでは以下の２つのプロセスで完成させます
①テストの対象を分析する「テスト対象分析」
②テストの要求を分析する「テスト要求分析」

テスト分析をやっ・・

テスト分析をやっ・・
マインドマップとは？

※ご連絡事項
ここから先のワークでは、テスト分析を、マインドマップ
で行っていきます。
そのため、テスト分析の詳細なご案内の前に、マインド
マップについてご説明します。

マインドマップとは
・脳の処理システム「放射思考」を図で表したもの（参考図書著者いわく）
参考文献：ザ・マインドマップ

・紙１枚で表現可能
・見やすい
・アイデアを思いつきやすい

マインドマップの書き方
以下をマインドマップにします！(P72)

①紙の中心に、マインドマップのテーマ＝セントラルイメージを書きます。

②メイン・ブランチをセントラルイメージから伸ばし、基本アイデアをキー
ワードでかく。

③メインブランチからサブ・ブランチを伸ばし、更に連想できるキーワード
を記入

④さらに、サブ・ブランチを伸ばして、キーワードを記述

⑤他のメインブランチも同様にブランチを伸ばしていく。

マインドマップの例
①Xmindツール

②手書き１

③手書き２

ワーク①マインドマップ
自分のポジションペーパの内容で一番いいたいことを選ん
で、マインドマップにしてみましょう！
時間は5分！！！

テスト分析をやってみよう
①テスト対象分析

テスト対象分析とは
「何をテストするか」を決める前に、テストを行う対象に
ついて、要件や仕様を把握する。

テスト対象分析の準備
テスト対象分析をやる前の確認事項（ ISTQB Advanced Level シラバス日本語版引用）
①テスト対象が記述されたドキュメントが存在するかいなか
例）要件定義書・設計書etc
②このドキュメントは、レビューに適切な評価で合格しており、レビュー後に必要に応じ
て更新されている。
上記に当てはまらない場合には関係者にテスト対象について話を聞くなどの対策が必要！

テスト対象分析のやり方
①３色ボールペン
仕様書に色ボールペンで印を付けていって、テスト対象の特徴をつかむ。
②インプット資料の目次を使う
仕様書・要件定義書からマインドマップ等を使って転記・整理しながら対象をつかむ。
③６W2H
Who（誰）・What（仕様）・Where（何処）
When（何時）・Why（要求）・Whom（C of C)
How to（設計）・How much（価格・価値）でテスト対象を分析

・占い画面に生年月日と性別を入力し、
「占う」ボタンを押下
・結果画面に遷移し、独自の占いロジックを用いた以下の判定結果を画面に表示させる。
大吉・吉・中吉・小吉・凶
・サーバのデータベースに占ったときの入力情報・占い結果等のデータが収集される。
・入力情報・占い結果等のデータは顧客の所有する訪問者分析システムへ日次で連携される。
なんのため？
赤い線で「最重要な箇所」
青い線で「重要な箇所」
緑の線で「疑問点・おかしいと
ころ」
参考文献：マインドマップから始めるソフトウェアテスト
①三色ボールペン
仕様書に色ボールペンで印を付けていって、テスト対象の特徴をつかむ。

②インプット資料の目次を使う
仕様書・要件定義書からマインドマップ等を使って転記・整理しながら対象を
つかむ。
１．システム概要
２．システム導入経緯
３．機能要件
４．非機能要件
５．データ要件
・・・
参考文献：マインドマップから始めるソフトウェアテスト

③６W2H
6W2H
Why（要求）
Whom（C of C)
How much（価格）
What（仕様）
How to（設計）
When（何時）
Where（何処）
Who（誰）
開発
顧客
参考文献：事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント

③６W2H
仕様
設計
何故
何時
何処
誰

③６W2H
Why
【何故】
Whom
【C of C)】
How much
【価格・価値】

③６W2H

③６W2H
仕様
設計
何故
何時
何処
誰
C of C価格・価値

③６W２H
行うときの注意
・まずWHATから書いてみる！
・原則キーワード
・最初は漏れを気にせず書いてみる
→書き終わったところで確認
・ダブりを気にしなくていい。

ワーク②テスト対象分析(1)
手元の仕様書をもとに、テスト対象を6W2Hで分析してみま
しょう。
時間は２０分！！

ワーク②テスト対象分析(2)
隣の人と共有してみましょう。
時間は５分！！

テスト分析をやってみよう
②テスト要求分析

テスト要求分析とは
（テスト対象分析結果等をもとに）
テスト要求をみつけ、テストすべき事柄まで落とし
込むこと

テスト対象分析だけ
⇒これでもテストできるけど・・・。

テスト要求分析のいいところ
・経験ベースのテスト
・非機能要件
etc・・・

テスト要求分析のやり方
①FV表
テスト対象分析の内容から、テストすべきことをユーザストーリを軸に表
にまとめる。
②品質特性から展開
ISO25010の品質特性をマインドマップのメイン・ブランチとして、テス
トすべきことを洗い出していく。
③Ostrandの4つのビュー
ユーザビュー、仕様ビュー、バグビュー、設計ビューの４つの観点から
テストすべきことをを洗い出していく。

①FV表 Function Verification Table
HAYST法で使用。
No 目的機能（Fr）検証内容（V) テスト技法
1 占う・独自占いロジックが
正常に動作すること
・入力された内容が正
しい内容でなかった
場合にはエラーとな
ること
境界値分析テスト

②品質特性から展開
非機能要件のテスト要求・テスト条件を抽出する際に便利。
ISO25010:システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル

ユーザビュー
（User-View）
• ユーザが何をするのか
• ユースケースetc
仕様ビュー
（Spec-View）
• 仕様の面から考える
• 境界値分析etc
バグビュー
（Fault-View）
• 起こしたい(見つけたい
)バクは何か
• 異常系etc
設計ビュー
（Design-View）
• 設計やコードから考え
る
• 状態遷移・タイミン
グetc
参考文献：http://jasst.jp/archives/jasst08t/pdf/2.pdf

ワーク②テスト要求分析(1)
手元の仕様書をもとに、Ostrandの４つのビューで
システムテストのテスト要求分析してみましょう。
時間は１５分！！

ワーク②テスト要求分析(2)
隣の人と共有してみましょう。
時間は５分！！

テスト要求分析のポイント
ユーザビュー
仕様ビュー
設計ビュー
バグビュー
ブラックボッ
クステスト
ホワイトボッ
クステスト
バランスよく
テストすると
よい

他にもありますテスト分析
①ゆもつよメソッド
機能一覧テストタイプテスト
カテゴリ
テストすべき事項
占い機能機能テスト入力チェック生年月日
表示画面レイアウト
ボタン操作ボタン
独自占いロジック
占いデータ結果登録
参考文献：http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf

他にもありますテスト分析
②VSTeP（ Viewpoint-based Software Test Process）
おみくじシス
テム
動作環境
WEB
機能
占い機能
データ収集機
能
データ連携機
能
データ要件
参考文献：http://qualab.jp/materials/VSTeP.130510.bw.pdf

最後に
テスト分析はまだまだいろんなアプローチ、方法論
etcがあります。
⇒テスト分析をもっともっと活用しましょう！！

困ったときの参考文献①
池田暁著,鈴木三紀夫著
「マインドマップから始めるソフトウェアテスト」
技術評論社 2007年
秋山浩一著
「事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント」
日科技連出版社 2014年
トニー・ブサン著,バリー・ブサン著,近田美季子訳
「新板ザ・マインドマップ」
ダイヤモンド社 2013年

困ったときの参考文献②
International Software Testing Qualifications Board著
Japan Software Testing Qualifications Board訳
「JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集」
（2011年）
「ISTQB Foundation Level シラバス日本語版」
（2012年）
「 ISTQB Advanced Level シラバス日本語版」
（2012年）

困ったときの参考文献③
「テストツールまるわかりガイド(入門編)」
http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0
.pdf
「ISO25010:システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−シ
ステム及びソフトウェア品質モデル」
「ソフトウェア品質保証技術の動向」
http://jasst.jp/archives/jasst08t/pdf/2.pdf
「テストアーキテクチャの具体例（ゆもつよメソッドの場合）」
http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf
「テスト観点に基づくテスト開発方法論 VSTePの概要」
http://qualab.jp/materials/VSTeP.130510.bw.pdf

ご清聴ありがとうございました。

幅広なテスト分析ができるようになろう

More Related Content

What's hot

Viewers also liked

Similar to 幅広なテスト分析ができるようになろう

幅広なテスト分析ができるようになろう