テスト設計コンテスト’21

TESUMAME

テス豆のテスト設計のご提案
Version: 2.0

チーム名：テス豆1

目次■ はじめに■ テストの全体像■ テスト計画■ テスト要求分析■ テストアーキテクチャ設計■ テスト詳細設計■ テスト実装■ テスト実行の結果■ 自動化による効果

2

はじめに（１）■ 背景
QFユーザからの問い合わせが増加に伴い、QF開発チームは機能アップデートしてリリース頻度を増加する必要がある。

頻繁に機能アップデートすると、「テスト範囲」や「消化すべきテスト回数」が増える。これにより、テストにかけるべき時間が増える。

手動テストのみではテストできる時間は限界があるので、本来必要なテストにかける時間が確保できず、十分なテストができなくなる。

「十分なテストができない」とQFに埋め込まれた欠陥の除去が十分にできずに、品質が悪い状態でQFをリリースしてしまう。

この結果、QF開発チームの開発効率の低下するため、頻繁なアップデートができなくなる可能性がある。
3

はじめに（２）■ 課題■ 十分なテストをするために「テスト実装とテスト実行」にかかる■「時間と金額」を削減できるようにテスト自動化する必要がある
殺虫剤のパラドクス等も考慮してテストケースやテストスクリプ
ト等は定期的に修正する必要がある■ 提案■ 手動テストと自動テストのテスト活動の時間を比較して、自動化■■■の費用対効果が良いテストを自動化する
自動テストを動かすためにテスト環境の構成要素とそれらの関係を決める
十分なテストができるように、テスト間の依存関係やテスト実行の効率が良くなるようにテスト実行の順序を決める
テストスクリプトの作成および修正にかかる時間を短くするためデータ駆動テストアプローチを適用する■ うれしいこと■ テストにかかる時間を削減できる■ 十分なテストができるようになる
4

はじめに（３）■ 費用対効果■ 費用■ テスト活動に関わる人数 × テスト活動に必要な時間 × 時給
■ テスト活動に必要な時間■

テスト環境アーキテクチャ設計の時間■

テスト環境の実装の時間■

自動テストスクリプト作成の時間■ 設備費用■ 効果■ 自動化できた消化すべきテストケース数× {(1テストケースあたりの手動テスト実行時間 × 時給) - [1テストケースあたりの自動テスト実行時間 × (1時間あたりの電力消費費用 + 1時間あたりのサブスクリプション費用)]}

5

テストの全体像■ 以下のようなプロセスでテスト自動化を実現
自動化の費用対効果の高い
機能一覧

テストベース
テスト
計画
QF

テスト
計画書

テスト
要求
分析

テスト
対象
分析

テスト対
象モデ
ル

機能一覧

自動化
する機
能の識
別

テストスイー
トアーキテク
チャ
テスト
スクリプト
テスト
詳細
設計

テスト
すべきこと

テスト
実行

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

テスト
実行結果

テスト
実装
テストシステムアーキテ
クチャ

テスト自動化の効果

6

テスト計画（１）■ 何を、どうやってテストするか
詳細項目

QF開発チームの一員であるテス豆は、ASTER社様より「機能アップデートによるリリース頻度増加を目的・方針見据えたテスト自動化」のご依頼を承りました。「費用対効果の高いテスト実行の自動化」をASTER社様に提案する。

スコープ
テストアイテム

クラウドテスト管理ツール Quality Forward

テスト対象機能

テスト対象モデルから導出した機能から、自動化の費用対効果の高い機能を選んだもの。

非テスト対象機能

上記以外。手動テスト担当チーム（（仮）：Aチームに頼む）

アプローチ
テストレベル選定

システムテスト

テストタイプ選定

機能テスト

テストタイプ毎の目的機能の合致性検証

テストタイプごとのテスト対象

費用対効果の高い機能一覧

テストアプローチ

該当機能の合致性検証のために必要な技法を選定し、必要なテストのパタンを洗い出す。

マネジメント
テストタスクと担当

テス豆

テスト環境

