【保存版】テスターが知っておきたいIT略語100選

ソフトウェア開発の現場では、非常に多くの略語が飛び交います。テスターになりたての方は、次のような会話を耳にして思わず固まってしまうこともあるでしょう。

• 「このAPIはもうSITを通した？」
• 「QAがUATの準備をしています」
• 「このデータはDBから取得しています」

これらの略語が分からないままだと、打ち合わせや議論の内容をつかむのも、ドキュメントを読むのも一苦労です。

そこで 「テスターなら知っておきたい略語100選」 というシリーズを始めることにしました。本記事では、最もよく使われる100語を、短く覚えやすい意味とあわせて紹介します。取り上げるのはソフトウェア開発やIT分野で使われる略語に限り、 dm = direct message、 WDYT = what do you think? のような一般的な略語は含みません。

1. API

Application Programming Interface：アプリケーションプログラミングインターフェース。ソフトウェアやシステム同士が通信し、データをやり取りするための窓口です。つまり、ソフトウェア同士が会話するための手段です。

2. UI

User Interface：ユーザーインターフェース。画面、ボタン、フォームなど、利用者がソフトウェアやシステムと接する要素の総称です。こちらは、人がソフトウェアと会話するための手段にあたります。

3. UX

User Experience： 利用者が製品を使うときに得る体験のこと。使いやすさ、快適さ、満足度などが含まれます。

4. QA

Quality Assurance：品質保証。プロセスや仕組みを整えることで、欠陥の発生を未然に防ぐ活動です。

QAはテストだけを指すものではありません。開発プロセス全体を通じて製品品質を高めるあらゆる活動を含む、より広い概念です。QAは品質マネジメントに関わる領域であり、テスト結果は業務プロセスの改善に活用されます（開発活動もテスト活動も対象で、DEVやPMを含むプロジェクトのすべての役割が関係します）。

5. QC

Quality Control：品質管理。成果物の品質を評価し、欠陥を見つける活動で、ソフトウェアテストはその代表例です。テストは品質管理活動の一つと位置づけられます。

シンプルに整理すると、 QAは欠陥を防ぐ活動、 QCは欠陥を見つける活動 です。

6. UAT

User Acceptance Testing：受入テスト。本番運用を始める前に、システムが業務要件を満たしているかをユーザーまたは顧客側の担当者が確認します。

7. SIT

System Integration Testing：システム統合テスト。複数のシステムやモジュールを接続し、データをやり取りした状態で正しく動作するかを確認します。

8. SDLC

Software Development Life Cycle：ソフトウェア開発ライフサイクル。要件収集、設計、開発、テストから、リリース、保守に至るまでの一連の工程を指します。

9. STLC

Software Testing Life Cycle：ソフトウェアテストライフサイクル。テスト計画、テスト設計、テスト実行、テスト完了報告までのテスト活動の流れを表します。

10. DB

Database：データベース。システムのデータを保管し、管理する場所です。

ここからは、テスターが Developer と働くうえで頻繁に出会う JSONやXMLなどの用語を見ていきます。いずれも技術ドキュメントや、Swagger、Postman、DevToolsといったAPIテストツールを使うとき、さらにはシステムログの中でも数多く登場する言葉です。

11. SQL: Structured Query Language

リレーショナルデータベースを操作するための問い合わせ言語で、データの作成、検索、更新、削除に使われます。
テスターは、データベース内のデータを確認できるよう SELECT、INSERT、UPDATE、DELETE といった基本的な文を押さえておきましょう。

12. JSON: JavaScript Object Notation

クライアントとサーバー間でデータをやり取りする際に広く使われるデータ形式で、特にREST APIで多用されます。
現在のAPIのほとんどは、データの送受信にJSONを採用しています。

13. XML: eXtensible Markup Language

構造化されたデータ形式で、かつてWebサービスで非常に広く使われ、現在も多くの企業システムで見かけます。
SOAP APIでは主にXMLが使われます。

14. HTTP: Hypertext Transfer Protocol

