テストの設計意図を届けよう 2023
〜テストしたいことを、よりスマートに伝えるための第一歩
JaSST’23 Tokyo
テスト設計コンテスト U-30クラス

セッション

井芹 久美子（テスト設計コンテスト審査委員会）
坂 静香（テスト設計コンテスト審査委員会）

1

このセッションについて想定している聴講者● テストケース・テストスクリプトを作成したことがある● 自分が作成したテストケース・テストスクリプト・その他テスト
設計成果物に対して満足していない、なにかモヤモヤしている● 自分が作成したテスト設計成果物をリーダーや開発者に確認してもらうと、無反応や厳しい反応など、嬉しくないことが起こる● 自分が作成したテストケース・テストスクリプトを実行してもらうと、自分が思ったように実行されずに確認漏れが出てしまう● 上記のような悩みを持つメンバーに対して、どうアプローチしようか悩んでいる● 特に悩みはないけれども、なんか参考になるかも？と思っている● テスコンU-30に挑戦しようかなー・・・と思っている2

このセッションについて● このセッションでお話しようとしていること○ テスト設計成果物を改善するための第一歩○ テスト設計成果物でテストの意図を届けるための工夫○ 仕様をなぞったテストから脱却するためのヒント
本スライドに掲載している成果物例は「こうすれば必ずうまくいく」という例ではなく「こうしたらよいかもしれない」という例に過ぎません。大事なことは、みなさんが普段作成している成果物に対して「今よりもうまくできるためにどうしたらよいだろう？」と考え、試して、自分たちに適したやりかたで実践できることです。
本講演で扱う成果物例が、改善案を考えるための参考になりましたら幸いです。

3

テスト設計コンテストU-30クラスについて
http://www.aster.or.jp/testcontest/●●●

テスコンはJaSSTの企画セッションとして始まった
その名の通り、テスト設計の腕を磨き競う場‘13からASTERの事業として開催‘17から、OPENクラスとU-30クラスに分けて開催○○

U-30は30歳以下の実務経験の浅い技術者が経験を積む場提示したテストベースに対して、「まずはやってみよう」「チュートリアルの内容を踏まえて一通りのプロセスをやりきろう」を目指してテスト設計に挑戦していただくテスト設計コンテスト’23 開催します！
●●●

説明会は5月、チュートリアルは5/24(水)夜開催予定！
予選後に審査委員とじっくり話せるフィードバック会を開催！
決勝戦は2024/1/27(土)！！挑戦者をお待ちしています♪
4自己紹介● 坂 静香○○○JaSST Tokyo実行委員・TOCfE Bootcampスタッフ
テスト設計コンテストU-30クラス審査委員↑なのに、テストのスタイルはフリーダム探索派（野生動物）● 井芹 久美子○○○

テスト設計コンテストU-30クラス審査委員、JSTQB技術委員
WACATE2020冬の招待講演やJaSSTなどで登壇経験を持つ
書籍「実践ソフトウェアエンジニアリング(第9版)」の翻訳に参加

5

講演のすすめかた
Zoom ウェビナー

セ
ッ
シ
ョ
ン
時
間
内

前半
・テスト設計成果物改善のファーストステップ

後半
・構造を見せる

残り時間があれば質問をピックアップして口頭で回答をしていきます

Discord テキストチャンネル
講師

講師

講師

6

参加者

質問は随時
Discordのセッションチャンネ
ル・Zoomに記載
してくださいその他感想や
フィードバックなど、ご自由にコメントを記載
してください講師

記載された質問に対して、回答
を返信していきます(セッション後も口頭回答したものも含め、残りの質問に回答を入れていきます)職場でこんなことが起こっていませんか？
● テスト設計の成果物が、実行可能な状態のテストケース・
テストスクリプトしかない● マインドマップやテスト設計のフレームワークを使っているが、仕様記述を載せ直しただけになってしまう● テスト観点を予め出してみているが、テストケースは仕様記
述のコピーペーストで作ってしまう● テストケースに優先度をつけるときに、過去の資料や経験をもとに、なんとなくつけている

7

レビューでいきなりこんな成果物を見せていませんか？

頑張って読んでもテストの十分性が判断できない

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

89ページ を参照して作成

仕様書の記述を写経していませんか？
書いた本人の仕様理解度は増すが、仕様以外の情報は載せられない

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

99ページ を参照して作成

テスト設計成果物が分離していませんか？

マインドマップに出ている観点をテストケース上に見つけられない
話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

109ページ を参照して作成

前後の成果物で矛盾が生じていませんか？
テストで確認したいことと、実際にできたテストケースで乖離がある

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

119ページ を参照して作成

結果としてこんなことが起こっていませんか？
● テストケースのレビュー依頼をしても、無反応だったり、不機嫌な反応が返ってきてしまう● テスト設計レビューミーティングを開催するが、テストケー
スを一つ一つ読み上げてしまい、時間切れになってしまう● レビューが十分に行われないまま、抜け漏れのあるテスト
ケースでそのままテスト実行してしまう● 仕様に対して抜け漏れなくテストしたはずなのに、リリース
後に問題が起こる● 優先度を下げてテストをしなかった箇所でリリース後に影響度の高い不具合が見つかる みんな頑張っているのに残念な結果になってしまう・・
12

テスト設計成果物で、なにか改善できるだろうか？
テスト設計成果物を改善してみよう！
1. テスト設計のプロセスを見直そう
2. テスト設計成果物の情報がつながるようにしよう
3. テスト設計成果物の妥当性を「Why？＋α」で確認してみよう
前半は、改善のファーストステップとして、
上記３つの改善案についてお話します！

13

テスト設計成果物改善のファーストステップ
成果物例は、「話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版」
Copyright(C) 組込みソフトウェア管理者・技術者育成研究会（SESSAME）
をテストベースとして作成しています。

14

１．テスト設計のプロセスを見直そう
昔の
テスト開発
プロセス

JSTQBの
テスト開発
プロセス

本講での
テスト開発
プロセス

テスト
実施

テスト設計※またはテスト計画、テスト準備など表現は様々

テスト分析

テスト
要求分析
テスト要求の獲得と整理/
テスト要求
モデリング

テスト設計
テスト
ｱｰｷﾃｸﾁｬ
設計
テスト
アーキテクチャ
モデリング

テスト
詳細設計
テスト技法の適用によるテストケースの
列挙

テスト実装

テスト
実行

テスト
実装

テスト
実施

手動/自動化
テストスクリプト(テスト手順)の記述

引用元：テスト設計チュートリアル ちびこん編 ‘21 資料

15

67ページ

プロセスごとに成果物をつくることを目指す
テストケースを開発成果物と捉えて段階的に詳細化していく必要がある
ソフトウェア開発プロセス
要求の
源泉

ソフト
要求
分析

ソフト
要求仕様
(要求モデ
ル)

ｿﾌﾄ
ｱｰｷ
ﾃｸﾁｬ
設計

