「良い」ソフトウェアテストの定義～プロが教える４つのポイント～

ソフトウェアテストの原則や要素は、ソフトウェアテスト技術者資格認定の運営組織であるJSTQB(Japan Software Testing Qualifications Board)や、システム開発関連の書籍を通して、学ぶこともできます。みなさまはすでに、さまざまな手段や方法で学習されているかもしれません。ただし、原則や要素を知識として身につけたからといって、実際にそれが実行できるかどうかは別の話です。プロジェクトの一部であるテストは、工数や予算によって十分に実施できないという例がよくあります。

テストを中心に年間4,000プロジェクト以上、導入企業2,000社以上の取引実績をもつSHIFTが考える「良い」ソフトウェアテストとは、従来からあるテストの重要なポイントを“効果的に実現すること”と考えます。

そのために必要な４つのポイントを、SHIFTが運営するヒンシツ大学の講義からピックアップしてご紹介します。

「良い」ソフトウェアテストの1つ目のポイントは、効率的なテストができるかどうかです。必要最低限の工数で十分なバグを見つけるには、さまざまな考慮が必要です。

ウォーターフォール型開発モデルでは、コンポーネントテスト、統合テスト、システムテスト、受入テストのように、時間軸の工程としてテストが分類されていました。この分類は非常に有用なのですが、保守開発やアジャイル開発の場合は、明確に区切られた工程がありません。そこで、テストの内容を表す言葉として「テストレベル」を導入して、コンポーネントテストレベル、統合テストレベル、システムテストレベル、受入テストレベル、という名前でテストを分類するようになりました。さらに細分化して、コンポーネントテストを単体テストとモジュールテスト、統合テストを内部結合と外部結合に分解することもあります。

テスト工程がテストレベルに変わったとしても、この順番でテストを行うことは大きな意味があります。前工程で行われるテストほど、テストの実行、バグの検出、バグの修正、再テストが短時間で済み、かつ工数も少なくて済むのです。同じバグでも、コンポーネントテストより統合テストで見つけた修正には、数倍の時間と工数がかかります。コンポーネントテストを万全に実施することが、あらゆるソフトウェアのテスト効率化につながります。それぞれのテストレベルの完了基準を定めて、基準をクリアしてから次のテストレベルに進むようにしましょう。

日本では、コンポーネントテストをコーディング含めて、入社年数の浅いメンバーや、パートナー会社が担当するケースが多く、コンポーネントテストを指導して完了基準を提示できる人材が不足しています。そのため、コンポーネントテストが不十分なまま統合テストを始めるのが常態化し、課題意識はあっても修正できないという話をよく聞きます。

それぞれのテストレベルで確認する観点を明確にすることが重要です。コンポーネントテストでは、ソースコードやモジュールの単位で部品としての動作を確認し、統合テストでは、システムがきちんと組み立てられているかどうかを確認します。システムテストではシステムとしての利用が問題ないかを確認し、受入テストでは業務のなかにシステムが収まることを確認します。観点が異なるため、テストの目的は異なるはずです。もし同じような確認をしていたらテストが重複していることになるため排除が必要です。

計算結果を確認するテストを例にとって、テストレベルごとの目的を記載してみます。

・コンポーネントテスト：プログラムが正しく組めていることを確認する
・統合テスト：画面・プログラム・データベースなどが正しく連携しているかを確認する。
・システムテスト：システムが使われる時系列に沿って正しく扱われるかを確認する。
・受入テスト：業務の流れのなかで適切に扱えるかを確認する。

目的によって確認のバリエーションも異なることがわかります。コンポーネントテストでは計算のバリエーションを考えますが、統合テストでは連携のバリエーションとなるので、通常、少ないバリエーションで済みます。システムテスト、受入テストと進むと、さらにバリエーションの数は減っていくでしょう。

このようにテストの目的を意識すると、テストの観点やバリエーションを最適化できます。しかし、多くの現場では、テストレベルが変わっても同じ観点で多くのバリエーションをテストしており、結果的にテストが重複していることがあります。場合により、担当者間の隙間を作らないようにテスト範囲を広げたり、修正後にはリグレッションテストを行うなど、意図的に重複したテストを行うことはあります。このような重複は、テストの目的に適っているので、どんどん取り入れましょう。

