Quality Forward テスト設計案
テクバン株式会社- シン・田町補充計画 -■アジェンダ
シン・田町補充計画について

テストアーキテクチャ

テスト設計コンセプト
テストタイプの選定
テスト設計の方針について

テスト設計における重要ポイントの選定

テスト設計の実施

■「シン・田町補充計画」について▼チーム名の由来“シン・エヴァンゲリオン”、“シン・ゴジラ”の「シン」と会社の所在地「田町」から命名▼チーム構成メンバー
長島、渡邊、大羽、松浦、濱田、石井• 全員が同じ会社のメンバーだが、それぞれ別の現場に従事しており、同じチームを組んで作業をしたことがない• テスト設計経験もまばらである■テスト設計のコンセプト
ユーザ目線での受け入れテストに準じた効果的かつ実現性の高いテストケースを作成

どの程度使えるか？
手っ取り早く知りたい・・・がんばった■テスト設計のコンセプト：工夫した点
マインドマップでのテスト要求分析・整理し、製品コンセプトに関係のある項目を抽出

ユーザ権限ごとの機能確認の優先度付けを実施、ユーザにとって重要な機能を特定し効率的にテスト実施できるようにした

また、テストアーキテクチャ作成方法の調査を行い、チームの環境・レベルに即した設計方針を確立

テストアーキテクチャとテスト要求分析の結果を比較し、テスト対象に抜け漏れが発生しないよう工夫した■テスト設計の方針について（前提）▼前提として以下のように利用想定シーンを考えた• 自分が従事している現場でQuality Forwardを導入する場合を想定• テスト工程は受入テストを対象として考える

現場の業務を分析し、受入テストに必要な項目を割り出す
当社に必要な機能とは？

■テスト設計の方針について（詳細）▼機能分析と業務分析を行った
機能分析
Quality Forwardの機能を業務に役立てることが可能か？
• 実際にQuality Forwardを触り、利用者の観点から必要な機能を推測• テスト担当者の経験から、テストすべき観点を割り出す

業務分析• 現在の業務で適用できるか、また業務で発生した問題についてQuality Forwardで解決できるか？ → マインドマップで整理する• 提案されているコンセプトが業務に役立てることができるか？
→ コンセプトを分析し、業務内容と当てはめてみる

■全体図 イメージ
▼テスト要求分析、テストアーキテクチャをそれぞれ２段階に分けて行う

テスト要求分析 Ver1

テストアーキテクチャ Ver1
テスト要求分析 Ver2
テストアーキテクチャ Ver2

テスト設計書作成

■テスト要求分析▼テスト要求分析のイメージ
実際の業務内容

実システム

営業資料

マニュアル

業務分析

アンチユーザ分析

コンセプト分析

機能分析

機能確認の優先度付け

テスト要求分析

テストアーキテクチャ

■テスト要求分析▼マインドマップで整理 (例：Ver2)

■テスト設計における重要ポイントの選定◎テスト観点を定める
テストマネジメント工数削減を目的としてQualityForward(以下QF)を導入するユーザとしてのテストを行う

必要な手順としては以下３つ

1）QFを導入する理由を考える

2）機能全体の把握（洗い出し）を行う

3)権限による機能確認の優先度付けを行う

■テスト設計における重要ポイントの選定◎テスト観点を定める＜1）QFを導入する理由＞
導入理由としては以下が挙げられる
・これまで手動で行ってきたテストマネジメント管理のスケーラビリティに限界を感じてきた
・PJにおけるテストマネジメントにおいて、規模にかかわらず利便性、応答性に特化したテスト管理ツールである
・他管理ツールと比較して高機能かつユーザビリティが良い・導入効果の実績があり費用対効果が高い
・可用性が高く、高品質である

■テスト設計における重要ポイントの選定◎テスト観点を定める＜2）機能全体の把握（洗い出し）を行う＞ Quality Forward 機能全体図を書き出す

■テスト設計における重要ポイントの選定◎テスト観点を定める＜3)権限による機能確認の優先度付けを行う＞
・優先度は「高」「中」「低」・ユーザ権限レベルは①テナント管理者、②プロジェクト管理者、③一般ユーザ

■テストアーキテクチャ▼テストアーキテクチャを作成する方法について調査を行った手法（まとめ方）

概要

分析結果

使い勝手

参考URL

テストタイプ

