JaSST’13 Tokyo

エンタープライズシステムにおけるテスト～ STE研究交流会 参加者の視点から ～2013年1月31日
JaSST’13 Tokyo @目黒雅叙園
鈴木 一裕 @kz_suzuki(C)2013 Kazuhiro SUZUKI All rights reserved.

JaSST’13 Tokyo

自己紹介
STE研究交流会の、いち参加者です。

鈴木 一裕@kz_suzuki
SIerにてエンプラ系ソフトウェアの検証、品質分析など
 STE研究交流会の他、末席を汚すだけの簡単なおしごと

テスト自動化研究会- （ソフトウェア品質技術者のための）データ分析勉強会- SQuBOK bot (@SQuBOK_BOT) など-



blog: ソフトウェアの品質を学びまくる
ソフトウェアテスト・品質、JSTQB、テスト自動化知識体系、・・・- 交流会での議論をキッカケに書いた記事など-



気になる検索ワード「エクセル ドラッグ インクリメントされない」
 「ワード 複数文書目次 リンク切れ」
 「エラー! 目次項目が見つかりません。」
 「jstqb 第三版 買うべき」 「人は必ず誰かに愛されてると言えるよ 槇原敬之」
(C)2013 Kazuhiro SUZUKI All rights reserved.

JaSST’13 Tokyo
発表資料

2

JaSST’13 Tokyo

おはなしすること
大きく2つのお話をします。



STE研究交流会に参加して感じたこと
シナリオテストについて考えたこと

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

3

JaSST’13 Tokyo

STE研究交流会との関わり
鈴木三紀夫さんに声をかけていただく。

密やかに議論をする場だと思ってみたら、NPO法人の下部組織。

場違いでは・・・。
JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

4

JaSST’13 Tokyo

交流会第1回
2012年6月15日、第1回に参加してみた。

知ったことテスト技法の認知は、組込系に比べてイマイチ
 テストエンジニアのロールモデルが不明確
 テストで使われている言葉がバラバラ
たとえばエンプラ特有の、「シナリオテスト」


エンプラってそうなの！？

感じたこと他の人が築いてくれた知識を受け取るだけの人生・・・ ちょうどシナリオテストの「正しい」作成方法に悩み中← 他の人にも需要あるのでは？

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

5

JaSST’13 Tokyo

交流会第2回
2012年10月4日、第2回に参加してみた。



意見百出「テストシナリオ」の定義 → 意見不一致
 「シナリオテスト」の定義 → 意見不一致
 シナリオテストの数え方 → 意見不一致
 意見不一致であることの認識 → 意見一致


誰が正しい/間違い、ではない
それぞれの方法・考え方は、切り口ごとに整理できるはず シナリオテストの方法論をまとめていきたい！
僭越ながらシナリオテストを考察。
※ここから先は、検討中の私見・各論であり、結論はありません・・・！
(C)2013 Kazuhiro SUZUKI All rights reserved.

JaSST’13 Tokyo
発表資料

6

JaSST’13 Tokyo

整理していきたいこと
シナリオテストの方法論を集めて整理していきたい。



定義と目的
管理方法

STEで議論した箇所

進捗の把握
 pass/fail の判定 ・・・




実行方法
検証のポイント リトライのポイント ・・・




設計方法
テストシナリオの洗い出し 「カバレッジ」の規定 ・・・


実装方法


テストシナリオの具体化 ・・・
JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

7

JaSST’13 Tokyo

整理していきたいこと
シナリオテストの方法論を集めて整理していきたい。

定義と目的 管理方法 実行方法 設計方法 実装方法JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

8

JaSST’13 Tokyo

テストと、シナリオ「テストシナリオ」でググって見ると、いくつかの種類が・・・。



トラフィック・接続数
レスポンスやリソースの状況を検証するための、システム負荷のパターン
 統合テスト and/or システムテストレベルで行う性能テスト


シミュレーション
年金・保険など複雑な判定を行うプログラムに与える初期条件
 統合テストレベルで行う機能テスト




ストーリー
システムで業務を完遂できるかの確認に利用するストーリー
 統合テスト and/or システムテストレベルで行う機能テスト


JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

9

JaSST’13 Tokyo

ストーリー的シナリオテスト
ストーリー的シナリオも、2つに分類できそう。

設計に基づくシナリオテスト
たとえば、画面遷移図から遷移バリエーションを抽出
 入力画面→確認画面→入力画面に戻る→・・・ を繰り返すとエラーになるといった、実装面での問題摘出に期待 テストレベルとしては、統合テストか