トヨタで自動車を造る工程を最適化するために長年のノウハウを集めた「トヨタ生産方式」があります。
この中に、7つのムダを排除する、という考え方がありますが、そのうちの「動作のムダ」を取り上げて、テストの効率化でもできることを考えてみましょう。

自動車を組み立てる現場は流れ作業です。各作業者は回ってくる自動車に対し自分に割り当てられた作業を実施し、完了したら、次の担当者に引き継ぎます。完成する台数は、ライン上の一番遅い作業が影響するため、その作業を徹底的に分析し、動作のムダを認識して省き、改善できないか考えます。

テストの実行も同じです。テストの内容を表示したり記録したりするウィンドウと、テスト対象のシステムを見て操作するウィンドウを切り替えながらする作業はムダな動作です。デュアルディスプレイを使うことはもちろんですが、重要なのは、テストケースの書き方です。書き方が粗いため実行手順がよくわからない、確認項目が曖昧で判断に迷うなど、このような状況が発生すると一気にテスト実行の効率が下がります。最悪の場合、仕様書通りという書き方をされると、テストの途中に仕様書を見て、合っているかどうかを確認するという、動作のムダが発生します。

システムがこの先もメンテナンスしながら使われることを考えて、誰でも効率的にテストができるよう、動作のムダが発生しないように、今からテストケースを改善しましょう。

機能あたりのテストケース数はどのように決めていますか？テスト設計で作った数、仕様書のページ数、ファンクションポイント、ソースコードの行数など、さまざまだと思います。

システムの機能には重要度に差があります。

オンラインショッピングを例にあげます。まず注文には、配送先の入力用にデータも揃っていなければなりません。キャンセルはどうでしょうか。注文をキャンセルするのは数クリックでできるので、さほど複雑でもありません。配送前であれば、後の手続きも限定的です。このように考えると、キャンセルより、圧倒的に注文機能の重要度が高いということがいえます。

こうしたことからも、テスト設計で作った数や仕様書のページ数が、テストケース数の比率を的確に表しているとは思えません。重要度を考慮して、テストケース数を割り振り、手厚くテストを実施しましょう。重要度の低いところばかりをテストしてしまうと、重要な機能のテストが十分に実施できないということが起こりかねません。

加えて、重要度の高い機能は先にテストしましょう。万が一何らかの問題が起きて、テストが打ち切られた際、重要な機能がテストできていないと非常に大きなリスクを抱えることとなります。重要な機能のテストは、時に複雑で手がつけにくく後回しになりがちですが、重要度を評価して、意識的に先にテストすることが効果的です。

テストのインプットには、要件定義書や基本仕様書が使われますが、多くの場合は、これらのドキュメントの書き手と読み手が異なるのではないかと思います。インプットがスムーズであればあるほど効率の良いレビューができ、テストだけではなく、開発の効率化や品質向上にもつながります。

読み手が受け取りやすい文章を書くことは容易ではありません。言葉の選び方で曖昧な表現になってしまうこともあります。そのため、これらのドキュメントを念入りにレビューすることは非常に重要ですが、効率の良いレビューとはどのようなものでしょうか？

まず、レビュー観点を決めます。業務の責任者、システムの利用者、システムの設計者、テストの設計者のように、ドキュメントの作成や利用の立場を選ぶのが一例です。レビュー観点によって、レビューアに担当を割り振ります。レビューアはその観点で確認すべき内容のチェックリストを準備すると、より効率的にレビューができます。レビューアが各自でレビューした結果を持ち寄って、指摘内容を確認していきます。その場では修正の方向性まで決めて、実際の修正は持ち帰りにするのも、効率化のポイントです。

ドキュメントは必要なことが全て書かれていなければならないとはいえ、あまり丁寧に書きすぎて冗長になってしまうと、読み込みや後の修正に工数が掛かったりします。プログラムでサブルーチンを書くように、ドキュメントも共通部分をまとめて構造化できると良いでしょう。重要なポイントとして、比較検討して選んだ内容については、決まったことに加えて決めた理由も書くことをお勧めします。技術や情勢が変化して判断材料が変わったときに、見直しのヒントになる重要な情報となります。

