SlideShare a Scribd company logo
1 of 11
Download to read offline
テスト分析とテスト設計勉強会@日本大学駿河台キャンパス
2017年2月3日(金)
SS開発本部/秋山浩一
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
JSTQBのテストプロセスについて
(第1部: 基本の再確認と読み解き)
「テスト分析」と「テスト設計」を中心に、構造化分析・設計の話も少々
・(私のパートは)ツイートOKです
ハッシュタグ: #test
ご質問がありましたら挙手あるいは
Twitterで@akiyama924へ遠慮なく
メイン
時間: 9:00~11:00(急いで退出しなくてもOK。JaSST実行委員を除く)
飲食: 基本的に不可(汚さないように、ごみは持ち帰るように。お願い!)
主催: NPO法人 ASTER 教育事業(ソフトウェアテスト技術振興協会)
録音・録画・写真: 不可(しないと思う)
キーボード等のタイプ音: 大きく、迷惑にならないように気をつけて。お願い!
携帯・スマホ: マナーモード
発表者: ボランティア。おしみない拍手をいただけると喜びます!!
本日の勉強会の進め方
https://connpass.com/event/47938
© 2017 Fuji Xerox Co., Ltd. All rights reserved. 1
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
(第1部) 9:00-9:40 秋山(Twitter ID: @akiyama924)
l JSTQBのテストプロセス(主に分析・設計)について
p 基本となる知識を理解しよう
p 質疑および休憩
(第2部-1) 9:45-10:00 リリカル (TW: @mhlyc)のLT
l テスト分析・設計について、釈然としないところ
p 分析と設計って行ったりきたりするものなのでは?
p だったらまとめて一つのプロセスでもいいのかな?
(第2部-2) 10:00-10:30 湯本 剛(TW: @yumotsuyo)さんのLT
l ゆもつよメソッドにおけるテスト分析とテスト設計
p 日本で一番実践的なテスト分析・テスト設計手法を学ぼう
p 意見交換(リリカル×湯本剛)
(第2部-3) 10:30-10:45 河野 哲也(facebook: Tetsuya Kouno)のLT
l テスコン優勝事例におけるテスト分析・設計の解説
p テスコンで優勝したテスト分析とテスト設計事例から学ぼう
(第2部-4) 10:45-10:55 まりまり(TW: @YamadaQuality)のLT
l 大学祭の模擬店でデザインの力を感じた話
p 分析や設計ってなんの役に立つの?
p 実践してみました! ! ! ! !
本日の流れ
2
① JSTQBのテストプロセスの概要
② JSTQBのテスト分析、テスト設計
③ 構造化分析と構造化設計
JSTQBのテストプロセスについて
© 2017 Fuji Xerox Co., Ltd. All rights reserved. 3
① JSTQBのテストプロセスの概要
n プロセスってなに? JSTQBのテストプロセス
n テストレベルやテストフェーズとの関係
© 2017 Fuji Xerox Co., Ltd. All rights reserved. 4
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
プロセスとは
l プロセス(process): 相互関係のある活動のセット。入力を出力に変換する。
[ISO/IEC 12207] (JSTQB用語集)
p [活動①] – [活動②] – [活動3] – [活動④] – [活動⑤] – [活動⑥] – [活動⑦](相互関係有)
p ≪入力≫→[活動(アクティビティ:Activity)]→≪出力≫
Ø入力を出力に変換する活動
p ≪入力≫したものの価値を[活動]で高めて≪出力≫する(私見:読み解き)
l JSTQBのテストプロセス(test process): 基本的なテストプロセスは、テスト
の計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価
と報告、テスト終了作業によって構成される。(JSTQB用語集)
p 論理的には、上記活動は順列に行われるが、実際には、重複したり並列に行われたりする場
合がある。(FL)
p 通常、システムやプロジェクトの状況に合わせてこれらの活動を調整する必要がある。
(FL)
p Shallではなく、ある程度の自由が許され、テーラリングが求められる(私見)
p [①{テストの計画}と{コントロール}] – [②{テストの分析}と{テストの設計}] – [③
{テストの実装}と{テストの実行}] – [④{終了基準の評価}と{報告}] – [⑤{テスト終
了作業}] (FL)
プロセスってなに?
JSTQBのテストプロセス
「しなければならない」(MUST)、「してはならない」(MUST NOT)、「必須である」(REQUIRED)、「するものとする」(SHALL)、
「しないものとする」(SHALL NOT)、「すべきである」(SHOULD)、「すべきではない」(SHOULD NOT)、「推奨される」
(RECOMMENDED)、「してもよい」(MAY)、および「任意である」(OPTIONAL) (RFC2119)
5
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
プロセスとテスト活動(ALTA:抜粋)
lテスト活動は、ソフトウェア開発と整合している必要がある。たとえば、シーケン
シャルなV字モデルの場合でシステムテストレベルに適用すると、次の内容。
pプロジェクト計画と同時にシステムテスト計画を始め、システムテストの実行と終了作業が完
了するまでテストコントロールを継続する。
pシステムテスト分析および設計は、要求仕様から、システムおよびアーキテクチャ設計仕様を
経て、コンポーネント設計仕様までのプロセスと並行して行う。
pシステムテスト環境の実装は、システム設計時に開始する場合があるが、これらの活動の大部
分は通常、コーディングおよびコンポーネントテストと同時に実行する。
pシステムテストの実行は、システムテスト開始基準にすべて合致したときに始まる。……略
……システムテストの実行は、システムテスト終了基準に合致するまで継続する。
pシステムテスト終了基準の評価およびシステムテスト結果のレポートは、システムテスト実行
を通じて行う。
pシステムテスト終了作業は、システムテスト終了基準に合致しシステムテスト実行の終了を宣
言してから始まる。
テストレベルやテストフェーズとの関係
= ジェネリックプロセスモデル(包括的・汎用プロセスモデル:ISO 29119同様)
開発 プロジェク
ト計画
要求仕様
アーキテク
チャ設計
コンポーネ
ント設計
コーディン
グとCT
システム
テスト
テスト計画
とコント
ロール
テスト分析 (続き) テスト設計
テスト環境
の実装
テスト実行
終了基準の
評価
終了作業
6
② JSTQBのテスト分析、テスト設計
n テスト分析、テスト設計
© 2017 Fuji Xerox Co., Ltd. All rights reserved. 7
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
テスト分析とテスト設計(ALTA)
lテスト分析:テストベースを分析する。テスト条件を識別する。
p≪入力≫: テストベース
Øこのドキュメントは、レビューに適切な評価で合格している
p[活動]: テストベースとテスト目的を分析を分析する
Øテストベースとして機能するテスト対象が記述されたドキュメントが存在する
p≪出力≫: 識別されたテスト条件
Ø一般的には、テスト条件をさまざまな詳細度合いで定義することが望ましい
lテスト設計:
p≪入力≫: テスト条件
p[活動]: 1. 必要なテストカバレッジを確保するテストケース設計技法を決定し適用する
2. 識別したテスト条件を遂行するテストケースを作成する
p≪出力≫: テストケース
テスト分析とテスト設計
8
③ 構造化分析と構造化設計
n 構造化分析
n 構造化設計
© 2017 Fuji Xerox Co., Ltd. All rights reserved. 9
© 2017 Fuji Xerox Co., Ltd. All rights reserved.
構造化分析と構造化設計
(『構造化分析とシステム仕様』 トム・デマルコ著)
l分析: 分析とは行動をとる前に実施する問題の調査である。
p分析の最も重要な生産物は仕様書である
Ø仕様書には機能仕様書、外部仕様書、設計仕様書、論理メモ、要求仕様書などがある
p後に続く行動とは、そのシステムを構築することである
l設計:設計は手続き的な部分と階層的な部分を決めて構築すること
p手続き的な部分:順序
p階層的な部分: トップダウンに分割、データ結合度、モジュール凝集度
構造化分析と構造化設計
10

