人手不足でお悩みの方は
＼ こちらの記事がおすすめ！ ／
UT（単体テスト・ユニットテスト）とは？
UT（ユニットテスト）とは、プログラムが単体で動作するかの確認を行うことを目的として行うテストです。単体テストとも呼ばれており、プログラムの開発を行う上で重要な作業と言えるでしょう。
単体テストは、プログラムの開発において行うテストの中で最小単位となるテストであり、プログラム単体が正常に動作することを保証することで、その後実施するテストをスムーズに進めることが可能となります。
UTには、以下の2つの種類があり、それぞれの観点で行うことになることをまずは理解しておきましょう。
- ホワイトボックステスト：ソースコードの中身が見える状態で条件が網羅できているかのテスト
- ブラックボックステスト：ソースコードの中身が見えない状態をテスト対象とし、想定される要因から正常に動作するかのテスト
また、UTの他にもプログラミング開発を行う上で実施するテストには、以下の3つがあります。詳しく解説していきますので、しっかり理解しておきましょう。
- IT（結合テスト・インターフェイステスト）
- ST（システムテスト）
UAT（ユーザー受け入れテスト）
IT（結合テスト・インターフェイステスト）とは？
ITは、インターフェイステストの略であり、結合テストとも呼ばれています。UTはソースコードの作成者や、同じチームの人が行うテストですが、ITは他社が作成したコードも合わせた状態でテストを行います。
結合テストの重要性は、以下の2点であり「機能間」「画面間」「データの連携」などについての動作確認を行うテストです。
- 複数のモジュールを組み合わせてみないとわからない動作不良や不具合を確認する
- STやUATなどのその後の動作テストへとスムーズに繋げるため
結合テストの範囲やどのモジュール同士を組み合わせるかは、開発する製品・サービスや企業の方針によって異なります。
また、ITを行うメリットや注意点については以下となりますので、行う際にはしっかり理解しておきましょう。
メリット 注意点
ITは複数のモジュール同士を組み合わせて実施するため、それぞれの単体機能の検証においてはUTテストよりも正確性に欠けてしまいます。そのため、UTをしっかり行なった上でITの実施へと進むことが重要なポイントとなります。
ST（システムテスト）とは？
ST（システムテスト）とは、作成したプログラムを実際の運用に沿って全体的に行うテストです。
STには「確認テスト」「評価テスト」「負荷テスト」の3つの種類があり、それぞれクリアしていくことが必要です。
確認テスト 回帰テスト
（リグレッションテスト）システムに修正を加えた際、変更していない部分や別の箇所に新たな不具合が発生していないかを確認
システム修正を行なった際には、必ず回帰テストを実行するデグレードチェックテスト システムに修正を加えた際、前のバージョンに戻っていないかや過去に修正したバグが再度発程していないかを確認 評価テスト セキュリティテスト セキュリティに関する機能が仕様書通りに動作しているか（外部からの不正アクセス・情報漏洩防止などの観点） ユーザビリティテスト 運用後ユーザーにとって操作性や見やすさ、分かりやすさの観点からつかいやすいかどうかを確認 障害許容性テスト 万が一障害が発生した際は最低限の機能が維持され、システムが動作するかを確認
テストの実施の際には、擬似的な障害を発生させ対応や復旧手順についても確認しておく必要がある負荷テスト 性能テスト システムの性能要件に基づいた仕様を満たしているかを確認
処理能力などのパフォーマンスを測定し、時間効率や資源効率などの条件ごとに測定・確認を行いシステムの最適化を行うロングランテスト 一定期間システムを連続して稼働させて行うテスト
パフォーマンスの低下や停止しないかの検証を行うストレステスト 過負荷状態でもシステムが正常に動作するかを確認
排他制御・競合条件・メモリーリークを検出し、高負荷の状態でテストを実施するロードテスト システムの通常時とピーク時の動きを測定し、ピーク時においても稼働が可能かを確認 キャパシティテスト パフォーマンスを維持したまま稼働できる最大のトランザクションを測定
ユーザー数やデータ量の増加時にどのようにシステムを増強するかを考慮するために実施するテスト
すべてのプログラムとハードウェアを合わせた状態でシステム全体のテストを行いましょう。通常のバッチ処理・月次処理・四半期処理・年次処理など想定される処理を一通りテストを実施し、正常に動作するかをそれぞれ確認していきましょう。
UAT（ユーザー受け入れテスト）とは？
UAT（ユーザー受け入れテスト）とは、依頼元である実施にシステムを使用するユーザーによって実施を行うテストです。
実際に依頼元であるユーザーが使用することで、分かりにくい点についてや別のバグについて指摘される場合が多いです。
また、開発側のミスで不具合が見つかった場合は、工程を差し戻して修正・改善を行い、再度UATを行う必要があります。
▼システム開発のリソースは足りていますか？人手不足でお悩みの方はこちらの記事がおすすめ！
それぞれのテストの順番は？
「UT」「IT」「ST」「UAT」のそれぞれのテストについて前述で解説しました。では、それぞれのテストはどの順番に実施していけばいいのでしょうか。
テストを実施する順番は以下であり、それぞれのテストを確実に実施しクリアした上で次のテストへと進みましょう。
- UT（単体テスト・ユニットテスト）
- IT（結合テスト・インターフェイステスト）
- ST（システムテスト）
- UAT（ユーザー受け入れテスト）
UATにパスすると開発は終了となり、納品・導入を行い依頼元での利用が開始されます。
テストはいつ終了するのか
それぞれのテストの順番については、前述説明した通りです。しかし、各テストでは予期せぬ不具合や差し戻し、最悪の場合単体からやり直しとなる可能性もあります。
そこで、スケジュールには開発・各試験の期間だけでなく、あらかじめ修正期間についても組み込んでいくことをおすすめします。
また、気になるのは「テストはいつ終了するのか」についてですが、企業によって独自指標の評価基準や経営判断によって不具合をどれだけ直すかが決まってくるでしょう。
テストを終了する判断として以下に例を挙げましたので、ぜひ参考にしてください。
- リリースして随時アップデートを行う
- 稀にしか起こらない致命的なバグは徹底的に試験を行う
- 新規ジャンルの参入のため先行者利益を取るために導入を行う
また、不具合を内在したままリリース後に発生する金銭的な損害と、稀にしか起こらないバグの発見までに要する人件費や労力、資本的な損害を比較して最終決定する場合もあります。
テスト以外でやるべき工程は？
テストの種類についてや行う順番についてここまで説明しました。システム開発を行う上で重要な工程である各テストの実施ですが、テスト以外でやるべき工程を理解しておくことも重要です。
ここからは、テスト以外でやるべき6つの工程についてそれぞれ詳しく解説していきますので、ぜひ参考にしてください。
- 要件定義
- 基本設計
- 詳細設計
- 開発
- 移行
- 運用・保守
また、ここで説明する工程はシステム開発の主流として利用されている「ウォーターフォールモデル」呼ばれている手法であり、滝の流れのように流れに従って開発を行う手法です。「局面化開発手法」「システム開発ライフサイクル」とも呼ばれています。
ウォータフォールモデルの特徴やメリットなどについては以下の記事「ウォータフォールモデルとは？特徴やメリットなどトレンドに沿って詳しく解説！」で詳しく解説していますので、併せて参考にしてください。
システム開発の手法は他にも多く存在していますが、まずは主流となる工程をしっかりと理解しておきましょう。
工程1：要件定義
まずは、顧客とどのような機能を開発するかなどを打ち合わせを行い、要点定義を行なっていきましょう。
ここで検討・定義する内容については以下となります。
- システム開発において目的の明確化
- 目的を実現するために必要な機能や非機能
- 業務要件
- 運用要件
- 外部連絡システム
- 予算・開発スケジュール
また、要件定義を進める上でのポイントは以下であり、フレームワークをうまく活用していきながら慎重に検討していきましょう。
- 業務フローを図式化し、現状業務を把握する
- As-ls（現状）/To-Be（理想像）分析の実施
- 導入効果（期間・費用・効果）の検証）
要件が定まった際には、要件定義書と呼ばれるドキュメントを作成し記録を残しておくことも忘れずに行なってください。
工程2：基本設計
基本設計では、要件定義で決定した事項を具体的にしていきます。
主な設計内容としては以下となり、基本設計が一通り行なった後には画面や帳票のサンプルを作成し顧客に対してのフィードバックを必要とする場合があります。
- ハードウェア・データベース・ソフトウェアの選定
- 開発に用いる言語
- 操作画面や結果の表示
- システム・サブシステムの機能概要
- 出力される帳票のレイアウト
- システム内部で使用する区分の決定
- データ移行・運用・セキュリティ方針
- 機能一覧・業務フロー図
- インプット・アウトプット内容
- 外部システムとの連携方法
また、基本設計を行った際には、基本設計書を作成し記録を残しておきましょう。
工程3：詳細設計
詳細設計では、基本設計で決定した事項に対しより詳しい内容を決定していきます。
詳細設計で主に検討する内容は以下であり、基本設計書の内容をどのように実現していくかを検討・決定していきましょう。
- 画面・帳票の機能設計
- バッチ処理などの自動実行処理の設計
- 表領域やファイルサイズなどのデータベース設計
- システムで使用するコードの設計
- それぞれの規約（開発規約・コーティング規約など）の検討
- UT仕様書の作成
また、基本設計の工程で作成した基本設計書のように、詳細設計のフェーズにおいても詳細設計書の作成が必要となってきます。
工程4：開発
基本設計書・詳細設計書に基づいてプロフラムのコーティングを行うなど、システム開発における作業を行なっていきます。
この開発のフェーズで前述した各テスト（UT・IT・ST・UAT）を行います。
工程5：移行
開発したシステムを顧客の本番環境へと移行を行っていきます。
移行前には、システム移行がスムーズに進むように、起こりうるさまざまな懸念点を考慮しながら移行手順書を作成していきましょう。
旧システムの仕様によるトラブルや、サービス停止期間の制限など開発するシステムや顧客の環境により移行時の状況が異なりますので、慎重に対応していくことが重要です。
また、システムの移行には以下の2つの種類がありますので、環境に応じて最適となる方法で行なうことが重要です。
- 一斉移行：新システムに一気に切り替える
- 順次移行：機能ごとに徐々に切り替える
工程6：運用・保守
実際に新システムを使用して不具合が発生した場合には速やかに修正処理や適切なアップデートを施していきましょう。
運用・保守はシステムを問題なく使うために欠かせない業務と言えるでしょう。
また、顧客からの追加機能の要望が上がった際には、追加開発を行っていくことも「保守」に該当します。
その際には「保守開発」と呼ばれるプロジェクトを別で設ける場合もあることを理解しておきましょう。
▼システム開発のリソースは足りていますか？人手不足でお悩みの方はこちらの記事がおすすめ！
まとめ
システム開発において必要不可欠であるそれぞれのテストについて詳しく解説しました。各テストの関係性や工程をしっかり理解した上で、慎重に作業を進めていきましょう。
また、テスト以外でやるべき工程に関しては、スムーズなシステム開発を行う上でも重要となりますのでしっかり理解を深めた上で、顧客との打ち合わせやフィードバックを随時取り入れながら進めていきましょう。
【SNSフォローのお願い】
kyozonは日常のビジネスをスマートにする情報を毎日お届けしています。
今回の記事が「役に立った！」という方はtwitterとfacebookもフォローいただければ幸いです。
twitter：https://twitter.com/kyozon_comix