DXが加速する現在において、ITも変革していかなければなりません。AIが進化するなかで、ドキュメントやプログラムの作成、テスト設計を自動でやることはまだできませんが、頭を使わずに、繰り返しやっているテストの実行は、自動化しやすいポイントです。

テストの自動化はむずかしそう、やり方を知らない、といった話を聞きますが、以前に比べてツールの入手は格段に容易になっています。また、ヒンシツ大学の講座でも、一日勉強してコツを確認すれば使えるようになります。100%自動化を適用できないなら標準にできない、という意見もありますが、自動化と人が実施するテストを上手に使い分けることが正しいやり方です。まずは、自動化の手法やツールを理解してから、自分のプロジェクトに合っているかどうかを評価しましょう。

また、テスト実行の他にも自動化できそうなところはありませんか？たとえば、日々の進捗やインシデント台帳の管理、テスト結果の集計など、管理が中心の作業のなかに情報の記入やコピー＆ペーストだけ、集計だけといった単純なことを繰り返していることがあります。テストの実行だけではなく、単純作業の繰り返しになっているところも自動化の可能性を探っていきましょう。

「良い」ソフトウェアテストの2つ目のポイントは、網羅的に行うテストです。作ったシステムを抜け漏れなく、隅から隅までテストをしている、これが自信をもっていえるようになる必要があります。いろいろな場面で網羅的にテストするポイントは異なりますので、これについて見ていきましょう。

単体テストは、ソースコードレベルで網羅性を確認することができます。通常は、「判断・分岐網羅」というレベルでテストを行います。これは、複合条件を分解して考えたときに、分岐になるところの全てのパターンのテストを実行するという方法です。プログラムを書く人は基本的にはこの考え方を知っているはずなので、問題なく適用できるでしょう。

この方法でどのくらい網羅できているかは、ツールで確認することができます。これで実行と分岐パターンを網羅できれば、書いたところを全て実行確認したということが証明されます。カバレッジ100%ともいわれます。

ここで、もう一歩踏み込んでテストをしたい人は、条件の不等号部分に注目します。不等号にイコールが付いているかどうかで、バグになる可能性が高いというのは、昔からいわれていることです。よって、不等号の条件を見つけたら、その境界値の両方の値をテストしましょう。実数や時間などを使っていることで、ぎりぎりの値は指定しにくいこともありますが、少なくとも書かれた値をテストすることでイコールの有無の間違いは見つけることができます。

プログラム設計の得意な人は、ソースコードの量が少なめになる傾向があります。さらに、網羅するための単体テストのケース数が圧倒的に少ないことが多いです。高度なプログラミングテクニックによってつくられた見やすいソースコードは、必要とするテストケース数も削減できるのです。

一つだけ注意点があります。プログラム設計の上手な人は、フェールセーフのコードを埋め込みます。「ここは絶対実行されないはずだけど、考慮漏れや将来の拡張で万一実行されると危ないことが起きるかもしれないので、そこを通ったときにエラーにする」というコードです。実行されないはずのところに書いてあるため、テストで実行するのは至難の業です。ところが世の中にはそういうフェールセーフコードをデッドコードとしか捉えない方もいて、絶対にカバレッジを100%にするように求めることがあります。その結果、問題を防ぐはずのコードが取り払われて、何かの改修をしたときにエラーになってしまいます。フェールセーフコードはカバレッジの対象外とし、それ以外の部分を網羅するようにしましょう。

機能テストでは、APIのレベル、基本設計書のレベルで、書かれている機能を網羅的に確認します。単体テストでは書いているソースコードを全てテストしたことは保証できますが、機能に必要なコードを書いているかどうかはテストできていません。そこで、機能テストで改めて確認することが必要になります。

まずは、テスト対象の機能に関連する状態、入力、出力、状態変化を全て見つけ出す必要があります。画面の仕様書だけを見ていると、データベースにどう格納されるかまで書いていないことが多いので、関連する情報を全て集めましょう。タイムゾーンなど、仕様書に明記されていない情報も可能性があります。

