支援対象地域:札幌、仙台、関東、愛知、関西、広島、福岡

  • TOP
  •   
  • コラム
  •   
  • テストとテスト工程とは?詳しく解説し

テストの概要について

システム開発は開発から納品を行うまで複数の工程が存在しており、 「要件分析」「要件定義」「基本設計」「詳細設計」「製造」「テスト」の工程に分類されます。 システム開発の基礎的な知識として「要件分析」に近い工程を上流工程と呼び、「テスト」に近い工程を下流工程と呼びます。 上流工程から下流工程に向かって作業を行い、それぞれの各工程を完了した後に次の工程に進むことをウォーターフォール型開発と呼び、システム開発の手法として一般的な代表的な方法の一つとして知られております。 ウォーターフォール型開発におけるメリットは一つの工程を完了させてから次の工程の作業に移るため、 工程における作業の漏れやエラーが少なく、手戻りや作業のやり直しなどのリスクを回避しやすくなるという点にあります。 また、工程ごとにクライアント(発注者)が進捗を確認することができるため開発者との意思疎通を図りやすくなるという点も特徴の一つとなります。
ウォーターフォール型開発と対照的な開発手法がアジャイル開発となります。 ウォーターフォール型開発がオーソドックスな開発手法であることに対して、アジャイル開発は比較的近年になり登場してきた開発手法と考え方であり、小規模な開発や開発速度が求められるプロジェクトに適しております。 アジャイル開発は大きな単位で開発を区切るのでなく、小規模な単位で開発を行うことで よりスピーディーに開発を完了させることを目的とした開発手法となります。 そのためアジャイル開発においては、開発から納品までの速度が速くなり市場に対してサービスを投入する速度や展開などが早くなるというビジネス上のメリットを享受することができます。 その一方で開発開始時にはプロジェクトに関する計画を綿密に立てないことも多いため、 開発方針およびスケジュールがプロジェクトスタート後に変更になりやすいというデメリットがあります。 また、複数の開発工程を同時に進めるため、進捗の管理が難しいことや、開発者一人一人の技術力やチームの総合力によってパフォーマンスが大きく変わるという点もデメリットの一つと言えるでしょう。

話を本題のテストに戻して説明を進めていきます。 テスト工程を理解するうえで必須となるのがV字モデルに関する知識となります。 V字モデルは「要件分析」「要件定義」「基本設計」「詳細設計」「製造」とテスト工程における 「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」を対応させ、それぞれを リンクさせる考え方となります。V字モデルは各工程の確認、検証作業を効率的に実施するために用いられる手法かつシステム開発におけるスタンダードな考え方の一つとして知られておりますので、各工程の知識とあわせて理解しておく必要があります。 開発工程におけるテスト工程は、細かい検証やミスがないかをチェックするだけでなく、成果物全体の品質に大きく影響する重要な工程である点を理解しなくてはいけません。 また、テスト工程においては様々なテスト手法や考え方が存在します。 開発に携わるエンジニアやテストエンジニアはそういった基礎的な知識を習得したうえで現場に参画する必要がありますので、不足している知識がある場合はしっかりと学習しておくことは必要です。 ここからはさらに詳しくテストについて解説させていただきますので、是非参考にしてみてください。

V字モデルについて

