関係者間の合意形成が難航して、仕様を確定できない。変更点がドキュメントに反映されず、手戻りが生じた。頼りになるメンバーが、プロジェクトを離脱してしまった。実行環境の構築が遅れ、テストに着手できない。それなのに、サービス提供は遅らせられない…。システム開発プロジェクトには、スケジュールに影響する様々なリスク要因が存在します。
その終盤、リリースを目前に控えたテスト工程で、さらなる進捗遅延は許されません。だからといって、工程を短縮するためにテストケースを削減した結果、不具合を見逃してしまったら?テストの意味がありませんよね。このようなジレンマの中で、スケジュールを守りながら高品質なソフトウェアを開発するためにテストエンジニアは、様々なテスト技法を活用して効率的な検証を行っています。
そこで本記事では、ソフトウェアテストの国際規格「ISO/IEC/IEEE 29119」の分類に基づき効率のよいテストに欠かせない、3種類のテスト技法をご紹介します。
内部構造を検証する「構造ベースのテスト技法」:ホワイトボックステスト
別名「ホワイトボックステスト」とも呼ばれるこの技法は、テスト対象の内部構造と処理内容に焦点を当てる技法です。「作った通りに動作しているかどうか」を確認する、開発者視点のテストと言えるでしょう。「カバレッジ(網羅率)」と呼ばれる指標を用いて、ソースコードのどの部分をテストしたのかを、定量的に表現できるメリットがあります。
代表的なホワイトボックステストである「制御フローテスト(制御パステスト)」では、ソフトウェアモジュールの構成要素(命令文、分岐構造、条件)に着目してカバレッジを計測します。デメリットは、100%に近い高カバレッジを達成しようとすればするほど、工数が増加してしまう点です。対策として、テスト対象の特徴やプロジェクトの状況に応じて、適切なカバレッジ基準を定めることが重要です。
また、仕様の解釈誤りやコーディングミスに起因する不具合の発見には、あまり適していません。したがって、期待結果を設定する際は内部構造だけではなく、きちんと最新の仕様にも準拠する必要があります。単体テストでの適用が一般的ですが、「内部構造を理解したうえで検証する」という意味で、モジュール間の結合テストでも使える技法です。
テスト実行をはじめて行うエンジニア向けのマニュアル型資料
テスト実施の基本とバク報告の書き方を解説
テスト実行者向け はじめてのガイドブック
要求に応えられているかをチェックする「仕様ベースのテスト技法」:ブラックボックステスト
一般的には「ブラックボックステスト」と呼ばれます。その名前の通り、内部構造を参照できないブラックボックスとみなして外から見たテスト対象のふるまいが、仕様に沿っているかどうかを重視するテスト技法です。具体的には、テスト対象への入力と、入力に対する出力を検証します。「使いたいように使えるかどうか」に着目する、ユーザー視点のテストといえます。テスト設計の際にはデシジョンテーブルや状態遷移図、状態遷移表などを用いて、様々な角度からテスト対象を分析します。
その過程で、仕様の妥当性や考慮不足がないかを整理できる点がメリットです。加えて、実装時の解釈誤りやコーディングミスの検出も期待できます。一方、要件や仕様が明確になっていないケースでは有効な検証ができません。さらに、開発ドキュメントに反映されていない実装によって、引き起こされる不具合の発見も困難です。よって、最新の仕様に基づいたテスト設計が重要なポイントになります。他にも、チェックすべき入力データや出力、条件のパターンが膨大になりがちです。
同値分割や境界値分析、デシジョンテーブルの簡略化などのテクニックを用いて、いかに効率的に試験項目を圧縮できるかが、テストエンジニアの腕の見せどころといえます。アルゴリズムを用いて、自動的に組み合わせパターンを絞り込んでくれるツールも提供されています。その特徴から、単体テストから総合テスト、ユーザー受け入れテストまで幅広い工程で用いられます。また、機能テストに限らず非機能テストにも適用できる技法です。
プロジェクト・プロダクト全体の品質を向上させ、デジタル改革を加速させます
バルテスの品質向上サービスのご紹介
スキルと直感がものをいう「経験ベースのテスト技法」:探索的テスト(アドホックテスト)
経験ベースのテスト技法では、担当者の経験を活用しながら、テスト対象の学習とテスト設計・実行を並行して進めます。そのため、事前のテスト設計はそれほど重視されないケースが多いです。不具合が潜む箇所を探るように試験を進める様子から、「探索的テスト(アドホックテスト)」とも言われます。担当者の経験によって、開発者視点とユーザー視点どちらの検証も可能です。
経験ベースのテストの最大のメリットは、効率よく不具合を発見でき、スケジュールを圧迫しない点です。特に、過去のプロジェクトで蓄積された不具合情報を用いて、精度の高いエラー推測が可能な場合があります。またスキルと経験、業務知識が豊富なテストエンジニアの支援が得られるケースでは、テスト工数を削減する有効な選択肢になりえます。加えて、仕様確定が不十分な状況でも検証を進められます。
反面デメリットとして、担当者の経験やスキルに依存するので、期待したような効果が上がらないおそれがあります。また、テスト実行を優先する目的で、テストケースやドキュメントの作成が省略・簡素化されがちなので、ナレッジが属人化しやすい点にも注意が必要です。経験ベースのテストだけでは、抜け漏れなく網羅的な検証を行うのは難しいことから他のテスト技法と組み合わせた補完的な適用がおすすめです。
品質を高め、コストダウンができる効果を9つの事例でご紹介
テストアウトソーシングの効果とコストダウン実例ガイドブック
まとめ
ここまで、ISO/IEC/IEEE29119の分類による3種類のテスト技法をご紹介してきました。それぞれの特徴や、活用シーンがイメージできたでしょうか?
メリット・デメリットを表にまとめると、次のようになります。
技法 | 特徴 | メリット | デメリット |
構造ベースのテスト技法 (ホワイトボックステスト) | 内部構造を検証 | カバレッジを用いて、品質を定量的に評価できる | ・カバレッジを達成するための工数が増加 ・仕様の解釈誤りから起きる不具合は発見できない |
仕様ベースのテスト技法 (ブラックボックステスト) | 入力に対する 出力の妥当性をチェック | ・仕様の解釈誤りを発見できる ・幅広いテスト工程に適用できる ・非機能テストにも使える | ・要件や仕様が明確でないとテストできない ・入力パターンが膨大になりがち |
経験ベースのテスト技法 (探索的テスト・アドホックテスト) | テストの設計・実行に経験を活用 | ・テスト設計と実行を並行するため効率がよい ・仕様が不十分でもテスト可能 | ・テスト担当者のスキル・経験に依存する ・ドキュメントが残されない場合が多い |
参考
- Foundation Level シラバス Version 2018V3.1.J03
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf - 【この1冊でよくわかる】ソフトウェアテストの教科書【増補改訂第2版】
- ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書
単独のテスト技法のみで品質を担保するのは非常に困難です。そこで、システム開発プロジェクトの状況に応じてテスト技法それぞれの特徴を理解し、適切に組み合わせた検証が大切です。本記事がそのヒントになれば幸いです。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。