ｿﾌﾄ
ｱｰｷﾃｸﾁ
ｬ
ﾓﾃﾞﾙ

ソフト
詳細
設計

ソフト
モジュー
ル
モデル

ソフト
実装

プログラ
ム

ソフトウェア開発プロセス/成果物と、テスト開発プロセス/成果物を対応させてとらえる

テストの
源泉/
テスト
ベース

テスト
要求
分析

テスト
要求仕様
(要求モデ
ル)

ﾃｽﾄ
ｱｰｷ
ﾃｸﾁｬ
設計

ﾃｽﾄ
ｱｰｷﾃｸﾁ
ｬ
ﾓﾃﾞﾙ

テス
ト
詳細
設計

テスト
ケース

テス
ト
実装

テスト手順
(手動/自動化
ﾃｽﾄｽｸﾘﾌﾟﾄ)

テスト開発プロセスとはいえ、いきなりこうはならない・・・

引用元：テスト設計チュートリアル ちびこん編 ‘21 資料

16

69ページ

ファーストステップ：自分たちができることを探す
暗黙のうちに行っている活動
ここを明確に定義する

テストケース
作成

テスト
実行

実は段階があるのに隠れている！
簡単にできることから始めよう。

頭の中から外に出そう→成果物としよう●●●

テスト対象を理解するために描いてみた雑な絵
仕様書を読んだときのつぶやき・思いつきを書いたメモ
メール・チャット・口頭でのやりとりをまとめたもの

普段行なっている「○○テスト」について、
テスト目的を改めて定義してみよう、認識を合わせてみよう
17

現在のテストケースから、一つ前の工程をつくる
テストケースをつくる準備工程を考えてみよう！
● 現在のテストケースで使っているパラメーターをリストにする● 現在のテストケースをグループ分けして、観点を挙げてみる
テストのリバースエンジニアリングに挑戦してみよう！
まずは簡単にできることから始めよう！

18

テストケースのパラメーターをリスト化する

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

199ページ を参照して作成

テストケースのパラメーターをリスト化する

抽象化
してみる

追加してみる

リストにしてみることで、足りないものを追加しやすくなったり、複数のテストで使えるようになるんだね

抽象化することで利用範囲が広がる
話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

20

9ページ を参照して作成

テストケースをグループ分けして、観点を探る

このテストケースで、なにを確認したいのだろう？

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

21

9ページ を参照して作成

テストケースをグループ分けして、観点を探る

イベントに対して状態遷移するか確認したい

表示と実際の温度がずれていないか確認したい

ランプの点灯状態が正しいか確認したい
設定値のとおりにふるまうことを確認したい
話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

229ページ を参照して作成

テストケースをグループ分けして、観点を探る

イベントに対して状態遷移するか確認したい

他にどんなイベントがある？
状態遷移しないイベントはある？

表示と実際の温度がずれていないか確認したい

温度以外になにかある？
タイマー残り時間もありそう

ランプの点灯状態が正しいか確認したい

状態ごとに各ランプの点灯消灯をみたほうがよさそう

設定値のとおりにふるまうことを確認したい

設定を変えたときのふるまいも確認が必要そう

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

23

9ページ を参照して作成

１．テスト設計のプロセスを見直そう

まとめ● テスト設計のプロセスを見直そう○○

テスト設計のプロセスと成果物について学ぼう
現在の自分たちの活動をもとに、テスト設計のプロセスを分けてみよう● 現在のテストケースから、一つ前の工程をつくってみよう○○

パラメータを書き出して、再利用できるようにしよう
テストの意図を書き出して、観点を探れるようにしよう

今できる小さなことから始めてみよう！

24

２．テスト設計成果物の情報が繋がるようにしよう
テスト分析成果物がすでにあるとしたら、テスト設計成果物の情報が繋がるように変えてみよう
うまく繋がるようにするために・・・● 情報を小さい単位で扱おう● 前後の成果物とリンクする情報を載せよう● 繋げるための成果物をつくってみよう● 繋がらないときに、あきらめずに考えよう
前半で、上から三つ目まで解説します！
四つ目は後半で解説するから待っていてね25

テスト分析成果物とテストケースを繋げる成果物をつくる
テスト分析成果物

テストケース
それぞれの関係を示す
成果物をつくる

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

26

9ページ を参照して作成

情報を小さい単位で扱う
テスト分析成果物
扱いやすい単位にする
ことで、後続の成果物に繋げやすくなるそれぞれの過程で小さく分割して、
繋がりやすく作ることも大事だね

センターをプロダクト全体にすると、情報量が多くなり、後続の成果物作成時に取捨選択・詳細化の必要が生じる
話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

27

9ページ を参照して作成

テストケース上に、リンクする情報を載せてみる

要求仕様書の記述

あれ・・・？？
確認したいことと、期待結果にずれが生じている？
テストケースも確認したいことも足さないとだめみたい
Copyright(C)組込みソフトウェア管理者・技術者育成研究会（SESSAME）

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

28

9ページ

及び参照して作成

テスト分析成果物とテストケースを繋げる成果物をつくる

テストケース

繋げる成果物

テスト分析成果物

情報を繋げて考えることで、
テストケースに反映しやすくなったよ！
話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版

29

9ページ を参照して作成

自由に発想したものを捨てる前にもう少し考えてみる

気になることを挙げてみたけれども、ハードウェアで確認することばかりになっちゃった・・
テストしなくて大丈夫かも・ハードウェアやミドルウェアが担うから
・外部システムの範疇だから・フレームワークで対応するから・システム外で対応するから・・・考慮しなくてよいか？？
30

この続きは後半で！

２．テスト設計成果物の情報が繋がるようにしよう

まとめ● 情報を扱いやすい単位で分けてみよう○

後ろの成果物に載せやすくなるまとめ方をしよう● 成果物が繋がるように、前後の成果物とリンクする情報を載せよう○

リンクさせてみた結果、情報がちぐはぐになっていないか
確認しよう● 成果物の繋がりが悪いときは、繋げる目的の成果物を作ってみよう
成果物の作成過程で考えたことを有効活用しよう！

31

３．テスト設計成果物の妥当性を確認してみよう
成果物を作ったら、妥当性を示せるように説明しよう
職場でよく耳にする魔法の言葉たち● 従来通りにしました！
● 仕様に書かれていることを一通りテストケースにしたので、網羅できています！
● テスト実行工数が少ないから、優先順位の高いものから進めて時間の許す限り実行する方針です！
● テストを効率よく実施するために組み合わせ技法を使いました！
32

「Why？」で根拠を見せる

テスト実行工数が少ない用意したテストを全て実行できない
結果として・・・

優先度の高いテストから、時間の許す限り実行していく
結果として・・・

確かに全てのテストを実行するのは無理だけれども・・・
これで本当にいいのかな？

33

Why＋αの問いかけをして検証する
どのくらい少ないのか？

テスト実行工数が少ない