テストに関連する言葉としてV字モデルについて紹介させていただきます。 V字モデルはシステム開発として一般的かつオーソドックスな手法として使われており、プロジェクトマネージメントの手法や管理に必要な知識としても知られております。 Vモデルはドイツ政府関連のシステム開発工程を規定するために開発されたことがきっかけであり、 それぞれの工程を概念図としてあらわすことでソフトウェア開発の中で行うべき活動とその成果物が明確になるという点が特徴となります。
Vモデルの概念図の左側には「要件分析」「要件定義」「基本設計」「詳細設計」となり右側には 「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」が表されます。 「要件分析」は「ユーザーテスト」とリンクしており、ユーザーが要件通りにシステムが作成されているかを確認するテストとなります。 「要件定義」は「システムテスト」とリンクしております。要件定義とは、プロジェクトを始める前の段階で、必要な機能や要求をまとめたものであり要件定義書には 詳しく必要な機能一覧や業務フロー図などが記載され、それらを参考にすべてのシステム開発が実装されます。 システムテストでは、要件定義で決定した内容がしっかりと実装されているかを確認、検証するのことになります。 「基本設計」は「結合テスト」とリンクしております。基本設計とは要件定義の次の工程であり、機能ごとにどのような業務を行うかを明確に定義していく形となります。
例えばシステムの画面や帳票、バッチ処理、ハードウェアやミドルウェアなどについて具体的に基本設計書に記述していきます。 インターフェーステスト、業務シナリオテスト、負荷テストの実施などがシステムテストで行うテストの内容となります。 「詳細設計」は「単体テスト」とリンクしております。詳細設計とはプログラム設計の前段階として基本設計で決定した内容を システムとしてそれをどう実現するかを具体的に決定していきます。 モジュール単位でテスト、ホワイトボックステスト、ブラックボックステストの実施などが単体テストの内容となります。 V字モデルにおいては、システム開発の工程で何をすればいいのかというテストの作業内容点が明確になるということが大きなメリットとなります。 また、テストの進捗の管理を行いやすくスケジュールの遅れや予定との乖離を防ぐことができるため、 プロジェクト運営上のリスク回避にも繋がります。 また、各工程のテストをしっかりと実施することで次の工程に進んだ際の修正の負担を軽減することもV字モデルの特徴と言えるのではないでしょうか。

W字モデルについて

V字モデルと関連する言葉としてW字モデルについても紹介させていただきます。 V字モデルは「要件分析」「要件定義」「基本設計」「詳細設計」とリンクさせ、「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」を 行っていくテスト手法であると説明させていただきました。 W字モデルでは、リンクさせた工程同士を同時並行で進めるという点がV字モデルと異なる点となります。 V字モデルは「要件分析」「要件定義」「基本設計」「詳細設計」が完了し、その次の工程として「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」を 実施していくのに対してW字モデルでは「要件分析」「ユーザーテスト」「要件定義」「システムテスト」「基本設計」「結合テスト」「詳細設計」「単体テスト」 といった形でいわばテスト工程を前倒しで行っていくということになります。 「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」の各工程のテストの内容についてはV字モデルと変わりませんので、ここでの説明は割愛させていただきます。
では、W字モデルのメリットについて説明させていただきます。 W字モデルでは、開発において早い段階からテスト工程が実施されるため、要件漏れや矛盾点などのリスクを回避することができるようになります。 また、システム設計の段階でテスト設計を構築することから、品質の担保や開発工程が進んでからの手戻りや無駄な工数を 極力減らすことができるという点も大きなメリットと言えるでしょう。 また、開発工程が進んでからもしくは納期が迫ってからテスト工程に取り掛かるのでなく早めにテスト工程の準備などを 行うことから余裕をもってテストに取り組めるということもW字モデルの特徴です。 また、W字モデルでは開発初期の段階から経験豊富なテストエンジニアを投入することになります。 そのため、設計の初期段階からシステム設計に関して様々な知見を活かしたプロジェクト推進が可能となり、 業務の品質向上を期待することができるでしょう。 その一方でW字モデルでは経験豊富なテストエンジニアが必要となるため人材の選定やコスト面など プロジェクト管理者側が配慮すべき点が多くなるというデメリットもあります。

テストの工程の説明

テストの工程について それぞれ意味と内容を説明させていただきますので、 参考にしてみてください。

単体テスト