Web上でクライアントとサーバーがデータを送受信するためのプロトコルです。
代表的なメソッドには GET、POST、PUT、PATCH、DELETE があります。

15. HTTPS: Hypertext Transfer Protocol Secure

HTTPの安全版で、TLSによる暗号化でネットワーク上を流れるデータを保護します。
現在では、ほぼすべてのWebサイトがHTTPSを使用しています。

16. REST: Representational State Transfer

Web APIを設計するためのアーキテクチャスタイルです。
「REST API」と言うとき、多くの場合はHTTPを使ってデータ（多くはJSON形式）をやり取りするAPIを指しています。

17. SOAP: Simple Object Access Protocol

システム間のデータ交換にXMLを用いるWebサービスのプロトコルです。
SOAPは銀行、保険、大企業のシステムでよく見られます。

18. CRUD: Create – Read – Update – Delete

• データに対する4つの基本操作です。
  Create – 新規作成
  Read – データの参照
  Update – 更新
  Delete – 削除
  管理系アプリケーションであれば、ほぼ必ず備えている機能群です。

19. JWT: JSON Web Token

API呼び出し時にユーザーの認証・認可を行うためのトークン規格です。
テスターは、ログインのテストやAuthorizationが必要なAPIのテストでJWTに出会います。

20. CORS: Cross-Origin Resource Sharing

あるWebサイトが別ドメインのリソースへアクセスすることを許可・制限する仕組みです。
フロントエンドで 「CORS policy」 のエラーが出た場合、原因はテスターやフロントエンドではなく、サーバー側の設定にあることがほとんどです。

21. BA: Business Analyst

ビジネスアナリスト（BA）。顧客やステークホルダーと対話しながら要件を収集・分析して明確化し、それを開発チームへ伝える役割です。
多くのプロジェクトで、テスターは要件の確認やテストケースの妥当性のすり合わせのためにBAとやり取りします。

22. PO: Product Owner

プロダクトに対して最終的な責任を負い、プロダクトバックログを管理して各ユーザーストーリーの優先順位を決める人です。
要件変更が発生したときや業務的な価値を確認したいとき、最終判断を下すのは多くの場合POです。

23. SM: Scrum Master

スクラムチームが正しくスクラムを実践できるよう支援し、障害（Impediments）を取り除き、チームのプロセス改善を助ける役割です。
スクラムマスターはチームの管理者（Team Manager）ではありません。

24. DoD: Definition of Done

ユーザーストーリーやプロダクトバックログアイテムが、どうなれば 完了 とみなせるのかを定めた基準です。

たとえば、次のような項目が挙げられます。

• 実装が完了している
• コードレビューが済んでいる
• ユニットテストに合格している
• 重大な不具合が残っていない
• ドキュメントが更新されている
• テスト環境へデプロイされている

ストーリーが「Done」と言えるのは、Definition of Doneをすべて満たしたときだけです。

25. DoR: Definition of Ready

ユーザーストーリーが、チームで開発に着手できる 準備が整った 状態かどうかを判断する基準です。

例：

• 要件が明確である
• 受入基準（Acceptance Criteria）がある
• 見積もり（Estimate）が済んでいる
• 未解決の大きな疑問が残っていない

DoRがあることで、要件が曖昧なまま開発を始めてしまう事態を防げます。

26. US: User Story

ユーザーの視点から要件を記述し、その機能がもたらす価値を明確にするための表現方法です。

ユーザーストーリーは、一般的に次の形を取ります。

As a …
I want …
So that …

例：As a customer, I want to reset my password so that I can access my account when I forget my password.

ユーザーストーリーは詳細な仕様書ではありません。あくまでチーム内の対話を始めるための出発点です。

27. AC: Acceptance Criteria

ユーザーストーリーが完了として受け入れられるために満たすべき条件です。

例：

• メールアドレスが正しい形式であること。
• パスワードは8文字以上であること。
• ログイン成功時にメッセージを表示すること。

受入基準は、テスターがテストケースを設計する際の拠りどころになります。

28. MVP: Minimum Viable Product

