テスト設計コンテスト’23
決勝プレゼンテーション資料

考えるアシカ予選(第1回レビュー)からの主な変更点● テストアーキテクチャの見直し● リスク分析の方法を見直し○ 『起こってほしくないこと』と『起こさないためのアプローチ』を具体化○ ChatGPTを用いたリスク抽出● ChatGPT × 意地悪漢字を用いたテスト要求抽出● テスト詳細設計以降の検討
2

チームの位置付け
園内チケットシステムの開発
開発を依頼
だんだん開発だんだん動物園
納入
・開発完了
報告書提出

Webチケットシステムの開発
開発を依頼
DEAN2開発

決済システム利用
QAチーム

だんだん開発の一人目 QAとして、テストを担当
予算の都合上、テストは外注せずに開発者も含めて内部で完結させたい。

ソフトウェア
テストのコンサルテーション

決済サービス提供企業

ASTER社3

背景(想定)● 本プロジェクトは予算の都合上、だんだん開発のQAと開発者でテストを行う● 各サブシステムを結合した状態でのテストは、限られた期間でしか行うことができない○

園内チケットシステムとWebチケットシステムはそれぞれ別のベンダーで開発されており、同時に開発が進められている● だんだん市の補助金申請期限が予め決まっている○

入場者が「密」にならないための入場規制が行えていることを示す開発
完了報告は申請期限に間に合うよう提出する必要がある● なにより、入園者に1日も早く「安心安全」に動物園を楽しんでもらいたい4

テストプロセスの全体像
テストベース
テストベーススコープ

リスク

ステークホルダの期待・ニーズ

ユースケース

テスト
要求分析
テスト計画書テスト
アーキテクチャ

テスト
計画

テストケース

テストアーキテクチャ
設計

テスト
詳細設計

5

マネジメント的テスト要求

テスト要求分析 - プロセス
テスト要求を多面的に捉えることを意識テストベース
テストベース

テスト計画

テストスコープの識別
テストに対する期待・不安

ステークホルダの識別

利用者以外のステークホルダ

ニーズの洗い出し

利用者
RDRAによるシステムの目的・業務ユースケースの抽出

業務ユースケース

UMLによる作り(How)の理解

シーケンス図意地悪漢字をガイドワードとして用いた生成AIによるテスト要求の抽出システムに対するニーズの深掘り

エンジニアリング的テ
スト要求

生成結果

エンジニアリング的テスト要求
6テスト要求分析 - ステークホルダの洗い出し
以下のような流れでステークホルダとその要求を洗い出していった● どんなステークホルダがいるか？
● そのステークホルダの立場や役割は？
● その役割からみたシステムやテストの期待や不安は？

得られたテスト要求は、「マネジメント的テスト要求」として、テストアーキテクチャへの反映を行なった

7

テスト要求分析 - RDRAによるモデリング
業務ユースケース

RDRA2.0は要件定義を行うためのフレームワーク。
システム化の目的から業務の内容、それを駆動するための情報を段階的に詳細化しながらモデルで表現できる。

⭕メリット・効果●
仕様書の書き方によらない理解●
機能間の関連を意識したテスト要求の抽
出●後のテストアーキテクチャでの活用によるテスト設計成果物の一貫性への寄与駆動するためのデータ

ユースケース複合図(業務フローつき)の一部❌デメリット●システムの設計方法など Howは関心事として扱わない

8

テスト要求分析 - システムの作りを理解
RDRAで表現されないシステムの作り (How)を理解するため、UML(シーケンス図 )を作成！

⭕メリット・効果●システム構成要素間のデータの流れ・タイミングを図示したことで、テスト対象への理解が深まった●
将来的な拡張を見据えた時のボトルネックとなりうる箇所を推測するのに役立った❌デメリット●
UMLにより直接的にテスト要求が抽出できるわけではない

作成したシーケンス図の一部

9意地悪漢字をガイドワードとして⽤いた⽣成AIによるテスト要求の抽出
鈴木 三紀夫氏の『意地悪漢字』 [*1]をガイドワードとして与え、生成AIによるテスト要求の抽出を実施。(モデルはGPT4)使用したプロンプト
意地悪漢字という考え方があります。
意地悪漢字は、テスト設計において、意地悪テストを考える時のガイドワードとして利用することができます。
意地悪漢字を用いて、システムの欠陥を見つけるためのテストケースを作ってください。
結果には選択した意地悪漢字、テストケースの概要、根拠を箇条書きで10個あげてください。
根拠には必ず意地悪漢字の一文字が含まれるようにしてください。
意地悪漢字としては以下が挙げられます。
- 落、除、捨、解、略、欠- 止、失、無、滅、消、廃- 稀、異、違、不、未、誤- 降、急、延、退、遅、縮- 壊、切、減、衰、断、禁- 飛、移、隠、乱、散、迷- 間、中、外、周、端、限- 戻、代、替、変、再、返- 共、連、続、合、同、交- 別、分、割、離、脇、入- 優、特、過、極、越、超- 全、片、独、差、微、満*1 鈴木 三紀夫: 意地悪漢字, JaSST2010 Hokkaido
対象となるシステム・機能は次のとおりです。
{テストベースの内容を記述する}