テスト工程の一点目が単体テストとなります。 単体テストはユニットテストと呼ばれることもあり、 ユニット単位で検証を行い、モジュールやコンポーネント単位でのテストを実施することになります。 単体テストのメリットとしては、モジュールやコンポーネント単位でテストを実施するため原因の特定と修正が容易があるということがあげられます。 また、単体テストの段階で不具合を見つけることで、結合テスト以降の工程においてテストの手戻りを少なくすることなどが可能となり、テストの安定性を担保するという意味もあります。 開発者がテストに関するドキュメントを参考にすることで、そのユニットの正常動作に必要不可欠な特性を理解することができるという点もメリットとしてあげておきます。単体テストにおいては、単体ストのユニットのAPIのドキュメントを確認することで 効率よくシステムを把握できるという一面もあります。 また、単体テストにおいては、コードが設計通りであることや意図したとおりに動作できているかとう点を確認するため、ソフトウェア開発者の手により実行されるケースも多いです。 そのため、単体テストにおけるデメリットや注意点としては開発者が単体テストを実施することが多いため、工数がかかりやすいということがあげられるケースも少なくありません。 最近では単体テストは自動化するケースが増えているため、 開発者およびテスターが単体テストを実施する際にテスト自動化ツールなどの知識や経験が必要になることも少なくありません。 いずれにせよ単体テストの品質がプロジェクト全体に及ぼす影響は大きいため、 専門的な知識と配慮をもって単体テストを実施することは必須と言えるでしょう。

結合テスト

テスト工程の二点目が結合テストとなります。 結合テストでは、単体テストの次の工程としてモジュールを結合させた状態でのテストを実施することとなります。 モジュール間のインターフェース構造や結合についての動作の確認を実施し、 プログラムやモジュール間の構造やデータの受け渡しなどについて問題がないかという点について検証を行います。 単体テストではあくまでもモジュールやコーポネントの確認であり、それぞれの結合についてのテストは結合テストで受け持つという形がポイントです。 結合テストにはいくつか手法がありますが、その代表的な例であるトップダウンテストとボトムアップテスト について説明させていただきます。 トップダウンテストは上位のモジュールからテストを実施していく方法となります。 上位モジュールがテストを通過することで、該当モジュールから呼び出される下位モジュールのスタブを用意して検証を行います。 このフローを繰り返し、最下位のモジュールの検証を行いテストが完了となるのがトップダウンテストの手法となります。 上位のモジュールからテストを実施するため、プログラム機能の漏れを発見するのが容易であることがトップダウンテストの メリットとなります。 ボトムアップテストは下位のモジュールからテストを実施し上位モジュールに対してテストを行っていく方法となり、トップダウンテストとは逆のアプローチとなります。 開発と同時にテストを実施できるというメリットがある一方で不具合があった際の影響も多いのがボトムアップテストとなります。 そのためどちらのテスト手法を選択するのかについてはシステム開発全体の特性や機能や規模など様々な要素を考慮し決定するといいでしょう。

システムテスト

テスト工程の三点目がシステムテストとなります。 システムテストは単体テスト、結合テストの次の工程となり全ての機能が揃った状態で様々なテストを行います。 V字モデルの項目で説明させていただきましたように、システムテストは要件定義の工程とリンクしております。 要件定義で決定した要件の内容に沿っているかという点について確認していくことになり、 要件定義書に記述した機能要件・非機能要件などをテストしていきます。 システムテストのテストの種類は何通りかありますので、プロジェクトやテスト内容に応じて それらを選定していきます。 機能テストでは、要件定義書に記述した機能について本番環境と同等の状態でシステム要件を満たしていることを検証します。 システムが機能要件通りに稼働することや、その他の機能が正しく動作するかという点について確認を実施するテストです。 構成テストでは、サポートされる各ソフトウェア構成とハードウェア構成に関するシステムのテストを行います。

ユーザーテスト

テスト工程の四点目がユーザーテストとなります。 ユーザーテストは受け入れテストとも呼ばれ、システムテストを実施した後のテスト工程となります。 運用環境やそれに近しい環境においてはユーザーが動作や品質などをチェックし、確認するテストとなります。 ユーザーテストはテスト工程における最終段階となります。 クライアント(発注者)の希望した機能が搭載されていても、実際の運用環境で しっかりと稼働しなければ意味がありません。 また、ユーザーテストでは思いもよらないトラブルやクライアント(発注者)が利用できるかなど 様々な観点でサポートを行う必要があります。 開発したシステムがクライアント(発注者)のニーズを満たせているかという点が最も重要となり、 リリース後の安定した運用にも影響してくる部分となりますので、ユーザーテストは非常に重要な工程であると 理解しておく必要があります。

