「テストケースとは…？」
「聞いたことあるけど、詳細は知らない…」
「意味はなんとなく知っているけど、必要なのか…」
などテストケースについてお悩みの方も多いでしょう。この記事ではテストケースについて詳しく解説していきます。
テストケースとは
テストケースとは、ソフトウェア開発において、プログラムが期待通りに動作するかを確認するための手順を文書化したものです。ソフトウェアは、新しく開発した機能や既存のプログラムを変更したことで、正常に動作しないことがあります。
正常にシステムが稼働する状況かどうか確かめるための工程を「テスト」と呼び、それを正しく行えるよう明文化したものをテストケースと呼ぶのです。
主に正常系と異常系に分かれています。画面に値を入力する機能を例にすると、正常系は指定された値を入力した際にエラーが発生せず、期待通りの結果が得られる場合の事を指します。それに対して異常系は、値を入力した際に期待通りのエラーが発生する事を指します。
テストケースを作成するタイミング
テストケースを作成するタイミングは主に開発が完了し、一通り動作してもバグが発生しないタイミングで行います。システムを動かし、バグが大量に発生するようであればテストを行うのはまだ早いと言えるでしょう。
大量にバグが発生するタイミングでテストを行なっても、テストをスムーズに進めることができず、正しいエラーなのか見分けるのが困難になるためです。
テストケースを作成する目的
システムを開発した本人やシステムに詳しい有識者がテストするなら、テストケースを作成せずに動作確認をすればいいのでは、と考える方もいるかもしれません。
しかし、テストケースを作成しなければ、漏れのない動作確認が進められず、重大なインシデントにつながる可能性があるのです。ここからはテストケースを作成する目的について解説します。
必要なテストを実施するため
テストケースの作成には、まず必要なテストを実施するという目的があります。
テストケースなしでテストを進めてしまうと、本来するべきテストが漏れてしまう可能性があります。また、テストをした記録も残らないため、第三者からみてどこまでテストが完了しているか、確認することが難しいのです。
「正常に動くソフトウェアであることの証明のために」また「顧客からの信頼を得るために」テストケースを作成します。
不当なテストを削除するため
必要なテストを実施することも重要ですが、不必要なテストを実施しないことも重要です。テストケースを作成し、有識者などの第三者に確認を取ることで、不要なテストを排除することができ、人件費や時間のコストを削減することができます。
誰が実施しても同じテストにするため
ソフトウェアのテストは、複数の人が何度も行うことが前提となります。
そのため、人によってエラーを出したり正常に動作したりしてしまうなどルールがない状態で実施しても意味がありません。これでは、システムが期待通りに動作しているのか判断することが難しいため、テストになりません。
従ってテストケースを作成する際は具体的な手順を用意し、誰が何度実行しても同じ結果になることが重要になります。
テストの種類について
テストケースを作成する際にテストの種類を把握しておく必要があります。
テストの種類を知らないと、的外れなテストケースを作成してしまったり、必要なテストを行わないままクライアントに報告してしまう危険性があるためです。ここからは主なテストの手法を紹介します。
機能テスト
機能テストとは、新しく開発または改修した機能がクライアントの要求通りに動作するのかを確認するテストです。
エラーが発生せずに動作するかテストするだけではなく、エラーも想定通りに出力されるのかテストする必要があります。エラーが発生せずに正常に処理が終了するテストを正常系、エラーが発生することを異常系と呼びます。
機能テストでは、要件を満たしているか確認することが目的であるため、一般的に処理内容を把握せずに入力データと出力データを比較し結果検証するブラックボックステストが用いられます。
ドメイン分析テスト
ドメイン分析テストとは、同値分析や境界値分析とほぼ同じ概念であり、システムの仕様条件の境界となる値とその隣の値に対してテストを行う技法のことです。
なぜ境界値に絞ってテストを行うのかというと、これまでテストを行ってきた際に境界値にてエラーが発生しやすい傾向があるためです。数値などの値を入力するときは必ず、境界値を意識してテストケースが作成されます。
ただし、関係性がある複数の変数をテストする場合にドメイン分析テストという言葉が使用されます。
仕様書確認テスト
仕様書確認テストとは、修正が発生したシステムの仕様書、設計書、ドキュメント通りに動作しているかを確認するテストです。システムの仕様の変更が発生した際には、仕様書や設計書の修正が必要になります。
修正した仕様書と異なった動作をしていないかどうかを確認します。実際にテストを行い仕様書に不備があり、実際のテスト結果の方が正しいと判断されれば、有識者や責任者の許可を取り、仕様書が修正される場合もあります。
負荷テスト
負荷テストとは、そのソフトウェアまたはプログラムで想定されている最大の負荷または、最大以上の負荷をかけてもシステムが正常に動作するかを確認するテストです。
例えば、想定しているユーザーのログイン数を超えても問題がないか、などのテストを行なっています。
主にチケット販売など、一時的に負荷がかかることが想定されているシステムや機能に対して行われるテストです。
実際にクライアントが使用している本番環境とは別に、テスト環境でシステムに負荷をかけ、異常や劣化が発生する限界点を把握することが目的となります。
回帰テスト
回帰テストとは、プログラムに変更を加えた際に、変更を加えていない箇所に新たな不具合が発生していないかを確認するテストになります。
システムが複雑化し、大規模になっていくほど一つの機能が、どこにどのような影響を及ぼすのか把握することが難しくなります。変更する前は、正常に動作していた機能が動作しなくなる場合を想定し、クライアントに確認をもらう前にテストを行い不具合を見つける必要があるのです。
受け入れテスト
受け入れテストとは、システムが発注者の要求通りに動作するかを確認するためのテストです。基本的に発注者側が実際にテストを行い、疑問点や不具合があればシステムを開発した受注者側に問い合わせする流れになります。
実際に運用する前の最後のテストとして受け入れテストは行われ、ここで不具合や疑問点などをすべて洗い出しておくことが目的です。
※関連記事
受け入れテストとは？言葉の定義や目的、実施方法を徹底解説
シナリオテスト
シナリオテストとは、ユーザーに実際に操作してもらう前に、開発側で実際にシステムを動かして想定通りに動作するかを確認するテストです。
ユーザーが実際にシステムを操作し、最終的な確認を行う前のテストになるため、重要なテストの一つとなります。
実際にユーザーが操作する手順に従ってシステムを操作し、想定通りに動作しない場合は、有識者や責任者に問い合わせ、早急に不備を解消する必要があります。
状態遷移テスト
状態遷移テストとは、画面の遷移が想定通りに行われることを確認するテストです。例えば、ホーム画面に戻るボタンを押下したとき、正常にホーム画面に遷移するかを確認します。
テレビのリモコンを例にするとわかりやすいですが、ボタンを押下するとチャンネルが切り替わり別の番組を視聴することができます。
それと同じように画面のボタンを押下したとき、想定通りに画面を遷移させることができるのかを確認するためのテストになります。
探索的テスト
探索的テストとは、テストケースを作成しテストを実行していくのではなく、テストを行なった後に次のテストの内容を決定しテストしていく方法です。
探索的テストでは、テストの終了や目的だけを定め、細かいテストケースは作成せず、テスターがプログラムの動作をみながら気になるところをテストしていき、システムの開発者にフィードバックを行う手法になります。
テストケース作成の観点
これまでテストケースの概要やテストの種類について解説してきました。ここからはどのような観点から実際にテストケースを作成するのかを解説していきます。
全体
全体的には以下の観点からテストケースを作成します。
-
- インプットした値に対して結果は想定通りであるか
- 想定されていない値が入力された場合も問題ないか
- 想定されている値が入力できるか
- エラーが出力された場合のメッセージ出力は正しいか
- 文字数制限は適切な値が設定されているか
- 数字しか入力できない箇所で文字を入力できないか
環境
環境は以下の観点にてテストケースを作成します。
-
- 実際にシステムが稼働する環境を想定してテストを行なっているか
- 時間やタイムゾーンに差異はないか
セキュリティ
セキュリティは以下の観点にてテストケースを作成します。
-
- 脆弱性の観点に問題はないか
- ログインする際などの認証、認可のロジックに問題はないか
- 認証、認可が不正だった場合の処理に問題はないか
エラー
エラーは以下の観点にてテストケースを作成します。
-
- エラーが発生した際に出力されるメッセージは想定通りか
- エラーが発生した際に処理がロールバックされるか
- エラーが発生した際にデータが更新されていないか
- 例外処理は想定通り行われるか
画面表示
画面表示は以下の観点にてテストケースを作成します。
-
- データが設定されていない場合の処理・表示に問題はないか
- エラーの場合や処理に成功した場合のポップアップは想定通りか
- 画面の遷移先は想定通りか
データ内容
データ内容は以下の観点にてテストケースを作成します。
-
- データベースのレコードは更新されているか
- データベースのレコードがシステムの処理に合わせて抽出されているか
- トランザクションは考慮されているか
※例えば、銀行からお金を引き出した際に口座の情報も合わせて更新されているかなど
接続
接続は以下の観点にてテストケースを作成します。
-
- 数多くのユーザーが同時に操作した場合の負荷や処理は考慮されているか
- ネット環境が悪い場合も考慮されているか
- 処理が途中でキャンセルされた場合を考慮されているか
- ユーザーが集中した場合は考慮されているか
- ユーザーが使用している環境、OSなどが考慮されているか
テストケースの入力値
開発したソフトウェアに値を入力する際に、どのような値を入力すれば良いのでしょうか。値を入力するといっても、想定できる値を全て入力すると膨大な工数が必要になり、とても効率的とは言えません。ここからは以下の手法を解説していきます。
境界値分析
テストしたいプログラムに値を入力し、バグが発生しやすい「境界値」または、その隣の値を発見し、そこを重点的にテストすることを境界値分析と言います。
例えば、10桁まで数値が入力できるプログラムがあるとします。そのプログラムに9桁10桁11桁と順に値を入力していき、想定通りにデータを入力することができるのか確認するのです。
これまで行われてきたテストから、値の境界にバグが発生しやすいことがわかっています。桁数を確認するテストを行うときは、境界値を意識しながらテストケースを作成しましょう。
同値分割
テストの回数をより少なくするための手法に同値分割という方法があります。
期待される処理の結果が同じであるプログラムがある場合、まずはそれをひとつのグループにまとめます。そのグループから適当に選んだ一つの値を入力したとき、正常に処理が行われることを確認します。
例えば、10未満の値を入力する項目があった場合、0〜9の値を入力するのではなく、「7」だけを入力し正常に処理ができているか、確認するのです。0〜9まですべてを入力すると9回のテストが必要であることに対して、同値分割では1回テストで済みます。
ぺワイズ法
ペアワイズ法とは、組み合わせテスト技法の一つであり、ペアワイズテストとも言われています。ソフトウェアの不具合は、1つまたは2つの要因の組み合わせにより発生しているという経験則に基づいて、テストケースを作成する方法です。
エラー推測
エラー推測とは、テストケースを作成する人の経験則に基づいてエラーが起きそうな値を決定する手法です。「数値しか入力できない」項目に対して、マイナスの値、NULL、文字列などの値を入れて結果を確認する方法となります。
テスト外注化が可能である
ここまでテストケースの作成方法と重要性などを解説していきました。質の高いテストケースを作成することで知識がない人がテストすることができますし、迷うことなく効率的にテストを進めることができます。
しかし、テストケースで確認するべき観点を全て網羅できていなかったり、具体的な内容ではなく曖昧なテスト内容だったりする場合は、バグを発見するのが遅れたり、重大なインシデントにつながったりする恐れがあります。
確実にテストを遂行し、最終的な工数を削減させるために、テストケース作成を外注化するという方法を提案します。テストケース作成に実績がある企業やパートナーを見つけ、効率的にまた、コストを削減しながらテストを進めてください。
まとめ
この記事で説明してきた内容をまとめると以下のとおりです。
-
- テストケースについての概要
- テストケースを作成するメリット
- テストケースを作成する目的
- テストケースの作成方法
テストケース作成はテストを行う上で重要な業務であるため、確実に行う必要があります。テストケース作成を専門的に行なっている企業にテストを外注化すれば、安全確実なテストを実現させることができるでしょう。
株式会社エイチビーラボでは、ベトナムに特化したオフショア開発サービスを提供しております。テストケース作成には豊富な実績があります。また、クラウドやITインフラ、システム関連でお困りの方は、ぜひお気軽にお問い合わせください。ご相談から、開発、運用まで親身にサポートいたします。