必要最小限でありながら、利用者が実際に使ってフィードバックを返せるだけの価値を備えた製品バージョンです。
MVPは品質の低い製品という意味ではなく、アイデアを検証するために本当に必要な機能だけを作る、という考え方です。

29. POC: Proof of Concept

アイデアや解決策が技術的に実現可能であることを確かめるための試作・検証です。

例：

• チャットボットへのAI組み込みを試す。
• 新しい決済ゲートウェイとの接続を試す。
• 新しいフレームワークの適用を試す。
  POCは、本格的な開発に投資するかどうかを決める前に実施されるのが一般的です。

30. KPI: Key Performance Indicator

設定した目標に照らして、個人・チーム・組織の成果を評価するための指標です。

例：

• 顧客が検出した不具合の割合。
• バグの対応時間。
• Sprint Velocity。
• Test Automation Coverage。
• Defect Removal Efficiency。

KPIはあくまで業務の成果を追跡するための指標であり、アジャイルが目指すものと混同すべきではありません。アジャイルにおいて最も重要な目的は、顧客に価値を届けることです。

31. E2E: End-to-End Testing

エンドツーエンドテスト。一連の業務プロセス全体が、システムと関連コンポーネントをまたいで正しく動作することを確認します。

たとえばECアプリケーションであれば、E2Eの流れは次のようになります。

ログイン → 商品検索 → カートに追加 → 決済 → 注文確認の受領

E2Eテストは単独の機能を確認するのではなく、始点から最終結果までの流れ全体を確認するテストです。

32. BVT: Build Verification Testing

新しいビルドが、より詳細なテストを続けられるだけの安定性を備えているかどうかを確認するテストです。

BVTでは、重要な機能と基本的な業務フローに絞って確認するのが一般的です。

BVTが失敗した場合、チームはそのビルドに対してそれ以上の詳細なテストを行わないと判断し、開発者に新しいビルドを依頼することがあります。実務では、BVTはSmoke Testingに近い意味で使われることもあります。ただし、呼び方や適用範囲は組織やプロジェクトのプロセスによって異なります。

33. FAT: Factory Acceptance Testing

納品や本番展開の前に、合意された要件を満たしていることを確認するため、ベンダー側またはシステムの開発拠点で実施する受入テストです。

FATは、ベンダーと顧客が関わるプロジェクト、とくに大規模システムや企業向けソリューションの導入案件でよく行われます。

大まかな流れはこうです。ベンダーが製品の準備完了を検証・証明する → 顧客が受け入れる → その後に導入・納品する。

34. SAT: Site Acceptance Testing

顧客の実際の設置環境・現地で実施する受入テストで、実運用に近い条件でシステムが正しく動作することを確認します。

FATがベンダー側での受入に重点を置くのに対し、SATは顧客の現地にシステムを導入した後で実施されるのが一般的です。

35. PVT: Production Verification Testing

本番環境へリリースした後に行う確認テストで、重要な機能が実環境で正しく動作することを担保します。

PVTでは、次のように範囲が小さくリスクの低い確認に絞るのが一般的です。

• システムが稼働しているかの確認。
• 重要なAPIの確認。
• ログインできるかの確認。
• 主要な業務フローの確認。
• 依存システムとの接続確認。

PVTはデプロイ後に実施されることが多く、Production Verificationという活動の一部と位置づけられます。

PVTを、本番環境でリグレッションテストを全件実施することと混同しないよう注意してください。

36. TDD: Test-Driven Development

開発者が機能を実装するコードを書く前に、自動テストを先に書くという開発手法です。

TDDの進め方は、次のサイクルで表されます。Red → Green → Refactor

Red：テストを書き、テストが失敗する。

Green：テストを通す最小限のコードを書く。

Refactor：テストが通る状態を保ったままコードを改善する。

TDDは主にユニットテストに関わるもので、通常は開発者が実践します。

テスターが自らTDDを実践する必要はありませんが、TDDを理解しておくと、開発者がどのようにコードを組み立て、検証しているのかがよく見えてきます。

37. BDD: Behavior-Driven Development