次に、入力がどのような値をとるかを考えます。ここで、より重要になるのはエラーの条件です。制限長を超えて入力されたり、数字が必要なところに文字が混ざっていたりなど、エラーのパターンを網羅的に拾い出す必要があります。標準的なパターンはチェックリストにして見落としを防ぎ、標準ではないエラーパターンを見落とさないように注意しましょう。

正常の入力値は、各入力項目の代表的な値を決めてテストします。単体テストで網羅していても、念のために境界値をテストするということもあります。こうして、全ての入力の候補を組み合わせてテストすることを考えます。機能テストのレベルでは、全ての値の組み合わせをつくると膨大になり、工数に見合わないことがあります。そこで、2つの値の組み合わせで問題が起きることが多いという調査論文に基づいて、二因子間網羅(直行表、ペアワイズ法などとも呼ばれる)という手法を使い、組み合わせ数を調整して妥当なテストケース数を設定します。

良い機能テストのポイントは、入出力や状態を網羅していることと、エラーのパターンを網羅していることです。組み合わせ条件は、機能の重要度評価に応じて、合理的な手法で削減するのが良い方法となります。

業務は複数のシステムが動作し、さまざまな人が関与して成立しています。シナリオテストでは、誰がいつ、どのシステムをどのように操作するかといった時系列の手順をシナリオとして、それに従ってテストを行います。

利用者が端末の前に座って、何らかの操作をして離席するまでは、機能テストのレベルで確認できます。シナリオテストでは、別の利用者が前の利用者の作成したデータを受け取る、あるいはデータが書き換えられながら業務が進行していく、あるいはいろいろなデータが集積された結果として集計データが作成されるというような状況をテストします。システムテストのレベルでシナリオテストを行う場合は、システム全体として矛盾がないことが主な確認ポイントになります。このシステムを使う業務を想定して、それぞれの業務がシステムを使って進行したときに、業務の遂行やシステムに残ったデータに問題がないかということを確認します。従って、シナリオテストではシステムを使う業務を一通り確認する、といった業務観点が最も重要です。

次に見るべきものは、人の活動や業務のタイミングの変化を起こすような、情報の受け渡しやデータの遷移のバリエーションです。一つの業務のなかでもいろいろなパターンの動き方がある場合は確認します。最後に、業務上の異常を探してシナリオにします。人間が行う業務は常に正しく動くとは限りません。注文が間違っていたことによるキャンセルや、トラックが動かずに納期遅れなどさまざまなケースがあります。これをシナリオとして取り入れます。

さらに「良い」ソフトウェアテストの３つ目のポイントは、使う人の立場を意識することです。システムは誰かが使って、はじめて価値が出ます。システムを使う人が、どういう立場で、どのような状態で、何を目的にシステムを使うのか考えてみましょう。

システムの品質特性として、ユーザビリティーがあげられます。これは、特定の人が、特定の状況下において、特定の目的でシステムを使った時の、有効性、効率性、満足度と定義されています。ユーザビリティーにフォーカスしたテストを行うこともありますが、一般的なテストにおいても、ユーザビリティーを意識することは重要なことです。コロナ禍において、状況が想定の範囲をはるかに超えていたという事情はあるものの、システムが使う人に負担をかけてしまう事例がいくつも報道されました。

ユーザビリティーは要件定義において検討するのが本来の姿です。要件定義や基本仕様で決まったことは、統合テストの段階で課題を指摘されることはありません。それでも、統合テストは、これまで机上だったものを、はじめてシステムとして実際に動作させるフェーズです。机上の設計と実際に動作させた時の感覚は異なるかもしれません。もし、利用者の有効性、効率性、満足度に課題を感じたならば、それを課題として報告するのが良いテストです。少なくとも、効率性について懸念がある、というような申し送りがされれば、受入テストでしっかりと再確認され、現場のエンドユーザーを苦しめる状況はきっと抑止されるでしょう。

