*本記事は旧TechblogからCOLORSに統合した記事です。
こんにちは！
エンジニアリングソリューション事業部のT.Kです。
突然ですが、システムエンジニアといえば、
ずっとソースコードを書いているイメージがありませんか？
システム開発には様々な工程があり、
ソースコードを書くコーデイングの工程以外にもとても重要な工程があります。
それがテストです。
私は現在、金融系プロジェクトに参画していますので 、
今回はこのプロジェクトを通して学んだことの振り返りを兼ねて、
テストの手法や観点について、振り返りと学習した内容を
この記事にまとめてみたいと思います。
目次
もくじ
なぜテストが重要なのか
テスト工程にもいくつか種類がありますが、
全て合わせるとプロジェクトの中でも一番期間が長い工程です。
なぜなら、様々な観点から繰り返しテストを行うことで未然にバグを取り除き、
品質を守る必要があるからです。
では、テストをしっかり行わないとどうなってしまうのでしょうか。
原因は多々ありますが、サービスが停止した場合主に
以下のような損失が考えられます。
- 業務が停止（経済的・時間的損失）
- ブランドイメージの低下（経済的損失）
医療システムや公共システムなどが停止した場合、
人命に関わることもあるかもしれません。
身近なところでいうと、カード会社のシステム障害で決済ができなかったり、
金融機関のシステム障害でATMやネットバンキングが利用できなかったり
時々ニュースにもなっていますよね。
上記の出来事を未然に防ぐためにもテストが重要となります。
しかし、ただテストを行えばよいかというとそうではありません。
テストの中にも様々な工程や手法があり、
何を/どのような観点でテストするかによって
適切に使い分けることが必要です。
ウォーターフォールモデルのテスト工程
私が参画しているプロジェクトでは「ウォーターフォール」という
開発手法が採用されています。
上述したように、テストはそれぞれの工程に適した内容で
行わなければなりません。
「ウォーターフォール」型の開発手法の場合、いくつかの工程があります。
これを開発工程とテスト工程で紐づけると以下のようになります。
この図は”V字モデル”とよばれ、開発工程とテスト工程の関係を現したものです。
それではV字モデルに沿ってテストの内容を詳しくみていきましょう。
１ ）単体テスト
目的：詳細設計通りにコーディングされている事を確認する
実施タイミング：コーディング完了時
対象：関数・メソッド
手法（種類）：ホワイトボックステスト
Javaの単体テストではJUnitというフレームワークがよく用いられます。
メリットとしては、一度テストコードを書けば同じ条件のテストを繰り返し、
実行・結果確認が行えることです。
これにより、手動実行によるミスと工数が削減できます。
またJenkinsなどのCIツールを使用すれば、定期的に自動実行できるため更に工数削減が見込めます。
単体テストについてはこちらの記事にも掲載しているのでぜひご覧ください。
２ ）結合テスト
目的：基本設計通りに機能が作成されている事を確認する
実施タイミング：単体テスト完了時
対象：機能・他システム間
手法（種類）：ブラックボックステスト
結合テストは内部と外部の2段階に分けてテストを実施します。
▶内部結合テスト
システム内の機能連携や画面間の連携の確認を行う。
▶外部結合テスト
他システムと連携させ、システム間のインターフェースやデータの送受信に
問題がないかの確認を行う。
このフェーズは機能単位で行います。
機能の観点から一連の流れで単体テストの対象を結合させて確認を行います。
また、テストは実際の業務フロー（シナリオ）に沿って行います。
３ ）システムテスト
目的：要件定義通りに機能が作成されている事を確認する
実施タイミング：結合テスト完了時
対象：システム全体
手法（種類）：リグレッションテスト
デグレードテスト
性能テスト
このタイミングになると、機能として問題ないことが分かっているので、
次は業務の流れで沿って、実際の業務に合った動作を行えるかを確認します。
４ ）受け入れテスト（ユーザテスト）
目的：要件通りにシステムが作成されているかを確認する
実施タイミング：システムテスト完了時
対象：システム全体
テスト手法
ここまでテスト工程について触れてきましたが、テスト工程によって
様々なテスト手法があることがお分かりいただけたのではないでしょうか。
この章ではそれぞれのテスト手法について説明していきます。
１）ホワイトボックステスト
プログラムの構造が正しいかどうかに観点を置いて行う手法です。
主に単体テストの際に用いられ、論理構造が正しいか、最後まで実行されるかなどを確認します。
構造に着目するため、仕様の誤りなどプログラム以外のバグを発見することはできません。
２）ブラックボックステスト
システムの中身を考慮せず、要件通りの動作をするか検証する手法です。
主に結合テストでの機能確認やシステムテストで用います。
処理と処理の境界となる値を使用し処理の切替を確認したり、状態遷移を確認したり、
デシジョンテーブルを用いて入力の組合せを可視化しテストケースを作成するなどを行います。
３） リグレッションテスト
プログラムを修正したときに他のプログラムに影響が発生していないかを確認する手法です。（※デグレードテストとも言います。）
開発が進みシステムが複雑化すると、1つの修正が他の部分に悪影響を与える可能性が高くなります。
このテストを行うことで不具合を早期発見することができます。
４） 性能テスト
システムの性能が要件を満たしているか確認する手法です。
開発工程の最終段階で行われます。
想定されるピーク時の負荷に耐えられるか確認するロードテストや、
想定以上の負荷をかけてどの程度処理を続けられるか確認する
ストレステストがあります。
まとめ
いかがでしたしょうか？
このように、テストは最小単位から順次行い、
最終的にシステム全体が対象となります。
このプロジェクトで学んだことを今後も活かし、適切なタイミングと方法で
確認を行うことにより問題（バグ）が発覚した際の影響（修正）範囲を
最小に抑えていきたいと思います！