More Related Content

Viewers also liked

なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudyなんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
POStudy
 
20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演
Kouichi Akiyama
 
#STAC2014 システムテスト自動化ハンズオン
#STAC2014 システムテスト自動化ハンズオン#STAC2014 システムテスト自動化ハンズオン
#STAC2014 システムテスト自動化ハンズオン
kyon mm
 

Viewers also liked (20)

マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計
 
TPI NEXT ざっくり概要
TPI NEXT ざっくり概要TPI NEXT ざっくり概要
TPI NEXT ざっくり概要
 
事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
 
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudyなんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
 
Goとtest coverage
Goとtest coverageGoとtest coverage
Goとtest coverage
 
20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演
 
20160607 SS2016 FP
20160607 SS2016 FP20160607 SS2016 FP
20160607 SS2016 FP
 
N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策
 
20160619 wacate
20160619 wacate20160619 wacate
20160619 wacate
 
JaSSTよいテストプロセスの作り方
JaSSTよいテストプロセスの作り方JaSSTよいテストプロセスの作り方
JaSSTよいテストプロセスの作り方
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
 
Toteka 04
Toteka 04Toteka 04
Toteka 04
 
#STAC2014 システムテスト自動化ハンズオン
#STAC2014 システムテスト自動化ハンズオン#STAC2014 システムテスト自動化ハンズオン
#STAC2014 システムテスト自動化ハンズオン
 
ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014
 
