ソフトウェアテストの設計は、慣れていない人であればどこからはじめればいいのかわからない人が多いのではないでしょうか。また、理解していないとミスをしやすいことがあります。そこで本記事では、ソフトウェアテストの設において失敗しない方法や品質を高めるコツを紹介します。
ソフトウェアテストにおける「設計」とは？
ソフトウェアテストにおける設計とは、テストをどのようなプロセスにおいて行うのかやどのようなデータを使うのか、どのような方法でテストを進めていくのかなど具体的に手段を決めることです。
JSTQBにおいて「テスト対象に対して、どのようなテストをどのような手段で実施すべきかというテスト戦術を検討するためのタスク」とテスト設計は定義されており、ソフトウェアテストにおいて重要なことです。一般的にテスト設計内容を全てテスト設計書にまとめていきます。
設計と計画の違い
テスト計画はテストを進めるための目的や予定、注意点、方向性などをまとめたものであり、テスト計画書にまとめることが一般的です。テスト設計はテスト計画書を基準として作られます。
ソフトウェアテストの設計における流れは3ステップ
ソフトウェアテストの設計において一般的な流れは次の3ステップです。
- テスト分析
- テスト設計
- テスト実装
ステップ1.テスト分析
テスト分析とは、テストをこれから進めるソフトウェアの機能やふるまいを要件定義書の読み込みなどさまざまな方法で調査し理解することです。ソフトウェアがどのような機能を持っているのか把握したうえで、それぞれの機能においてふるまい方を分析していきます。
ステップ2.テスト設計
テスト設計は、テスト設計のあとにどのようなパターンや観点で、どの機能に対してテストを進めるか設定することです。
テスト設計におけるテスト観点とは、ソフトウェアの機能が適切に動いているかを確認するためのテストの方法や切り口などを定義しているのが特徴です。そのため、テスト観点では、ソフトウェアの機能を十分に把握することが重要です。
ステップ3.テスト実装
テスト実装とは、テストを進めやすいようにプロセスやテストをする目的などをわかりやすく記載したテストケースを作成することです。テスト観点を基準にテストケースの作成を進めることが一般的です。テスト仕様書はテストケースをまとめたものをいいます。
ソフトウェアテストの設計でよくある2つの失敗
ソフトウェアテストの設計でありがちな失敗は次の2点です。
- 要件定義書を書き写しただけになっている
- 過去の仕様書を流用している
1.要件定義書を書き写しただけになっている
要件定義書を書き写しただけでは、テスト担当者がどのように判断していいのかわからないことがあります。この場合テスト担当者がテストケースを作った担当者に確認する必要があり、余分に時間がかかってしまいます。
また、テスト担当者が誤って判断した場合、要件定義書とは異なる内容のテスト内容となるケースも少なくありません。
2.過去の仕様書を流用している
過去の仕様書を流用しているケースも少なくありません。ソフトウェアやシステムは毎回違う内容であるため、毎回作り直す必要があります。過去の仕様書を流用したものを使ってテストが進められると、テスト内容が適切でない可能性が高くなるのです。
ソフトウェアのテスト設計で失敗を防ぐ3つのポイント
ソフトウェアのテスト設計で失敗を防ぐためには次のポイントが挙げられます。
- 重要な結論を最初に読む
- 要件定義書の厳密性をチェックする
- 情報の不足や漏れを確認する
ポイント1.重要な結論を最初に読む
ソフトウェアのテスト設計において重要な結論を最初に読むことにより失敗を防ぎやすくなります。要件定義書は先に結論を把握しておくことで、全体の機能をスムーズに理解できます。最初から読んでいれば、いろいろなことが記載してあるため理解するのに時間がかかる可能性があるのです。
ポイント2.要件定義書の厳密性をチェックする
ソフトウェアのテスト設計において要件定義書の厳密性をチェックすることで失敗を防げます。要件定義書に記載する内奥は誰が見てもわかりやすく明確にすることが重要です。
エラーログに関しても、ただエラーが出ると記載するのではなくどのようなエラーがでるのかまで記載しましょう。
ポイント3.情報の不足や漏れを確認する
ソフトウェアのテスト設計において失敗を防ぐために、情報の不足や漏れを確認しましょう。
クライアントと要件定義をした担当者の間でわかっていることでも、テスト担当者が理解していない可能性があります。そのため、要件定義書にはテストに必要な内容は全て記載することが重要です。
ソフトウェアのテスト設計で品質を高める4つのコツ
ソフトウェアのテスト設計で品質を高めるためには次のコツが挙げられます。
- 担当者にレビューしてもらう
- ユースケースを想定する
- テストケースが偏っていないかをチェックする
- 担当者とのコミュニケーションを深める
1.担当者にレビューしてもらう
テスト観点を洗い出した後は、要件定義書を作成した担当者にレビューを依頼しましょう。要件定義書を作った人は、ソフトウェアについて最も理解していることが一般的です。
そのため、確認をしてもらうことでテスト観点の漏れを防げます。レビューは必ずテストケースの作成前に確認しましょう。テストケースを作成後であれば、テスト観点の確認が十分でなくなる可能性があります。
2.ユースケースを想定する
ソフトウェアのテスト設計で品質を高めるためには、ユースケースを想定しましょう。ソフトウェアのテストを進めるとき、実際にユーザーがどのような環境においてまたどのような目的でソフトウェアを使うのかを理解することが重要です。
例えば、外国人が入力するフォームに、日本語でのみ案内をしたとしてもほとんど意味がありません。利用するユーザーにとって不親切なシステムとなりかねません。
3.テストケースが偏っていないかをチェックする
テストケースが偏らないかを確認することが重要です。テストケースの漏れを防ごうとすると、どうしても偏りが出る場合があります。
これまで似たテストをした場合や、要件定義書を作成した担当者と何度もテストを行っている場合などに起こり得ます。無意識にテストを進めると偏りがちなので、意識をして偏らないようにしましょう。
4.担当者とのコミュニケーションを深める
要件定義書を作成した担当者と十分なコミュニケーションをとることが重要です。担当者の意図をつかめないままテストを行うと、思ったようなテストにならない可能性があります。その結果ソフトウェアの品質を低下させることにつながります。
ソフトウェアテストの設計でよくある質問
ソフトウェアテストの設計でよくある質問をまとめました。
設計で失敗する主な理由は何ですか？
ソフトウェアテストの設計するのは、テスト工程において心構えが出来ていない場合が一般的です。テストを設計する場合、過去のテスト仕様書を参考にしたり、要件定義書を参照することが一般的です。しかしそれだけでなく、要件定義書に記載されていない要件を読み込むことが重要です。
ソフトウェアテストの設計について学べるおすすめの本はありますか？
次のページではソフトウェアテストにつかえる本を紹介していますので、ぜひこちらも参考にしてみてください。
まとめ
ソフトウェアテスト設計する場合は、要件定義書の厳密性の確認や結論から読むなどしっかり理解することが重要です。さらに、漏れや情報不足がないように進めましょう。そのためには、担当者としっかりとしたコミュニケーションをとることが重要です。
