システム開発において、テストは欠かせない作業です。
入念なテストを行いデバッグすることで、システムの品質と信頼性が担保されます。
テスト観点とは、そんなテスト作業を正しく実行するために必要なものです。
今回はテスト観点とテストケースの違い、また重要性や洗い出し方の例を紹介します。
テスト観点とは？
テスト観点とは、テストを行う上で必要になってくる考え方や切り口のことを指します。
切り口というといささか抽象的に聞こえてしまうかもしれませんが、要はそれぞれの機能に対して、どういったテストを行うべきなのかを考えるということです。
テスト観点を細かく洗い出すことで、より厳密なテストが行うことができ、品質向上に繋がります。
テスト観点の重要性
テスト観点は、テストの方向性を決めるためにも重要な役目を果たします。
例えば、開発の現場によっては開発者とテスターがそれぞれ分かれている場合があります。
その際、開発者がテスターに対してテストの指示を出すことになりますが、その指示が曖昧だった場合、テスターはどういったテストを行えばよいかわからず、困ってしまいます。
テストを任されたプログラムの、何の機能をテストすればいいのか、また、どういった結果が返ってきたら正しいのかが分からないからです。
この機能はどんな動きを確認する必要があるのか、そのためにどういった値を入れてどういった結果が返ってくれば仕様通りと見なすのか、これらを考えることがテスト観点であり、テストケースを作成する際の重要な部分になってきます。
テスト観点を考えることで、テストの正しい方向性が見えてくるため、テストケースを作成しやすくなります。
テストケースとの違い
実際のテスト作業は、テストケースをもとに進めていきます。
テスト観点がテストを行う際の考え方であるのに対し、テストケースはプログラムの実行手順や入力する値、条件ごとに期待されるテスト結果などをまとめた手順書のようなものです。
テストケースは、誰が見てもどのようなテストを行うのか分かるように作成する必要があります。作成されたテストケースをもとに手動、もしくは、自動化ツールを用いてテストを行っていきます。
テストの自動化については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
https://pengi-n.co.jp/softwaretest/archives/296
テスト観点を洗い出すうえで重要な4つの要素
テスト観点を洗い出すうえで重要なのは次の4点です。
- 機能要素
- 検証方法
- 入力条件
- 出力結果
ソフトウェアテストは、商品やシステムなどの品質を保ったり信頼性を高めたりするために重要なプロセスです。そのためには、テストにおいて効率性や網羅性が求められます。ソフトウェアテストの質を高めるためには、さまざまな要素においてテスト観点を洗い出すことが重要です。
1.機能要素
テスト観点とは、テストをする対象を明確にすることです。どのような機能やシステムをテストするかを明確にするために、検証する対象である機能を要件定義書から洗い出すことが求められます。
機能要素の例として、ボタンを選んだときの画面推移機能やそれぞれのページにおける画面を表示する機能などが挙げられます。複数の機能が組み込まれているソフトウェアであれば、時間がかかるため注意が必要です。
2.検証方法
検証方法とは、テストをするシステムや対象となる機能にたいしてどのように検証をするのかをいったテストです。それぞれの機能において、確認するべき点や適切な検証方法を活用するのかを明確にすることが求められます。
検証方法にはユーザビリティテストや互換性テスト、異常値テスト、条件網羅テストなどが含まれます。システムや機能によって適切な検証方法を選択するようにしましょう。
3.入力条件
入力条件とは、テスト観点を考えるうえで、インプットする内容やイベント、値、発生する可能性があることなどの条件です。
例えば、スペースやNULL、大文字小文字、動画を再生した後に発生するイベントなどさまざまな例が挙げられます。カレンダーに反映するシステムの場合は、うるう年をはじめ通常通りではないタイミングがある場合も入力条件にあてはまります。
4.出力結果
出力結果とは、どのようなことを観察すればいいかといった要素です。
例えば、文字化けをしていないか、規定の値以外を入力した場合エラーメッセージが表示されるか、音声を同期した場合ずれが生じていないかなど出力条件にもさまざまな要素があります。テストを出力した結果において、どのようなことを確認するかを明確にすることが重要です。
テスト観点の洗い出し方は5ステップ
テスト観点の洗い出し方は次の手順となります。
- テスト対象の発見・決定から始める
- 動詞を用いて基本構造を構築する
- 基本構造に形容詞・副詞を加える
- 基本構造と派生構造を組み合わせる
- 得られる期待結果を検討する
テスト観点はテスト対象を見つけてから、テストをすることによる期待結果の検討などさまざまなステップが必要です。そのため、時間がかかる場合が一般的です。
ステップ1.テスト対象の発見・決定から始める
テスト観点を洗い出すうえで、テスト対象の発見・決定から始めます。それぞれの要素を組み合わせることによって品質を高めることを重視するようなテスト対象を見つけることが求められます。
また希望を明確にすることによってテスト期間の設定が可能です。納期に遅れないように、テストの規模や時間などを確認することが求められます。
ステップ2.動詞を用いて基本構造を構築する
テスト対象の要素を発見したら動詞を用いて基礎構造を構築していきます。例えばテスト対象に更新したり登録したりすることが機能網羅テストに必要です。
この他にも操作網羅テストや状態網羅テスト、入力網羅テストなどにおいて動作が求められます。これらのテストはソフトウェアやシステムに搭載されている機能を網羅している点が特徴です。
ステップ3.基本構造に形容詞・副詞を加える
基本構造において動詞を使った構築が終わったら、次の手順として形容詞や副詞を加えていきます。目的や早く、強く、負荷が高いなどといった部分が形容詞や副詞などにあてはまります。
形容詞や副詞の要素を加えることにより、テストタイプをより具体的にすることが可能です。さらに、網羅性を高めるといった効果もあります。
ステップ4.基本構造と派生構造を組み合わせる
基本構造に副詞や形容詞を加えてより具体性を高めたら、次に派生構造と組み合わせていきます。例えば、テスト対象に対してAをBさせるといった構造と、CをDさせるといった構造をくみあわせることにより、AとCを、BやDさせるといった具合です。
複数のモジュールを組み合わせることによって、連携テストや連動テストなど複雑な構造のテストタイプを作成できるようになります。
ステップ5.得られる期待結果を検討する
ここまで、基本構造や派生構造、組み合わせ構造といったテストタイプを作成してきました。最終プロセスとして、それぞれのテストにおける期待する結果を検討します。
それぞれの構造においてテスト期待結果を設定することで、最終的な目標につなげられます。テスト結果にAをBさせると、最終的な結果につながるといった形です。
テスト観点の洗い出し例
テスト観点は、それぞれの機能でテストするべきポイントを洗い出していきます。ここではいくつかの機能を例にあげて、テストケースを作るときのそれぞれのテスト観点を参考までにご紹介します。
テキストボックス
入力可能文字数
入力できる文字数が、仕様の入力可能文字数と同じ、またはそれ以下になっており超過しないかを確認します。
半角と全角の制御
半角と全角の入力制御が仕様通りになっているかを確認します。
文字と数字の制御
テキストボックスが仕様通り文字と数字両方が入力可能なのか、もしくは数字しか入力出来ないように制御されているのかを確認します。
コピー&ペースト時の挙動
対象のテキストボックスにコピー&ペーストで文字が貼り付けられた場合、仕様の入力文字数を超過してしまわないかを確認します。
また、コピー&ペーストを禁止の設定にしている場合は、コピー&ペースト出来ないようになっているかを確認します。
フォーカスアウト時の入力チェック
入力チェック処理を実装している場合、対象のテキストボックスからフォーカスアウトした場合に、入力チェック処理が正しく動作するかを確認します。
検索ボタン
検索条件が仕様通りか確認
ボタン押下時、検索フォームに入力された値に対して部分一致・前方一致等、仕様通りの検索条件で検索が行われることを確認します。
入力必須の検索項目が未入力時の入力チェック
ボタン押下時、入力必須の検索項目が未入力だった場合、メッセージが表示されるかを確認します。
画面遷移
遷移先の画面が正しい画面か確認
別画面へ遷移する際、遷移先が正しい画面であるかを確認します。
また、画面のタイトルや項目等の文言が正しいかも確認します。
前画面の値やパラメータが、遷移先の画面にも渡されているか確認
システムによっては、前画面の値やパラメータを遷移先の画面でも引き継ぐ場合があります。
その際、前画面で入力した値やパラメータが遷移先の画面に渡されていて、正しい挙動をしているかを確認する必要があります。
データベース
検索処理時の結果を確認
システム内で検索処理が発生した場合、検索対象のデータが正しく抽出されるかを確認します。
登録処理時の結果を確認
システム内でデータの登録処理が動いた場合、データベースにもデータが新規追加されているかを確認します。
また、登録件数に誤りがないかも確認します。
更新処理時の結果を確認
システム内でデータの更新処理が動いた場合、データベース内の対象データが更新されているかを確認します。
また、更新件数や、対象でないデータも誤って更新していないかを確認します。
削除処理時の結果を確認
システム内でデータの削除処理が動いた場合、データベース内の対象データが削除されているかを確認します。
また、削除件数や、対象でないデータも誤って削除していないかを確認します。
エラー表示
エラーメッセージの表示を確認
エラー発生時、仕様通りのエラーメッセージが表示されることを確認します。
入力チェックエラー時の挙動を確認
入力チェック処理でエラーが発生した場合に、対象項目の色が変わるなど、状態が変化する仕様である場合、仕様通りの挙動をしているかを確認します。
例外処理発生時の挙動を確認
例外処理が発生した場合、エラーメッセージと共にエラーログが出力されて、該当箇所の特定が出来る様になっているかを確認します。
セキュリティ
複数人が同時にシステムを利用している場合の排他制御
複数人がシステムを同時に利用している場合に、同一データの更新を防ぐために排他制御がされているかを確認します。
一定時間無操作時のタイムアウト
システムにログインして、一定時間無操作の時間が続いた場合、自動的にタイムアウトされるかどうかを確認します。
利用者のアクセス権限制御
管理者や一般ユーザー等、ユーザー毎に利用できる機能や画面に制限がある場合、それぞれのロールごとに正しくアクセス制限が効いているかを確認します。
テスト観点の考え方
テスト観点の考え方については、様々な切り口があります。
いくつか、テスト観点の着眼点として考えてみるとよいポイントを紹介します。
経験から判断する
長年システム開発に従事している開発者であれば、自身の経験から見えてくるテスト観点があります。
例えば、過去に開発やリリースに携わった経験があり、その時に発生した想定外のエラーについて調査・修正を行ったのであれば、今後同様のエラーが発生した場合の対処法を既に習得していることになります。
過去の経験からそのエラーに対しての対処法を知っているため、今後開発するシステムでは同じエラーを発生させないようにテスト観点として洗い出すことが出来ます。
違和感を掘り下げてみる
開発中やテストケースの作成中に、ここはテストしておいた方がいいかもしれない、と少しでも違和感を感じることがあったらもう少し掘り下げてみましょう。
例えば、大多数のユーザーが利用する複雑なシステムは、操作マニュアルがあったとしてもユーザーごとの使い方は様々です。
その分、イレギュラーな操作や、想定外のデータ登録が行われる可能性も出てきます。
イレギュラーな操作が行われるとしたらどの画面でどういった操作が行われそうなのか、想定外のデータがデータベースに登録されてもシステム上問題はないかなど、感じた違和感を掘り下げていき、それらをテスト観点として洗い出しましょう。
リストを作ってまとめておく
洗い出したテスト観点はリストとしてまとめておきましょう。
リストを作成後、テスト観点を共通の認識としてプロジェクト内で共有しておくことで、そのリストを別のシステム開発にも流用することが出来て、以降の作業を効率よく行うことが出来ます。
また、新規の開発や既存機能の改修時にも、テスト観点が見つかれば随時リストを更新し、常に最新のものにしておきましょう。
まとめ
品質向上に繋がる正しいテストケースを作るためにも、テスト観点は重要な要素となってきます。
自身の経験や違和感からテストするべき項目を思いついたら、まずはそれらを洗い出してリストにまとめておきましょう。
また、リストは常に最新の状態に更新しておき、他のシステム開発でも流用できるようにしておきましょう。様々な機能や状況に対応できるテスト観点を持っておくことで、品質向上に繋がるテストを実施することができます。