10

意地悪漢字をガイドワードとして⽤いた⽣成AIによるテスト要求の抽出
生成結果例(一部)⭕メリット・効果●
テスト設計初学者が、テスト条件を抽出するための参考にできる●経験者でも漏れていたテスト条件に気づくことがある❌デメリット●
出力結果をそのまま活用することはできない●
数撃って当てる必要がある

具体例を示してもらえることで、漢字1文字よりは発想を広げやすい1. 漢字: 欠- テストケース: メールアドレスやパスワードに必要な文字が欠けている場合のログイン試行- 根拠: 欠けた情報の扱いを確認する
2. 漢字: 無- テストケース: ログイン時にメールアドレスやパスワードを無入力にする- 根拠: 無入力状態の扱いをテストする
3. 漢字: 誤- テストケース: 会員情報と異なる誤ったメールアドレスやパスワードでのログイン試行- 根拠: 誤入力時のシステムの反応を確認する(〜中略〜)
6. 漢字: 限- テストケース: 同時ログイン試行者数がシステム限界を超えた場合- 根拠: システムの負荷耐性をテストする
7. 漢字: 消- テストケース: システムから会員情報が突然消えた場合の対応- 根拠: データ損失時のエラー処理を検証する
8. 漢字: 間- テストケース: 時間枠の間に変更が生じた場合のシステム対応- 根拠: 時間枠更新時のデータ処理を確認する
9. 漢字: 超- テストケース: 入場券の購入枚数が許容枚数を超えた場合- 根拠: 超過状況でのシステムの制限を検証する
10. 漢字: 変- テストケース: 会員情報（メールアドレスやパスワード）が頻繁に変更される場合- 根拠: 情報変更頻度が高い場合のシステムの安定性を検証する

11

リスク分析

リスクはテストベースからだけでなく、UMLや生成AIからも多面的に抽出想定されるリスクを次の4つに分類。
リスクがどのような影響を及ぼすのかを一目でわかるように！
●事業におけるリスク→ 売上や利益など●運用におけるリスク→ 動物園スタッフなど●利用におけるリスク→ 動物園の入園者など●
セキュリティにおけるリスク

リスクの軽減策は『テストに盛り込んだり、強化する』だけでなく、設計へのフィードバックを行うことで、より早いタイミングでのフィードバックを実現！

12応⽤HAZOPのガイドワードを⽤いたリスク項⽬の抽出
多面的な視点でリスク分析を進める
ため、生成 AIに応用HAZOPのガイドワード[*2]をプロンプトとして与え、リスク項目の抽出を試行。 (モデルはGPT4)使用したプロンプト
まずは、次のテーブルを読み込んでください。
|着目点1|着目点2|ガイドワード||---|---|---||振る舞いそのもの|有無|全く〜しない||振る舞いそのもの|程度|強く、弱く||振る舞いそのもの|速度|急いで、ゆっくり||振る舞いそのもの|持続時間|ずっと、短く||振る舞いそのもの|範囲|余分に、不十分に||振る舞いそのもの|向き|反対に、他に||振る舞いそのもの|種類|違う||振る舞いそのもの|タイミング|遅く、早く、同時に||振る舞いそのもの|タイミング|別々に||振る舞いそのもの|順序|前に、抜かして、後に||振る舞いそのもの|順序|余分に、繰り返し、反対に||振る舞いそのもの|回数|多く、少なく||振る舞いの対象|対象物|違うものに||振る舞いの対象|対象物の向き|反対に||振る舞いの対象|対象物の量|多く、少なく、なし|
このテーブルはソフトウェアのリスク項目を洗い出すためのガイドワードです。
このガイドワードを用いて、与えられた使用から推測されるリスク項目を洗い出してください。
定義されたガイドワードは許可なくあなたが変更することはできません。
仕様から読み取ることで想定できるリスクについては列挙する必要はありません。
仕様に明示されていないリスクを洗い出すことが今回の目的です。

*2: 河野 哲也: ソフトウェア要求仕様におけるHAZOP を応用したリスク項目設計法, JaSST2012

抽出したリスク項目を箇条書きにして出力してください。
より多くのリスクを抽出できるよう努力してください。
各リスク項目の出力結果には、次の3点を記述するものとして、指定された出力は行わないように注意ください。
- ガイドワードから導出したリスク項目- 選択した着目点1, 着目点2, ガイドワード(必ずガイドワードを記載すること)- リスクを抽出した理由
仕様は後ほど与えられますので、まずは処理内容を理解してください。
この内容に対して意見はいりません。

13