なぜ少ないのか？

優先度はどうやって決めているのか？

用意したテストを全て実行できない優先度の高いテストから、時間の許す限り実行していく

全て実行できなくてもよい根拠があるか？

テスト実行工数が絶対に必要であることを説明して、工数を増やす対策をとったほうがよい場合もあるから、制約事項の妥当性も検証してみよう
34

この結果
どうなるのか？

問いかけを受けて直してみる
納期の都合でテストの工数が2日しか確保できない

1日分のテストを削減する必要がある

優先度の低い画面表
示に関するテストを
実施しない

この結果
どうなるのか？

用意したテストは3日分ある

最初の説明よりも納得度は上がっているけれども、この結果はどうなるのだろう？

35

未来を予測して検証してみる

納期の都合でテストの工数が2日しか確保できない

画面上に必要な注意書きが抜けていた

注意書きは運用時に読む必要がある
記載だった

優先度の低い画面表示に関するテストを実施しなかった

テストで発見できるはずの不具合を見逃した

うーん・・・優先度の決め方がまずいみたい・・・
でもどうしたらいいんだろう？

36

顧客の運用トラブルが発生したWhy＋αの問いかけをして改善してみる
テスト実施以外で対策をとるとしたら何があるだろう？
納期の都合でテストの工数が2日しか確保できない

1日分のテストを削減する必要がある

優先度の低い画面表
示に関するテストを実施しない

画面表示に関する
テストの優先順位が低い理由は？

用意したテストは3日分ある

複数人で考えると様々な気づきが得られるよ！

問いかけにはコツがいるけれども、挑戦して数をこなしてみよう！
37

Why＋αの問いかけをして改善してみる
画面上に必要な注意書きが抜けていた
納期の都合でテストの工数が2日しか確保できない
リリース後に発見されてもすぐに修正可能なアイテム
はテストの優先度を下げる

画面表示に関するテストを実施しない

顧客が注意書きの抜けに気づく

画面表示のチェックを顧客に依頼する

顧客の運用トラブルを回避できる

ステークホルダーに知らせる、
合意する、協力してもらう、という行動で未来を変えられそう。

様々なケース・様々な解決案を考えてみよう！
38

Whyの回答を検証するために、問いを投げかける
検証のための”問い”を投げかけて、より納得がいく回答にする● どうして”従来通り”であれば問題がないのだろうか？
● 仕様に書かれていることの確認で十分なのだろうか？
仕様に書かれたことを確認すると、どんな嬉しいことがあるのだろうか？
● 優先順位に従って実行して、時間切れになったら残りは実行しなくてよいと判断した根拠はなんだろう？
実行しないとその先どんなことが起こるだろうか？それは共有できているだろうか？
● その技法を使うことで嬉しくなるのだろうか？
（使わなくても困らないと思ったりはしないか？）● 指定したパラメーターが適切だと言える根拠は？
39

３．テスト設計成果物の妥当性を確認してみよう

まとめ● テスト設計成果物に対する根拠を明確にしよう○

因果関係で示すことで、根拠を明確にしてみよう● さらに問いかけをして検証することで、より納得がいく説明ができるようにしよう● 未来を予測して問題がおこらないか確認しよう○

望ましくない結果が起こるとしたらどんなことがあるかを考えてみよう● 問いかけをしながら問題点を改善しよう○

複数人で、チームで、いろんな考えをだしてみよう
今よりも説明しやすく、納得してもらえることを目指そう！

40

Whyに答えられない・・・簡潔に説明できない・・・
しかし・・・伝えたつもりがこんな質問が返ってくる・・・
何かテスト少ないね？
テスト多過ぎ…？

過不足ないことを説明するにはどうしたらよい？？

これで必要なテストが揃っているの？

今より納得してもらえるにはどうしたらよい？？

時間がないからパッと見てわかるものがほしいんだけど？

長々と説明せずに簡潔に伝えるにはどうしたらよい？？

41自分のテスト設計の「Why」に対して、短い時間でわかりやすく意図を届けるために、できることはあるだろうか？・・・

後半に続く！

42

後

半

43

ありがちな質問
うまく説明するにはどのような情報が必要か考えてみよう

何かテスト少ないね？
／テスト多過ぎ…？
これで必要なテストが揃っているの？
パッと見てわかるものがほしいんだけど？

44

ありがちな質問
うまく説明するにはどのような情報が必要か考えてみよう

何かテスト少ないね？
／テスト多過ぎ…？

何を全体と考える？
過不足ない？
全体のうちどこまで考える？
テスト間、その背景の仕様間の関係性は？

これで必要なテストが揃っているの？
パッと見てわかるものがほしいんだけど？

45

ありがちな質問
うまく説明するにはどのような情報が必要か考えてみよう
何を全体と考える？

何かテスト少ないね／テスト多過ぎ…

過不足ない？

これで必要なテストが揃っているの？

目的に合っている？

全体のうちどこまで考える？
テスト間、その背景の仕様間の関係性は？
テスト目的は？

パッと見てわかるものがほしいんだけど？

着眼点は？

46

ありがちな質問
うまく説明するにはどのような情報が必要か考えてみよう
何を全体と考える？

何かテスト少ないね／テスト多過ぎ…

過不足ない？

これで必要なテストが揃っているの？

目的に合っている？

パッと見てわかるものがほしいんだけど？

全体のうちどこまで考える？

主なテスト内容は？
どう読み解けば良い？

47

テスト間、その背景の仕様間の関係性は？
テスト目的は？
着眼点は？

ありがちな質問
うまく説明するにはどのような情報が必要か考えてみよう
何を全体と考える？

何かテスト少ないね／テスト多過ぎ…

過不足ない？

これで必要なテストが揃っているの？

目的に合っている？

パッと見てわかるものがほしいんだけど？

全体のうちどこまで考える？

主なテスト内容は？
どう読み解けば良い？

テスト間、その背景の仕様間の関係性は？
テスト目的は？
着眼点は？

テスト目的は事前に合意されているとしても他はテスト担当者が伝える必要がある…

構造を見せるとよいかも？
48

現実には目的の深堀りが必要なケースはあるが後ほど検討する「構造を見せる」とは本講演での定義

本講演では、次の3点を同時に実現することを伝えたいことの「構造を見せる」「構造を可視化する」と表現する

特定の着眼点に基づいて全体像を見せる
どこまで
考える？

着眼点は？
全体は？

構成要素の要点を適切な抽象度で見せる
構成要素同士の関係性を見せる

49

テスト間、仕様間の関係性は？

「構造を見せる」とはイメージを掴んでみよう「ある日の夕食のメニューと必要な食材は何か」という着眼点で構造を可視化
牛肉、えのきだけ、
豆苗、卵
ほうれんそうすき焼き

割下

砂糖、みりん

おひたし

醤油

みそ汁

鰹節

長ねぎ、豆腐
キャベツ

白飯
米

味噌

