🔰現場で迷わない！「PT/IT/ST/OT」をやさしく理解しよう！

はじめに

開発の話し合いで「pt」「it」「st」「ot」という用語が出てきて、戸惑ったことはありませんか。「t」はテストの「t」なのですが、略称だと何がどの順かなどとこんがらがったりするのはよくあることだと思います。
こちらではなるべく簡単な表現で、４つのテストの説明を初心者向けに整理しました。
まず全体像、つぎにやること、そしてつまずきやすい所と対策をゆっくりと学んでいきましょう。

用語のよみかえ

• pt＝program test(プログラムテスト：単体テスト)
• it＝integration test(インテグレーションテスト：結合テスト)
• st＝system test(システムテスト)
• ot＝operation test(オペレーションテスト：運用テスト/受け入れ前の最終確認)

---

1. 「部品→つなぎ→全体→運用」

• pt：部品ひとつが正しく動くかを確認します。
  例：関数や画面の入力チェック、計算結果が正しいこと。
• it：部品どうしのつなぎが正しいかを確認します。
  例：apiの呼び出しができ、データの受け渡しが正しく行われ、タイムアウトせずに時間内に終了すること。
• st：完成品としての全体が期待どおりかを見ます。
  例：機能がそろっているか、速さや安全性も足りているか。性能が予想範囲内でセキュリティも保たれていること。
• ot：本番の使い方と手順で問題がないかを確かめます。
  例：実際のオペレーション、監視、バックアップからの復元、当番の対応手順。

覚えかた：「部品→つなぎ→全体→運用」の順で広がっていきます。
個人的には「piso-t（ピソティー）」と覚えていましたが、一般的ではないこととデータベース監査ツールのPISOと間違ったりするのでおすすめしません。味噌ピーと勘違いしたらまずいですし。
数学的には(p+i+s+o)tみたいな感じでしょうか。

---

2. なにをする？最小セットだけ覚える(チェックリストつき)

2.1 pt(単体)

• ねらい：ひとつの処理が仕様どおりか。
• 最小セット：[ 　] 正常系　[　 ] 異常系　[　 ] 境界値(例：０/最大値)
• コツ：外部サービスはモックで置きかえる。ログに入力と結果を出す。

モック：モックアップ。本物に似せたダミーシステム。

2.2 it(結合)

• ねらい：画面→API→DBなどの流れが切れないか。
• 最小セット：[ 　] 主要ユースケースが通る　[ 　] データ形式ずれ無し
  [ 　] タイムアウト/リトライを試す
• コツ：if仕様(項目名・桁・文字コード)を表にして見比べる。

API：Application Programming Interface（アプリケーション・プログラミング・インタフェース）。プログラムやWeb間で機能を使ったりデータのやりとりを行ったりする接続手法。
DB：Database（データベース）。データを集め、利用、管理するシステム。

2.3 st(システム)

• ねらい：使う人の期待を全体で満たすか。
• 最小セット：[ 　] 機能の合否　[ 　] 性能(レスポンス)　[ 　] セキュリティ基本
• コツ：本番に近い構成で、ピーク想定データを流す。

2.4 ot(運用)

• ねらい：本番を回せるか。
• 最小セット：[ 　] 監視アラートが飛ぶ　[　 ] バックアップ→復元ができる
  [ 　] 連絡手順と当番の動作がそろう
• コツ：台本(やる順番)を１枚にまとめて、実際に演習する。

---

3. つまずきやすい所と対策

よくある５つの質問

• Q1．ptとutはちがうの？
  A1．ut（Unit Test/ユニット単体のテスト）とは呼び方のちがいで、ほぼ同じ意味として使われます。
• Q2．otとuatのちがいは？
  A2．どちらも本番前の確認。uat（User Acceptance Testing/ユーザー受け入れテスト）は利用部門の受け入れ、otは運用手順の確認が中心です。
• Q3．自動化はどこから？
  A3．まずpt、つぎに主要なitの経路。stは計測、otは手順のスクリプト化を目指しましょう。
• Q4．完了の目安は？
  A4．各段階で合否の基準(文字で定義)をつくり、それを満たしたら完了とします。
• Q5．データ量はどのくらい？
  A5．最低でも本番のピークを想定しましょう。作るのが大変なら生成スクリプトを用意してもよいでしょう。

テスト失敗例：本番で夜間バッチが落ちたのはなぜ？

1. なぜ？ stでは通ったが、夜間バッチでエラーになった。
2. なぜ？ テスト環境のデータ量が本番より少なかった。
3. なぜ？ データ作成がたいへんで、最小だけで済ませた。
4. なぜ？ データ量の基準と責任者を決めていなかった。
5. なぜ？ st/otの合否基準に「本番同等データ量」と「担当者」を書いていなかった。

• 根本原因：基準と担当の書きもれ。
• 対策：st/otの基準にデータ量と担当を明記する。データ生成を自動化して、毎回おなじ量を使う。

---

おわりに

• 仮説：4段階(pt/it/st/ot)を意識して、合否基準と担当を最初に決めれば、本番トラブルと手戻りは確実に減ります。

• 根拠：問題は後ろで見つかるほど高くつく傾向にあります。前の段階でつぶすほど安全で楽にできます。ただし、運用の不備はotでしか見えない点に注意です。

• 再検証：次の開発で、欠陥がどの段階で見つかったかを記録し、st以降の流出率の推移を見ましょう。

• 示唆・次のアクション：

  1. １ページの基準表(pt/it/st/otのやること・合否・担当)を作りましょう。
  2. 代表テストデータを共有し、pt→it→stで再利用しましょう。
  3. ptと主要itを自動化、otは台本化＋演習を定番にしましょう。

テストは常にシステムと関係します。この記事が日々の会話で迷わないための地図になればうれしいです。