テストを効果的に実施するには

ソフトウェアテストの重要性を前回の記事で述べたが、網羅率を上げるために総当りで調べていては時間がかかるばかりである。ソフトウェアの品質を向上させるためにどのようなテストを行うべきかまとめた。

静的テスト・動的テスト

テストを実行方法で分類した際には、それぞれ「静的テスト」と「動的テスト」に分けられる。

静的テスト

プログラムを実行せずに、ソフトウェアの内部をチェックするテスト

人間による検証（レビュー）

ドキュメントやソースコードを作成者以外が「見る」「読む」といった方法で確認し、ソフトウェアの誤りを検出する
主な目的は、潜在バグの可能性となるコードを目視でチェックすることである。更に開発者がレビューを前提に作業するため、ソースコードの可読性が向上する。レビューはできるだけ複数人で行うことが望ましい。これらは設計工程で実施しており、成果物のエラーを早期に発見するためのテストである。
コンピュータによる検証

ソースコードや形式化された設計などをコンピュータにより自動解析する
ソースコードがプログラミング言語の文法やコーディング規約に則っているか検証する。このような静的テストを支援するソフトウェアを「静的テストツール」と呼び、プログラムの形式的な部分を自動的に解析、検証を行う。

動的テスト

プログラムを実際に実行して結果を確認するテスト

テスト工程で以下のテストが行われる

ホワイトボックステスト

テスト対象の設計や実装の内容から全ての処理経路の動作を確認する
テスト対象を「中の見える箱」として捉えるため、ホワイトボックスと呼称される。この処理経路の網羅具合についての基準はカバレッジ(網羅率)と呼称され、目標とするカバレッジを確保するようにテストケースを作成する。
ブラックボックステスト

テスト対象の内部構造を一切意識せずに、インプット・アウトプットが仕様通りの結果か確認する
テスト対象を｢中の見えない箱｣として捉えるため、ブラックボックスと呼称される。具体的には、テスト対象に対してある入力を与えた場合に、どのような出力がされるか(または状態が変化するか)という点に注目してテストケースを作成する。
グレーボックステスト

製品内部の動きを把握した上で、製品外部から機能・仕様の観点でテスト
ホワイトボックステストとブラックボックステストの中間に位置するためグレーボックスと呼称される。内部を把握した上で行うため、無駄なテストを省き必要なテストの漏れを防ぐために用いられる。

品質の観点から行うテスト

テストはバグを検出するためだけでなく、全体の品質を確保するために行うものである。機能面のテストだけでは品質確保に至らないため、非機能要件に対してのテストが必要となる。これらのテストは一般的には総合テストで実施され、ユーザビリティやセキュリティ、ソフトウェア品質特性などの観点を元に作成する。

性能テスト

要求する処理能力を満たしているか確かめるテスト
｢量を返す力｣と「早く返す力」の二点を量るために行う。これをそれぞれ「スループット」、「レスポンスタイム」という指標で表し、把握する必要がある。「量を返す力」とは時間に対してどれだけ同時に処理できたかを指しており、「早く返す力」とは処理要求から処理結果が返ってくるまでの時間の早さを指している。これらの処理能力を左右するのが「リソース」である。CPUやメモリ、ディスクやネットワークなどのシステムが処理活動を行うために必要な資源を指す。例えるなら処理を行うためのエネルギー源である。処理に対してどれだけのエネルギーを使用するかによって、処理能力の基礎を決めることになる。

上記の観点から、事前に設定された性能目標を満たしているかどうかを判断する。
負荷テスト

短時間で大量のデータを与えるなどの高い負荷をかけ、実際の業務に耐えられる処理能力があるか確かめるテスト
通常では起きないが、処理が短時間に集中することで隠れた問題が発生する場合がある。そのような事態を防ぐために行うテスト。また性能の限界を把握することで、性能限界を超えるようなアクセスが発生する場合の対応策を立てる必要がある。性能テストと併行して、負荷テストを実施することもある。
高い負荷をかけるために、負荷生成ツールを用いることが多い。Apache JMeterやGatlingなどが有名である。
ユーザテスト

ソフトウェアの使いやすさ(ユーザビリティ)を、確かめるテスト
テスト対象は操作感だけでなく、デザイン、柔軟性など多岐にわたる。そのため、大人数の操作データを解析するよりも、少人数でテストを行い意見や行動といった数値化できないデータを収集することが望ましい。そのため、調査結果を客観的に判断する評価軸を設定する必要がある。評価軸としては「ニールセンの10原則」が有名である。
セキュリティテスト