夕食の全体、その構成要素である料理と食材、要素同士の関係性がわかる
参考：コトバンク「割下」

https://kotobank.jp/word/%E5%89%B2%E4%B8%8B-665774

50

「構造を見せる」とはありがちな状況

ところで、複雑なソフトウェアのテストを複数人で行う場合は説明が難しくなりがち…
様々な
使用状況

多数の
機能、役割

説明しても
伝わりにくい理解に時間がかかる
納得しにくい気にすべきことがたくさん気になることも理解度もバラバラ

議論しにくい前提や得意分野が異なる
経験/立場が異なる人同士工夫して分かりやすく説明しないと、伝わらない※他の改善策として、仕様の複雑さの低減やオンボーディングの工夫なども考えられるが本講演ではテスト成果物の説明にフォーカスする51

「構造を見せる」とは●特定の着眼点に基づいて全体像を見せる●

構成要素の要点を適切な抽象度で見せる●

構成要素同士の関係性を見せる
この3点を同時に分かりやすく見せるには、図表の活用がお勧め

構造を図表で分かりやすく見せてみようということで、後半は4つ目のテスト設計成果物の改善方法について考えていく
1.
2.
3.

テスト設計のプロセスを見直そう
テスト設計成果物の情報がつながるようにしよう
テスト設計成果物の妥当性を「Why？＋α」で確認してみよう

4. テスト設計成果物の中で情報の構造を見せよう52

「構造を見せる」とは

本講演の後半の構造

テ
ス
ト

利
点

方
法

考
慮

ま
と
め

以降の節目のページでは右上の図にてどこを話しているか示します

ありがちな
質問

「構造を見せる」とはとはテストで見せると良い構造

構造を見せる
利点

構造を見せる
方法

テスト自体の
構造

説明が
より容易に

ゼロから
つくる場合

見落としている構造があるかもしれない

テスト対象とその周辺の構造(まだ秘密)

既存の構造がある場合抽象度が期待と違うのかもしれない

2つの利点の関係性53伝わらない時に考慮したいこと

まとめ

より適切な表現方法があるかもしれない

テストで見せると良い構造

と
は

テ
ス
ト

利
点

テスト設計成果物に表現される代表的な情報はテストとそのインプット
よって、見せたい構造は次の2つ● テスト自体の構造● テスト対象とその周辺の構造

54

方
法

考
慮

ま
と
め

テストで見せると良い構造

テスト自体の構造

テストフレーム『テストケースの構造をテスト観点で表したものを「テストフレーム」と呼ぶ』
必要なテスト観点の検討、議論に役立つ

テストコンテナ
各テスト観点をどのテストタイプ、テストレベルなどで扱うか示せる

テストコンテナのモデルを活用すると、左の例のようにプロジェクトで行うテストの全体像を分かりやすく見せられる『』内と図の引用元：テスト設計チュートリアル
テスコン編 '21 資料 23、24、48ページ

55

テストで見せると良い構造 テスト対象とその周辺の構造
IPO(入力、処理、出力)を整理する

申請日
一覧作成処理● 矢印、四角、丸といった図形で表せる

氏名

申請者
一覧

テストで使われる考え方を利用する● テスト対象を⼊⼒調整、貯蔵といった要素で分解した、ゆもつよメソッドの論理的機能構造○ 『⼤村朔平さんの書籍「⼀般システムの現象学」に書かれていたものを、湯本さんがテスト分析のモデルとして改変したものである。』

ソフトウェア要件定義、設計で使われる考え方を利用する● ユースケース図、シーケンス図、など● 次ページから例を見せる『』内の引用元： JaSST'21 Tohoku ゆもつよメソッドワークショップ 仕様書読みとモデル図作成 8ページ
図の引用元：JaSST'15 Tokyo「解決！テストアーキテクチャ設計」 講演資料：「湯本からのコメント」 4ページ

56

テストで見せると良い構造

テスト対象とその周辺の構造の例

枠内は、架空の経費申請システムの仕様である
着眼点「経費申請の状態とその遷移」に基づいて、構造を見せてみよう
申請作成者が申請作成を開始すると、作成中という状態になる。申請作成者は作成を終えたら、申請ボタンを押す。申請ボタンの代わりに一時保存ボタンを押すかEscキーを押すと一時保存処理が実行されるが、状態は変わらず作成中のままである。
申請ボタンを押した時点での予算残高に比べて申請額が高額の場合は所属部門部長承認待ちとなる。予算残高に比べて申請額が同額か少額の場合は所属部門の課長承認待ちとなる。所属部門の課長または所属部門の部長が所属部門承認ボタンを押すと、経理部課長であるAさんまたはBさんによる承認待ちとなる。
AさんまたはBさんが経理部承認ボタンを押すと申請が完了状態となる。
各承認者は、申請に不備を見つけた場合、差し戻しボタンを押す。差し戻した場合、通常は1つ前の状態に戻る。ただし、Aさんが差し戻したとき、または、Bさんが差し戻したときは常に申請者宛となるため、作成中となる。

57

テストで見せると良い構造

テスト対象とその周辺の構造の例

状態遷移図、状態遷移表で表現すると、複雑さや、状態とイベントの関係が俯瞰しやすい
差し戻し

一時保存

所属部門
部長承認待ち所属部門
承認

申請[金額>残高]

作成中

所属部門
承認

申請[金額<=残高]
差し戻し

所属部門
課長承認待ち

経理部課長
承認待ち

経理部
承認

申請完了

差し戻し

状態
イベント

作成中

所属先部門課長承認待ち 所属部門部長承認待ち

経理部課長承認待ち

申請完了

申請[金額<=残高] 所属部門課長承認待ち N/A

N/A

N/A

N/A

申請[金額>残高]

所属部門部長承認待ち N/A

N/A

N/A

N/A

一時保存

作成中

N/A

N/A

N/A

N/A

所属部門承認N/A

経理部課長承認待ち

経理部課長承認待ち

N/A

N/A

経理部承認

N/A

N/A

N/A

申請完了

N/A

差し戻し

N/A

作成中

作成中

作成中

N/A

58

テストで見せると良い構造テスト設計成果物の中で見せたい構造は次の2つ● テスト自体の構造● テスト対象とその周辺の構造○構造を見せた経験が少ない方には、より前のプロセスで行うテスト対象とその周辺の構造の可視化に、まず取り組むことをお勧めする

以降、テスト対象とその周辺の構造をメインに説明する
なお、テスト自体の構造でも使える話は多い
59

構造を見せる利点

説明がより容易に

と
は

テ
ス
ト

利
点

方
法

考
慮

ま
と
め

2つの利点をお話しする。うち、1つ目は、既にお話しした通り
何かテスト少ないね／テスト多過ぎ…
これで必要なテストが揃っているの？
パッと見てわかるものがほしいんだけど？

全体/構成要素と関係性が俯瞰しやすく、着眼点が分かりやすくなり、
説明しやすくなる

