システム開発における各テストフェーズの観点について
もうすぐ入社2年くらいのなかじまです。最近いろんな工程のテストに携わらせていただいていて、同じシステムのテストなのに着目するところが全然違うんなーと感じてます。
この記事では、そんなソフトウェアテストにおける異なるテスト観点に焦点を当て、テストフェーズの全体的な流れと要点・注意点について説明させていただきます。
エンジニア歴が若い方や、あまりテストをしたことがない方にぜひ読んでいただきたいです。
※ 一部の環境や分野では記載内容が異なる可能性があります。あくまでも参考程度でお読みください。
テストの目的とは？
まずシステム開発ではなぜテストを行うのでしょうか？
それは「品質を上げるため」が最大の目的になります。これはプロジェクトの成功要因＝QCD(Quality(品質)、Cost(コスト)、Delivery(納期))のQにあたります。
またプロジェクトによっては「納品」の成果物の一部にテスト結果があり、レビュー＋指摘対応を終えることで、「作業完了＝納品」を意味することもあります。
デバッグとテストの違い
「テストってデバックしてシステムが動くか確認することでしょ？」と思っている人もいるかもしれませんが、
デバッグは、テストの一部として問題を特定し、修正するプロセスのことです。
デバッグは作ったものが、正しく動くかどうかの確認。動かないのであれば、その理由の確認。性善説に基づいて実施します。
一方でテストは、作ったものが正しく”動かない”ことの証明。基本的な心構えは、「ここは、正しく動かないのでは？」「こうしたら、実は、エラーにならないのか？」という、性悪説に基づいて実施します。
テストの種類について
いよいよテスト工程の話になります。システムを作り終える（テストしながら改修するので完成ではないですが）と長い長いテストフェーズに入ります。
（※ プロジェクトによって呼称が異なる場合もあります。主に、IBM用語。参考：IBM テスト・フェーズ）
単体テスト（UT）
自分の端末で、Visual Studioなどの環境でテストする。システム内結合テスト（ITa）
対応システムの規模により、以下のように分けることがあります。- 露払いテスト
サーバー環境（開発環境）で、個別の機能をテストする。 - システム内連携テスト（本テスト）
サーバー環境（開発環境）で、自システム内部での機能間の連携テストをする。
- 露払いテスト
システム間連携テスト（ITb）
システム対システムで、主に、I/Fの観点でのテストをする。パフォーマンステスト（PT）
性能面、ボリューム面の確認をする。システムリソース状態の確認。OS面の設定まで確認する必要が発生することもありえる。オペレーションテスト（OT）
運用面のテスト。サーバーダウン、起動、系切替、エラー検知、運用SOPにのっとった手順などを確認する。サイクルテスト（CT）
業務運用面をシミュレートしたテスト。
例えば、日中の業務を回して夜間バッチを流すなど1日の流れを指す場合や、ユーザー登録、注文処理、支払いといった、ユースケースを指す場合があり、それらが一連の流れで正しく機能することを確認する。ロングランテスト
長期間動作させたときのテスト。主に、メモリリークの検出を目的とする。ユーザーアクセプタンステスト（UAT）
ユーザー側主体の受け入れテスト。
UTとITaのテストケース作成の視点について
いろんなテスト工程がありますね。
それでは前半のUTとITaについて詳しく見ていきましょう。
まずテストにはブラックボックスとホワイトボックスという異なる視点のテストのアプローチがあります。
| アプローチ | 観点 | 弱点 |
|---|---|---|
| ブラックボックステスト | 設計に沿った実装になっているかをテストする。 テストに際しては、プログラムを1つの箱と見立てて、外側から与える情報と、結果の振る舞いに着目する。 | ソースコードを見ていないので、ステップの網羅率は100%にならない。 |
| ホワイトボックステスト | ソースコードが正しく動くか（条件分岐や繰り返し文などのロジック）をテストする。 テストに際しては、プログラムの内部の構造（特にソースコード）に着目し、全てのステップを網羅する。 | 設計に沿った、正しい実装が行われているかが、わからない。 |
それぞれの視点の弱点を補うように網羅させるようテストケースを作成していきましょう。
ベースはブラックボックスで8〜9割は網羅できると思います。残りの1〜2割はソースコードを見ながら、特にexception周りを確認しながら網羅させましょう。
UTとITaをなぜ、２度やるのか？
UTとITa（露払い）は同じ内容のテストになることがありますが、なぜ同じテストを2度実施するのでしょうか？
- 実行環境による差異がある。
- Windowsサービスは、サービス登録しないとわからない問題や、環境設定面で発生する問題がある。
- OSの設定の問題（サービス起動ユーザーの権限問題など）
- ライブラリやフレームワークの問題
- Configファイルの設定の問題
- レグレッションの一環（UTの欠陥修正の影響で、合格していたケースが不合格になることがある）
などなど他にもいろいろあります。
とはいえ、やはり同じテストを2度実施するのは大変ですよねー。
ならどうするか？
まずは、ITaの完成形をイメージしながらUTのテストケース作成しましょう。
テストケースはブラックボックスベースで、ブラックボックスで確認できないテストケースを網羅できるよう追加しましょう。
そしてUTの実施。
ITaケースはUTのテストケースを元に、「サーバー環境では、実施できないものを取り除く」
ITaは、ほぼUTでのテストの再打鍵になりますが、UTテストデータがあって
、エビデンスのひな型があって、参照するテスト結果もあればUTに比べて打鍵時間は短縮できるでしょう！
まとめ
今回はシステムテストの全体の流れと、前半のUT, ITaあたりについて書かせていただきました。（なんだか文字ばっかりの記事になってしまいましたね。。。）
ソフトウェアテストは品質保証の重要な要素であり、適切なテスト戦略を確立することは成功に不可欠で、それぞれのテスト工程で、何に着目すべきか理解したうえでテストする必要があります。
ご覧いただきありがとうございました。
後半はまた改めて執筆したいと思います。