ソフトウェアテスト

現代社会では、ソフトウェアが支えていると言っても過言ではありません。ソフトウェアを安心・安全に利用するためには、開発工程でそのソフトウェアが正常に動作するかを確認する「ソフトウェアテスト」が必要です。

ソフトウェアの品質を担保する視点に欠かせないのは、起こり得るリスクを回避し、「ソフトウェアテストの必要性」を理解することです。普段の業務で漠然と使っている「欠陥」や「テスト」と言った言葉に対し、焦点を合わせてみましょう。

この記事では、「ソフトウェアテスト」の基礎的な内容から、テスターによって偏りが出ない統一したテスト手法ついて解説します。
ソフトウェアテストに携わる方や、開発関係者の方は参考にしてみてください。

ソフトウェアテストとは

ソフトウェアテストの目的

ソフトウェアをリリースする上で大切なことは、「不具合のない製品」を作ることです。不具合が多く使えない機能が多いと利用者の不満は増大し使い物にならないシステムになります。
ソフトウェアテストで不具合を発見し、品質改善や品質不良を防ぎましょう。

ソフトウェアテストでは、テスト対象の特徴に合わせてテストケースを組み、さまざまなテストを繰り返して不具合を見つけ出すことで、ユーザー（発注者）にとって有用なソフトウェアになることを目指します。テストケースとはソフトウェアテストを実施する際に用意する、実行条件や入力データ、期待される出力や結果などの組み合わせです。人が開発する以上、開発工程での不具合をゼロにすることは不可能です。ソフトウェアテストは質の良いソフトウェアを開発する上で、重要なプロセスの1つと言えるでしょう。

ソフトウェアテストの7原則

ソフトウェアテストでは、全ての開発関係者が心得ておくべき7つの原則があります。7原則を頭に入れておくことで、より正確なテストが可能になります。

No	原則	ポイント
1	テストは欠陥があることしか示せない	・「現状認識」することが必要である
2	全数テストは不可能	・テスト技法を使い効果的なテストを行う
3	初期テスト	・欠陥の修正は、後になるほどコストがかかる
4	欠陥の偏在	・欠陥の多発地帯を知ろう
5	殺虫時のパラドックス	・テストには、新しい視点が必要である
6	テストは条件次第	・ユーザーの要求とテスト条件を意識する
7	「バグゼロ」の落とし穴	・欠陥が無くなってからも、ユーザーの要求に基づいた継続的な仕様書やテストケースの見直しは必要である

テストは欠陥があることしか示せない

ありとあらゆるテストケースを消化して欠陥が見つからない状態だったとしても、それは欠陥が「ない」こと証明しているのではなく、これ以上欠陥が「ある」ことを証明できないということです。テストでは「故障する=欠陥がある」ことは示すことができますが、「故障しない=欠陥がない」ことは示すことはできません。レアなテストケースが抜け漏れていて、そこに欠陥が潜んでいる可能性があります。テスト経験者だと、今までの経験と照らし合わせて進めていきますが、過去の数々のプロジェクトでも、本番障害はある割合で発生しています。

もちろんリリース前にテストケースはかなり手厚く有識者にレビューをしてもらっていて、更に場合によっては「強化テスト」を実施することもあります。それでも本番障害は発生します。
本番障害の内容を全て詳細に把握しているわけではありませんが、原因として考えられるのは、レアなテストケースの抜け漏れが半分以上を占めています。

全数テストは不可能

全数テストとは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。小規模な製品テストで入力される可能性のあるデータパターンがある程度限られていれば、全数テストは可能かもしれません。大規模システムの場合、関連のある機能をサブシステムという括りで分割させるケースがあります。各サブシステムが取り得る全ての状態の組み合わせ、入力条件の組み合わせでのテストはもってのほかです。ソフトウェアの性質や目的、使われ方などから重点的にテストする箇所を絞ったり、優先順位を決めたりしてテストします。

初期テストが重要