シート名：テストシステムアーキテクチャを参照のこと

スケジュール

シート名：テストスイートアーキテクチャに定めるテストの順番を参照のこと

リスクとその対策

7

スコープ

テスト計画（２）
テストアイテム

クラウドテスト管理ツール

テスト対象機能

テスト対象モデルから導出した機能から、自動化の費用対効果の高い機能を選んだもの。

非テスト対象機能

上記以外。手動テスト担当チーム（（仮）：Aチームに頼む）

Quality Forwardアプローチ■ 何を、どうやってテストするか
テストレベル選定

システムテスト

テストタイプ選定

機能テスト

テストタイプ毎の目的機能の合致性検証

テストタイプごとのテスト対象

費用対効果の高い機能一覧

テストアプローチ

該当機能の合致性検証のために必要な技法を選定し、必要なテストのパタンを洗い出す。

マネジメント
テストタスクと担当

テス豆

テスト環境

シート名：テストシステムアーキテクチャを参照のこと

スケジュール

シート名：テストスイートアーキテクチャに定めるテストの順番を参照のこと

リスクとその対策
リスク
手を動かせるメンバが限られている。
やみくもに自動化してもスクリプト保守コストがかかってしまう。

対策
費用対効果の高い機能一覧から、現メンバ（3人）で１Wで出来そうな機能を選定する。
実装保守しやすいものを選定する。

全て手動でやってしまうと、機能アップデー
トがかさむとテスト時間が膨大になってしま 何度もテストする見込みの物を選定する
う。
自動化ツールはどうすればいいのか。
成果物

TBD

文書管理 TBD

無償で環境構築コストの低いものを利用する。

テスト設計書ドキュメント体系書

8テスト要求分析（１）■ テスト対象モデルの作成

9

テスト要求分析（２）■ 自動化するテストの選定自動化す 実装に手間がかからず、よく使われそうで、不具合がありそうなところを自動化する。
る基準■ 実装に手間がかからないとは■ 入力する項目や遷移を数え、それらが少ないこと■ よく使われそうとは■ マニュアルを見なくても操作できて、手も止まらないほどさわれること。

■ 不具合がありそうとは■ ひと通りさわってみて、テスト管理という仕事の阻害につながりそうなこと。
10

テスト要求分析（３）■ 自動化化するテスト
実装想定工数
画面遷移数 合計数がかかる

チェック プルダウ
ボックス ン

ユーザ招待機能5アップ

フィルド フィルタ コピペ

ロードラッグ

1

ユーザ削除機能
ユーザ権限変更機能

