テスト・QA関連の仕事をしている、山本くにお と申します。
いままでやってきたことについて、記事として投稿したいと思います。
みなさんの活動の一助になれば、幸いです。
ところで・・・
みなさんは、テスト設計は、どのように実施していますか？
組織や担当者によって、アプローチも成果物も異なると思います。
今回は、自分自身なりのテスト設計の進め方について、お話いたします。
テスト設計のプロセスについて
みなさんの組織では、テスト設計関連のプロセス＆成果物ってどうなっていますか？
時代と組織の成熟度の応じて、下記のような段階があると考えています。
- テストが独立した活動として存在しない
- ①開発 > ②リリース
- テストが活動として認識される
- ①開発 > ②テスト > ③リリース
- テストは、実施だけじゃないらしい
- ①開発 > ②テスト準備 > ③テスト実施 > ④リリース
- テストは、計画して進めたほうが効果的らしい
- ①開発 > ②テスト計画 > ③テスト準備 > ④テスト実施 > ⑤リリース
- テストは、技法等を用いて設計したほうが、効率的らしい
- ①開発 > ②テスト計画 > ③テスト設計 > ④テスト準備 > ⑤テスト実施 > ⑥リリース
- テストは、分析してから計画・設計したほうが、より効果的らしい
- ①開発 > ②テスト計画 > ③テスト分析 > ④テスト設計 > ⑤テスト準備 > ⑥テスト実施 > ⑦リリース
- テストは、設計と実装で活動を分割することで、より効率化できるらしい
- ①開発 > ②テスト計画 > ③テスト分析 > ④テスト設計 > ⑤テスト実装 > ⑥テスト準備 > ⑦テスト実施 > ⑧リリース
- テストは、終了処理を行うと、次の案件に効果的らしい
- ①開発 > ②テスト計画 > ③テスト分析 > ④テスト設計 > ⑤テスト実装 > ⑥テスト準備 > ⑦テスト実施 > ⑧テスト終了処理 > ⑨リリース
この段階で、やっと JSTQB で定義されているプロセスがだいたい出揃いましたが、ここまで定義されている組織はどれぐらいあるでしょうか？
若い組織では、なかなか難しいのではないでしょうか？
上記から、テスト設計を実施するために、大きく下記の３つのプロセスがあると考えています。
１． テスト分析
２． テスト設計
３． テスト実装
それぞれのプロセスで、どのようなことを実施ているかは、各々ご説明させていただきます。
【 JSTQB に記載されている、基本的なテストプロセス 】
テスト分析
ここでのテスト分析は、テスト設計を実施するためにテスト対象・機能等の分析を行うフェーズです。
上記のステップの中でも、ちょっとだけ記述しましたが、テスト計画時にも対象案件の分析がありますが、今回はテスト設計に向けてのテスト分析について、記述いたします。
基本的には、テストベース（企画書・要求・要件・仕様書・etc）・類似サービス等を用いて、テスト対象物の分析を行い、テスト設計のインプットとなる情報・予測等を抽出作業です。
分析の一環として、テストベースのレビューを兼ねる場合もあり、上流でのテストとして実施している方々も多いのではないでしょうか？
この時点でテストベースに不明点・不備がある状態で、テスト設計を進める場合は、後工程での手戻り・テスト成果物のメンテナンス等の工数を、テスト計画変更のインプットとすることを、おススメいたします。
一般的な活動の例として、JSTQB に記載されている内容を列挙いたします。
• テストベース(例えば、要件、ソフトウェア完全性レベル4(リスクレベル)、リスク解析レポート、アーキテクチャ、設計、インターフェース仕様)をレビューする。
• テストベースやテスト対象のテスト容易性を評価する。
• テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいて、テスト条件を識別し優先順位を付ける。
上記の内容から、組織によって様々なアウトプットが定義・作成されていると思いますが、基本的に下記のようなものを作成しています。
- テスト観点表（箇条書きのドキュメント・表・マインドマップ・etc）
- テスト条件等も上記観点に含めてまとめる
- 各種テスト条件・機能等に対する優先度
- 上記観点をベースに対象となる、テスト対象になる因子・水準
- 三銃士モデルでは、テスト値を呼んでいます
- レビューによってブラッシュアップされたテストベース
- レビュー時に検出された指摘事項(上流での不具合)も大切なテスト資産なので、別途まとめましょう！
テスト設計
上記テスト分析を実施したのちに、テスト観点＆テスト値をベースに、テスト観点(機能・画面・ふるまい・確認観点)をどのように組み合わせるかを検討し動作・状態を考え、テスト値(因子)の内容からどのようなテスト技法を適用するのが最適で、どのような値(水準)を設定するかを検討します。
上記内容から、テストケース(高度なもの)を作成します。
この段階では、テストで確認したい観点だけが集まった状態なので、実施する際の効率を考えてた、テスト手順書は次のテスト実装で行います。
ここでも、一般的な活動の例として、JSTQB に記載されている内容を列挙いたします。
• 高度なテストケースを設計し、優先順位を付ける。
• テスト条件やテストケースをサポートする上で必要なテストデータを識別する。
• テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する。
• テストベースとテストケースの間で双方向のトレーサビリティを作成する。
上記の内容から、組織によって様々なアウトプットが定義・作成されていると思いますが、基本的に下記のようなものを作成しています。
- テスト観点マトリクス(対応表)
- テストケース(高度なもの)
ある程度、経験のあるテスト実施者ならば、テストケースだけでもテスト実施はできると思いますが、このままでは実施内容・結果が属人的なものになってしまいますので、より属人性を減らすテストを実施するためには、次のテスト実装のフェーズも大事になってきます！
テスト実装
上記、テスト設計を実施したのちに、高度なテストケースのままでは、テスト対象全体を把握していないと非効率になってしまいます。
テスト実装をする際には、テストケースを独立性を担保しつつ、効率的な手順を Step By Step で記述します。
また、この際にテストデータ・アカウント・環境・端末等も考慮して、実装を行うことをおススメします。
上記、テスト条件・制限・制約・準備等が不足していると、テスト実施当日に、何もできなくなってしまう場合もありますので、ご注意ください！
ここでも、一般的な活動の例として、JSTQB に記載されている内容を列挙いたします。
• テストケースを決定し、実装し、優先順位を付ける。(テストデータの識別も含まれる)
• テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によってはテストハーネスを準備し、テストの自動実行スクリプトを書く。
• 効率よくテストを実行するため、テスト手順をベースにしてテストスイートを作る。
• テスト環境を正しくセットアップしたことを確認する。
• テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する。
上記の内容から、組織によって様々なアウトプットが定義・作成されていると思いますが、基本的に下記のようなものを作成しています。
- テスト手順書
- テストデータ
- テストアカウント
♯♯ まとめ
テスト設計は、テストベース(企画・仕様書・類似サービス・etc)をもとに、スリーレイヤーやＣＰＭ法で実施している方々も少なくないと思います。
最低限のテストを実施すための手法として、ＱＣＤのトレードオフのなかで、より良い手法を選択していただければ、良いと思います。
今回ご紹介した方法は、リーダーやマネージャの方々が、脳内で自然に実施している内容を、アクティビティを分解して可視化したものになっています。
基本的には、下記のプロセスを踏まえて、各々の成果物を作成して、ナレッジを可視化＆共有して組織力強化を促進できると、考えています！
１． テスト分析
２． テスト設計
３． テスト実装
参考サイト
- JSTQB(Japan Software Testing Qualifications Board) シラバス(学習要項) http://jstqb.jp/syllabus.html
- 三銃士モデル
- JaSST 2016 Tokyo http://www.jasst.jp/symposium/jasst16tokyo/report.html#plan7
- JaSST 2017 Tokyo http://www.jasst.jp/symposium/jasst17tokyo/report.html#plan7