開発が進めば進むほど、不具合が発生した時の影響が上流工程まで遡るため、その分修正・手戻りのコストが多くなります。
開発の早い段階でテストを行って不具合を潰しておくことが重要です。

欠陥の偏在

欠陥というのは、ソフトウェア全体に均等に分布しているのではなく、ある特定の機能、モジュール、クラスに集中しているというものです。業務要件が複雑な機能や難易度の高い機能に偏りがちな傾向にあります。開発する中で、逼迫したスケジュールの中で作られた機能や、有識者が少なく質の高いレビューが出来ていない機能も該当します。
効果的にテストを行うためには、その予測結果に基づいて、重点的にテストをする箇所を絞り込みます。

殺虫剤のパラドックス

同じような観点のテストを何度も繰り返していると新しい欠陥が見つからなくなります。開発者はその観点のみを意識し設計・実装を進めます。同じ成分で構成された殺虫剤を繰り返し使用していくと、それに耐性を持った虫が出現することで、いずれ効果がなくなってしまうということに似ていて、このように例えられています。経験の少ない開発メンバーで構成されたチームの場合、相対的に視野が狭くなる傾向にあります。そこに経験のあるメンバーが加わることで、視野を広げることが可能と言えます。絶えず視点を変えてテスト設計をしましょう。

テストは条件次第

「条件」とは、構築するシステムや会社を取り巻く環境を指しています。例えば、構築するシステムが金融系のシステムであれば、金額計算やデータの整合性を確保する点において重きを置いてテストをする必要があります。個人情報を大量に扱うシステムであれば、セキュリティに重きを置いてテストをします。全て同じ条件のテストではなく、システムの性質や会社を取り巻く環境によって、テストのやり方は変える必要があります。さまざまな条件を見極めてテスト設計とテストの方法を決めていきましょう。

「バグゼロ」の落とし穴

「バグ0＝高品質なシステム」というわけではありません。高品質かどうかを測る指標は、バグの件数だけでなく性能や信頼性等の指標によっても評価します。
極端な例ですが「バグ0です、でも画面表示するのに30秒もかかります」といったシステムは高品質とは言えません。開発現場で性能テストや負荷テスト、その他非機能要件も意識して様々な角度からテストを経験していたら、自然と「バグ0＝高品質なシステム」という認識が生まれます。テスト初心者であると、「バグ0＝高品質なシステム」という誤った理解を持った現場も少なくはないと思います。
また、バグを修正する際に、機能や性能、システム全体に影響はないかを確認することも大切です。

ソフトウェアテストで重要な２つの視点

ソフトウェア品質保証において､重要なV&Vという２つの観点が以下です。

ソフトウェアテストの知識と技術

「ソフトウェアテスト」はソフトウェア開発に必要不可欠だということは、だれもが知っていることだと思いますが、本当に網羅的にテストができているかや限られた時間とコストでいかに効率的にテストを実施するかなど悩み事を抱えているソフトウェア開発現場は多いのではないでしょうか。

それらを解決していくにはソフトウェアテストに関わる正しい知識と優れた技術が必要になります。

下記の内容を説明ができる人はどのくらいいるでしょうか。
これらの理解を無くして効率的かつ網羅性の高いテストの実現は難しいと言えるでしょう。

・上流工程ドキュメントがソフトウェアテストに及ぼす影響
・テスト計画やテスト設計の必要性
・テストの目的ごとのテストアプローチの変化

ソフトウェアテストの計画

ソフトウェアテストは闇雲に必要なテストを行うわけでなく、期日までに十分なクオリティを確保するべく計画的に実施します。
テスト計画においては、どのようなテストを行うのか、どのタイミングで行うのか、どの程度のリソースを確保するのかなどを設計します。

ソフトウェアの複雑化・大規模化がもたらす問題

ソフトウェアが複雑化、大規模化すると、それに比例して、障害数が増えるなど、以下の事象が出やすくなります。