セキュリティ要件に対するセキュリティ対策漏れがないか確かめるテスト
不正アクセスなどにより情報流失を招きかねないソフトウェアの脆弱性を見つけ出すために行う。ウイルス感染や不正アクセスによる事故が多発しているため、このテストを重要視する企業が以前よりも増えている。外部からの脅威だけでなく、内部での情報操作や権限コントロールにも注意が必要である。
保守性テスト

ソフトウェアに欠陥が見つかった際の修正のしやすさや、新しい機能の追加しやすさなどを確かめるテスト
ソフトウェアの保守を行う際に計画されている作業や操作が正しく行えるかを検証する。それらの作業が他のシステムに影響を与えないことを確認する。保守性が確保されていないと、メンテナンスが行いにくく、問題発生時に対応が遅れる危険性がある。また、担当者の引継ぎで困るような事態を防ぐために行う必要がある。
信頼性テスト

ソフトウェアが要件で決めた回数、期間、条件で稼動できるかを確かめるテスト
開発時には問題が起きなかったソフトウェアも長期間利用することで、問題が発生するということが起こりうる。そのため、実際の利用期間や環境を想定したテストを行う必要がある。負荷テストが短期間に集中するものだったのに対し、信頼性テストは長期間の負荷に対する想定を行う。
移植性テスト

将来的に、ソフトウェアを別なハードウェアや環境に移す際の移植のしやすさを確かめるテスト
新たなPCの購入やそれに伴うOSの変更などが想定されるため、それらに対応するか確かめるためにテストを実施する。移植が可能かだけでなく、移植のしやすさも評価対象である。

非機能とは、ソフトウェアがどのように動作をするかをあらわしたものである。これらの検証にはブラックボックステストが用いられており、テスト範囲はソフトウェアが持つ機能以外の全てである。上記全ての非機能要件テストをどのソフトウェアでも毎回行っているわけではないが、これらのテストがあることを意識して絞り込むと、効果的なテストを実施することができるだろう。

効果的なテストを実施するには

多角的な視点からテストを行うために様々な種類のテストが存在する。テストを効果的に実施するためには、目的を理解したうえで下記のような工夫が必要となるので注意しなければならない。

スコープ(適用範囲)を明確にする

それぞれのテストの実施する範囲は明確に決まっているわけではない。しかし、重複してテストを実施することは非効率である。例を挙げると、単体テストで確認した箇所を結合テストで再度確認する必要はない。また、機能テストと性能測定のような異なった観点のテストを併行して進めるのではなく、別途テストを実施することで、より厳密なテストを実施できる。
正しいプロセスで行う

実施する上で、どういった手順で作業をするのかが重要となる。どのような成果物を作成するのか、その成果物を誰がいつどのような観点でレビューするのか、などの「プロセス」を決定し、それに従うことが重要である。こうして作業の品質を高めることで、作成する成果物の品質も高くなる。テストでは、観点の抜けや漏れの防止に役立つ。
テスト支援ツールを利用する

同じ作業を繰り返し実行することが多いため、それらをテスト支援ツールに任せることで効率が向上する(テスト自動化)。また、テスト対象に高い負荷をかけるなど、手動で実施するには難しいテストであっても、ツールを使えば実施できる場合がある。このようにツールを適材適所で利用することで、作業効率が向上する。しかし、設定したプログラムにミスがあると、手戻りが起こる危険があるため、ツールが正しく動いているか確認する必要がある。またツールに頼りすぎると十分なテストが行えず、かえって手動で行うよりも時間を要してしまうこともあるので、運用には注意が必要である。
テスト管理をする

作業が予定通り進んでいるか確認し、結果の分析や評価を行う。そこから得られた教訓を次回の開発に活かしていく。
プロジェクトマネージャや品質管理者だけでなく、テスト実施者も大いに関わる。それがバグ管理である。これは、バグトラッキングなどとも呼称され、テストを実施して発見されたバグを報告し、そのステータスを管理する必要がある。
情報を共有する

先ほどのバグ管理であれば、そのバグはどのような観点のテストケースから発見されたのか、バグの発生原因は何かといった情報を記録し、共有する。これにより、更なるバグ発見へとつながる。そして、これらの情報を活用することで、バグの再発防止やプロセスの改善につなげることができる。