Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ソフトウェアテストチョットデキタ!
―テスト設計コンテストで学んだこと―
2015年10月3日
Akiharu SATOH
1© Akiharu SATOH, 2015. All Rights Reserved.
Ver. Morioka
テスト設計コンテストとは
2© Akiharu SATOH, 2015. All Rights Reserved.
コンテンツ
1. テスト分析・設計って何?
2. しなてすの軌跡
3. テスト設計コンテストから
学んだこと
3© Akiharu SATOH, 2015. All Rights Reserved.
コンテンツ
1. テスト分析・設計って何?
2. しなてすの軌跡
3. テスト設計コンテストから
学んだこと
4© Akiharu SATOH, 2015. All Rights Reserved.
テスト設計コンテストとは
5© Akiharu SATOH, 2015. All Rights Reserved.
テスト設計コンテストとは
6© Akiharu SATOH, 2015. All Rights Reserved.
質問
そもそも、
ソフトウェアテストを
どう進めていますか?
7© Akiharu SATOH, 2015. All Rights Reserved.
テスト活動が
重視されるにつれ、
テストのプロセスも
細|分|化
してきている。
8
テストプロセス
© Akiharu SATOH, 2015. All Rights Reserved.
テストプロセス
9
テスト分析 テスト設計 テスト実装 テスト実行 テスト評価
テストの準備(テストケース作成) テストの実行
ソフトウェアが単独で意味を持つようになった時代のテスト
何をテストするか どうテストするか
更に作業(必要なスキル)...
テストプロセス
テストプロセスを
細かく捉えることにより、
各プロセスにおける技術が
進歩してきている。
10© Akiharu SATOH, 2015. All Rights Reserved.
テスト分析技術
テストプロセス
11© Akiharu SATOH, 2015. All Rights Reserved.
テスト技法
テスト自動実行
技術
テスト評価技術
テストケース
生成技術
テスト分析 テスト設計 テスト実装 テスト実行...
いくつかのテストプロセス
12
ISTQB Advanced Level (Test Manager)におけるテストプロセス
引用した資料:「SSFに基づくテスト技術スキルフレームワーク スキル基準」、ASTER, IVIA
「ISTQB Ad...
テスト分析・設計
それで結局、
テスト分析・設計とは
何なのか?
13© Akiharu SATOH, 2015. All Rights Reserved.
テスト分析・設計
• 仕様書をもとにいきなりテストケースを書くとテストすべき事項が漏れやすくなる。
漏れないとしても、テストが充分であることの保証がしにくくなる。
• テスト漏れを防ぐために、まず仕様書などのテストベースからテストに対する要
求...
世の中のテスト分析・設計手法
15
手法名 表現方法 特徴 プロセス
NGT ツリー テスト全体をテスト観点で網羅 VSTeP
FV表 表形式 目的機能の切り口でV&V を網羅 HAYST法
ゆもつよメソッド 表形式 機能×テストタイプで網羅を...
テスト分析・設計
こんな話を某所でしたら、
いろいろ突っ込まれた。
16© Akiharu SATOH, 2015. All Rights Reserved.
• テスト分析って要求事項を洗い出すって言うけど、人とかお金
とかツールに関する要求...
テスト分析・設計
より深い話は置いといて、
ここでは・・・
17© Akiharu SATOH, 2015. All Rights Reserved.
テスト分析・設計
テスト分析・設計
をやると
なにか良いことが
ありそうだJ
18© Akiharu SATOH, 2015. All Rights Reserved.
テスト分析・設計
ということを感じてほしい・・・
19© Akiharu SATOH, 2015. All Rights Reserved.
コンテンツ
1. テスト分析・設計って何?
2. しなてすの軌跡
3. テスト設計コンテストから
学んだこと
20© Akiharu SATOH, 2015. All Rights Reserved.
しなてすの軌跡
ところで、
気になっていますよね?
21© Akiharu SATOH, 2015. All Rights Reserved.
しなてすの軌跡
今皆さんの前で話している人、
そして、テスト設計コンテストなる
イベントで優勝したしなてすとは
何者なのか?
22© Akiharu SATOH, 2015. All Rights Reserved.
自己紹介
23© Akiharu SATOH, 2015. All Rights Reserved.
自己紹介します。
誕生の瞬間
24
コンテスト参加
の発端は
Twitter
© しなてす, 2015. All Rights Reserved.
メンバ集め
まえたさん
はるはる(佐藤)
あみーめい
グループ会社横断の
研修プログラム受講生の輪
WACATE(ソフトウェアテストの
合宿形式の勉強会)の輪
25© しなてす, 2015. All Rights Reserved.
テスト設計コンテストに参加した理由
26
まえたさんはるはる
あみーめい
テスト設計を
やってみたかった
WACATEで
学んだことを
使ってみたかった
WACATEに
参加した記念に
テストを
経験して
みたかった
© しなてす, 2015....
27
そして
チーム発足
品川でテストの話を
してるんだから、
チーム名は
「しなてす」で。 うん、それで!
© しなてす, 2015. All Rights Reserved.
28
チーム発足から
足かけ2年半・・・
© しなてす, 2015. All Rights Reserved.
29
テスコン
優勝!!!
© しなてす, 2015. All Rights Reserved.
コンテンツ
30
『優勝するまでの軌跡』
•1年目 テストを設計してみよう!
•2年目 テスト設計を最後までやってみよう!
•3年目 コンテストで予選を通過しよう!
•3年目決勝 目指せ優勝!
© しなてす, 2015. All Rights ...
1年目
1年目
テストを設計してみよう!
31
テスト対象:話題沸騰ポット
チームが持っているもの:
WACATEで学んだこと
各メンバーの業務経験
しなてす © しなてす, 2015. All Rights Reserved.
1年目
成果物概要
32しなてす © しなてす, 2015. All Rights Reserved.
1年目
33
結果 予選敗退
しなてす © しなてす, 2015. All Rights Reserved.
審査委員
「テスト設計はどこですか」
2年目
2年目
テスト設計を
最後までやってみよう!
34
テスト対象:自動販売機
チームが持っているもの:
前年度の審査委員コメント
前年度予選、決勝の各チームの発表と成果物
テスト設計コンテストのチュートリアル
各メンバーの業務経験やコミュ...
2年目
成果物概要
35
自動販売機
所有者
電力会社
購入者
飲料
メーカー
自動販売機
メーカー
補充員 保守員
営業
(窓口)
★自販機開発者
★・・・テストを見る人
(同一の
場合も)
経営者
しなてす
良い報告をしたい
売れる自販機を...
2年目
36
結果 予選敗退
しなてす © しなてす, 2015. All Rights Reserved.
審査委員長
「書類上は通過だったのに」
3年目
3年目
テスト設計コンテストで
予選を通過しよう!
37
テスト対象:自動販売機
チームが持っているもの:
前年度の審査委員コメント
前年度予選、決勝の各チームの発表と成果物
報告会でもらったコメント
各メンバーの業務経験やコミュニティ...
3年目
成果物概要
38
+自動販売機
所有者
電力会社
購入者
飲料
メーカー
自動販売機
メーカー
補充員 保守員
営業
(窓口)
★自販機開発者
★・・・テストを見る人
(同一の
場合も)
経営者
しなてす
良い報告をしたい
売れる自販機...
3年目
39
結果 予選通過
しなてす © しなてす, 2015. All Rights Reserved.
しかし・・・
審査委員やテストエンジニアの
辛口コメントに答えられない現
実!
3年目 決勝
3年目 決勝
目指せ優勝!
40
テスト対象:自動販売機
チームが持っているもの:
予選通過時に審査委員・聴講者からもらった
辛口コメント
しなてす © しなてす, 2015. All Rights Reserved.
自動販売機
所有者
電力会社
購入者
飲料
メーカー
自動販売機
メーカー
補充員 保守員
営業
(窓口)
★自販機開発者
★・・・テストを見る人
(同一の
場合も)
経営者
しなてす
良い報告をしたい
売れる自販機を作ってほしい
今回の立場:...
3年目 決勝
42しなてす © しなてす, 2015. All Rights Reserved.
結果
3年目 決勝
43しなてす © しなてす, 2015. All Rights Reserved.
3年目 決勝
44しなてす
テスコン
優勝!!!
© しなてす, 2015. All Rights Reserved.
しなてすのテスト設計
ここで
しなてすのテスト設計を
ほんの少し紹介させてください。
45© Akiharu SATOH, 2015. All Rights Reserved.
前提
• 立場
– しなてすは自動販売機のシ
ステムテストを請け負った第
三者検証会社のチーム。
– 顧客である自動販売機メー
カーとテストを分担し、特に
ユーザ視点でのテストを受
け持つ。
• テスト環境
– 自動販売機の実機 数台
– 充分...
テスト分析
47
ステーク
ホルダ分析
ステーク
ホルダの
関心事整理
ステークホルダ
の関心事マップ
テスト方針
策定
自販機オーナーの
安心に対する
テスト要求整理
テスト方針
顧客ヒアリング
結果
自動販売機
業界知識
テストベース
※こ...
テストアーキテクチャ
48
テスト条件
のグルーピ
ング
質問事項の
明示
テスト要求
リスト
テスト条件
の関係検討
グルーピングの
方針
質問事項
テスト条件
の保守性
検討
テスト条件・
装置対応表
テスト条件
グルーピン
グ方針検討
重...
しなてすのテスト設計
プレゼン当日の資料は
テスト設計コンテストのサイトから
入手できます。
49© Akiharu SATOH, 2015. All Rights Reserved.
設計時に意識したこと
我々が大事だと思って取り組んだこと。
50
1. 最初に用語・概念を揃える。
2. 複数の方法・ケースを検討する。
3. 方法・ケースを取捨選択する際、
その理由を残す。
4. モデリングの際は有名な表記方法を使う。
© ...
最初に用語・概念を揃える
• しなてすでは、多くのコンテスト関係者と意思疎通をしやすくするため、用語や
概念はJSTQB用語集に従っている。
• 何から何まで全てきっちり揃えてはいない。(ベストエフォート)
51
テスト条件・・・コンポーネント...
複数の方法・ケースを検討する
• 「他に考えられないか?」を検討することによる抜け漏れ防止。
• 「他の方法は検討したのか?」という問いに対する説明力向上。
52
テスト条件のまとめ方
関連するテス
ト詳細設計以
降の作業
評価ポイント テスト...
方法・ケースを取捨選択する際、その理由を残す
• 残さないと、自分たちも数カ月後には忘れている。
• 意外と他のチームはできていないように感じる。(見聞きした手法をただ使って
いるだけという印象)
53
要求ID 分類
設置者にとっての安心
(...
モデリングの際は有名な表記方法を使う
• 有名な表記法だとツールのサポートが充実している。
• 特別な教育をしなくても読める人が多い。ただし本来の使い方からアレンジす
る場合、元の読み方を知っている人には違和感を感じさせるので注意!
54
テス...
コンテンツ
1. テスト分析・設計って何?
2. しなてすの軌跡
3. テスト設計コンテストから
学んだこと
55© Akiharu SATOH, 2015. All Rights Reserved.
想定される疑問
56
それで結局、
テスト分析・設計を
してみて良かったの?
© Akiharu SATOH, 2015. All Rights Reserved.
想定される疑問への回答
57
エンドユーザー、ステークホルダに
より意識を向けるようになった
業種職種による考え方や
気にしている観点の違いに気付けた
どんなテストをやりたいかを
明確に残すことができた
放っておくと人による
差異が大きいところ...
想定される疑問への回答
58
加えて・・・
© Akiharu SATOH, 2015. All Rights Reserved.
3年間コンテストに参加して得たもの
プロジェクト3回分のテスト設計経験
遠隔活動を回す勘所
社外発表の機会
顧客を納得させるための説明をしようとする意識
ありがたい審査委員コメント
テストについて話せる仲間
テスコンをきっかけにした更なる広がり...
テスト分析設計の勧め
60
いかがでしょうか。
ちょっと試してみる気に
なりましたか?
© Akiharu SATOH, 2015. All Rights Reserved.
試し方いろいろ
61
テスト設計コンテストに
出てみる
※2016は締め切られましたとりあえず自前で、
いま担当している範囲で
ちょっと試してみる
書籍、勉強会やセミナーで
さらに勉強してみるテストの有識者や
コンサルタントに
相談してみる
©...
テスト分析設計を学べそうなところ
62© Akiharu SATOH, 2015. All Rights Reserved.
ジャンル 名称など 説明
勉強会 WACATE ソフトウェアテストに関する、1泊2日の合宿形式の勉強会。
有識者やテス...
身につけたい技術
最後に。
より良いテスト分析・設計をするために、
エンジニアが身につけたほうが良いと、
私が思っている汎用技術・手法を
挙げます。
63© Akiharu SATOH, 2015. All Rights Reserved.
身につけたい技術
マインドマップ
• 表現したい概念の中心となるキーワードやイメージを中央に置き、そこから放射
状にキーワードやイメージを広げ、つなげていく。(from Wikipedia)
• 簡単そうに見えるが提唱者Tony Buzanの言...
身につけたい技術
MECEの引き出し
• MECEとはMutually Exclusive and Collectively Exhaustive、要は漏れなくダブ
りなくということ。
• テスト要求やテスト観点をツリー形式や前述のマインドマッ...
身につけたい技術
TOCfE 3つの道具
• TOC(制約理論)に基づく、3つの思考ツール(ブランチ、クラウド、アンビシャス
ターゲットツリー)の使用をお勧めしたい。fEとはfor Educationのこと。ということ
で、とても手軽に使える。...
身につけたい技術
ソフトウェアのアーキテクチャ関連技術
• ソフトウェアを分析・設計するときの考え方は、テストを分析・設計するときにも適
用できる。特定の技術を深く知るより、浅くても幅広く知っている方が良いだろう。
• UMLのような普及した表...
身につけたい技術
コーディング技術
• ソフトウェアの表面的なテストなら極端な話ユーザーにやってもらえばいい。
ニールセン博士の有名な言葉:「5人のユーザでテストすれば、ユーザビリティ
問題の85%を発見できる」
• ソフトウェアのテストをプロ...
身につけたい技術
一番大事なのは
テスト要求のもととなる情報を
兎に角たくさん入手することだと
思います。
69© Akiharu SATOH, 2015. All Rights Reserved.
身につけたい技術
そのために大切なものは
きっとステークホルダと
良好な関係を
築くスキルなのだと思います。
日頃の仲間との会話も重要ですね。
70© Akiharu SATOH, 2015. All Rights Reserved.
まとめ
• テストはテストケースを作って実行するだけではない。
→テストケースを作る前に分析・設計のプロセスがある。
• テスト分析・設計をやることで、テスト漏れの防止や、テスト実装以
降の作業がラクになることが期待できる。
• 実際、テスト設...
ソフトウェアテストチョットデキタ!
―テスト設計コンテストで学んだこと―
2015年10月3日
Akiharu SATOH
72
Ver. Morioka
END
© Akiharu SATOH, 2015. All Rights Reserv...
Upcoming SlideShare
Loading in …5
×

ソフトウェアテストチョットデキタ!Ver morioka

381 views

Published on

第一回盛岡ソフトウェアテスト勉強会(2015/10/3)でお話しした内容です。
2015年テスト設計コンテストで私たちのチーム「しなてす」が優勝しました。そのテスト設計コンテストの参加を通して学んだことを紹介します。

Published in: Software
  • Be the first to comment

  • Be the first to like this

ソフトウェアテストチョットデキタ!Ver morioka

  1. 1. ソフトウェアテストチョットデキタ! ―テスト設計コンテストで学んだこと― 2015年10月3日 Akiharu SATOH 1© Akiharu SATOH, 2015. All Rights Reserved. Ver. Morioka
  2. 2. テスト設計コンテストとは 2© Akiharu SATOH, 2015. All Rights Reserved.
  3. 3. コンテンツ 1. テスト分析・設計って何? 2. しなてすの軌跡 3. テスト設計コンテストから 学んだこと 3© Akiharu SATOH, 2015. All Rights Reserved.
  4. 4. コンテンツ 1. テスト分析・設計って何? 2. しなてすの軌跡 3. テスト設計コンテストから 学んだこと 4© Akiharu SATOH, 2015. All Rights Reserved.
  5. 5. テスト設計コンテストとは 5© Akiharu SATOH, 2015. All Rights Reserved.
  6. 6. テスト設計コンテストとは 6© Akiharu SATOH, 2015. All Rights Reserved.
  7. 7. 質問 そもそも、 ソフトウェアテストを どう進めていますか? 7© Akiharu SATOH, 2015. All Rights Reserved.
  8. 8. テスト活動が 重視されるにつれ、 テストのプロセスも 細|分|化 してきている。 8 テストプロセス © Akiharu SATOH, 2015. All Rights Reserved.
  9. 9. テストプロセス 9 テスト分析 テスト設計 テスト実装 テスト実行 テスト評価 テストの準備(テストケース作成) テストの実行 ソフトウェアが単独で意味を持つようになった時代のテスト 何をテストするか どうテストするか 更に作業(必要なスキル)で分類してプロセスを細分化 参考にした資料:「テスト設計コンテスト2015 チュートリアル資料」、ASTER © Akiharu SATOH, 2015. All Rights Reserved. ※テストプロセスの例。いくつかのプロセスが提唱されている。 テストをする ソフトウェア(プログラム)がハードウェアのおまけだった時代のテスト
  10. 10. テストプロセス テストプロセスを 細かく捉えることにより、 各プロセスにおける技術が 進歩してきている。 10© Akiharu SATOH, 2015. All Rights Reserved.
  11. 11. テスト分析技術 テストプロセス 11© Akiharu SATOH, 2015. All Rights Reserved. テスト技法 テスト自動実行 技術 テスト評価技術 テストケース 生成技術 テスト分析 テスト設計 テスト実装 テスト実行 テスト評価
  12. 12. いくつかのテストプロセス 12 ISTQB Advanced Level (Test Manager)におけるテストプロセス 引用した資料:「SSFに基づくテスト技術スキルフレームワーク スキル基準」、ASTER, IVIA 「ISTQB Advanced Levelシラバス日本語版」、ISTQB © Akiharu SATOH, 2015. All Rights Reserved. テスト 計画 テスト 分析 テスト 設計 テスト 実装 テスト 実行 終了基準 評価と レポート テスト 終了作業 Test.SSF(SSFに基づくテスト技術スキルフレームワーク)におけるテストプロセス テスト 要求分析 テスト アーキテクチャ 設計 テスト 詳細設計 テスト 実装 テスト 実行 テスト 報告 テスト 評価
  13. 13. テスト分析・設計 それで結局、 テスト分析・設計とは 何なのか? 13© Akiharu SATOH, 2015. All Rights Reserved.
  14. 14. テスト分析・設計 • 仕様書をもとにいきなりテストケースを書くとテストすべき事項が漏れやすくなる。 漏れないとしても、テストが充分であることの保証がしにくくなる。 • テスト漏れを防ぐために、まず仕様書などのテストベースからテストに対する要 求事項を洗い出しまとめる(テスト分析)。 • 洗い出したテストの要求事項は、テスト実装・実施の容易性やテストケースの保 守性などが考慮されていない。そのため、テストしやすくなるように、実施順序 や再利用などの構造を検討したうえでテストケースを作る(テスト設計)。 14 仕様書 テスト ケース テストへの要求事項 テスト実装、テスト実行、報告、保守 がしやすいテストケースのまとめ方 ・・・ テスト ケース テスト ケース どうテスト するのか? テスト設計 何をテスト するのか? テスト分析 © Akiharu SATOH, 2015. All Rights Reserved.
  15. 15. 世の中のテスト分析・設計手法 15 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&V を網羅 HAYST法 ゆもつよメソッド 表形式 機能×テストタイプで網羅をチェック ゆも豆 Tiramis ツリー(マイン ドマップ) テストカテゴリ分析を実施。機能はマインドマップ(MM) - TAME ツリー(マイン ドマップ) テスト設計思考の可視化とテスト観点の洗い出しおよび 整理 - 引用した資料: 「高信頼化ソフトウェアのための開発手法ガイドブック」, 2010, IPA/SEC (p.118) 発表されているテスト要求分析手法 © Akiharu SATOH, 2015. All Rights Reserved.
  16. 16. テスト分析・設計 こんな話を某所でしたら、 いろいろ突っ込まれた。 16© Akiharu SATOH, 2015. All Rights Reserved. • テスト分析って要求事項を洗い出すって言うけど、人とかお金 とかツールに関する要求は扱わないの? • テスト漏れを防ぐためとあるけど、テスト分析をすればテスト漏 れはなくなるの? • テスト分析の目的はテスト対象の理解なんじゃない?→いや いやそれはテスト対象分析の目的でしょ?→分析の目的は分 析対象の理解だと思う。 • テスト分析とテスト要求分析って何が違うの? • ・・・・・・
  17. 17. テスト分析・設計 より深い話は置いといて、 ここでは・・・ 17© Akiharu SATOH, 2015. All Rights Reserved.
  18. 18. テスト分析・設計 テスト分析・設計 をやると なにか良いことが ありそうだJ 18© Akiharu SATOH, 2015. All Rights Reserved.
  19. 19. テスト分析・設計 ということを感じてほしい・・・ 19© Akiharu SATOH, 2015. All Rights Reserved.
  20. 20. コンテンツ 1. テスト分析・設計って何? 2. しなてすの軌跡 3. テスト設計コンテストから 学んだこと 20© Akiharu SATOH, 2015. All Rights Reserved.
  21. 21. しなてすの軌跡 ところで、 気になっていますよね? 21© Akiharu SATOH, 2015. All Rights Reserved.
  22. 22. しなてすの軌跡 今皆さんの前で話している人、 そして、テスト設計コンテストなる イベントで優勝したしなてすとは 何者なのか? 22© Akiharu SATOH, 2015. All Rights Reserved.
  23. 23. 自己紹介 23© Akiharu SATOH, 2015. All Rights Reserved. 自己紹介します。
  24. 24. 誕生の瞬間 24 コンテスト参加 の発端は Twitter © しなてす, 2015. All Rights Reserved.
  25. 25. メンバ集め まえたさん はるはる(佐藤) あみーめい グループ会社横断の 研修プログラム受講生の輪 WACATE(ソフトウェアテストの 合宿形式の勉強会)の輪 25© しなてす, 2015. All Rights Reserved.
  26. 26. テスト設計コンテストに参加した理由 26 まえたさんはるはる あみーめい テスト設計を やってみたかった WACATEで 学んだことを 使ってみたかった WACATEに 参加した記念に テストを 経験して みたかった © しなてす, 2015. All Rights Reserved.
  27. 27. 27 そして チーム発足 品川でテストの話を してるんだから、 チーム名は 「しなてす」で。 うん、それで! © しなてす, 2015. All Rights Reserved.
  28. 28. 28 チーム発足から 足かけ2年半・・・ © しなてす, 2015. All Rights Reserved.
  29. 29. 29 テスコン 優勝!!! © しなてす, 2015. All Rights Reserved.
  30. 30. コンテンツ 30 『優勝するまでの軌跡』 •1年目 テストを設計してみよう! •2年目 テスト設計を最後までやってみよう! •3年目 コンテストで予選を通過しよう! •3年目決勝 目指せ優勝! © しなてす, 2015. All Rights Reserved.
  31. 31. 1年目 1年目 テストを設計してみよう! 31 テスト対象:話題沸騰ポット チームが持っているもの: WACATEで学んだこと 各メンバーの業務経験 しなてす © しなてす, 2015. All Rights Reserved.
  32. 32. 1年目 成果物概要 32しなてす © しなてす, 2015. All Rights Reserved.
  33. 33. 1年目 33 結果 予選敗退 しなてす © しなてす, 2015. All Rights Reserved. 審査委員 「テスト設計はどこですか」
  34. 34. 2年目 2年目 テスト設計を 最後までやってみよう! 34 テスト対象:自動販売機 チームが持っているもの: 前年度の審査委員コメント 前年度予選、決勝の各チームの発表と成果物 テスト設計コンテストのチュートリアル 各メンバーの業務経験やコミュニティ活動で得たもの しなてす © しなてす, 2015. All Rights Reserved.
  35. 35. 2年目 成果物概要 35 自動販売機 所有者 電力会社 購入者 飲料 メーカー 自動販売機 メーカー 補充員 保守員 営業 (窓口) ★自販機開発者 ★・・・テストを見る人 (同一の 場合も) 経営者 しなてす 良い報告をしたい 売れる自販機を作ってほしい 今回の立場: 第三者検証会社 所有者次第 R07 設置者の売りたい値で 消費者が買える こと 組合せテスト テスト優先度 R05 異常状態がすぐわ かる 組合せテスト シナリオテスト (順序依存関係) 「後」よ り「先」の要求を 先にテストする こと 凡例 先 後 (条件 質問 テス 要 求 質問 R02 異物が入った時に適 切に動作すること ユースケーステスト R06 販売が適切に停止 する ユースケーステスト R03 安心して使い続けら れる 状態遷移テスト アドホックテスト R04 セキュリティが確保 されている 組合せテスト シナリオテスト R08 ブザー音が適切であ ること シナリオテスト R09 明るさが適切である こと シナリオテスト TQ001 TQ002 TQ003 TQ004 TQ005 TQ006 TQ016 TQ023 TQ009 TQ010 TQ011 TQ012 高い 低い 要求ID 説明 テスト技法 テ ス ト 要 求 分 析 テストアー キテクチャ 設計 テスト要求 分析書 テストアーキテクチャ 設計書 テ 詳 設 TD01 TD02 テストアーキテクチャ ステークホルダ図 テスト要求リストテスト方針 発表時間 オーバーだよ! しなてす © しなてす, 2015. All Rights Reserved.
  36. 36. 2年目 36 結果 予選敗退 しなてす © しなてす, 2015. All Rights Reserved. 審査委員長 「書類上は通過だったのに」
  37. 37. 3年目 3年目 テスト設計コンテストで 予選を通過しよう! 37 テスト対象:自動販売機 チームが持っているもの: 前年度の審査委員コメント 前年度予選、決勝の各チームの発表と成果物 報告会でもらったコメント 各メンバーの業務経験やコミュニティ活動で得たもの しなてす © しなてす, 2015. All Rights Reserved.
  38. 38. 3年目 成果物概要 38 +自動販売機 所有者 電力会社 購入者 飲料 メーカー 自動販売機 メーカー 補充員 保守員 営業 (窓口) ★自販機開発者 ★・・・テストを見る人 (同一の 場合も) 経営者 しなてす 良い報告をしたい 売れる自販機を作ってほしい 今回の立場: 第三者検証会社 所有者次第 R07 設置者の売りたい値で 消費者が買えること 組合せテスト テスト優先度 R05 異常状態がすぐわ かる 組合せテスト シナリオテスト (順序依存関係) 「後」より「先」の要求を 先にテストすること 凡例 先 後 (条件依存関係) 質問事項が解決されてから テストすること 要 求 質問 R02 異物が入った時に適 切に動作すること ユースケーステスト R06 販売が適切に停止 する ユースケーステスト R03 安心して使い続けら れる 状態遷移テスト アドホックテスト R04 セキュリティが確保 されている 組合せテスト シナリオテスト R08 ブザー音が適切であ ること シナリオテスト R09 明るさが適切である こと シナリオテスト R01 当たりやすさに不具 合が無い ユースケーステスト TQ001 TQ002 TQ003 TQ004 TQ005 TQ006 TQ016 TQ023 TQ009 TQ010 TQ011 TQ012 高い 低い 要求ID 説明 テスト技法 テスト 要求 分析 テストアー キテクチャ 設計 テスト要求 分析書 テストアーキテク チャ設計書 テスト 詳細 設計 テスト詳細 設計書 TD01 TD02 TD03 テスト観点 ID 内容 優先度 TR_R07_01 設定された価格で販売できること 6 TR_R05_01 商品切れであることが正しく通知され、不正に動作しないこと 4 TR_R05_02 釣り銭切れであることが正しく通知され、不正に動作しないこと 4 TR_R02_01 おつり取り出し口と紙幣投入口に異物が入った時に適切に動作す ること 3 TR_R04_01 売上処理に不具合がないこと 2 テストスクリプト テストアーキテクチャ ステークホルダ図 テスト要求リスト テストケーステスト方針 1年前の成果物のブラッシュアップ版 適切なプレゼン はるはる.wmf Opefy(≠DevOps) 操作 操作内容 操作時に 使用する値 確認事項 確認時に 使用する値 入金 「金種」と「枚数」の値に従っ て、紙幣投入口または硬貨 投入口に金を入れる 金種,枚数 ・金額表示機に「表示」に書かれている値が表 示されること ・販売可能な商品ボタンが点灯していること 表示 しなてす © しなてす, 2015. All Rights Reserved.
  39. 39. 3年目 39 結果 予選通過 しなてす © しなてす, 2015. All Rights Reserved. しかし・・・ 審査委員やテストエンジニアの 辛口コメントに答えられない現 実!
  40. 40. 3年目 決勝 3年目 決勝 目指せ優勝! 40 テスト対象:自動販売機 チームが持っているもの: 予選通過時に審査委員・聴講者からもらった 辛口コメント しなてす © しなてす, 2015. All Rights Reserved.
  41. 41. 自動販売機 所有者 電力会社 購入者 飲料 メーカー 自動販売機 メーカー 補充員 保守員 営業 (窓口) ★自販機開発者 ★・・・テストを見る人 (同一の 場合も) 経営者 しなてす 良い報告をしたい 売れる自販機を作ってほしい 今回の立場: 第三者検証会社 所有者次第 3年目 決勝 成果物概要 41 テスト 要求 分析 テストアー キテク チャ 設計 テスト要求 分析書 テストアーキテク チャ設計書 テスト 詳細 設計 テスト詳細 設計書 TD01 TD02 TD03 テスト観点 ID 内容 優先度 TR_R07_01 設定された価格で販売できること 6 TR_R05_01 商品切れであることが正しく通知され、不正に動作しないこと 4 TR_R05_02 釣り銭切れであることが正しく通知され、不正に動作しないこと 4 TR_R02_01 おつり取り出し口と紙幣投入口に異物が入った時に適切に動作す ること 3 TR_R04_01 売上処理に不具合がないこと 2 Opefy定義表 チョット磨いた テストアーキテクチャ ステークホルダ図 テスト要求リスト テストケーステスト方針 テスト条件と関連装置の対応表 しなてす © しなてす, 2015. All Rights Reserved.
  42. 42. 3年目 決勝 42しなてす © しなてす, 2015. All Rights Reserved. 結果
  43. 43. 3年目 決勝 43しなてす © しなてす, 2015. All Rights Reserved.
  44. 44. 3年目 決勝 44しなてす テスコン 優勝!!! © しなてす, 2015. All Rights Reserved.
  45. 45. しなてすのテスト設計 ここで しなてすのテスト設計を ほんの少し紹介させてください。 45© Akiharu SATOH, 2015. All Rights Reserved.
  46. 46. 前提 • 立場 – しなてすは自動販売機のシ ステムテストを請け負った第 三者検証会社のチーム。 – 顧客である自動販売機メー カーとテストを分担し、特に ユーザ視点でのテストを受 け持つ。 • テスト環境 – 自動販売機の実機 数台 – 充分な額と種類の貨幣 – 充分な量と種類の飲料 46 製品企画 システム要求分析・方式設 計 ソフトウェア要求分析 ソフトウェア設計 コーディング ソフトウェアテスト システムテスト 最終審査 製造・出荷 ソフトウェア 開発 ハードウェア 開発 しなてすと 共同作業 (客先常駐) 6月 7月 8月 9月 10月 11月 12月 HERE NOW 自動販売機開発の全体像 © Akiharu SATOH, 2015. All Rights Reserved. どんな技術も効果を発揮できる 前提があるので、こういう前提の話を コンテストのプレゼンでもすればよかったと 反省している。
  47. 47. テスト分析 47 ステーク ホルダ分析 ステーク ホルダの 関心事整理 ステークホルダ の関心事マップ テスト方針 策定 自販機オーナーの 安心に対する テスト要求整理 テスト方針 顧客ヒアリング 結果 自動販売機 業界知識 テストベース ※これ以降のプロセ スでも参照されるが、 簡単のために省略 インテーク テストのテスト 要求整理 自動販売機 所有者 電力会社 購入者 飲料 メーカー 自動販売機 メーカー 補充員 保守員 営業 (窓口) ★自販機開発者 ★・・・テストを見る人 (同一の 場合も) 経営者 しなてす 良い報告をしたい 売れる自販機を作ってほしい 所有者次第 ステークホルダ図 テスト要求リスト USDM形式で、テスト すべきものとその理由 を明記 マインドマップで 発散して、その後収束 「自販機オーナーの 安心を保障する!」 © Akiharu SATOH, 2015. All Rights Reserved.
  48. 48. テストアーキテクチャ 48 テスト条件 のグルーピ ング 質問事項の 明示 テスト要求 リスト テスト条件 の関係検討 グルーピングの 方針 質問事項 テスト条件 の保守性 検討 テスト条件・ 装置対応表 テスト条件 グルーピン グ方針検討 重複テスト 条件の排除 星取り表で 理由づけ テスト条件関係図 商品切れ時に商品選択 できないこと 売切れランプが 設定どおりの明るさ で点くこと インテーク テスト 優先度高 優先度中 優先度低 機能テスト 障害テスト 機能テスト 障害テスト エージング テスト 機能テスト 障害テスト テストアーキテクチャ テストアーキテクチャ 状態遷移図をベースに、 テスト条件を 階層構造で整理 テスト条件間の 関係を図で整理 © Akiharu SATOH, 2015. All Rights Reserved.
  49. 49. しなてすのテスト設計 プレゼン当日の資料は テスト設計コンテストのサイトから 入手できます。 49© Akiharu SATOH, 2015. All Rights Reserved.
  50. 50. 設計時に意識したこと 我々が大事だと思って取り組んだこと。 50 1. 最初に用語・概念を揃える。 2. 複数の方法・ケースを検討する。 3. 方法・ケースを取捨選択する際、 その理由を残す。 4. モデリングの際は有名な表記方法を使う。 © Akiharu SATOH, 2015. All Rights Reserved.
  51. 51. 最初に用語・概念を揃える • しなてすでは、多くのコンテスト関係者と意思疎通をしやすくするため、用語や 概念はJSTQB用語集に従っている。 • 何から何まで全てきっちり揃えてはいない。(ベストエフォート) 51 テスト条件・・・コンポーネントやシステムのアイテムやイベントで、 テス トケースにより検証できるもの。たとえば、機能、トランザクション、品質 特性、構造要素など。 用語の例 © Akiharu SATOH, 2015. All Rights Reserved.
  52. 52. 複数の方法・ケースを検討する • 「他に考えられないか?」を検討することによる抜け漏れ防止。 • 「他の方法は検討したのか?」という問いに対する説明力向上。 52 テスト条件のまとめ方 関連するテス ト詳細設計以 降の作業 評価ポイント テストタイプでまとめる テスト要求の優先度でま とめる テスト対象の機能で まとめる テスト対象の、テスト前後 のソフトウェア状態でまと める テスト対象のシステムアーキ テクチャでまとめる インテークテスト、機能テ スト、異常系テスト、耐久 テスト、性能テストなど、 実施すべきテストタイプご とにグループを作る。 テスト要求ごとにリスク ベースで優先度を設け、 優先度別にグループを 作る。 テスト条件を、関連す る機能ごとにまとめる。 連続してテストしやすいよ う、テスト前後の状態が、 「販売中」のもの、そうでな いもの、とに分ける。 テスト条件をハードウェアに 密に関わるもの、ソフトウェア の機能に関するもの、業務・ サービスに関するものといっ た単位でまとめる。 テスト実装 テストケースの作成しやす さ ★★★★ ★(不考慮) ★★ ★★ ★★ テスト実装 検証観点漏れの起こりにく さ ★★★★★ ★(不考慮) ★★ ★★ ★★ テスト実行 テストの実行(操作、結果確 認)しやすさ ★★★★ ★(不考慮) ★★ ★★★★★ ★★ 報告 進捗管理・テスト進捗報告 のしやすさ ★★★ ★★★★ ★★★ ★(不考慮) ★★ 報告 テスト対象の品質を保証し ていることの報告しやすさ ★★★ ★★★★★ ★★★★ ★(不考慮) ★★ 報告 テスト妥当性の報告しやす さ ★★★★ ★★★★ ★★ ★(不考慮) ★★ 保守 装置や機能変更・追加に対 するテストケースの保守し やすさ ★(不考慮) ★(不考慮) ★★★★★ ★(不考慮) ★★ 検討結果 採用する。 同種のテスト毎にまとめる ことで、テスト実装と実行 がしやすくなり、作業効率 が向上すると考えた。保 守のしやすさは別途対策 する。(本書2.3節参照) 採用する。 ただしこの観点はテスト 実装・実行のしやすさを 考慮していないので、テ ストタイプによるグルー ピングとの合わせ技で 対応する。 不採用。 機能の品質保証をし ていることは説明し やすいが、今回のテ ストは非機能中心で あるため。 不採用。 連続実行しやすいが、バ グの再現や再テストが難 しい可能性がある。また、 この方法のみでは報告・ 保守のしやすさを考慮で きない。 不採用。 今回のしなてすのテストス コープは主にサービスに関わ るところを扱っているため、こ の方法でうまく分類できない。 そのため、実装、実行、報告 ともにやりやすくならない。 【テストアーキテクチャ設計】テスト条件のグルーピング方針の検討結果 © Akiharu SATOH, 2015. All Rights Reserved.
  53. 53. 方法・ケースを取捨選択する際、その理由を残す • 残さないと、自分たちも数カ月後には忘れている。 • 意外と他のチームはできていないように感じる。(見聞きした手法をただ使って いるだけという印象) 53 要求ID 分類 設置者にとっての安心 (自動販売機への要求事項) 理由 R01 カ ネ 懸賞ルーレットの当たりやすさに不具合が無い 付加機能としての懸賞機能により不利益が出ないか心配なため 売上がわかる 売上データ格納用データベースの機能であり、今回のテスト対象外であると合意しているため コストがわかる 本自動販売機にはコストを示す機能がないため 偽の貨幣を受け付けない ハードウェアに関わるものであるため 在庫数がわかる 売上データ格納用データベースの機能であり、今回のテスト対象外であると合意しているため 販売数がわかる 売上データ格納用データベースの機能であり、今回のテスト対象外であると合意しているため R02 モ ノ 異物が入ったときに適切に動作する 異物が入ったときに適切に振る舞い、二次被害を防止したいため R03 安定して使い続けることができる 安定して長く運用したいため 盗まれない(本体、金、商品) ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため 壊れない ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため R04 販売不可状態がすぐにわかる 準備中などの販売不可時や故障時に早く復旧し、販売機会の損失を防ぎたいため R05 販売が適切に停止する 異常に販売停止となることで、消費者または設置者に不利益が発生しないようにしたいため R06 ブザー音が適切である TPOをわきまえた音量設定をしたいため R07 照明やランプの明るさが適切である TPOをわきまえた明るさ設定をしたいため 動作音が小さい ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため 大きさが適当 ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため 安定性がある ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため 色・デザインが景観を損ねない ハードウェアに関わるものであり、メーカーで検討すべき事項と考えたため R08 ヒ ト 設置者が売りたい値段で消費者が商品を買うことができる 設置者と消費者の希望が一致していることを確認するため。クレームを起こさないため メーカーサービスが充分である 運用サービスに関わるものであり、メーカーで検討すべき事項と考えたため 【テスト分析】今回のテストで扱うべき要求事項の判断とその理由 ※網掛けは今回のテストで扱う要求、非網掛けは扱わない要求を表す。 © Akiharu SATOH, 2015. All Rights Reserved.
  54. 54. モデリングの際は有名な表記方法を使う • 有名な表記法だとツールのサポートが充実している。 • 特別な教育をしなくても読める人が多い。ただし本来の使い方からアレンジす る場合、元の読み方を知っている人には違和感を感じさせるので注意! 54 テストを始める 条件を明示 テストするかたまり テストタイプ 【テストアーキテクチャ設計】自動販売機のシステムテストのアーキテクチャ © Akiharu SATOH, 2015. All Rights Reserved.
  55. 55. コンテンツ 1. テスト分析・設計って何? 2. しなてすの軌跡 3. テスト設計コンテストから 学んだこと 55© Akiharu SATOH, 2015. All Rights Reserved.
  56. 56. 想定される疑問 56 それで結局、 テスト分析・設計を してみて良かったの? © Akiharu SATOH, 2015. All Rights Reserved.
  57. 57. 想定される疑問への回答 57 エンドユーザー、ステークホルダに より意識を向けるようになった 業種職種による考え方や 気にしている観点の違いに気付けた どんなテストをやりたいかを 明確に残すことができた 放っておくと人による 差異が大きいところだと思うが、 皆が同じくらい 意識できるようになった。 自分に無い視点を 得ることができた。 まさにチーム力! 創造的作業の成果を 見える化して残したことで、 以降の作業がラクになりそう © Akiharu SATOH, 2015. All Rights Reserved.
  58. 58. 想定される疑問への回答 58 加えて・・・ © Akiharu SATOH, 2015. All Rights Reserved.
  59. 59. 3年間コンテストに参加して得たもの プロジェクト3回分のテスト設計経験 遠隔活動を回す勘所 社外発表の機会 顧客を納得させるための説明をしようとする意識 ありがたい審査委員コメント テストについて話せる仲間 テスコンをきっかけにした更なる広がり ・・・ こんなものが得られました。 59© しなてす, 2015. All Rights Reserved.
  60. 60. テスト分析設計の勧め 60 いかがでしょうか。 ちょっと試してみる気に なりましたか? © Akiharu SATOH, 2015. All Rights Reserved.
  61. 61. 試し方いろいろ 61 テスト設計コンテストに 出てみる ※2016は締め切られましたとりあえず自前で、 いま担当している範囲で ちょっと試してみる 書籍、勉強会やセミナーで さらに勉強してみるテストの有識者や コンサルタントに 相談してみる © Akiharu SATOH, 2015. All Rights Reserved.
  62. 62. テスト分析設計を学べそうなところ 62© Akiharu SATOH, 2015. All Rights Reserved. ジャンル 名称など 説明 勉強会 WACATE ソフトウェアテストに関する、1泊2日の合宿形式の勉強会。 有識者やテスト仲間と親しくなれる場にもなります。 書籍 ソフトウェアテスト Press総集編 Vol.1~Vol.10の総集編PDF テスト分析・設計の話題のほか、テストに関するさまざまな 話題が載っています。 イベント JaSST 日本各地で実施してるソフトウェアテストのシンポジウム。 セッションやチュートリアルでテスト分析・設計のテーマが 扱われることがある。 イベント SQiPシンポジウム ソフト品質のシンポジウム。こちらでもセッションやチュートリ アルでテスト分析・設計のテーマが扱われることがある。 イベント テスト設計チュートリ アル テスト設計コンテスト関連イベントだが、コンテスト参加者で なくても参加可能。 そのほか、SlideShare等のSNSやブログなどで情報発信されている方もいらっしゃいます。
  63. 63. 身につけたい技術 最後に。 より良いテスト分析・設計をするために、 エンジニアが身につけたほうが良いと、 私が思っている汎用技術・手法を 挙げます。 63© Akiharu SATOH, 2015. All Rights Reserved.
  64. 64. 身につけたい技術 マインドマップ • 表現したい概念の中心となるキーワードやイメージを中央に置き、そこから放射 状にキーワードやイメージを広げ、つなげていく。(from Wikipedia) • 簡単そうに見えるが提唱者Tony Buzanの言う意味で正しく使える人はそれほど 多くないらしい。 • ソフトウェアテストと絡めた書籍としては、「マインドマップから始めるソフトウェア テスト」、池田暁、鈴木三紀夫 がある。 64© Akiharu SATOH, 2015. All Rights Reserved.
  65. 65. 身につけたい技術 MECEの引き出し • MECEとはMutually Exclusive and Collectively Exhaustive、要は漏れなくダブ りなくということ。 • テスト要求やテスト観点をツリー形式や前述のマインドマップで表現する場合、 ある階層に漏れが無いか?などステークホルダ間で合意形成しやすくしてくれ る。 65 Who When Where What Why How 5W1H ヒト モノ カネ 時間 Consumer CompanyCompetitor 3C © Akiharu SATOH, 2015. All Rights Reserved.
  66. 66. 身につけたい技術 TOCfE 3つの道具 • TOC(制約理論)に基づく、3つの思考ツール(ブランチ、クラウド、アンビシャス ターゲットツリー)の使用をお勧めしたい。fEとはfor Educationのこと。ということ で、とても手軽に使える。 • ある現象をとりまく因果関係の明確化や対立の解消、段階的課題解決に取り組 むためのアプローチを示してくれる。テストに限らず、様々な問題の解決に役立 つと思う。 • 最近何故か私の周りのテストクラスタの方々が学んでいる。 66© Akiharu SATOH, 2015. All Rights Reserved.
  67. 67. 身につけたい技術 ソフトウェアのアーキテクチャ関連技術 • ソフトウェアを分析・設計するときの考え方は、テストを分析・設計するときにも適 用できる。特定の技術を深く知るより、浅くても幅広く知っている方が良いだろう。 • UMLのような普及した表記法は、テスト要求やテストアーキテクチャを表現する 場合も活用できる。特に良質のツールが手軽に使えるところが良い。 67 ※挙げている書籍は個人的に興味あるものです © Akiharu SATOH, 2015. All Rights Reserved.
  68. 68. 身につけたい技術 コーディング技術 • ソフトウェアの表面的なテストなら極端な話ユーザーにやってもらえばいい。 ニールセン博士の有名な言葉:「5人のユーザでテストすれば、ユーザビリティ 問題の85%を発見できる」 • ソフトウェアのテストをプロとしてするのなら、ソフトのアーキテクチャと同じくらい、 ソフトウェアのコードの性質(どこに欠陥が潜みやすい、など)を知っている必要 があると思いませんか? 68© Akiharu SATOH, 2015. All Rights Reserved.
  69. 69. 身につけたい技術 一番大事なのは テスト要求のもととなる情報を 兎に角たくさん入手することだと 思います。 69© Akiharu SATOH, 2015. All Rights Reserved.
  70. 70. 身につけたい技術 そのために大切なものは きっとステークホルダと 良好な関係を 築くスキルなのだと思います。 日頃の仲間との会話も重要ですね。 70© Akiharu SATOH, 2015. All Rights Reserved.
  71. 71. まとめ • テストはテストケースを作って実行するだけではない。 →テストケースを作る前に分析・設計のプロセスがある。 • テスト分析・設計をやることで、テスト漏れの防止や、テスト実装以 降の作業がラクになることが期待できる。 • 実際、テスト設計コンテストを通じてテスト分析・設計をやってみた ところ次のような良いことがあった。 – 皆がエンドユーザやステークホルダを意識してテストに取り組むようになっ た。 – 自分にはないチームの他メンバの視点を得ることができた。 • テスト分析・設計を学べそうなところ(情報源)は多数あるので、引き 続き学んでいただき、小さいところから実践して欲しい。 71© Akiharu SATOH, 2015. All Rights Reserved.
  72. 72. ソフトウェアテストチョットデキタ! ―テスト設計コンテストで学んだこと― 2015年10月3日 Akiharu SATOH 72 Ver. Morioka END © Akiharu SATOH, 2015. All Rights Reserved.

×