ソフトウェア・テストPRESS
Vol.10に記載のテストタイプ

現在の業務と一致しており、アーキテクチャとして作りやすい〇

https://note.com/katar
uyube/n/na3195a510ef
eISO-25010

品質要求を定義し、その実装を評価するための国際規格観点が広く、テストの抜け漏れに利用できる〇

テストレベル

レベルごとに分類されるテスト
グループ

テスト計画時の前提条件で対象外とした

×

機能単位

機能単位で分類されるテスト
グループ

テスト計画時の前提条件においてQF全機能をテスト対象としてはいないため機能単位の分析は不適切と判断した×

QFの実態に即した分析が可能
でアーキテクチャとして作りやす
いものの粒度が不十分△

コンセプト単位コンセプト単位で分類されるテストグループ

分析結果からテストタイプとISO-25010を併用する方針とした

http://JSTQjstJqb.jp/dl/JSTQBSyllabusFoundation_Ver%20
sion2018.J01.pdf (JSTQBシラバス P22)

■テストタイプの選定▼テストタイプを性質ごとに分類し、選定を行ったシステム/ソフトウェア構造の網羅性▼
・ 構造テスト
プログラムの内部構造に着目し網羅率を確認する→ テストアーキテクチャVer2で削除

機能適合性▼
・ 機能テスト機能が動作することを確認する（画面、機能単体のテスト）
・ 機能組み合わせテスト
機能同士を組み合わせても問題ないことを確認する（ALL-Pair法、HAYST法などで確認した方がいい部
分） → テストアーキテクチャVer2で削除
・ シナリオテスト
一連の機能がシナリオ通りに動作することを確認する→ テストアーキテクチャVer2で削除

セキュリティ
▼・ セキュリティテスト
システムのセキュリティが問題ないことを確認する

性能効率性▼・ ロードテスト
負荷を高めた状態でも問題なく動作することを確認する
・ ストレステストシステムに想定以上の負荷を与えても問題ないことを確認する
・ 拡張性テスト
システム負荷が増大しても問題なく動作することを確認する（ユーザ数やデータ容量が増大しても対応できる）→ テストアーキテクチャVer2で削除

信頼性▼・ロバストネステスト
誤った入力をしても動作することを確認する（マイナスを入力、仕様にないファイルをアップロード）

・ 回復性テスト
システムがダウンしても復元できることを確認する→ テストアーキテクチャVer2で削除
・ 信頼性テスト
既定したＳＬＡを満たすことを確認する→ テストアーキテクチャVer2で削除

互換性▼
・ データ互換性テスト
入出力するファイルに問題ないことを確認する（Excelファイルなのか、バージョンはいくつなのか）
使用性▼・ ユーザビリティテスト
ユーザにとって使いやすい機能となっているかを確認する

・ 構成テストOS、ブラウザなどの特定の環境で動作することを確認する

■テスト設計の実施▼それぞれのテストタイプについて調査のうえテスト設計を実施した【例１】 機能適合性テスト機能適合性に留意したテストケースを作成

・完全性・・・機能が利用者の目的を満たしているか・正確性・・・機能が正しく動作するか・適切性・・・機能が利用者の目的(業務など)を達成するのに適切な仕様となっているか■テスト設計の実施▼それぞれのテストタイプについて調査のうえテスト設計を実施した【例２】 使用性テスト
ユーザビリティ特性に留意したテストケースを作成

・適切度認識性・・・「システムの機能が利用者のニーズに適切であること」を利用者に認識できるようにしているか
・習得性・・・
利用者が定義されたシステムの 学習目標を達成できるか・運用操作性・・・
システムが運用しやすい操作性か。運用時に想定される誤操作に対する許容やユーザーの期待に一致しているか・ユーザエラー防止性・・・
システムが利用者が誤操作しないよう防止できているか

等

■まとめ
Quality Forwardの利用想定シーン（現場で使用する場合）をもとに方針決めを行った

利用者の観点から必要機能およびテストすべき点を割り出す（機能分析）
業務におけるQuality Forwardの活用性をマインドマップで整理（業務分析）

テストタイプとISO-25010をもとにテストアーキテクチャ設計の概要を把握
テストアーキテクチャ検討（アーキテクチャ図の作成、テストタイプ分類手法の調査）

ユーザー目線での受け入れテストに準じた効果的かつ実現性の高いテストケースを作成

やり切った- ご清聴ありがとうございました -