利点1

テストの内容や、背景にある仕様をどう理解したかといった

テスト成果物の説明がより容易になる
他には？

60

構造を見せる利点
枠内は、架空の福利厚生申込システムの仕様である
テストを考える情報として、十分だろうか？
画面遷移
ユーザーがログインすると、ホーム画面に遷移する。
ホーム画面には、ホテルと遊園地セットプラン予約、40歳以上がん検診補助申請、申請/予約一覧、通知設定、システム管理、等のメニューがあり、メニューを選択するとそれぞれの画面に遷移する。
ホテルと遊園地セットプランを予約する場合、予約が完了すると予約結果画面に遷移する。40歳以上がん検診補助申請の場合は、申請中に証跡添付画面に遷移して領収書等の画像添付が必要である。証跡を添付後、申請画面に戻って申請ボタンを押す。
申請/予約履歴は一覧形式だけでなく、詳細画面に遷移して申し込み内容を確認することができる。

61

構造を見せる利点
例

架空の福利厚生申込システムの画面遷移図

ログイン
画面

ホーム
画面

ホテルと遊園地
セットプラン予約画面

予約結果画面

40歳以上がん検診
補助申請画面

証跡添付画面

申請/予約
履歴詳細画面

申請/予約一覧画面
通知設定画面システム管理画面…

62

構造を見せる利点
例

架空の福利厚生申込システムの画面遷移図

ログイン
画面

ホーム
画面

ホテルと遊園地
セットプラン予約画面

予約結果画面

40歳以上がん検診
補助申請画面

証跡添付画面

申請/予約
履歴詳細画面

申請/予約一覧画面● 1つ前の画面に戻ることはできない？
● ログアウトはどの画面からできる？
● 40歳以上がん検診補助申請画面とシステム管理画面には全員アクセス可能？

通知設定画面システム管理画面…

63

構造を見せる利点
例

不明点や不足に気付きやすくなる

架空の福利厚生申込システムの画面遷移図

ログイン
画面

ホーム
画面

ホテルと遊園地
セットプラン予約画面

予約結果画面

40歳以上がん検診
補助申請画面

証跡添付画面

申請/予約
履歴詳細画面

申請/予約一覧画面● 1つ前の画面に戻ることはできない？
● ログアウトはどの画面からできる？
● 40歳以上がん検診補助申請画面とシステム管理画面には全員アクセス可能？

通知設定画面システム管理画面

利点2構造を見せると不明点や不足に気付きやすくなる…

64構造を見せる利点

2つの利点の関係性

複雑なソフトウェアのテストを複数人で行う場合にテスト成果物に納得しにくい問題…
様々な
使用状況

多数の
機能、役割

説明しても
伝わりにくい理解に時間がかかる
納得しにくい気にすべきことがたくさん気になることも理解度もバラバラ

前提や得意分野が異なる
経験/立場が異なる人同士65

議論しにくい構造を見せる利点

2つの利点の関係性

複雑なソフトウェアのテストを複数人で行う場合にテスト成果物に納得しにくい問題…
様々な
使用状況

多数の
機能、役割

説明しても
伝わりにくい理解に時間がかかる
納得しにくい気にすべきことがたくさん気になることも理解度もバラバラ

前提や得意分野が異なる構造を見せる

議論しにくい利点1
経験/立場が異なる人同士利点2

全体/構成要素と関係性/着眼点が分かりやすくなる

テスト成果物の説明がより容易に短時間で理解しやすい

不明点や不足に気付きやすい議論しやすい納得しやすい構造を見せる利点が2つ組み合わさると、テスト成果物により納得してもらいやすくなる
66

構造を見せる方法

と
は

テ
ス
ト

利
点

方
法

考
慮

ま
と
め

方法は2つ

● ゼロからつくる○

構造を可視化する過程が学びや気づきに繋がる● 必要な構造が既に可視化されている場合は、活用する○

特にテスト対象とその周辺の構造は、仕様書などに既に可視化された構造が掲載されていることがある○

ステークホルダーに馴染みがある構造を使えると、より説明しやすくなる■

ただし、そのまま使えるとは限らない

67

構造を見せる方法

ゼロからつくる場合

多くの場合、基本的な手順は次の通り
1

どのような着眼点から見た構造を見せるか決める

2

インプットになる情報を収集し必要な要素を抜き出す

3

要素の要点抽出や抽象度の調整を行う

4

要素同士の関係性や位置付けが分かるようまとめる

大雑把にまとめてからインプットの再収集をした方が良い場合など、手順を入れ替えたり繰り返したりする方が効率的・効果的なことがある※手順を知りたい方はJaSST'22 Tokyo 「テストの設計意図を届けよう」資料56-57, 60-65ページもご参考にどうぞ
https://www.jasst.jp/symposium/jasst22tokyo/pdf/C5.pdf
68構造を見せる方法

既存の構造がある場合

既に可視化されている構造がある場合は、積極的に利用を検討しよう
ただし、そのままでは使えず、修正や書き直しが必要なこともある●

確認したいポイント
全体として捉えられている範囲は期待通りか？
構成要素や関係性の記述に過不足はないか？
○○●

抽象度は期待通りか？
○●

例：エラー時の挙動は含まれているか？
着眼点が違う、敢えて書かれなかった、間違いや勘違い、といったさまざまな理由で期待とは異なることがある
例：右図より「数字」「数字以外」に分ければ十分？

入力値
数字

情報が古くないか？

既に可視化された構造は、活用する前に必ず目の前のテスト設計を念頭において見直す
69

伝わらない時に考慮したいこと

と
は

テ
ス
ト

利
点

方
法

考
慮

構造を見せて説明はできたはずなのに、上手く伝わらず納得してもらえない場合、まずは以下を考えてみよう● 見落としている構造があるかもしれない● 抽象度が期待と違うのかもしれない● より適切な表現方法があるかもしれない

70

ま
と
め

伝わらない時に考慮したいこと

と
は

テ
ス
ト

利
点

方
法

考
慮
①

構造を見せて説明はできたはずなのに、上手く伝わらず納得してもらえない場合、まずは以下を考えてみよう● 見落としている構造があるかもしれない● 抽象度が期待と違うのかもしれない● より適切な表現方法があるかもしれない

71

ま
と
め

見落としている構造があるかもしれない
構造

構造を見せるには、着眼点が必要
構造の見落としを防ぐには、着眼点に気づく必要がある

着眼点

必要な着眼点はテストで解決するべき問題によって変わる

テストで解決するべき問題多くの場合、
テストで知りたい情報とも言える

72

見落としている構造があるかもしれない
構造

着眼点

テストで解決するべき問題

テスト目的

テストで解決するべき問題がテスト目的に既にまとまっている
場合は、テスト目的をもとに着眼点を洗い出す
しかし、暗黙知や割愛された前提が潜んでいることもある
テスト目的を読んでもテストで解決するべき問題を十分把握できたか怪しいときには…？