利用者やステークホルダーの視点から見た、システムに期待される振る舞いを中心に据える開発手法です。

BDDでは、次の構文がよく使われます。 Given → When → Then

例：

Given 利用者がログイン画面にいる
When 正しいユーザー名とパスワードを入力する
Then システムはログインを成功させる

BDDの本質はGiven–When–Thenという構文そのものではなく、開発者・テスター・ビジネス側が、システムに期待する振る舞いを一緒に合意するという点にあります。

38. ATDD: Acceptance Test-Driven Development

機能の受入基準を明確にするために、開発に先立って、あるいは開発と並行して受入テストを定義していく開発手法です。

ATDDは、次の役割どうしの協働を促します。Business + Developer + Tester

狙いは、「私たちは何を正しく作るべきか」「機能が要件を満たしたとどう判断するか」を、あらかじめ全員で合意しておくことです。

注意： TDD、BDD、ATDDの3つは非常に混同されやすい用語です。共通点はあります （いずれも「テストを先に考える」アプローチです） が、同じものではありません。実務ではBDDとATDDの境界が必ずしも明確ではなく、適用の仕方もチームによって異なります。

• TDD → コードと技術的な設計に焦点を当てる。
• BDD → システムの振る舞いに焦点を当てる。
• ATDD → 受入基準と業務的な価値に焦点を当てる。

39. SDET: Software Development Engineer in Test

テストを専門とするソフトウェアエンジニアです。開発スキルを備え、自動テストのソリューションやフレームワーク、ツール、テスト基盤の構築に携わります。

SDETが関わる領域には、次のようなものがあります。

• Test Automation
• Test Framework
• API Testing
• Performance Testing
• CI/CD
• Developer Tools
• Test Infrastructure

SDETは単なる「コードが書けるテスター」ではありません。拡張性と保守性のあるテストソリューションを作るために、より高いレベルのソフトウェア開発の思考とスキルが求められる役割です。

40. RCA: Root Cause Analysis

根本原因分析。表面的な症状に対処するのではなく、問題や障害を引き起こした本当の原因を突き止める活動です。

例： Problem：利用者が決済できない。

「決済に失敗する」→ これは現象にすぎません。

「APIがHTTP 500を返す」→ これも症状の一つかもしれません。

RCAでは、さらに掘り下げていきます。

なぜAPIはHTTP 500を返すのか。
→ データベースがタイムアウトしているから。

なぜデータベースがタイムアウトするのか。
→ クエリが最適化されていないから。

なぜクエリが最適化されていないのか。
→ 重要なカラムにインデックスが張られていないから。

Root Cause：データベース設計またはクエリが適切でなかった。

テスターにとってRCAは、「誰がバグを作ったか」を突き止めるためのものではありません。なぜ不具合が起きたのか、同じ不具合を繰り返さないために何をすべきかをチームで理解することにこそ意味があります。

41. BRD: Business Requirements Document

企業や顧客の業務的な視点から、要求やニーズを記述したドキュメントです。

BRDが答えようとするのは、次の問いです。

「事業としてどんな課題を解決したいのか、何を達成したいのか」

たとえばある銀行が、顧客が支店に足を運ばなくても取引できるように、オンライン送金機能の構築を求める、といったものです。

テスターにとってBRDは、機能がどう動くかだけでなく、その機能の背後にある業務的な背景とビジネス目標を理解する助けになります。

42. SRS: Software Requirements Specification

システムやソフトウェアの要件を記述した仕様書で、システムがどのような機能と振る舞いを提供すべきかを定義します。

SRSには、次のような内容が含まれます。

• Functional Requirements
• Non-functional Requirements
• 業務ルール
• インターフェースや連携
• システムの制約条件
• 性能・セキュリティに関する要件
• など

SRSは、テスターが何をテストすべきかを理解し、テスト条件を洗い出すうえで重要な情報源になります。

ただし近年のアジャイル開発では、大きく固定的なSRSではなく、 ユーザーストーリー、受入基準、プロダクトバックログ といった形で要件が管理されることもあります。

43. FR: Functional Requirement