要求に基づくシナリオテスト
たとえば、ユースケースシナリオから業務パターンを抽出 機能そのものがない、うまく連携できないといった、仕様面での問題摘出に期待 テストレベルとしては、システムテストか

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

10

JaSST’13 TokyoISTQB的テストシナリオ
テストシナリオってなんでしょう。

ISTQBの定義


テストシナリオ = テスト手順仕様 =テストの実行のために、一連の手順を定めたドキュメント

この「手順」は何に基づくもの？
プログラミングが終わった順
 重要度順 テストの効率


A1

A2

A3

A4

A1

A2

A3

A4

B1

B2

B3

B4

B1

B2

B3

B4

C1

C2

C3

C4

C1

C2

C3

C4



ユーザの業務に沿った順 ← 「狭義のテストシナリオ」(C)2013 Kazuhiro SUZUKI All rights reserved.

JaSST’13 Tokyo
発表資料

11

JaSST’13 Tokyo

テストシナリオの定義（案）（狭義の）テストシナリオの定義



外から見ると、ユーザの実際の業務を模したストーリー
中を見ると、ユーザの業務をシステムの利用に還元した、テストケースの順序つき集合

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

12

JaSST’13 Tokyo

なぜ、シナリオテスト？
統合テストまでで、各機能は確認済みなのに。



機能の間がうまくつながって、一連の業務が最初から最後まで滞りなく流れるかをチェック
機能間の整合性 機能の隙間にある人間系との連動


例: 図書館の管理システム
ユースケース記述は、各機能単位-

本を予約する
本の確保を通知する
本を借りる
本の予約を取り消す
本を返却する ・・・

予約して・借りて・延長して・延滞して・返却する といった、「貸出」に関する業務のライフサイクルを確認
JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

13

JaSST’13 Tokyo

整理していきたいこと
シナリオテストの方法論を集めて整理していきたい。

定義と目的 管理方法 実行方法 設計方法 実装方法

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

14

JaSST’13 Tokyo

管理の考え方
シナリオはテストケースの集合という前提で・・・

シナリオの本数？テストケースの件数？
シナリオ本数

テストケース件数

長所

業務の流れそのものなので、  各ケースの粒度が近いので、お客様にイメージしていた進捗の管理がしやすい。
だきやすい。

短所

各シナリオがどこまで進んでいるかがわかりづらい。



複数のシナリオが同じテストケースを含むことがある。

→ 両方を管理した方がいい。

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

15

JaSST’13 Tokyo

整理していきたいこと
シナリオテストの方法論を集めて整理していきたい。

定義と目的 管理方法 実行方法 設計方法 実装方法JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

16

JaSST’13 Tokyo

実行の考え方実行におけるルールも統一するといいですね。

検証のポイント

テストケースごと？シナリオが終わった時点？
→ ケースごとに見る方がいい
個々のテストケースは、シナリオの中で相互依存している- 途中にしか現れないアウトプットもある
-

1

2

3

4

5最後だけ？

途中も？



リトライのポイント


再テストでは、シナリオ中の失敗した箇所からやり直す？
→シナリオの最初からやり直すのがいい-

シナリオは、前のテストケースの事後条件を事前条件としている

1

2

最初から？
(C)2013 Kazuhiro SUZUKI All rights reserved.

3

45
JaSST’13 Tokyo
発表資料

途中から？

17

JaSST’13 Tokyo

整理していきたいこと
シナリオテストの方法論を集めて整理していきたい。

定義と目的 管理方法 実行方法 設計方法 実装方法JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

18

JaSST’13 Tokyo

設計・実装の考え方
一番大事な、テストシナリオの作り方。



シナリオの設計
カバレッジが測れるような論理的な設計方法がほしい 機能やフローが追加された際、合理的にシナリオを追加したい

業務要件から業務フロー・ユースケースをテストケースに還元→でもこれだけでは足りない！
 ユースケースを連結した、さらに長いシナリオ→連結の組み合わせ爆発にどう対処する？


『ソフトウェアテスト技法ドリル』では、「いつ」「どこで」という、システム利用する人の属性や背景も考慮シナリオの実装設計したシナリオに対し、具体的な値を与える
 考え方と方法は、これから・・・(C)2013 Kazuhiro SUZUKI All rights reserved.

JaSST’13 Tokyo
発表資料

19

JaSST’13 Tokyo

まとめ ～STE研究交流会に期待すること～
ものすごく期待しています。

エンプラ特有のテストの課題を明らかにしたい シナリオテストの考え方を整理したい 主催者の方々の知見を盗みたい

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

JaSST’13 Tokyo
発表資料(C)2013 Kazuhiro SUZUKI All rights reserved.

20