73見落としている構造があるかもしれない
構造

着眼点

テストで解決するべき問題
テスト対象で実現したいこと

テスト目的

発生しそうな
欠陥や故障

テスト目的を読んでもテストで解決するべき問題を十分把握できたか怪しいときには…？

必要な着眼点を見落としにくくするために解決するべき問題の背景を考える●●

ステークホルダーがテスト対象で実現したいことは？
どのような欠陥や故障、問題が発生しそうか？
○ 「リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。」「」内の引用元：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03

74

1.3 テストの 7 原則

見落としている構造があるかもしれない例

架空の福利厚生申込システムの仕様から、テストを考えてみる■ホテルと遊園地のセットプラン予約登録機能
ユーザーは以下を入力して “予約” ボタンを押下する。共通入力項目（すべて入力必須）● 人数（おとな）、人数（こども）… “人数（おとな）” が0の場合、または、合計が16名以上の場合はエラー● 部屋数 …0の場合、10以上の場合、合計部屋数が “人数（おとな）” の数以上の場合はエラー● チェックイン日 …存在しない日付の場合はエラー● チェックアウト日 …存在しない日付、または、チェックイン日以前の場合はエラー● 遊園地チケット種類 …プルダウンによる選択式● 遊園地入場日 …存在しない日付、または、チェックイン日からチェックアウト日の範囲に含まれない日付の場合はエラー
予約ボタンが押されると、本システムでホテルの空室確認と予約登録を行う。遊園地の空き確認と予約
登録は遊園地予約システムにて行い、予約結果として画面表示する。予約結果画面の “ホーム” ボタンを押すと、ホーム画面に戻る。
■ホテルと遊園地のセットプラン予約キャンセル機能
申請/予約一覧画面から予約情報を選択した上で”詳細”ボタンを押し、遷移した申請/予約履歴詳細画面
で ”キャンセル” ボタンを押すことにより、キャンセルできる。結果は申請/予約履歴詳細画面に表示される。ホテルのキャンセルは本システムで行い遊園地予約システムにもキャンセル依頼を送信する。
キャンセルは、ホテルチェックイン日の1週間前まで可能である。
75

見落としている構造があるかもしれない

例

別のドキュメントやヒアリングでの調査も踏まえて画面遷移図を書いてみた（関係部分のみ、[ ]内はリンクまたはボタンの名称）
[ホーム]

[ホーム]

ホーム画面

ホテルと遊園地[ホテルと遊園地 セットプラン予約画面[予約]

予約結果画面

セットプラン予約][一覧][申請/予約一覧]

申請/予約一覧画面
[ホーム]

76

予約情報を
選択して[詳細]

申請/予約履歴詳細画面[キャンセル]見落としている構造があるかもしれない

例

仕様の文章、画面遷移図から、テストを考えてみる
❏
❏
❏
❏
❏
❏
❏
❏
❏
❏

…
すべての入力項目に有効な値を入力して予約ボタンを押すと予約登録できること
入力項目のうち1つでも無効な入力があると、予約登録できないこと…
ホテルチェックイン日の1週間前にセットプランのキャンセルできること
ホテルチェックイン日の1週間前の日の翌日に予約をキャンセルできないこと…
ホーム画面で”申請/予約一覧”を押すと、申請/予約一覧画面に遷移すること
予約結果画面で “ホーム” ボタンを押すと、ホーム画面に遷移すること…

テストできそう！

…でも、これだけで十分？
77見落としている構造があるかもしれない

例

更に考えてみる●●

このシステムで実現したいことは、何だろう？
○ ホテルと遊園地を同時に予約登録・キャンセルできること○ …
このシステムで問題が発生するとしたらどんな問題だろう？
○ ホテルと遊園地のいずれか片方しか予約登録・キャンセルできないとユーザーが困りそう○ …

片方しか予約登録・キャンセルできずにユーザーが困ることがないか、考えてみよう！

78見落としている構造があるかもしれない

例

更に考えてみる●●

このシステムで実現したいことは、何だろう？
○ ホテルと遊園地を同時に予約登録・キャンセルできること○ …
このシステムで問題が発生するとしたらどんな問題だろう？
○ ホテルと遊園地のいずれか片方しか予約登録・キャンセルできないとユーザーが困りそう○ …

片方しか予約登録・キャンセルできずにユーザーが困ることがないか、考えてみよう！

予約登録・キャンセルには、仕様に登場する次のシステムが関与するはず●●ホテルの予約とキャンセルの処理を行うシステム
遊園地の予約とキャンセルの処理を行うシステム…福利厚生申込システム(テスト対象)…遊園地予約システム

2つのシステム間の関係性を含む構造を可視化して、考えてみよう
79見落としている構造があるかもしれない

例

ユーザー、システム、連携先システムの関係性の構造を可視化すると登場人物が整理できるが、それだけ？ 他に読み取れることは？

福利厚生申込システム(テスト対象)
端末

ホテル
予約DB

80

遊園地予約システム

遊園地
予約DB

見落としている構造があるかもしれない

例

ユーザー、システム、連携先システムの関係性の構造を可視化すると登場人物が整理できる
また、登場人物同士の間で起こる問題を考えやすくなる

福利厚生申込システム(テスト対象)
端末

ホテル
予約DB

やりとりできなくなったら
どうなる？

81

遊園地予約システム

遊園地
予約DB

見落としている構造があるかもしれない
時系列の構造を可視化と流れが分かりやすくなる…が、それだけ？ 他に読み取れることは？
ユーザー

福利厚生
申込
システム
(テスト対象)

キャンセル
をする
予約情報を
取得する

結果を確認
する
キャンセル期限前か確認する
遊園地のキャンセルを
依頼する

遊園地予約
システム

82

ホテルを
キャンセル
する

結果を表示
する

遊園地を
キャンセル
する

結果を送信
する

見落としている構造があるかもしれない

例

時系列の構造を可視化すると流れが分かりやすくなる他、期限到来や処理の割込みを考えやすくなる
ユーザー

福利厚生
申込
システム
(テスト対象)

キャンセル
をする
予約情報を
取得する

依頼処理が期限に間に合わなかったら？

結果を確認
する
キャンセル期限前か確認する
遊園地の
キャンセル
を依頼する

遊園地予約
システム

83

ホテルを
キャンセル
する

結果を表示
する

遊園地を
キャンセル
する

結果を送信
する

見落としている構造があるかもしれない

例

時系列の構造を可視化すると流れが分かりやすくなる他、期限到来や処理の割込みを考えやすくなる
ユーザー

キャンセル
をする

福利厚生
申込
システム

予約情報を
取得する

(テスト対象)依頼処理が期限に間に合わなかったら？

結果を確認
する
キャンセル期限前か確認する
遊園地の
キャンセル
を依頼する

遊園地予約
システム

ホテルを
キャンセル
する

結果を表示
する

遊園地を
キャンセル
する