かつての情報システムは、事務処理における伝票管理や集計計算を電子化することを主要な目的として構築されていました。取引に関する機能がもれなく提供されている、計算結果が正しい、という機能的な品質がシステムに求められ、また、システムをつくる側もこの機能的品質に最適化した開発標準を整備してきました。現在においては、システムの利用範囲をさまざまな方面に拡大するような取り組みが行われています。利用場面によっては、機能的な品質よりも、もっと別の観点が優先されることが増えてきました。

いくつか例をあげます。ワクチン予約のシステムは、予約開始に間に合うことが重要でした。チェックの甘さなどが取り沙汰される報道もありましたが、さまざまな兼ね合いで選択がなされたはずです。オンラインショッピングのシステムは、ショッピング自体の機能から、消費者にどうアピールするかに重きを移しつつあります。ショッピングの機能的品質が完璧でも、それは売上拡大にはつながりません。メールや広告で消費者をサイトに呼び、消費者が気になる商品を提示することで、消費者の購入意欲を呼び覚ますような取り組みが求められます。

もっと革新的な企業においては、ITを中心としたビジネスモデルを創造し、それをシステムとして提供し、運用実績からさらにビジネスモデルをブラッシュアップするという取り組みを行っています。最近、急成長したフードデリバリーは、この一例に当てはまるでしょう。ビジネスモデルを安定させるまでの試行錯誤がポイントで、アジャイルなシステム提供が求められます。

過去の機能的品質を中心とした開発標準に囚われすぎると、そのシステムが優先すべき要因に見合わない可能性があります。良いテストを行うためには、ビジネスオーナーの立場で、システムとして優先すべき要因を念頭において計画する必要があります。システム単位だけではなく、ひとつのシステムのなかでも、機能的品質への要求に濃淡があることが考えられます。テストを行うにあたって、何に重きを置くか、どのように濃淡をつけるか、どのように計画するか、これからのシステムではビジネスの意識をもってより細分化して考えていく必要があります。

インフラ設計や運用設計は基本設計とは別に行われていることが多く、運用はシステムの機能と切り離して考えられることが多いです。以前の典型的な運用現場では、運用面の作業が発生した場合、紙の手順書を作ります。その承認を得たうえで、手順書にある内容を1項目ずつ手作業で設定して確認していたものです。

現実には、設定や運用の問題から社会的に重要なシステムが止まる例も起きています。ストレージの故障が手順書通りにバックアップに切り替わらなかったり、メモリー不足の警告を見逃したことにより翌日に波及で取引が止まったという事例もありました。物理的なハードウェアが関わることが多いため、テストを網羅的に実施しにくいという事情があるのは致し方ない部分です。しかし、だからといってテストをせずにシステムが止まってしまうというのでは問題外です。

近年は、クラウドの導入が増えてきています。これは単に、サーバーの置き場所がクラウドになったということではなく、インフラ設定や運用の概念が変わるということです。たとえば、インフラの設定はAPIでできるようになり、手作業の代わりにスクリプトを書いて実行します。メンテナンスのためにシステムを止める必要はなく、新しいクラウドインスタンス上で最新化しておいて、確認後に切り替える方法をとることができます。異常時の振る舞いも、クラウド内でシミュレートして確認することができます。

DevOpsという概念がありますが、これは平成の間に切り離されてしまったアプリ開発とインフラ・運用を、また統合しようという考え方です。開発と運用を一体に考え、運用を効率化する機能、運用時に行われるテストを合わせて、最適なシステムを検討します。DevOpsまで行かなくても、インフラ設定をスクリプトで行うようになると、これもソフトウェアとしてテストを行うことになります。従って、これからの「良い」ソフトウェアテストには、インフラ・運用まわりのテストも含まれるようになる、といえるでしょう。

システムの寿命は延びています。今のシステムのなかにはこの先数十年使われ続けるものも多いはずです。そうなると、テスター含め開発者は入れ替わっていくので、システムのドキュメントは後継者に十分な情報を伝えるものでなければなりません。テストのドキュメントも同じです。システム開発において、決まった情報だけ書かれたドキュメントは、十分とはいえません。