機能要件。システムが何をしなければならないかを記述したものです。

例：

• 利用者はメールアドレスとパスワードでログインできる。
• 利用者は商品を検索できる。
• 利用者は商品をカートに追加できる。
• 注文完了後、システムは確認メールを送信する。

FRをテストするとき、テスターは主に、システムが要求どおりの振る舞いと機能を実現しているかの確認に集中します。

44. NFR: Non-functional Requirement

非機能要件。システムがどのように動作すべきか、あるいは満たすべき品質特性を記述したものです。

例：

• 応答時間は2秒以内であること。
• 同時に10,000人の利用者を支えられること。
• 機密データは暗号化されていること。
• システムが継続的に稼働できること。
• アプリケーションが使いやすいこと。

非常に重要でありながら、見落とされがちな要件群です。

テスターは この機能は正しく動くか だけを問うべきではありません。

次のような問いも必要です。

• 十分に速く動作するか。
• 安全か。
• 想定される負荷に耐えられるか。
• 使いやすいか。

45. ALM: Application Lifecycle Management

アプリケーションのライフサイクル全体を管理すること。アイデアの着想、要件分析、開発、テスト、リリースから保守までが対象です。代表的なツールにJiraがあります。

ALMには、次のような活動が含まれます。

Requirements → Development → Testing → Release → Maintenance

テスターにとってALMは、テストを「開発者がコードを書き終えた後に行う独立した作業」ではなく、製品のライフサイクル全体の一部としてとらえる視点をもたらします。

ALMツールが管理を支援できる対象は、次のとおりです。

• Requirements
• Test Cases
• Defects
• Releases
• Traceability

46. SDM: Software Development Methodology

ソフトウェア開発の進め方を組み立て、管理するために用いる方法論やアプローチです。

例：

• Waterfall
• Agile
• Scrum
• Kanban
• DevOps

チームが採用している開発手法は、次の点に直接影響するため、テスターも理解しておく必要があります。

• テスターはいつ参加するのか。
• テストはいつ実施するのか。
• 要件はどのように管理するのか。
• 不具合はどのように報告するのか。
• 製品はいつリリースするのか。

同じテスト活動であっても、ウォーターフォールとアジャイルではテスターの働き方が大きく変わることがあります。

47. Spike

解決方法を決める前に不確実性を減らすため、調査・学習・実験のために確保する時間や作業のことです。

たとえば、新しい決済APIを組み込みたいものの、次の点がまだ分からないとします。

• APIは要件を満たせるのか。
• リクエスト数に制限はあるのか。
• 必要な機能に対応しているのか。
• 組み込みにどれくらい時間がかかるのか。
• 技術的な問題はないか。

こうしたとき、チームは Spike （スパイクタスク）を立て、調査や小さな試作を行います。

Spikeの目的は、完成した機能を作ることではありません。主眼は開発前に学び、リスクを減らすことにあります。

テスターもSpikeに参加できます。とくに次の点を確かめたいときに有効です。

• テスト容易性
• 自動化の可能性
• テストツール
• システムの可観測性
• 技術的なリスク

48. CI: Continuous Integration

継続的インテグレーション。ソースコードの変更を共通リポジトリへ頻繁に統合し、自動で検証するプラクティスです。

CIのパイプラインは、たとえば次のように動きます。

Code Commit → Build → Automated Tests → Feedback

テスターにとってCIは、次のようなテストを自動実行することで、不具合をより早く見つける助けになります。

• Unit Test
• Integration Test
• API Test
• Static Analysis
• Security Scan

CIによって、テスト活動を開発者がコードを変更した瞬間により近づけられます。

49. CD: Continuous Delivery / Continuous Deployment

CDには、大きく2つの意味があります。

Continuous Delivery

ソフトウェアを常に リリース可能な状態 に保つこと。
本番環境への新バージョンの適用には、手動の承認ステップが残る場合もあります。

Continuous Deployment

必要な検証をすべて通過した変更が、 自動的に本番環境へデプロイされる こと。

したがって、Continuous Delivery ≠ Continuous Deploymentです。関連はしていますが、まったく同じ概念ではありません。