結果を送信
する

構造を元に考えた結果、追加したいテストが見つかった！
●●

予約登録処理中またはキャンセル処理中に遊園地予約システムに予約情報を送れなくなった場合のテスト
キャンセル処理中にキャンセル可能期間を超えてしまった場合のテスト
84見落としている構造があるかもしれない
必要な構造の見落としを減らすために、できること

見落とし
を減らす
ために
更に上手く
伝える
ために

解決すべき問題とその背景を知る

ステークホルダーが実現したいことは？

発生しそうな欠陥や故障は？

問題にふさわしい着眼点を探し、構造を可視化する
発想を広げ、構造からできるだけ多くを読み取るとよい
モブ作業、過去の欠陥情報や規格などを活用して発想を広げる85

余談 実現したいことや発生しそうな欠陥や故障が繋がらない場合
前半の「自由に発想したものを捨てる前にもう少し考えてみる」の説明

実現したいことや発生しそうな欠陥や故障をはじめとして、気づいたことが目の前のテストと繋がらないように見えることがある、例えば…
●

システム以外からの受付により、上限を超えて予約登録されることはないか○調査したところ、他の手段による影響は考えなくてよいとのこと。忘れて良い？
福利厚生申込システム(テスト対象)
端末

●

ホテル
予約DB

遊園地予約システム

電話等？

すぐに諦めずに、一度深堀りしてみよう○

気になることの要点は、予約数が上限を超えることがないかどうか■ 上限を超えるかもしれない状況はないか？
86

遊園地
予約DB

余談 実現したいことや発生しそうな欠陥や故障が繋がらない場合
気づいたことが一見、目の前のテストに関係ないように見える場合に試したいこと● 気になったことの要点を問い直して適用を試みる○●

前ページの例の通り

特にソフトウェアの要件や仕様を検討する場面では、

ソフトウェアがサポートできることを考える
例

ポットが倒れた場合にお湯が漏れると危険■

ポットが傾いたら、ソフトウェアで蓋を自動ロックできないだろうか？

気になったことは問い直したり角度を変えて考えたりして、できるだけ活用を87

伝わらない時に考慮したいこと

と
は

テ
ス
ト

利
点

方
法

考
慮
②

構造を見せて説明はできたはずなのに、上手く伝わらず納得してもらえない場合、まずは以下を考えてみよう● 見落としている構造があるかもしれない● 抽象度が期待と違うのかもしれない● より適切な表現方法があるかもしれない

88

ま
と
め

抽象度が期待と違うのかもしれない構造を見せる際のポイントの1つ、適切な抽象度にするために気をつけたいこと
抽象度の
検討時

テスト分析の早い段階では広い範囲に対する構造を扱う●●

段階的に詳細化や具体化をすると大きな見落としを回避しやすくなる
全体を俯瞰してポイントを絞ってから無駄なく詳細の調査ができる

89

抽象度が期待と違うのかもしれない構造を見せる際のポイントの1つ、適切な抽象度にするために気をつけたいこと
抽象度の
検討時

テスト分析の早い段階では広い範囲に対する構造を扱う●●

段階的に詳細化や具体化をすると大きな見落としを回避しやすくなる
全体を俯瞰してポイントを絞ってから無駄なく詳細の調査ができる

抽象度のバラつきに注意
構造
(図表)の
可視化
作業中

●
●
●

例：画面遷移図に遷移と直接関係しない画面表示の細かな仕様を載せる…着眼点が分かりにくくなる、画面と遷移より細部が気になる
例：アルファベット／”&”／記号 …“記号”とは？
抽象度が違う内容も含め、いろいろ発想すること自体は有益○ 後から見るメモや別の構造など、記録先は検討する

90

抽象度が期待と違うのかもしれない構造を見せる際のポイントの1つ、適切な抽象度にするために気をつけたいこと
抽象度の
検討時

テスト分析の早い段階では広い範囲に対する構造を扱う●●

段階的に詳細化や具体化をすると大きな見落としを回避しやすくなる
全体を俯瞰してポイントを絞ってから無駄なく詳細の調査ができる

抽象度のバラつきに注意
構造
(図表)の
可視化
作業中

説明する
時

●
●
●

例：画面遷移図に遷移と直接関係しない画面表示の細かな仕様を載せる…着眼点が分かりにくくなる、画面と遷移より細部が気になる
例：アルファベット／”&”／記号 …“記号”とは？
抽象度が違う内容も含め、いろいろ発想すること自体は有益○ 後から見るメモや別の構造など、記録先は検討する

相手に応じて説明にどの構造を使うか考える●

相手の関心事と前提知識を確認、推測し、使う構造とその順序を考える○ マネージャーとテストチームメンバーでは関心事は違うだろう91伝わらない時に考慮したいこと

と
は

テ
ス
ト

利
点

方
法

考
慮
③

構造を見せて説明はできたはずなのに、上手く伝わらず納得してもらえない場合、まずは以下を考えてみよう● 見落としている構造があるかもしれない● 抽象度が期待と違うのかもしれない● より適切な表現方法があるかもしれない

92

ま
と
め

より適切な表現方法があるかもしれない

例

枠内は架空のECサイトの割引についての仕様だが、分かりにくい
前月購入1万円以上のクラスAの会員が毎月10日の0:00から14:59までに購入した場合は1.0割引
前月購入1万円未満のクラスAの会員が毎月10日の0:00から14:59までに購入した場合は0.7割引
前月購入1万円以上のクラスBの会員が毎月10日の0:00から14:59までに購入した場合は0.7割引
前月購入1万円未満のクラスBの会員が毎月10日の0:00から14:59までに購入した場合は0.5割引
前月購入1万円以上のクラスCの会員が毎月10日の0:00から14:59までに購入した場合は0.5割引
前月購入1万円未満のクラスCの会員が毎月10日の0:00から14:59までに購入した場合は割引なし
前月購入1万円以上のクラスAの会員が毎月10日の15:00から23:59までに購入した場合は1.5割引
前月購入1万円未満のクラスAの会員が毎月10日の15:00から23:59までに購入した場合は1.0割引
前月購入1万円以上のクラスBの会員が毎月10日の15:00から23:59までに購入した場合は1.0割引
前月購入1万円未満のクラスBの会員が毎月10日の15:00から23:59までに購入した場合は0.7割引
前月購入1万円以上のクラスCの会員が毎月10日の15:00から23:59までに購入した場合は0.7割引
前月購入1万円未満のクラスCの会員が毎月10日の15:00から23:59までに購入した場合は0.5割引
前月購入1万円以上の会員が毎月20日に購入した場合は0.5割引
前月購入1万円未満の会員が毎月20日に購入した場合は割引なし
毎月15日と最終日以外の日の購入の場合は割引なし
93より適切な表現方法があるかもしれない

例