テストに関する資格について

テストに関する資格について 関連性の高い資格をいくつか紹介させていただきますので、参考にしてみてください。

JSTQB認定テスト技術者資格

テストに関する資格の一点目がJSTQB認定テスト技術者資格となります。 JSTQB認定テスト技術者資格はJSTQBが運営するテスト資格となります。 JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織であり、 各国のテスト技術者認定組織が参加しているISTQB(International Software Testing Qualifications Board)の加盟組織です。 JSTQBは「運営委員会(Steering committee)」「技術委員会(Technical committee)」「諮問委員会(Advisory committee)」の 三つの運営員会から構成されており、それぞれ高い専門性をもった研究者、エンジニア、コンサルタントから 成り立っております。 教育や参考書についてはJSTQBが認証し、試験についてはJSTQBと試験実施を受託する組織、現在は一般財団法人日本科学技術連盟(日科技連)が 行うという形を採用しております。 なお、JSTQB認定テスト技術者資格は国内の転職活動だけでなく、海外のおける転職活動などにおいても一定の評価を獲得することが できます。 JSTQB認定テスト技術者資格 Advanced Level試験は複数の選択肢から正解を選ぶタイプのテストであり、テストマネージャは65問出題され、試験時間は180分です。 テストアナリストは40問出題され、試験時間は120分です。

IT検証技術者認定試験(IVEC)

テストに関する資格の二点目がIT検証技術者認定試験(IVEC)となります。 IT検証技術者認定試験は、一般社団法人IT検証産業協会(IVIA)が認定するテストエンジニアの資格試験となります。 IVIAの運営目的としては、IT検証サービスに関連する団体、企業、個人が集いより良いIT検証サービスを目指し業界の健全性と発展などを目指して運営されている組織となります。 業界認知度向上、情報発信、技術者創出・育成などを柱として掲げております。 IT検証技術者認定試験は試験区分および技術者名称を難易度によって分類しており、 IT検証技術者レベル1~7まで設定されております。 それぞれについて人物像と役割が公開されておりますので、紹介させていただきます。 「IT検証技術者レベル1」はテスト実行者の役割でテスト実行、不具合報告を行う知識を求められます。 「IT検証技術者レベル2」はテスト実行の取りまとめの役割でテスト実行をまとめ、テストケースの知識を求められます。「IT検証技術者レベル3」はテスト実装からテスト詳細設計者の役割でテスト実装を行う知識を求められます。「IT検証技術者レベル4」はテスト詳細設計者の役割でテスト詳細設計からテスト実装まで行う知識を求められます。「IT検証技術者レベル5」はPM、技術リーダーの役割でテストアーキテクチャ設計から実行まで管理する知識を求められます。 「IT検証技術者レベル6」は上級PM、プロジェクト最終責任者の役割で顧客の要求を含め、プロジェクト全体をみる(営業、技術、教育も)知識を求められます。 「IT検証技術者レベル7」は研究者、上級コンサルタントでテスト業界に大きな影響を与えるような研究又は活動を行う知識を求められます。

ソフトウェア品質技術者資格

テストに関する資格の三点目が ソフトウェア品質技術者資格となります。 ソフトウェア品質技術者資格はソフトウェアの品質向上に関する知識を目的とした 資格であり、財団法人日本科学技術連盟が主催しております。 品質保証だけではなく、開発者、テストエンジニアなどソフトウェアに携わるすべての方を対象とした試験になっており、ソフトウェア全般の知識やスキルを身につけることが可能となります。 出題はシラバスに沿った内容から出題される傾向にあるため、 試験勉強としては財団法人日本科学技術連盟で案内している参考書籍を利用することと、 ITに関する幅広い知識を学習することが近道と言えるでしょう。

まとめ

いかがでしたでしょうか? テストについて詳しく解説させていただきましたので、参考にしていただけましたら幸いです。