Stac2013 開会挨拶
Stac2013 開会挨拶Stac2013 開会挨拶
Stac2013 開会挨拶
 
テストプロセス改善技術の概要
テストプロセス改善技術の概要テストプロセス改善技術の概要
テストプロセス改善技術の概要
 
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
 
20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
 
スマートフォンアプリの テスト自動化をはじめよう
スマートフォンアプリの テスト自動化をはじめようスマートフォンアプリの テスト自動化をはじめよう
スマートフォンアプリの テスト自動化をはじめよう
 
テスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからテスト自動化のこれまでとこれから
テスト自動化のこれまでとこれから
 

More from Kouichi Akiyama (11)

業務状態遷移テストを語る夕べ
業務状態遷移テストを語る夕べ業務状態遷移テストを語る夕べ
業務状態遷移テストを語る夕べ
 
Ralph's Chart連結
Ralph's Chart連結Ralph's Chart連結
Ralph's Chart連結
 
20180421 Issueの書き方と伝えかた勉強会
20180421 Issueの書き方と伝えかた勉強会20180421 Issueの書き方と伝えかた勉強会
20180421 Issueの書き方と伝えかた勉強会
 
Oa mat
Oa matOa mat
Oa mat
 
SS2016 Workshop
SS2016 WorkshopSS2016 Workshop
SS2016 Workshop
 
よいアーキテクチャ、よいライブラリ、よいテスター
よいアーキテクチャ、よいライブラリ、よいテスターよいアーキテクチャ、よいライブラリ、よいテスター
よいアーキテクチャ、よいライブラリ、よいテスター
 
20080615 wacate
20080615 wacate20080615 wacate
20080615 wacate
 
20140610 秋山-ss2014
20140610 秋山-ss201420140610 秋山-ss2014
20140610 秋山-ss2014
 
Answer
AnswerAnswer
Answer
 
20081024 ja sst-sapporo
20081024 ja sst-sapporo20081024 ja sst-sapporo
20081024 ja sst-sapporo
 
とてか2
とてか2とてか2
とてか2
 