架空のECサイトの割引の仕様の構造を可視化してみた
購入日時など、いくつかの条件により割引率が決まるらしいことはわかるが、条件の全体像や条件同士の組み合わせの規模は分かりやすいだろうか？
1.5割引…
前月購入1万円未満

条件に応じて
割引率が
変わること

1.0割引

会員クラスA

毎月10日15:00から23:59まで

会員クラスA

毎月10日0:00から14:59まで

会員クラスB

毎月10日15:00から23:59まで

前月購入1万円未満

会員クラスA
会員クラスB

毎月10日0:00から14:59まで
毎月10日15:00から23:59まで

前月購入1万円以上

会員クラスB
会員クラスC

毎月10日0:00から14:59まで
毎月10日15:00から23:59まで

前月購入1万円以上

0.7割引

0.5割引

…

なし

…
94

より適切な表現方法があるかもしれない

例

こちらの方が、条件の全体像や条件同士の組み合わせの規模を確認しやすい
1

2

3

4

5

6

7

8

9

10

0:00-14:59

Y

Y

Y

Y

Y

Y

N

N

N

N

15:00-23:59

N

N

N

N

N

N

Y

Y

Y

Y

終日

N

N

N

N

N

N

N

N

N

N

上記以外の日 終日

N

N

N

N

N

N

N

N

N

N

会員クラス

A

A

B

B

C

C

A

A

B

B

前月購入金額 前月購入1万円以上である

Y

N

Y

N

Y

N

Y

N

Y

N

1.5割

-

-

-

-

-

-

X

-

-

-

1.0割

X

-

-

-

-

-

-

X

X

-

0.7割

-

X

X

-

-

-

-

-

-

X

0.5割

-

-

-

X

X

-

-

-

-

-

なし

-

-

-

-

-

X

-

-

-

-

条件 購入日時

毎月10日

毎月20日

動作 割引

95

より適切な表現方法があるかもしれない
適さない表現方法で構造を可視化した場合の弊害● 意図や全体像が分かりにくい○●

何が書かれているか全部を事細かに確認するまで分からない

要素間の関係性が表現しきれない○

包含関係、順序関係など関係性が読み取りにくくなることがある構造に適した考え方や表現方法を選ぶのが大事、そのためには…
着眼点を明らかにし、絞りこむ

学び、選択肢を増やす

一言で言うと？ 目的から見て考えるべきは？

テストだけでなく1つの構造にフロー、多重度など複数を詰め込むより、着眼点を絞った方が容易

ソフトウェアの要件定義や設計の考え方、各種図表などの表現方法を知っておく

学ぶと着眼点を明らかにしやすくなり、着眼点を意識すると学びやすくなる96

後半のまとめ

と
は

テ
ス
ト

テスト設計成果物の改善方法のひとつ、「テスト設計成果物の中で情報の構造を見せよう」を考えてきた
point1構造を分かりやすく見せることで…
説明がより容易になる
不明点や不足に気付きやすくなる
point2

うまく伝わらない場合に…
見落としに注意
ー実現したいことと、発生しそうな欠陥や故障を考えるー

抽象度に注意表現方法に注意
97

利
点

方
法

考
慮

ま
と
め

本講演全体のまとめ
テスト設計成果物の改善方法を紹介しました
実践や学びのきっかけにしていただければと思います

1.
2.
3.
4.

テスト設計のプロセスを見直そう
テスト設計成果物の情報がつながるようにしよう
テスト設計成果物の妥当性を「Why？＋α」で確認してみよう
テスト設計成果物の中で情報の構造を見せよう
実践や学びの場としてテスト設計コンテストの参加、予選・決勝戦の見学、説明会・チュートリアルの参加をご検討いただればU-30審査員一同とても嬉しいです
情報は公式サイトから http://www.aster.or.jp/testcontest/index.html

テストの設計意図を届けて、より良いテスト・プロダクトを目指しましょう！
98参考文献と引用文献

99

参考文献と引用文献：前半
いずれも、本書作成時点の情報である
前半●

JaSST’22 Tokyo テスト設計コンテスト U-30クラス セッション「テストの設計意図を届けよう 〜テストケース・テストスクリプトだけ渡していませんか？」○●

テスト設計チュートリアル ちびこん編 '21 資料○●

https://www.jasst.jp/symposium/jasst22tokyo/pdf/C5.pdf

http://www.aster.or.jp/business/contest/doc/2021_chibicon_V1.0.0.pdf

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版
Copyright(C) 組込みソフトウェア管理者・技術者育成研究会（SESSAME）○

以下からダウンロード可能である
https://www.sessame.jp/workinggroup/WorkingGroup2/POT_Speciﬁcation.htm●

TOCによる学習のつながり ～学習内容の分析・解釈・応用に使う「ちゃんと考える」ための道具～（教育のためのTOC国際認定プログラム 公式テキストブック）●

岸良裕司・きしらまゆこ(著), 考える力をつける3つの道具, ダイヤモンド社,2014年
100参考文献と引用文献：後半
いずれも、本書作成時点の情報である
後半(1/2)●JaSST’22 Tokyo テスト設計コンテスト U-30クラス セッション「テストの設計意図を届けよう 〜テストケース・テストスクリプトだけ渡していませんか？」○●@IT 「問題解決力」を高める思考スキル（4）
理する
○

●

https://atmarkit.itmedia.co.jp/ait/articles/0311/29/news004.html

https://en.wikipedia.org/wiki/IPO_model＠IT 明日から使えるシステム開発プロジェクトの進め方 再入門（4） 基本設計をスムーズに進めるための5つのポイント――要件定義書の読み合わせ、データ構造、IPO、外部接続「設計のゴールは各機能でのIPO（INPUT→PROCESS→OUTPUT）の決定」○●

構造化：全体像を見極め、構成要素を整英語版Wikipedia IPO model○●

https://www.jasst.jp/symposium/jasst22tokyo/pdf/C5.pdf

https://atmarkit.itmedia.co.jp/ait/articles/1510/27/news012_3.html

秋山 浩一 (著), ソフトウェアテスト技法ドリル【第2版】
科技連出版社,2022年
101

テスト設計の考え方と実際, 日参考文献と引用文献：後半
いずれも、本書作成時点の情報である
後半(2/2)●(2021年版) ソフトウェアテストの上流設計-4 テスト分析と論理的機能構造○●

JaSST'21 Tohoku ゆもつよメソッドワークショップ○●

http://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-1-3.pdf

http://jasst.jp/symposium/jasst15tokyo/pdf/B2-3.pdf

テスト設計チュートリアル テスコン編 '21 資料○●

仕様書読みとモデル図作成

JaSST'15 Tokyo「解決！テストアーキテクチャ設計」 講演資料：「湯本からのコメント」○●

https://note.com/yumotsuyo/n/nccd9f9600564

http://www.aster.or.jp/business/contest/doc/2021_tescon_V1.0.0.pdf

ISTQBテスト技術者資格制度
2018V3.1.J03○

Foundation Level シラバス 日本語版 Version

https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

102