Webアプリケーション（以下Webアプリ）開発に携わる企業の方の中には、開発工程が多岐にわたるため、実装後の作業であるWebアプリにおけるテストの必要性や、実施方法について把握しきれていないという方も少なくないと思われます。
本記事では、検証工程に携わったことが少ない方に向けて、検証の重要性と効果的な導入方法について詳しく解説していきます。
Webアプリにおけるテストとは
Webアプリの開発工程におけるテストとは、作成された成果物に対して評価を行う作業です。
評価基準は工程やWebアプリによってさまざまですが、まずはWebアプリにおけるテストの前提である実施の理由について簡単に解説していきます。
テストを実施する目的
Webアプリにおけるテストで最初に思い浮かぶ目的は、欠陥(バグ)の摘出ではないでしょうか。
ただ、欠陥の摘出とはあくまで目的を達成するための手段であり、本来の目的は欠陥の摘出を内包した、より広義的なものになります。
目的はプロジェクトによってさまざまですが、ここではよく用いられるステークホルダー（利害関係者）基準での、Webアプリにおけるテストの達成基準について4件ご紹介します。
- 明確にしたすべての要件を満たしていることを確認
- ソフトウェアの品質が不適切になるリスクレベルを軽減
- 契約上、法律上、または規制上の要件や標準を遵守
- ステークホルダーが意志決定できる品質レベルについての十分な情報提供
テスト工程を実施しなければならない理由
【1-1】において、テストを実施する目的は明確になりましたが、ここでは目的を達成するためになぜテストを実施する必要があるのかについて解説していきます。
まず、ステークホルダーの観点からすると「開発工程における大きな手戻りや、リリース後の致命的な不具合による損失を防ぐため」が挙げられます。
開発工程の手戻りは工数の増加、リリース後の致命的な不具合は利益の損失につながってしまいます。そのため、テスト実施の理由としては損失の回避と将来的な利益の確保となります。
また、開発工程の観点からすると「テスト終了後に欠陥の根本原因を分析するため」が挙げられます。
開発工程においては、どこでどのような欠陥が出たか、どのような欠陥が開発工程のスケジュールに影響を及ぼしたかなどを欠陥ベースで情報集積することで、次回以降の開発工程における改善案の提示を行うこともテスト実施の理由となります。
Webアプリテストの作業工程
ここでは、Webアプリテストの目的と理由についてより理解を深めるため、具体的な作業工程を解説していきます。
実行計画
Webアプリにおけるテスト工程を実行することが決まった段階で、まずは実行計画を開始します。
最初に、テストに必要なリソースの確認を行います。
必要なリソースは主に下記の6つになります。
- プロジェクト方式
- 仕様書
- 設計書
- 製品マニュアルやテスト対象機器
- 旧バージョンが存在する場合の各種テスト情報
- 競合製品が存在する場合は競合製品の情報や実機
これらの情報をもとにテストの内容やスケジュールを策定していきます。
次に、スケジュール策定を実施します。
テスト対象物のテスト実行範囲(確認を行う事項)を明確化し、優先順位を付けます。また前述の過去のテストデータなどから不具合の予想件数を想定できる場合はその数を割り出しておきます。
必要な情報を集め終えた後、その情報を元にタスク・工数・マイルストーン・要員・終了基準を決定し、スケジュールを組みます。
最後に、テスト工程における連携手段とリスクの明確化を実施し、本工程を終了します。
考えられる主なリスクは下記の4つになります。
- 要員のトラブル
- コミュニケーションミス
- テスト実行を阻害するブロックバグやテスト対象物の品質
- 機器の不足や故障
上記に関しては発生してからの対応のため、スケジュール策定段階で想定することは難しいですが、前述の過去のテストデータなどから計画段階で回避策を用意しておくことでリスクを低減することが可能となります。
環境準備
Webアプリにおけるテスト環境準備とは、テスト実行する上で必要なリソースを確保・確認する段階になります。
具体的な準備は下記の６件になります。
- 作業環境の準備
- テスト環境やテスト対象の準備
- 必要なリソースの動作確認
- プロジェクト用語集と組織図の準備
- コミュニケーションツールと運用ルールの準備
- テスト実行に必要な管理表の用意
テストケース準備
Webアプリにおけるテストケース準備とは、テスト実行に必要な実施条件、動作、期待結果を示したドキュメントの作成を行う段階になります。
具体的な事例は【3-3】において説明します。
実行
Webアプリにおけるテスト実行とは、【2-1】～【2-3】の工程で作成した内容を用いてテストを実行する段階になります。
基本的には「テスト項目と予定時間の確認・打鍵」を行うだけの作業ですが、障害の発生に伴い不具合報告と確認テストが追加で発生する場合があります。
不具合報告
実行段階において確認された不具合や確認事項はエンジニアへ報告する必要があるため、不具合報告書を作成します。
手順としては下記の通りになります。
- 期待値と異なる事象の確認（テスト実行時に確認）
- 不具合かどうかの判定（各種ドキュメントとの整合性チェック）
- 事象の発生条件の明確化
- 再現手順の明確化
- 不具合の評価（品質への影響度や修正優先度）
- (3)～(5)を記載した不具合報告書の作成
- 環境準備において不具合管理表を作成した場合は管理表へ記載
実行報告
実行完了後にテストケースの実行件数や不具合率などの実行計画段階で定めた終了基準を満たしているか確認し、テストを終了する判定が下された際にはテスト実行報告を作成します。
テスト実行報告にまとめる内容は下記の4点になります。
- 実行件数や不具合率などの集計
- 実行中に発生した問題点とその解決策の提示
- 次回への改善点や要望の提示
- テストに使用した各種データ・物品の整理・保管
本工程は欠陥を取り除くというテストの直接的な目的からは乖離する内容ではありますが、【1-2】の「テスト終了後に欠陥の根本原因を分析するため」に該当するテストを実行する理由の一端であるため、必要不可欠と言えます。
Webアプリテストの手法
ここでは、【2】で示したテストの流れを実行する際のテストの区分方法や、テスト仕様書の作成方法について解説していきます。
テストレベル
テストレベルとは、テストを系統的にまとめ、マネジメントしていくグループです。
具体的には下記の４件になります。
・単体テスト
個別にテスト可能なコンポーネントに焦点をあてるテスト。
・結合テスト
コンポーネントまたはシステム間の相互処理に焦点をあてるテスト。
・総合テスト
システムが実行するエンドツーエンドのタスクと、タスクの実行時にシステムが示す非機能的振る舞いといったシステムや製品全体の能力に焦点をあてるテスト。
・受入テスト
システムテストと同様、一般的に受け入れテストはシステムやプロダクト全体の振る舞いや能力に焦点をあてるテストではあるが、目的は不具合を検出することではなく、システムが導入に向けて準備できているかどうか、および顧客 （エンドユーザー）が使用できるかどうかを評価するテスト。
各工程は一回だけ行い、原則として後戻りは許されません。
前工程の成果物をインプットし、次工程にアウトプットする成果物を作成することをウォーターフォールモデルと呼びます。
下記のような左側が設計プロセス（上流工程）、右側が検証プロセス（下流工程）のV字モデルでは、横に対応する仕様書をインプットとして、仕様書通りの成果物ができているかどうかの確認を行います。
テストレベルごとに目的・テストベース・典型的な欠陥・アプローチ方法が異なるため、【2-1】実行計画段階の必要な情報として挙げることができます。
テストタイプ
テストタイプとは、ソフトウェアシステムの目的や特性毎に条件を束ねたものです。
具体的には下記の4件になります。
・機能テスト
システムが実行する事項が機能要件を満たしているかを評価するテスト手法。
・非機能テスト
システムやソフトウェアの使用性、性能効率性、セキュリティといったシステムが「どのように上手く」振る舞うかを評価するテスト手法。
こちらの具体例は【3-3】の”手順⑦”に記載してあります。
・ホワイトボックステスト
システムの内部構造や実装にもとづいてテストを導出する手法。
この手法は内部構造を理解しているコードの実装者で行われるテストやレビューが主軸になるため、テストチームとして実行されることは少ないです。
・確認テストとリグレッションテスト
欠陥を修正、追加、変更といったシステム対応を行った場合、元の欠陥が修正されたこと、機能が正しく実装されていること、予測しなかった悪い影響が発生していないことを確認するためのテスト。
すべてのテストタイプはすべてのテストレベルで実行可能ではありますが、プロジェクトの方針にあわせて各テストレベルに全テストタイプを適用する必要はありません。
テストタイプは必要となるもっとも早い段階のテストレベルで行うことで大きな手戻りや致命的な欠陥の作りこみを防ぐことができるため、どのテストタイプも可能な限り早い段階で実施することが重要です。
テスト項目作成
ここでは、【2-3】の工程において作成する仕様書の内容について解説していきます。
手順①：開発仕様の確認と熟知
下記5件の資料を収集し、収集した内容をテスト設計文書として記録する。
- テスト設計の上で必要なドキュメント
- テスト対象の機能要求から必要なドキュメント
- テスト対象のコンプライアンスに関わる情報
- テスト対象の非機能要件
- 過去のテストドキュメント
またテスト設計文書は作成した際に修正作業や後の作業工程のために参照元のドキュメントとのトレーサビリティ(追跡性)を確保しておくことが重要です。
手順②：テスト対象物の仕様をベースにテスト要素とテスト条件の抽出
テスト要素は”手順①”で作成したテスト設計文書をベースにテストの実行できるパターンを抽出したものになり、テスト条件はテスト要素に与えるさまざまな入力値になります。
また、この2件は量が増えやすく、テキストでの管理が困難であるため、下記のような管理体制であることが望ましいです。
・テスト要素
抽出後に要素同士の関係性を明確化し、樹形図の作成によって管理する。
（参考：IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP115「図 M3-3 機能樹形図（Function Tree）」を参考の上作成）
・テスト条件
複数条件が絡み合う場合、テキストベースでの管理は難しいためデシジョンテーブルやマトリクス表の作成によって管理する。
※例として、有効値と無効値の数値処理を行う条件には下記の2件を用いる場合が多いです。
同値分割法：有効値と無効値といった条件をひとまとめにし、その中から代表の値を選定する手法
境界値分析：有効値と無効値の境目の値にフォーカスをあて、その数値を条件とする手法
（参考：IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP132「図 M4-7 同値分割と境界値分析による”月”データの有効値と無効値の抽出」を参考の上作成）
手順③：テスト要素とテスト条件を組み合わせる
テスト要素とテスト条件を組み合わせたものが、テスト設計の最小単位であるテストケースとなります。
この工程で組み合わせるものを検討するのではなく、”手順①”で示したテスト設計文書のトレーサビリティを参照し、組み合わせを導き出していきます。
手順④：テスト要素と例外のテスト条件又はテスト要素と異常のテスト条件を組み合わせる
本来は開発仕様書を始めとするドキュメントを用いることで、想定する動きが正常に動作しているか確認できるため、問題はないように思います。
しかし、想定していない状況（サーバーダウンなど）に陥った際、次に説明する2パターンのテスト条件を実行していない場合、脆弱性により大きな損失を被る可能性があります。
例外のテスト条件とは、仕様の範囲内ではあるが仕様で定められていない値を与えられる条件のことです。
・例外条件（数値パターン）
（参考：IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』より P144「表 M5-４ 有効値30~50の例外条件」を参考の上作成）
・例外条件（名称パターン）
（参考：IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP144「表 M5-5 都道府県名称の例外条件」を参考の上作成）
異常のテスト条件とは、仕様に関係なくテスト要素に本来使用する想定ではない値が与えられる条件のことです。
具体的な例としては下記が挙げられます。
- 整数入力欄に文字コードではないデータが与えられた
- データが与えられなかった
- データの処理中に次のデータが与えられた
- データの入力先が排他状態だった
上記2パターンのテスト条件については、開発仕様書などで範囲が定められていないため、条件になり得る量は膨大になります。
そのため、テスト仕様書作成担当者とレビュアーがテスト設計文書や開発仕様書からプロジェクトのスコープに適応する条件や、リスクの大きい条件を選定することが理想です。
手順⑤：テストケースをテスト仕様書へ落とし込む
”手順③”と”手順④”で作成したものを実際にテスト仕様書に落とし込んでいく作業になります。
この作業で重要なのは、テスト実行担当者のレベル、テストの期日、工数を考慮した上で『記述の粒度』を変えるという点です。
『記述の粒度」の例としてログイン確認の項目を書いた場合、下記のようになります。
・『記述の粒度』が低い場合
「登録済みアカウントでログイン」
・『記述の粒度』が高い場合
「IDに“XXXX”、Passwordに“AAAA”を入力し、ログインボタンを押下する」
スキルレベルが高いテスト実行担当者の場合、『記述の粒度』が低い場合でも理解することが可能ですが、スキルレベルが低いテスト実行担当者の場合、『記述の粒度』が高いと、テストケースの意図を理解するまでに時間を要してしまいます。
また、『記述の粒度』が高い場合、スキルレベルが高いテスト実行担当者が読了に時間を要し、テスト仕様書作成担当者が記述に多くの時間を割くことになります。
そのため、テスト実行担当者のスキルレベル、テストの期日、工数にあわせて最適化することを念頭に置き、テスト仕様書作成にあたることが重要になります。
当然ではありますが『記述の粒度』の高低に関わらず、理解しやすい文章や作りにすることはテスト実行担当者の補助のみならず、実行報告や次回以降のテスト工程のサンプルとして生かしやすくなるため、気を付ける必要があります。
手順⑥：作成したテスト項目に対して期待値を設定する
作成したテスト仕様書のテスト項目に対して、正誤の判断に用いる期待値が必要になります。
こちらはテスト設計文書と参照元のドキュメントとのトレーサビリティ（追跡性）を用いて設定することが多いです。
例外のテスト条件や異常のテスト条件を用いた項目や参照元のドキュメントとの整合性が取れない場合に関しては、開発者やプロジェクト責任者に確認を取る必要があります。
また期待値が文章化できない場合には、リファレンスを用意して期待値を示します。
手順⑦：非機能テストのテスト基準策定
【3-2】で示した非機能テストの内容を精査します。
代表的なものは下記の３件になります。
・性能テスト
・負荷テスト
・脆弱性テスト
これらのテストの実行可否、使用方法、ツールを選定しテスト仕様書に追加またはチェックリストを作成します。
Webアプリテストの今後の展望
今後Webアプリにおけるテスト実行は、テスト自動化ツールや “Sizzy”などの検証補助に利用できるツールを導入することで最適化できると考えます。
テスト自動化ツールは、そもそもツールを開発できる技術者がテストチームにいないことや、短期的な視点で見れば工数を損失するなどの障害も多いですが、導入後の長期的な視点で見ると工数の削減やヒューマンエラーの削減につながるため、導入には前向きな検討が必要です。
検証補助ツールは、昨今の開発従事者の在宅勤務化に伴い、在宅環境における検証端末の有無や、テストチーム内の検証環境の差異といった問題を解消するためにも急務であると考えます。
もちろん“Sizzy”を始めとする検証補助ツールは、検証の効率化といった面でも大変役に立ちます。
そのため、在宅勤務化がこれからというテストチームであったとしても、テスト実行者の負担軽減、工数削減、そしてプロジェクト全体の品質向上につなげるため、導入への前向きな検討が必要です。
Webアプリにおけるテストまとめ
Webアプリのテストは開発工程で発生するあらゆる不具合を拾い上げ、製品としての魅力を担保する役割を担っています。
将来的な不利益を回避や利益の確保につながるため、Webアプリに携わる方は最低限の目的と工程を理解することでよりよい成果物を目指しましょう。