テスターにとってCDは、次の領域と関わります。

• Automated Testing
• Quality Gates
• Test Environment
• Deployment Verification
• Release Validation

50. DevOps: Development + Operations

ソフトウェア開発チームとシステム運用チームの連携を強め、開発からリリース、運用に至る流れを自動化・改善していくアプローチです。

DevOpsは、次のような流れと結びついています。

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor

DevOps環境のテスターは、最終工程だけをテストする存在ではありません。

テスターは、次のような幅広い活動に関われます。

• Test Automation
• CI/CD
• Quality Gates
• API Testing
• Performance Testing
• Security Testing
• Monitoring
• Observability

重要なのは、品質がチーム全員の責任になる（役割ごとに担う品質の側面は異なります）ということであり、テスターだけの責任ではないという点です。

51. IDE: Integrated Development Environment

統合開発環境。プログラミングを支援する各種ツールを、ひとつの画面にまとめて提供するソフトウェアです。

IDEには、一般に次の機能が備わっています。

• Code Editor
• Debugger
• Build Tools
• Version Control Integration
• Plugin / Extension

代表的な例：

• IntelliJ IDEA
• Visual Studio Code
• Eclipse

テスターが毎日IDEでコードを書く必要はありません。ただし自動テスト（オートメーションテスト）に取り組むなら、IDEを使うことでテストコードの記述、デバッグ、自動テストケースの管理がぐっと効率的になります。

52. SDK: Software Development Kit

ソフトウェア開発キット。特定のプラットフォームやエコシステム向けにアプリケーションを開発するために必要なツール、ライブラリ、ドキュメント、部品一式をまとめたものです。

例：

• Android SDK
• iOS SDK
• AWS SDK
• OpenAI SDK

SDKには、次のものが含まれます。Libraries + APIs + Tools + Documentation

テスターがSDKに出会うのは、モバイルアプリのテストや、サードパーティのサービスと連携するシステムのテストのときです。

例： 決済を組み込んだアプリケーションではPayment SDKが使われることがあります。この場合テスターは、アプリの画面だけでなく、アプリがSDKや外部システムとどうやり取りしているかまで確認する必要があります。

53. OOP: Object-Oriented Programming

オブジェクト指向プログラミング。プログラムをobject（オブジェクト）とclass（クラス）を軸に組み立てるプログラミング手法です。

OOPでよく取り上げられる4つの概念があります。

• Encapsulation – カプセル化
• Inheritance – 継承
• Polymorphism – 多態性
• Abstraction – 抽象化

なぜテスターがOOPを知っておくべきなのでしょうか。テスト自動化に取り組むと、とくに大規模なフレームワークでは次の要素に日常的に出会うからです。

• Class
• Object
• Method
• Inheritance
• Interface

OOPを理解していれば、自動化フレームワークの構造を読み解けるようになり、コードの組み立て方について開発者とも話しやすくなります。

54. ORM: Object-Relational Mapping

プログラム内のオブジェクトと、リレーショナルデータベースに保存されたデータとを対応づける技術です。

例：コード上に User というオブジェクトがあるとします。

• このオブジェクトは、テーブルusersに対応づけられます。
• そしてid, name, email といった属性が、データベースの各カラムに対応づけられます。

代表的なORMには、次のものがあります。

• Hibernate
• Entity Framework
• Django ORM
• Sequelize

テスターがORMを知っておきたいのは、UIやAPIで見えている不具合の原因が、Application ORM Databaseの対応づけにあることもあるからです。

この流れを理解していれば、「APIが誤ったデータを返す」と報告するだけで終わらず、一歩踏み込んだ原因分析ができます。

55. MVC: Model – View – Controller

アプリケーションを3つの主要な要素に分ける、代表的なソフトウェアアーキテクチャパターンです。

• Model: データと、データに関わるロジックを管理する。
• View: 利用者に画面を表示する。
• Controller: リクエストを受け取り、各要素間の処理を調整する。

イメージとしては、こう整理できます。User → View → Controller → Model → Database