何かを収集し、比較検討する過程が重要で、最後に残った結果は、もしかしたら時代の変遷とともに変えなければならないかもしれません。テスト設計のドキュメントでは、過程と結果が明確に異なります。テスト対象の項目を抽出し、テスト観点により展開し、項目のとるべき因子水準を整理し、組み合わせを考える、ここまではテストケースをつくるための過程です。テスト設計の最終的なドキュメントはテストケースですが、過程のドキュメントがなければメンテナンスすることができません。新しい項目、新しい観点、新しい水準、これらが発生すれば該当する過程まで立ち返ることが必要になりますし、テスト密度の調整で観点や組み合わせ数を増減させることも多々あります。観点の取捨選択や、組み合わせ手法の選択を行った場合には、その検討過程も残しておく必要があるでしょう。

仕様書に限らず、議事録のようなドキュメントでも、決まった情報だけでなく検討の過程が残されるべきです。そうでなければ、将来の見直しのときに、白紙から検討しなければならなくなります。古い技術を使っていたので変えたいが、それを選択した理由が残っていないために新しい技術で置き換えて問題ないという判断ができず、ずっと古いまま使い続けている、というような話も聞きます。「良い」ソフトウェアテストには、将来のことも考えて、必要なドキュメントに十分な情報を残しておくことも含まれます。

「良い」ソフトウェアテストの４つ目のポイントは、成長や改善に繋がる知見を今後に残していくことです。

テストは開発の最終段階で実施するため、スケジュールがタイトになることが多いです。このスケジュールを守るためには、正確な見積りが不可欠です。

見積りでは、テスト設計やテスト実行の工数、レビューや管理の工数、バグが発生した時のレポート工数といったものを整理して、想定のテストケース数、バグ数に対して工数がどのくらいになる、という計算を行います。これらの数字にブレがあると見積りと実際の工数が乖離しやすいので、数字の精度を上げることが重要です。テストの実績から工数などを取り入れて、より精度の高い見積りを用意しましょう。

「テストを行い、バグを発見して報告して直してもらった」

テストの目的としてはある意味、正しいかもしれませんが、あるべき姿とはいえないでしょう。

テストで見つけたバグには、本来前の工程で見つけなければならないはずのものが含まれることがほとんどです。検出したバグについて、重度、原因、本来見つけるべきフェーズなどを開発側と一緒に整理して、次の開発でレビュー観点や単体テスト観点に活用してもらいましょう。

開発時に見つかるバグが増えると、テストで見つかるバグが減りますが、これは開発側にとってもテスト側にとっても不毛なバグレポートのやり取りが減ることになります。

テストの工数実績が妥当かどうかも確認しましょう。

例えば、修正後のテスト、リグレッションテストなどのために、どのくらい同じテストを実行しているのか、という点です。繰り返し同じテストをするのであれば、自動化を検討する価値があります。また、エビデンス取得やインシデントの管理に工数を要しているのであれば、適切なツールの導入で改善できないか検討することができるでしょう。

ツールの導入は、ツールを学習して使えるようになるまで導入コストがかかりますが、いずれは工数が改善される可能性が大いにあります。将来性を見込んでツールを導入する価値があるか、という観点で評価し、目先のコストに囚われすぎないようにしましょう。

「良い」ソフトウェアテストとは、従来からいわれているテストの考え方を、“効果的に実現すること”と捉えることができます。

本コラムでは「良い」ソフトウェアテストを実現するための４つのポイントを、テストの考え方、実現方法などいろいろな観点から整理してみました。これらの内容はヒンシツ大学の多くの講義のなかで触れているものです。コラムで気になる内容がありましたら、ぜひヒンシツ大学を受講してください。

「ヒンシツ大学」とは品質／ソフトウェアテスト専門会社・株式会社SHIFTの教育専門機関です。ソフトウェアテスト業界著名人の監修テキストと、経験豊富な弊社講師陣により、入門、実践、応用から管理、テスト戦略まで、バリエーションに富んだ講座を提供しております。高品質なテストスキル／マネジメントスキルを組織として身につけて、短い時間、少人数でも品質を担保する。そういった人材育成をお手伝いするのが「ヒンシツ大学」です。