20170203 test analysisdesign

  • 1. テスト分析とテスト設計勉強会@日本大学駿河台キャンパス 2017年2月3日(金) SS開発本部/秋山浩一 © 2017 Fuji Xerox Co., Ltd. All rights reserved. JSTQBのテストプロセスについて (第1部: 基本の再確認と読み解き) 「テスト分析」と「テスト設計」を中心に、構造化分析・設計の話も少々 ・(私のパートは)ツイートOKです ハッシュタグ: #test ご質問がありましたら挙手あるいは Twitterで@akiyama924へ遠慮なく メイン
  • 2. 時間: 9:00~11:00(急いで退出しなくてもOK。JaSST実行委員を除く) 飲食: 基本的に不可(汚さないように、ごみは持ち帰るように。お願い!) 主催: NPO法人 ASTER 教育事業(ソフトウェアテスト技術振興協会) 録音・録画・写真: 不可(しないと思う) キーボード等のタイプ音: 大きく、迷惑にならないように気をつけて。お願い! 携帯・スマホ: マナーモード 発表者: ボランティア。おしみない拍手をいただけると喜びます!! 本日の勉強会の進め方 https://connpass.com/event/47938 © 2017 Fuji Xerox Co., Ltd. All rights reserved. 1
  • 3. © 2017 Fuji Xerox Co., Ltd. All rights reserved. (第1部) 9:00-9:40 秋山(Twitter ID: @akiyama924) l JSTQBのテストプロセス(主に分析・設計)について p 基本となる知識を理解しよう p 質疑および休憩 (第2部-1) 9:45-10:00 リリカル (TW: @mhlyc)のLT l テスト分析・設計について、釈然としないところ p 分析と設計って行ったりきたりするものなのでは? p だったらまとめて一つのプロセスでもいいのかな? (第2部-2) 10:00-10:30 湯本 剛(TW: @yumotsuyo)さんのLT l ゆもつよメソッドにおけるテスト分析とテスト設計 p 日本で一番実践的なテスト分析・テスト設計手法を学ぼう p 意見交換(リリカル×湯本剛) (第2部-3) 10:30-10:45 河野 哲也(facebook: Tetsuya Kouno)のLT l テスコン優勝事例におけるテスト分析・設計の解説 p テスコンで優勝したテスト分析とテスト設計事例から学ぼう (第2部-4) 10:45-10:55 まりまり(TW: @YamadaQuality)のLT l 大学祭の模擬店でデザインの力を感じた話 p 分析や設計ってなんの役に立つの? p 実践してみました! ! ! ! ! 本日の流れ 2
  • 4. ① JSTQBのテストプロセスの概要 ② JSTQBのテスト分析、テスト設計 ③ 構造化分析と構造化設計 JSTQBのテストプロセスについて © 2017 Fuji Xerox Co., Ltd. All rights reserved. 3
  • 5. ① JSTQBのテストプロセスの概要 n プロセスってなに? JSTQBのテストプロセス n テストレベルやテストフェーズとの関係 © 2017 Fuji Xerox Co., Ltd. All rights reserved. 4
  • 6. © 2017 Fuji Xerox Co., Ltd. All rights reserved. プロセスとは l プロセス(process): 相互関係のある活動のセット。入力を出力に変換する。 [ISO/IEC 12207] (JSTQB用語集) p [活動①] – [活動②] – [活動3] – [活動④] – [活動⑤] – [活動⑥] – [活動⑦](相互関係有) p ≪入力≫→[活動(アクティビティ:Activity)]→≪出力≫ Ø入力を出力に変換する活動 p ≪入力≫したものの価値を[活動]で高めて≪出力≫する(私見:読み解き) l JSTQBのテストプロセス(test process): 基本的なテストプロセスは、テスト の計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価 と報告、テスト終了作業によって構成される。(JSTQB用語集) p 論理的には、上記活動は順列に行われるが、実際には、重複したり並列に行われたりする場 合がある。(FL) p 通常、システムやプロジェクトの状況に合わせてこれらの活動を調整する必要がある。 (FL) p Shallではなく、ある程度の自由が許され、テーラリングが求められる(私見) p [①{テストの計画}と{コントロール}] – [②{テストの分析}と{テストの設計}] – [③ {テストの実装}と{テストの実行}] – [④{終了基準の評価}と{報告}] – [⑤{テスト終 了作業}] (FL) プロセスってなに? JSTQBのテストプロセス 「しなければならない」(MUST)、「してはならない」(MUST NOT)、「必須である」(REQUIRED)、「するものとする」(SHALL)、 「しないものとする」(SHALL NOT)、「すべきである」(SHOULD)、「すべきではない」(SHOULD NOT)、「推奨される」 (RECOMMENDED)、「してもよい」(MAY)、および「任意である」(OPTIONAL) (RFC2119) 5
  • 7. © 2017 Fuji Xerox Co., Ltd. All rights reserved. プロセスとテスト活動(ALTA:抜粋) lテスト活動は、ソフトウェア開発と整合している必要がある。たとえば、シーケン シャルなV字モデルの場合でシステムテストレベルに適用すると、次の内容。 pプロジェクト計画と同時にシステムテスト計画を始め、システムテストの実行と終了作業が完 了するまでテストコントロールを継続する。 pシステムテスト分析および設計は、要求仕様から、システムおよびアーキテクチャ設計仕様を 経て、コンポーネント設計仕様までのプロセスと並行して行う。 pシステムテスト環境の実装は、システム設計時に開始する場合があるが、これらの活動の大部 分は通常、コーディングおよびコンポーネントテストと同時に実行する。 pシステムテストの実行は、システムテスト開始基準にすべて合致したときに始まる。……略 ……システムテストの実行は、システムテスト終了基準に合致するまで継続する。 pシステムテスト終了基準の評価およびシステムテスト結果のレポートは、システムテスト実行 を通じて行う。 pシステムテスト終了作業は、システムテスト終了基準に合致しシステムテスト実行の終了を宣 言してから始まる。 テストレベルやテストフェーズとの関係 = ジェネリックプロセスモデル(包括的・汎用プロセスモデル:ISO 29119同様) 開発 プロジェク ト計画 要求仕様 アーキテク チャ設計 コンポーネ ント設計 コーディン グとCT システム テスト テスト計画 とコント ロール テスト分析 (続き) テスト設計 テスト環境 の実装 テスト実行 終了基準の 評価 終了作業 6
  • 9. © 2017 Fuji Xerox Co., Ltd. All rights reserved. テスト分析とテスト設計(ALTA) lテスト分析:テストベースを分析する。テスト条件を識別する。 p≪入力≫: テストベース Øこのドキュメントは、レビューに適切な評価で合格している p[活動]: テストベースとテスト目的を分析を分析する Øテストベースとして機能するテスト対象が記述されたドキュメントが存在する p≪出力≫: 識別されたテスト条件 Ø一般的には、テスト条件をさまざまな詳細度合いで定義することが望ましい lテスト設計: p≪入力≫: テスト条件 p[活動]: 1. 必要なテストカバレッジを確保するテストケース設計技法を決定し適用する 2. 識別したテスト条件を遂行するテストケースを作成する p≪出力≫: テストケース テスト分析とテスト設計 8
  • 10. ③ 構造化分析と構造化設計 n 構造化分析 n 構造化設計 © 2017 Fuji Xerox Co., Ltd. All rights reserved. 9
  • 11. © 2017 Fuji Xerox Co., Ltd. All rights reserved. 構造化分析と構造化設計 (『構造化分析とシステム仕様』 トム・デマルコ著) l分析: 分析とは行動をとる前に実施する問題の調査である。 p分析の最も重要な生産物は仕様書である Ø仕様書には機能仕様書、外部仕様書、設計仕様書、論理メモ、要求仕様書などがある p後に続く行動とは、そのシステムを構築することである l設計:設計は手続き的な部分と階層的な部分を決めて構築すること p手続き的な部分:順序 p階層的な部分: トップダウンに分割、データ結合度、モジュール凝集度 構造化分析と構造化設計 10