目次
システム開発においては、一般的に「システムテスト」と呼ばれるテストレベルの段階で、構築されたシステム全体の評価を実施し、最終的な品質を測ります。
ただし「システムテスト」には、機能の組み合わせに着目した確認や、非機能要件に対する確認、ビジネスプロセスやユースケースに沿った確認といった目的があり、構築されたシステム上で確認できる評価は、表層的なものにすぎません。
また、それらの確認は、たいていの場合リリースの直前に行われることが多く、たくさんの時間をかけて評価を行うことは難しいでしょう。
最悪の場合、システムテストで影響の大きな問題が発覚し、リリースに影響が出る、などといったこともあります。
そういった問題を引き起こさないためにも、目的に沿った品質計画を立て、段階的かつ効率的に品質を担保していくことが重要となります。
そこで今回は、開発途中で行われる「コンポーネントテスト」で多く用いられ、ほかのサブシステム、ほかのチームに依存せずに、コンポーネント単位で品質を確認・向上する際に必要となる「スタブ(Stub)」について、その目的とメリットをご説明します。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流~下流(テスト計画・テスト設計・テスト実行・テスト品質管理)まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
スタブとは?
「スタブ」とは、テスト対象から見た下位モジュール(呼び出される側)に成り代わる中身をもたないテスト専用のダミー部品です。
各システムやコンポーネントが完成していれば、それらをつなぎ合わせることでインターフェースの実装に間違いがないか、データの取り扱いに間違いがないかを見ることができます。
実施前にはコンポーネント単体や、モジュール単体での品質が担保されていることがとても重要になるのですが、下位モジュールが開発途中である場合「呼び出す機能」のテストを行えないことがあります。
そのときに作成・使用されるのが「スタブ」です。
ソフトウェアテストに外注の選択肢を
「ソフトウェアテストを外注すべき5つの理由とは!?」の資料をぜひご覧ください。
スタブの仕組みとメリット
スタブは「上位モジュールから呼び出される」という機能だけを持っています。
つまり、スタブ自体に特別な処理はなく、上位モジュールが必要とする返り値・変数のみを定数でもたせることが一般的です。
スタブを下位モジュールのダミーとして置くことで、上位モジュールの「呼び出し処理」を開発序盤であってもテストすることができるようになります。
スタブを活用したテスト手法
スタブはシステム開発において、コンポーネントテストでよく使用されます。
とくに、上位モジュールから下位モジュールへの流れを確認する「トップダウンテスト」で多く用いられます。
コンポーネントテストに関してはこちらもご覧ください。
>>コンポーネント(単体、ユニット)テストとは?手法などを例で紹介のページへ
トップダウンテストでの活用
トップダウンテストとは、上位のモジュールから下位のモジュールへ順にテストする手法です。
その際、スタブを使って上位モジュールの精度を確認したあと、スタブ部分にした下位モジュールのテストを行うという流れで進めていきます。
トップダウンテストは、最上位のモジュールから下位モジュールを結合して徐々にテストをしていくため、モジュールを結合した場合の不具合を早期に発見し、取り除くことができるというメリットがあります。
下位モジュールを期待通りに呼び出せていない、誤ったタイミングで呼び出しているなどがあれば、早い段階で検知し取り除けるのです。
一方で、上位のプログラムは多くのモジュールを呼び出すため、テストとプログラミングを並行して行う場合、大量のスタブが必要になる点はデメリットとなります。
スタブを活用した開発手法
スタブは特定の開発手法にも欠かせません。それが「テスト駆動開発」です。
テスト駆動開発での活用
「テスト駆動開発」とは、プログラムに必要な各機能について、最初にテストコードを書き、そのテストをクリアできるように最低限のプログラミングを行なった後、コードを洗練させていく開発手法です。
プログラミングとテストを並行して行うため、テスト駆動開発においてはほとんどの場合でスタブが必須となります。
テスト駆動開発では、設計内容を具体的にテストコードに記述することで、プログラミングと設計内容の食い違いを瞬時に検知し、短い間隔でフィードバックを得ることができるという点がメリットです。
ただし、トップダウンテストの場合と同様に、テスト駆動開発においても大量のスタブを用意するというタスクが発生してしまうため、テストとプログラミングを並行して行う場合、大量のスタブが必要となる点はデメリットになります。
テスト駆動開発についてはこちらもご覧ください。
>>テスト駆動開発(TDD)とは?目的やメリット・デメリット、やり方を解説のページへ
ドライバとの違い
スタブと似たような概念に「ドライバ」と呼ばれるものがあります。
「ドライバ」とは、テスト対象から見た上位モジュール(呼び出す側)に成り代わる、中身を持たないテスト専用のダミー部品です。
コンポーネントテストには、下位のモジュールから上位のモジュールへ順にテストをする「ボトムアップテスト」という手法もあります。
このときの上位モジュールには、このドライバと呼ばれるダミーモジュールを使用します。
最下位のモジュールからテストしていくため、一般的な開発手法のなかではプログラミングと並行してテストを実施しやすいというメリットはありますが、上位モジュールのテストが手薄になってしまい、システム全体の連携などに潜在する問題を十分に検知できないというデメリットがあります。
モックとの違い
スタブと似たような概念で用いられるものに「モック」と呼ばれるものもあります。
モックはスタブと同じく、上位モジュールから下位モジュールへのテストにおいて使用されるものですが、大きな違いは「確認する対象」です。
スタブを使用する場合、上位モジュールが下位モジュールを「正しく呼び出せているか」を確認しますが、モックは上位モジュールが下位モジュールに対して「行った出力内容が正しいか」を主に確認します。
スタブは、テストを効率よく進めるためのツールという位置づけであるのに対し、モックは、テストコードの一部と表現できるかと思います。
スタブを活用したテストの注意点
ここまでシステム開発における、スタブを活用することで効果が得られるテスト手法や、開発手法について説明をしてきましたが、もちろん注意点もあります。
まずは前出していますが、当然スタブを作成する工数がかかります。
評価対象モジュールの下位に位置するモジュールが、完成してない数が多いほど、その分のスタブを用意しなければなりません。
テストとプログラミングを並行して行うことで、早い段階で不具合を検知し、取り除ける半面、大量のスタブが必要となるため、工程スケジュールが逼迫するリスクも考慮してスケジュールを組み立てる必要があります。
また、スタブで行った確認結果に依存し過ぎないことも必要です。スタブはあくまで中身をもたないテストを効率よく行うダミー部品です。
スタブを使ったテストではうまくいっていたものが、出来上がった下位モジュールと結合してみると不具合が出る
ということは想定して開発を進めなければなりません。
テスト計画書テンプレートをダウンロード
テスト計画はソフトウェアテストにおける最初の工程にあたり、何をどのようにテストをするかといったソフトウェアテストの全体像を示した全体テスト計画書と、それをインプットにした個別テスト計画書のドキュメントを作成します。
本テンプレートは、全体テスト計画書作成のためのテンプレートです。
SHIFTが実際のプロジェクトで使用している計画書を初心者にも扱いやすいようシンプルな構成にまとめ、各項目に記述すべき内容と補足説明を記載しております。ぜひ、テスト計画書作成業務にご活用ください。
また、下記コラムにて、テスト計画の中でも特にプロジェクトによって内容が大きく変わる、テスト戦略(「テスト対象」「テストの範囲」「アプローチ」)にフォーカスし、記述方法、考え方について詳しく解説していますので、合わせてご覧ください。
(コラム)テスト戦略~テスト計画プロセスにおけるテスト戦略の考え方~
テスト計画はソフトウェアテストにおける最初の工程にあたり、何をどのようにテストをするかといったソフトウェアテストの全体像を示した全体テスト計画書と、それをインプットにした個別テスト計画書のドキュメントを作成します。
本テンプレートは、全体テスト計画書作成のためのテンプレートです。
SHIFTが実際のプロジェクトで使用している計画書を初心者にも扱いやすいようシンプルな構成にまとめ、各項目に記述すべき内容と補足説明を記載しております。ぜひ、テスト計画書作成業務にご活用ください。
また、下記コラムにて、テスト計画の中でも特にプロジェクトによって内容が大きく変わる、テスト戦略(「テスト対象」「テストの範囲」「アプローチ」)にフォーカスし、記述方法、考え方について詳しく解説していますので、合わせてご覧ください。
(コラム)テスト戦略~テスト計画プロセスにおけるテスト戦略の考え方~
まとめ
いかがでしたでしょうか。
特定の開発手法、テスト手法に効果を発揮するスタブですが、メリット・デメリットを理解し、目的に沿ったツールとしての利用をしなければ、その効果を十分に活かすことはできません。
目的に沿った品質計画を立て、段階的かつ効率的に品質を担保していくことが重要となります。
SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。
また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます!
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。
そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。
\おすすめの資料/ ※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に <理由&メリット>
・ソフトウェアテストを外注すべき5つの理由とは!?
・サービス導入事例集
これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。
ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。