システム開発のテストについて
1.初めに
システム開発の工程の一つである「テスト」ですが、システムの品質を決定する最も重要な段階です。
本記事では、4つの主要なテストと私のシステム開発での実体験をまとめます。
2.テストの種類
まず、テストの種類は主に4つに分かれます。
段階を踏んでテストを進めていくことで、不具合を極力なくすことができるようになります。
また、不具合が出た場合にも原因の特定が容易になることもあります。
下記図がそれぞれの概要になります。

一つずつテストの種類について説明をしていきます。
①単体テスト(UT)
システム内の最小単位である関数やモジュールを対象としたテストです。
開発の初期段階で行うテストで、各部品が設計通りに動作するか、バグが発生しないかを確認します。
単体テストの時点で不具合を修正することで、後の工程での不具合を最小限にとどめられます。
②結合テスト(LT)
複数のプログラムやモジュールを組み合わせた状態で動作を確認するテストです。
単体テストをクリアした後に行うテストで、モジュール間のデータ連携やインタフェースに問題がないかを確認します。
単体では問題なく動作するシステムが結合した際に起こるバグを検出することができます。
③システムテスト(ST)
システム全体が要件通りに動作するかどうかを検証するテストです。
総合テストとも呼び、選任のテスターが納品前の最終確認として行います。
システムテスト仕様書をもとに、ユーザーの操作を想定した一連の機能・負荷への対応・セキュリティ・エラー発生時の処理などを検証します。
④受け入れテスト(UAT)
クライアント側が実施する品質テストです。
ユーザーテストとも呼び、システムテストを経て納品されたシステムが指定の要件やパフォーマンスを満たしているかどうかを総合的に判断します。
システム開発の最終工程であり、実際の運用環境に近い条件で行われます。
3.テストの際の留意点と実体験

私がテストを実施するテスターとしての気を付けていた3つの留意点と実体験について記します。
留意点①:テスト実施手順がわからない時は有識者に確認する
⇒テスト仕様書の記載でテストの条件や、実施方法が曖昧なことがありました。
一年目の時には、テスト条件がよくわからないままテストを実施してしまったことがありました。(もちろん再テストになりました。)
そこから自身で勝手に判断せずに、過去にそのテストケースを実施したことがある方などに積極的に確認することを意識するようになりました。
結果としてテストをする前の準備というところで、スムーズに進めることができるようになりました。
(例)ログイン画面→トップメニュー画面→ユーザー情報変更画面の順に画面遷移し、
正常終了することを確認する。
【確認したいこと】
・ログインするユーザーに制限はあるのか。
・ユーザー情報変更画面では何か入力を行うのか。
など
留意点②:テストした結果は必ず自身で見返す
⇒テストのエビデンスで不備に気づけないことがありました。
作成したエビデンスを見返す習慣がなかった時には、そもそもエビデンスの整形ミスやエビデンス不足になっていることがありました。
テスト後のエビデンスを確認するようになってからは余計なミスは少なくなり、打鍵者(私)とレビュー者の時間の短縮につながりました。
留意点③:些細な不具合でも報告する
⇒不具合と書くと大げさですが、気になったところは有識者の方などに都度聞くようになりました。
実体験としては、テスト実施中にテスト観点ではないところで不具合を見つけ、その報告をした際に感謝されたということがありました。
そこからテストの中で気になる箇所はその度に確認をするようになりました。
4.最後に

記事の冒頭にも記載しましたが、システム開発における「テスト」とはシステムの品質を決定する最も重要な段階です。
ただの作業としてテストを実施するのではなく、それぞれのテストケースの意味を考えながら行うことでよりシステムの品質を高くすることができるかと思います。
私自身システム開発のテスト実施を行ってきましたが、テストケースの意味などに注目するようになってから、テストの結果に対して正当な見返しができるようになったと思います。
皆さんもテスト実施の前に、テストの意味について振り返ってみてもらえればと思います。
6.参考文献