不具合出そうか(1－3点）

低いほど低いほどよく使わ 理由

不具合が 理由

れそう

多そう

クリック

1
2

数値が低いほど良い

よくつかわれそうか(1－3点）

ファイル オート

テナント使用量表示機能2

備考

多いほど工多いほど工数がかかる

プロフィール設定機能

費用対効果の高さ

何度もテストされるか

必須入力数

フォーム

実装に手間がかからず、よく使われそうで、不具合がありそうなところに絞って、自動化する

1

テナント切り替え機能

1

12

3 今回は対象外。何度もテストされるケースがないため
3 今回は対象外。一度動けば影響を受けない。
82273313531633223253 今回は対象外。何度もテストされるケースがないため
3 今回は対象外。一度動けば影響を受けない。
1133732243 今回は対象外。何度もテストされるケースがないため
3 今回は対象外。一度動けば影響を受けない。
10313

パスワード再設定機能

34

31023サインイン機能

2114

1 毎回使うため

3プロジェクト追加機能

2

1

126

1 プロジェクトは次々作られると想定
3102338231344

111214226

1 QFで何したいかと考えるととっつきやすかった
1 表示はユーザの問い合わせも多く、修正になりやすいと考えた
822813126415

1117224 対象外。ダウンロードするだけで自動化の意味に疑問がある。
239337 対象外。取込用Excelを作らなければいけないため。
1191

18 対象外。編集工数が数値以上に重たい
1110232103316

2

プロジェクトへのユーザ追加機能
プロジェクト設定変更機
能3

カバレッジパネル表示機

1

能テストスイート作成機能

2excelスマートインポート機能

1

1

131

1

テストスイートダウン
ロード機能
テストケース取込機能

1

テストケース編集機能

1

テストスイート設定機能

2

テストスイートの新バー

1
11182273

3

13

追加ヘッダ設定機能

1225 対象外。JSON形式の入力が絡む
3

3

11

テストフェーズ作成機能

1337

13

11

コメント入力機能

154102315

予実績入力機能

15410 対象外。予実の入力の手間

1112

テストサイクル作成機能

233813122441013143391111337121044811104410131464151117ジョン設定機能

テストサイクル設定変更
機能
レビュー機能12153

テスト実行機能1

レポート表示機能
チームwiki機能
BTS連携機能

231111

テスト要求分析（４）■ テスト観点、テストアプローチの特定※一部を抜粋。残りは、成果物1および、成果物2「テスト自動化機能選定とその効果」のシート名「テストすべきこと」にすべて列挙済
12

テストアーキテクチャ設計（１）■ テストシステムアーキテクチャ■ メリデメ分析を経て、以下の仕組みで自動化を実現
候補

メリット

デメリット

Java環境があればできる

Maven環境構築

無償ツール

Selenium（Java）

無償ツール

Selenium（python） python環境があればできる現状なし。

無償ツール

その他

お金かからない。

学習コスト

有償ツール

その他

出来ることが多い

学習コスト

13

テストアーキテクチャ設計（２）■ テストスイートアーキテクチャ

14

テスト詳細設計■ テストアプローチにそって、テストケースの形に詳細化する。

※一部を抜粋。残りは、成果物1および、成果物2「テスト自動化機能選定とその効果」の
15
シート名「テスト詳細設計」にすべて列挙済

テスト実装■ 自動テストスクリプトの作成や修正の時間を削減するため、データ駆動テストアプローチを適用■ Seleniumの自動テストスクリプトとテストデータを分離■ テストデータだけ変更が必要な場合は、自動テストスクリプ
トは変更せずに利用できる

16

テスト実装(サンプル)■ seleniumによる自動テスト■ csvからデータを取得するデータ駆動型テスト
ログイン失敗のテストケース

CSVの情報を元にテスト実行

17

テスト実行結果（１）■ 以下の問題に遭遇。不具合でなかったとしても、手間がかかり、よく使われやすい、不具合が出やすい機能にしぼって自動化して、機能追加や不具合確認で何度も生じるテストを次は短い時間でできる見込みがあることを示すことができた。
T9テストレポートの表
示機能のテスト

問題点1

テストブロッカーの設定をしているが、チャートのテストブ
ロッカー上位ランキングに表示されない

問題点2

自動テストスクリプトを複数回実行していると、サイクル一覧ボタンの表示不正がおきる
T6のテストサイクル作
成機能のテスト〇18

テスト実行結果（２）ストブロッカー上位ランキ■ 問題点1:テストブロッカーの設定をしているが、チャートのングに表示されない

テストブロッカー上位ランキングに表示されない設定済

表示されない設定済

BLOCKとなるテストケースがあるにもかかわらず〇
19

テスト実行結果（３）■ 問題点２：自動テストスクリプトを複数回実行していると、
サイクル一覧ボタンの表示不正がおきる

表示不正

〇
20

自動化による効果
1回目のテストで問題発見。回数を重ねると自動化の効果の可能性
100

1回目は自動化工数90がかかり、手動の方80が効率がいい場合が70ある。

2回目も手動だと自動化しておくと、工数はトータルで2回目以降は楽にな倍になる。

る。楽になるのは、

60

n回目以降かもしれ

50ないが。

4030
2010011回目手動工数

1回目自動工数

2回目手動工数

2回目自動工数

単位はひとまず5K￥/時間。数値については継続して見直していく。
21

発表は以上です。ご清聴ありがとうございました。

22

以降、付録（成果物1の図表）。

23