応⽤HAZOPのガイドワードを⽤いたリスク項⽬の抽出使用したプロンプト
EH-220 入場時間枠選択の仕様を基にリスク項目を洗い出します。以下は、リスク項目とそれに関連する着目点、ガイドワード、およびリスクの抽出理由です。

既に人手によりリスク項目として抽出済みであったが、有効な視点

1. リスク項目: 残数情報の表示誤り- 着目点: 振る舞いそのもの、程度- ガイドワード: 強く、弱く- 理由: 残数が正確に表示されない場合、入場者は誤った判断をする可能性があり、これは入場チケットの誤購入や混乱を引き起こす可能性があります。
2. リスク項目: 残数情報の更新遅延- 着目点: 振る舞いそのもの、タイミング- ガイドワード: 遅く、早く- 理由: 情報更新が遅れると、入場者が利用可能な時間枠を正確に把握できず、適切な時間枠の選択に影響を与える可能性があります。

生成AIのみで完結することは難しいものの、発想を広げる目的としては有効活用できる！

(〜中略〜)
5. リスク項目: 残数表示「〇」「数字」「x」「ー」の不適切な切替- 着目点: 振る舞いそのもの、タイミング- ガイドワード: 遅く、早く- 理由: 残数表示の切替が適切なタイミングで行われない場合、入場者が誤った情報に基づいて決定を下す可能性があります。
これらのリスク項目は、仕様に明示されていないが、ガイドワードを用いた分析により抽出されたものです。発券機の運用において、これらのリスクを考慮し、適切な対策を講じることが重要です。

14

⽣成AIをテスト活動に⽤いる場合の考慮点 - リスク分析の例
テスト要求
テストベース

応用HAZOPのガイドワード

出力の偏りを抑止するためにガイドワードを与えてあげる(人間による)リスク抽出(ChatGPTで)HAZOPガイドワードによるリスク抽出

まずは人間が考えてみる(ChatGPTが抽出した)
リスク項目(人間が抽出した)
リスク項目

足りない視点があったら、受け入れてマージする(人間による)
ChatGPTで抽出したリスク項
目の選定・
人間が抽出したリスク項目のマージ(最終的な)
リスク項目

15

テストアーキテクチャ設計
テストアーキテクチャにおいて考慮したこと●●●

システム構成要素間でのコミュニケーションの問題を事前に洗い出す
入場規制に関わる機能が実現できていることを早期に示す
実施に時間のかかるロングランテストを早期に実施する

ピンクで網掛けしたテストコンテナ●
最優先で実施するコンテナ
イエローで網掛けしたテストコンテナ●
状況に応じて実施の順序の変更や実施不要の判断に倒すことを検討するコンテナ
ブルーで網掛けしたテストコンテナ●
優先度は低いが、システムとしての完成度を高めるために実施すべきテストコンテナ

16

テストアーキテクチャ設計(コンテナ図)
テストコンテナの責務がわかりやすくなるよう詳細化

17

テストアーキテクチャ設計(詳細図)

テストアーキテクチャ と、実装結果であるテストケース との間で、テストの意図が途切れないようにするために、テストアーキテクチャの要素毎に テストアーキ
テクチャ詳細図 を作成していった

18

探索的テストのアプローチ(1)
入場規制に関する機能やリスクとして抽出されたことのテストを強化するために、テス
トチャータを用いた探索的テストを実施

19

探索的テストのアプローチ(2)ユーザの特性（せっかち、のんびり、間違いやすいなど）を意識した探索的テストを実施

20

テスト詳細設計

将来的にテスト管理ツールへの移行も視野に管理しやすいスプレッドシート形式にした

21

仕様における問題点‧曖昧さの検出とフィードバック
リスクに該当しない仕様書の誤記や、振る舞いとして曖昧な点についてフィードバックを行なった

22

ツール選定におけるアピールポイント
複数人でテスト開発したり、履歴を管理することも想定したツールを選定

テスト設計成果物

Markdownで記述し、GitHubで管理テキストデータで扱うため、差分がわかりやすく、複数人での開発時はPRを活用したテスト開発も可能

RDRAモデル

Miroで作成

シーケンス図mermaid(Markdown)で記述し、GitHubで管理要求分析モデル

MindMupで作成

テストアーキテクチャ
テストケース

同期的な編集は不向きであるが、他のマインドマップツールとの互換性や、draw.io + mermaid(Markdown)で作成し、GitHub
クラウドストレージでの管理のしで管理やすさを考慮

Google スプレッドシートで作成
23

まとめ

● 多面的な視点でテスト要求を抽出できた● テスト設計の意図を各成果物間で途切れさせないよう、テスト要求分析からテスト詳細設計までの繋がりを意識した表現方法を目指した● 生成AIをテスト設計に活用するための具体案を示せた24

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

テスト設計をしていて面白い！と思えるテストベースを提供くださった実行委員・関係者の皆様ありがとうございました！

25