・障害の除去には、工数がかかり、修正確認の工数増大
・障害は、その発見時期が遅れるほど、対処工数⇒テスト終盤の障害は、日程に影響を及ぼす、可能性大
・結果的に、日程遅延が発生しやすくなる

重複、抜け、漏れが、懸念される

市場で重障害が、発生する確率が高くなります。ソフトウェアの複雑化・大規模化は、開発および評価にかかる負荷が増える一方になるため、以下の対応が必要となる

・開発部門 ：追加・改良開発を減らす⇒上流工程での品質作り込み
・テスト部門：効率的なテスト⇒計画的なテストが必要

ソフトウェアテストの実施

テストの実施では、実施前の準備作業が重要です。基本的にはどの開発工程も着実なテストの実施に必要な作業となります。
プロジェクトの規模やシステム特徴によっては、省略できるものもあるかもしれません。しかし計画もなく省略してしまうと、テストの進行に混乱が生じたり進捗が遅れたり、目的が達成できなくなったりなど問題が発生する可能性があります。
主要な開発工程を理解した上で目的を持って理解します。

ソフトウェアテストの観点

製品のソフトウェア品質を左右するテスト、そのテストを行う上で重要なのが「テスト観点」です。テスト観点とは、製品のどの部分を、どのようにテストするのかを決めることです。
例えば、登録データシステムの場合、入力画面は正しく表示されているか、入力されたデータは正しい形式になっているか、登録されたデータに不備はないかと、テスト観点はシステムによってさまざまです。

これらを細部まで網羅することで、より厳密なテストが行うことが可能であり、製品のソフトウェア品質向上へと繋がります。

テスト観点1：基本構造を組み立てるもの

「～する」という動詞で表現されるものでソフトウェアに対する「入力トリガー」から見つけ出します。
具体的には「登録する」、「照会する」、「検索する」などを探します。テスト観点 1 は、機能そのものにあたります。

テスト観点2：基本構造から派生構造を作り出すもの

テストデータや機能のバリエーションを増やすために、それらを修飾する形容詞や副詞で表現されるものです。ソフトウェアの「異常を誘発するための要因」を挙げます。
例えば「大量の・少量の」、「連続して・飛び飛びに」、「素早く・ゆっくりと」、「超過して・不足して」といったものがテスト観点 2 にあたります。

テスト観点3：組み合わせ

「集合、関係、組み合わせ」を示すものです。このテスト観点は、ソフトウェアというよりもシステム全体としてのテスト観点となります。例としては、「エンド・ツー・エンド型で」、「同時に組み合わせて」、「連結・連動中に」などです。

テスト観点4：期待結果の網羅性の観点

「どうなる」という期待結果の属性を表すものです。テスト観点 1、2、3 は、見つけ出したテスト観点自体をさらに整理・分解してテストを詳細化することが可能です。
例えば「登録する」という観点に対して、様々な登録方法を見つけることで分解することができます。

（※図6-1、テスト観点1～4：高信頼化ソフトウェアのための開発手法ガイドブックP150）

ソフトウェアテストの分類

開発工程による分類

単体テスト

システム開発で、最初に単体テストを行います。単体テストでは、作成したプログラムを一つずつ単体でテストして正常に動作するかを検証し、個々のモジュールについて機能や性能、運用性などをチェックします。

結合テスト

結合テストでは、単体テストで確認した複数のモジュールを組み合わせて不具合がないか、連結がうまくいくかを検証します。
小さな結合から大きな結合まで、いくつかの段階に分けて実施します。

システムテスト

プログラムとハードウェアを合わせてシステム全体のテストを行います。
システムテストが、開発者側の最終テストです。ハードウェアを実際に動かしながら、通常のバッチ処理、月次処理、四半期処理、年次処理など、すべてのサブシステムで想定される処理を一通り実施します。システムテストは結合テストが終わり、その修正が完了したタイミングで行います。
ただし、テスト計画自体はシステムの基本設計の段階からすでにスタートしています。システムテストの目的は、要件定義で決めた要件が満たされているかどうかを確認することです。
システムテストで問題がなければ発注者側に引き渡され、実際に稼働して運用テストに移ります。運用テストで問題がなければ、そのまま本番に移行します。