MVCを理解しておくと、テスターは不具合がどこに潜んでいそうかを思い描けるようになります。

例：利用者が Login を押したのに、誤ったメッセージが表示された。

このときテスターは、次のように分析を進められます。

• UI/ View: リクエストは正しく送られているか。
• Controller: リクエストは正しく処理されているか。
• Model: データは正しく取得されているか。
• Database: 利用者のデータそのものは正しいか。

実際のシステムが別のアーキテクチャを採用していても、不具合を分析するうえで役立つ考え方です。

56. MVVM: Model – View – ViewModel

画面を持つアプリケーションの開発でよく使われるアーキテクチャパターンで、とくに一部のフレームワークやモバイルプラットフォームで採用されています。

3つの要素は次のとおりです。

• Model: データと業務ロジック。
• View: 利用者が目にし、操作する画面。
• ViewModel Viewにデータと状態を供給する中間層。

テスターがMVVMに出会うのは、モバイルアプリのテストや、このパターンに対応したフレームワークを使うアプリケーションのテストのときです。

アーキテクチャを理解しておくと、次のことが分かります。

• 画面上の表示の誤りが、必ずしもUIに起因するとは限らない。
• ViewModelのデータが誤っている場合も、そもそもバックエンドのデータが最初から誤っている場合もある。

57. GitOps: Git Operations

Gitリポジトリをシステム構成やインフラの信頼できる唯一の情報源（Source of Truth）とする、運用とデプロイの管理アプローチです。

 注意：実務では GitOps という用語は、単なる「Git Operations」より広い意味で使われます。Git、Infrastructure as Code、自動化を土台にした運用手法を指す言葉です。

GitOpsの流れは、次のように描けます。Git Repository → Configuration / Infrastructure as Code → Automated Deployment → Environment

環境設定の変更はテスト結果に直接影響するため、テスターもGitOpsを知っておくべきです。

例：コードは変わっていないのに、今日はテストが失敗する。

原因は、次のいずれかにあるかもしれません。

• Environment Configuration
• Database Configuration
• Feature Flag
• Infrastructure
• Deployment Configuration

58. VM: Virtual Machine

仮想マシン。ソフトウェアによって模擬され、物理マシンやサーバー基盤の上で動作するコンピュータ環境です。

1台の物理マシンで複数のVMを動かせます。Physical Machine →VM 1 – Test Environment | VM 2 – Staging Environment | VM 3 – Development Environment

テスターがVMに出会うのは、テスト環境を扱うときや、仮想化基盤上に構築されたシステムを扱うときです。

VMは、次の目的で比較的独立した環境を用意するのにも役立ちます。

• Test
• Development
• Deployment
• Troubleshooting

59. OS: Operating System

オペレーティングシステム。ハードウェア資源を管理し、アプリケーションが動作するための土台を提供する基盤ソフトウェアです。

例：

• Windows
• macOS
• Linux
• Android
• iOS

互換性テストを行うとき、テスターはとくにOSに注意を払う必要があります。

例：

Mobile App

• Android
• iOS

Desktop App

• Windows
• macOS

Server

• Linux
• Windows Server

特定のOSでしか再現しない不具合もあります。だからこそOSはテスト環境の重要な構成要素なのです。

60. CPU: Central Processing Unit

中央処理装置。計算を実行し、プログラムの命令を処理する部品です。

ざっくり整理すると、こうなります。

• CPU → 処理能力
• RAM → 一時的な記憶領域
• Storage → データの保存

テスターにとってCPUがとくに重要になるのは、性能テストを実施するときや、システム資源に関わる問題を調べるときです。

例：システムの応答が遅いとき、原因はAPIではなく、次のような点にあるかもしれません。

• CPU使用率が高すぎる。
• RAMが足りない。
• データベースが過負荷になっている。
• 特定のプロセスが資源を占有している。

性能テストでは、APIの応答時間を測るだけでなく、システムを複数の層から見る視点が欠かせません。

出典＠Hoàng Liên Sơn氏（TESTING VNグループ）

今後も更新予定です。