受け入れテスト（顧客側）

発注者側が納品されたソフトウェアに対して行うテストが、受け入れテストです。

品質の観点による分類

どういった品質を確かめる目的で行われるのかという視点に基づく分類です。

実行方法による分類

テストの実行方法による分類です。

技法による分類

ソフトウェアテストの品質は、テスト項目の抽出に大きく依存しています。テストデータの抽出以降の作業が正確だとしても、テスト項目の抽出が不十分であれば、テストに漏れが発生することになり、テスト本来の目的を達成することはできません。テストのためにはどのような操作をして何を確認するかを定めた「テストケース」を作成します。
テストケース作成に用いる技法による分類です。

ホワイトボックステスト

ホワイトボックステストはプログラムの論理構造が正しいかどうかのテストです。デバッガでステップ実行などしながら、それぞれの行、それぞれのブロックで実行される文は正しく書かれているか、if分やswitch文の条件は適切か、きちんと終了まで実行されるかを確認します。このテストの実行によってカバレッジ率が算出され、プログラムの品質を計る一つの指標となります。
ホワイトボックステストで焦点となるのはあくまでプログラムの論理構造なので、以下のような不具合は見つけることは出来ません。

・要求仕様自体の誤りや不備
・データに関するバグ
・マルチタスクや割込みに関するバグ

ブラックボックステスト

ブラックボックステストは名前の通りプログラムを一種のブラックボックスとして扱うテストで、様々な入力に対して妥当な出力が返されるかどうかを確認します。
多くのプログラムでは可能な入力の組み合わせは膨大で、それらをすべて試すことは不可能です。そこで効果的な入力をもれなく選び取る方法が考案されています。

同値分割と境界値分析とエラー推測

技法	説明
同値分割	データをグループ分けし、各グループから1つまたは複数のデータを抽出したものをグループを代表するテストデータとする
境界値分析	有効と無効の境界データを取り出してテストデータとする
エラー推測	経験的に知っているエラーが起こりやすいパターンからテストデータを作る

同値分割と境界値分析は、ブラックボックステスト手法の中でも基本的な手法です。同値分割では入力全体の集合を「同値クラス」という部分集合に分割します。
同値クラスは、同じ同値クラスの入力であればプログラムの動きに本質的な違いが出ないような入力の集合です。

多くはプログラムが期待する入力値である「有効同値」、そしてそれ以外のあらゆる入力値である「無効同値」に分けられます。
それぞれの入力項目ですべての同値クラスの入力を行えば、あらゆる入力に対してテストされたことになります。

境界値分析では同値クラス同士の境界に注目します。同値クラスの境界は条件文によって分けられることが多く、これを書き間違えることでバグになります。
そこで境界をまたぐもっとも近い入力の組を入力とすることで処理の切り替えがきちんとなされていることを確かめます。

まとめ

「ソフトウェアテスト」は、ソフトウェア開発において必要不可欠です。システムがリリースされてから問題が発生した場合、金銭的な損失だけでなく企業としての信頼にも大きなリスクを背負います。ソフトウェア開発が抱える問題はソフトウェアテスト技術を使って解決します。

ソフトウェアテストの実施は、実施前の準備作業が重要です。基本的にはどの開発工程も着実なテスト実施に必要な作業となるからです。
製品のソフトウェア品質を左右するテストで重要なのが「テスト観点」です。テスト観点はシステムによってさまざまです。テストケースの細部まで網羅することで、より厳密なテストが行うことが可能であり、製品のソフトウェア品質の向上へと繋がります。

弊社、株式会社QualityCubeのサービス、クオリティドクターテストは、チケット制テスト工程代行サービスとは、予めチケット（工数の単位）を購入しテストが必要となった時に必要な部分だけ委託する仕組みです。
必要な時に必要な分だけ委託することができ、コスト削減をすることが可能です。（※お気軽にご相談ください）