QA IT用語 韓国語一覧
테스트/QA IT 용어 일본어 목록
111語収録 / 111개 수록
複数の入力パラメータの組み合わせを網羅的または効率的に検証するテスト手法。ペアワイズ法などを活用してテストケース数を削減しながら品質を担保する。
여러 입력 파라미터의 조합을 망라적 또는 효율적으로 검증하는 테스트 기법. 페어와이즈 기법 등을 활용해 테스트 케이스 수를 줄이면서 품질을 확보한다.
ソフトウェアをリリースするために満たすべき品質・テスト・承認条件の総称。リリース判断の客観的な指標として機能し、出荷可否の判定に使われる。
소프트웨어를 릴리스하기 위해 충족해야 할 품질·테스트·승인 조건의 총칭. 릴리스 판단의 객관적인 지표로 기능하며, 출시 가능 여부를 판정하는 데 사용된다.
UIのスクリーンショットを比較し、意図しない見た目の変化を自動検出するテスト手法。CSSやレイアウト崩れの早期発見に有効。
UI 스크린샷을 비교하여 의도치 않은 시각적 변화를 자동으로 감지하는 테스트 기법. CSS 및 레이아웃 깨짐을 조기에 발견하는 데 효과적이다.
ソフトウェアの品質を確認するためにテストケース・テスト手順・テストデータを計画・定義するプロセス。効率的なバグ検出に直結する重要な工程。
소프트웨어 품질 확인을 위해 테스트 케이스·테스트 절차·테스트 데이터를 계획하고 정의하는 프로세스. 효율적인 버그 검출에 직결되는 중요한 공정.
ソフトウェアの最小単位（関数・メソッドなど）を個別に検証するテスト手法。バグの早期発見やリファクタリング時の安全性確保に有効で、CI/CDパイプラインに組み込まれることが多い。
소프트웨어의 최소 단위(함수·메서드 등)를 개별적으로 검증하는 테스트 기법. 버그의 조기 발견과 리팩토링 시 안정성 확보에 효과적이며, CI/CD 파이프라인에 통합되는 경우가 많다.
バグが発見されてから修正・クローズされるまでの一連の状態遷移プロセス。New→Open→Fixed→Verified→Closedなどのステータス管理が基本となる。
버그가 발견된 후 수정·종료될 때까지의 일련의 상태 전이 프로세스. New→Open→Fixed→Verified→Closed 등의 상태 관리가 기본이 된다.
iOS・Androidアプリのテスト自動化ツール。WebDriverプロトコルを使用し、複数のプログラミング言語でモバイルアプリのE2Eテストを記述・実行できるOSSフレームワーク。
iOS·Android 앱의 테스트 자동화 도구. WebDriver 프로토콜을 사용하여 여러 프로그래밍 언어로 모바일 앱의 E2E 테스트를 작성·실행할 수 있는 오픈소스 프레임워크.
ソフトウェアの変更後に既存機能が正常に動作するかを確認するテスト手法。バグ修正や機能追加による意図しない影響（デグレード）を検出するために実施する。
소프트웨어 변경 후 기존 기능이 정상적으로 동작하는지 확인하는 테스트 기법. 버그 수정이나 기능 추가로 인한 의도치 않은 영향(디그레이드)을 검출하기 위해 실시한다.
システムに意図的に障害や異常を注入し、エラー処理やフォールバック動作の正確性を検証するテスト手法。カオスエンジニアリングの基礎技術の一つ。
시스템에 의도적으로 장애나 이상을 주입하여 에러 처리 및 폴백 동작의 정확성을 검증하는 테스트 기법. 카오스 엔지니어링의 핵심 기술 중 하나.
Pythonの人気テストフレームワーク。シンプルな構文でユニットテストや統合テストを記述でき、豊富なプラグインとフィクスチャ機能で大規模プロジェクトにも対応する。
Python의 인기 테스트 프레임워크. 간단한 문법으로 단위 테스트 및 통합 테스트를 작성할 수 있으며, 풍부한 플러그인과 픽스처 기능으로 대규모 프로젝트에도 대응한다.
ソフトウェア変更後に既存機能が壊れていないかを確認するテスト計画。対象範囲・優先度・自動化方針などを定め、リリース品質を担保する。
소프트웨어 변경 후 기존 기능이 손상되지 않았는지 확인하는 테스트 계획. 대상 범위·우선순위·자동화 방침 등을 정해 릴리스 품질을 보장한다.
テストコードの品質を検証する手法。ソースコードに意図的な変更（ミュータント）を加え、既存テストがその変異を検出できるかを確認することでテストの網羅性を評価する。
테스트 코드의 품질을 검증하는 기법. 소스 코드에 의도적인 변경(뮤턴트)을 가하여 기존 테스트가 해당 변이를 감지할 수 있는지 확인함으로써 테스트의 망라성을 평가한다.
テストを自動化する範囲・ツール・実行タイミングを定めた計画。ユニット・統合・E2Eなど各レイヤーの自動化方針をテストピラミッドに基づき決定する。
테스트를 자동화할 범위, 도구, 실행 시점을 정한 계획. 유닛·통합·E2E 등 각 레이어의 자동화 방침을 테스트 피라미드를 기반으로 결정한다.
テスト実施結果をまとめた報告書。テストケースの合否、バグ件数、カバレッジ、品質状況などを記載し、リリース判断の根拠となる重要ドキュメント。
테스트 실행 결과를 정리한 보고서. 테스트 케이스 합격 여부, 버그 건수, 커버리지, 품질 현황 등을 기재하며 릴리스 판단의 근거가 되는 중요 문서.
アプリケーションの実行時に各処理のCPU使用率・メモリ消費・実行時間を計測し、ボトルネックを特定する手法。最適化の優先箇所を明確にする。
애플리케이션 실행 중 각 처리의 CPU 사용률·메모리 소비·실행 시간을 측정하여 병목 지점을 파악하는 기법. 최적화 우선순위를 명확히 하는 데 활용된다.
テスト技法の一つ。入力値を同じ処理結果になるグループ（同値クラス）に分割し、各クラスから代表値を選んでテストケースを効率化する手法。
테스트 기법 중 하나로, 입력값을 동일한 처리 결과를 가지는 그룹(동치 클래스)으로 분할하여 각 클래스에서 대표값을 선택해 테스트 케이스를 효율화하는 기법.
テスト対象の関数やシステムが満たすべき「性質（プロパティ）」を定義し、ランダムに生成した多数の入力データで自動検証するテスト手法。QuickCheckが先駆け。
테스트 대상 함수나 시스템이 충족해야 할 '속성(property)'을 정의하고, 무작위로 생성한 다수의 입력 데이터로 자동 검증하는 테스트 기법. QuickCheck이 선구자다.
発見されたバグをビジネス影響度・再現率・深刻度などの基準でランク付けし、修正順序を決定するプロセス。CriticalからLowまで段階的に管理する。
발견된 버그를 비즈니스 영향도·재현율·심각도 등의 기준으로 등급을 매기고 수정 순서를 결정하는 프로세스. Critical부터 Low까지 단계적으로 관리한다.
ソフトウェアを特定の地域・言語向けに適応させた際、翻訳・日付・通貨・文字コードなどが正しく動作するかを検証するテスト手法。
소프트웨어를 특정 지역 및 언어에 맞게 적용했을 때, 번역·날짜·통화·문자 인코딩 등이 올바르게 동작하는지 검증하는 테스트 기법.
テストを実行する前に必要な初期状態やデータを準備・セットアップする仕組み。テストの前後処理（setUp/tearDown）を定義し、再現性のあるテスト環境を確保する。
테스트를 실행하기 전에 필요한 초기 상태나 데이터를 준비·설정하는 구조. 테스트의 전후 처리(setUp/tearDown)를 정의하여 재현 가능한 테스트 환경을 확보한다.
単体テスト・結合テストが完了した後、システム全体が要件定義通りに動作するかを検証するテスト工程。本番環境に近い環境で実施する。
단위 테스트·통합 테스트 완료 후, 시스템 전체가 요건 정의대로 동작하는지 검증하는 테스트 공정. 운영 환경에 가까운 환경에서 실시한다.
APIのリクエスト・レスポンスをスクリプトで自動的に検証する手法。CI/CDパイプラインに組み込み、バックエンドの品質を継続的に担保するために活用される。
API의 요청·응답을 스크립트로 자동 검증하는 기법. CI/CD 파이프라인에 통합하여 백엔드 품질을 지속적으로 보장하는 데 활용된다.
システムをリリース前に実際のユーザーや顧客が要件を満たしているか検証するテスト。UAT（User Acceptance Testing）とも呼ばれ、最終承認の判断基準となる。
시스템을 릴리스하기 전에 실제 사용자나 고객이 요건을 충족하는지 검증하는 테스트. UAT(User Acceptance Testing)라고도 하며, 최종 승인의 판단 기준이 된다.
開発プロセス全体を通じて品質を継続的に維持・改善するアプローチ。CI/CDパイプラインやテスト自動化と組み合わせて、リリースごとに品質基準を担保する考え方。
개발 프로세스 전반에 걸쳐 품질을 지속적으로 유지·개선하는 접근 방식. CI/CD 파이프라인 및 테스트 자동화와 결합하여 릴리스마다 품질 기준을 보장하는 개념.
テスト時に未実装または依存コンポーネントの代替として使う仮実装。呼び出しに対して固定値を返すだけのシンプルな代替オブジェクト。
테스트 시 미구현 또는 의존 컴포넌트의 대체로 사용하는 가짜 구현체. 호출에 대해 고정값만 반환하는 단순한 대체 객체.
バグや障害・タスクの優先度を分類・評価するプロセス。重大度と緊急度を基準に対応順序を決定し、限られたリソースを効率的に配分するために行う。
버그나 장애, 태스크의 우선순위를 분류·평가하는 프로세스. 심각도와 긴급도를 기준으로 대응 순서를 결정하고, 한정된 리소스를 효율적으로 배분하기 위해 수행한다.
人間が手作業でソフトウェアの動作を確認するテスト手法。自動化テストと対比され、UIの使い勝手や複雑なシナリオの検証に適している。
사람이 직접 소프트웨어의 동작을 확인하는 테스트 기법. 자동화 테스트와 대비되며, UI 사용성이나 복잡한 시나리오 검증에 적합하다.
システムの応答時間・スループット・安定性を検証するため、負荷シナリオや測定指標を事前に定義するテスト計画プロセス。
시스템의 응답 시간, 처리량, 안정성을 검증하기 위해 부하 시나리오와 측정 지표를 사전에 정의하는 테스트 계획 프로세스.
実際のエンドユーザーがWebサービスを利用する際のパフォーマンスデータをリアルタイムで収集・分析する手法。RUMとも呼ばれ、ページロード時間やエラー率を把握できる。
실제 최종 사용자가 웹 서비스를 이용할 때의 성능 데이터를 실시간으로 수집·분석하는 기법. RUM이라고도 하며, 페이지 로드 시간이나 오류율을 파악할 수 있다.
テストがソースコードのどの程度の範囲を網羅しているかを数値化・分析する手法。行・分岐・条件などの観点でカバレッジを計測し、テストの品質向上に活用する。
테스트가 소스 코드의 얼마나 많은 범위를 커버하는지 수치화하고 분석하는 기법. 라인·분기·조건 등의 관점에서 커버리지를 측정하여 테스트 품질 향상에 활용한다.
時間を区切ったセッション単位で探索的テストを実施する手法。テスターが目標（チャーター）を持ち、一定時間内に自由にシステムを探索しながらバグを発見する。SBTとも呼ばれる。
시간을 구분한 세션 단위로 탐색적 테스트를 수행하는 기법. 테스터가 목표(차터)를 가지고 일정 시간 내에 자유롭게 시스템을 탐색하면서 버그를 발견한다. SBT라고도 불린다.
システム全体をユーザー視点で最初から最後まで通して検証するテスト手法。実際の使用シナリオを模倣し、UIからDBまで一連のフローが正常に動作するかを確認する。
시스템 전체를 사용자 관점에서 처음부터 끝까지 검증하는 테스트 기법. 실제 사용 시나리오를 모방하여 UI부터 DB까지 일련의 흐름이 정상적으로 동작하는지 확인한다.
個々のコンポーネント（モジュール）を独立して検証するテスト手法。ユニットテストより広い範囲をカバーし、コンポーネント単体の動作・インターフェースを確認する。
개별 컴포넌트(모듈)를 독립적으로 검증하는 테스트 기법. 유닛 테스트보다 넓은 범위를 커버하며, 컴포넌트 단체의 동작과 인터페이스를 확인한다.
BDD（Behavior Driven Development）はユーザーの振る舞いを自然言語で記述したシナリオを基にテストと実装を進める開発手法。Given-When-Thenの構文が使われる。
BDD(Behavior Driven Development)는 사용자의 행위를 자연어로 기술한 시나리오를 기반으로 테스트와 구현을 진행하는 개발 방법론으로, Given-When-Then 구문이 사용된다.
システムやアプリケーションの応答速度・処理能力・安定性を負荷をかけながら測定・評価するテスト手法。リリース前の品質保証として実施される。
시스템이나 애플리케이션의 응답 속도, 처리 능력, 안정성을 부하를 가하면서 측정·평가하는 테스트 기법으로, 릴리스 전 품질 보증을 위해 실시된다.
複数のWebブラウザ（Chrome、Firefox、Safari、Edgeなど）で、アプリケーションの表示や動作が一貫していることを確認するテスト手法。
여러 웹 브라우저(Chrome, Firefox, Safari, Edge 등)에서 애플리케이션의 표시 및 동작이 일관되게 작동하는지 확인하는 테스트 기법.
UX専門家がニールセンの10原則などの経験則に基づいてUIの問題点を発見する評価手法。ユーザーテストより低コストで短期間に実施できる。
UX 전문가가 닐슨의 10원칙 등 경험 법칙을 기반으로 UI 문제점을 발견하는 평가 기법. 사용자 테스트보다 저비용으로 단기간에 실시할 수 있다.
ソフトウェア変更後に既存機能が壊れていないかを確認する回帰テストを、スクリプトやツールで自動実行する手法。CI/CDパイプラインに組み込まれることが多い。
소프트웨어 변경 후 기존 기능이 정상 동작하는지 확인하는 회귀 테스트를 스크립트나 도구로 자동 실행하는 방법론으로, CI/CD 파이프라인에 통합되는 경우가 많다.
本番環境で意図的にランダムな障害を注入し、システムの耐障害性を検証するNetflixが開発したカオスエンジニアリングツール。
프로덕션 환경에서 의도적으로 무작위 장애를 주입하여 시스템의 내결함성을 검증하는 Netflix가 개발한 카오스 엔지니어링 도구.
開発ライフサイクルの早い段階（左側）でテストを実施する手法。バグの早期発見によりコスト削減と品質向上を実現する。CI/CDパイプラインと組み合わせて活用されることが多い。
개발 라이프사이클의 초기 단계(왼쪽)에서 테스트를 수행하는 기법. 버그를 조기에 발견하여 비용 절감과 품질 향상을 실현하며, CI/CD 파이프라인과 함께 활용되는 경우가 많다.
開発・検証・本番など複数の環境を適切に分離・維持管理すること。環境差異による不具合を防ぎ、品質担保と安定したリリースを実現するために不可欠なプロセス。
개발·검증·운영 등 여러 환경을 적절히 분리하고 유지 관리하는 것. 환경 차이로 인한 결함을 방지하고, 품질 보증과 안정적인 릴리스를 실현하기 위한 필수 프로세스.
ユーザー操作を模倣してシステム全体を端から端まで検証するE2Eテストを、Cypress・Playwrightなどのツールで自動実行する手法。リグレッション防止に有効。
사용자 동작을 모방하여 시스템 전체를 처음부터 끝까지 검증하는 E2E 테스트를 Cypress·Playwright 등의 도구로 자동 실행하는 방법. 회귀 방지에 효과적이다.
コードの各分岐（if/elseなど）が少なくとも1回実行されたかを測定するテスト網羅率指標。ステートメントカバレッジより厳密な品質基準として用いられる。
코드의 각 분기(if/else 등)가 최소 한 번 실행되었는지 측정하는 테스트 커버리지 지표. 구문 커버리지보다 엄격한 품질 기준으로 활용된다.
サービス間のAPI契約（コントラクト）を検証するテスト手法。ConsumerとProviderそれぞれが期待するインターフェース仕様を合意・検証することで、マイクロサービス間の結合不具合を早期に検出する。
서비스 간 API 계약(컨트랙트)을 검증하는 테스트 기법. Consumer와 Provider 각각이 기대하는 인터페이스 사양을 합의하고 검증함으로써 마이크로서비스 간 연동 결함을 조기에 발견한다.
本番環境に意図的に障害や異常を注入し、システムの耐障害性と回復力を検証するテスト手法。Netflix発祥のカオスエンジニアリングに基づく。
운영 환경에 의도적으로 장애나 이상을 주입하여 시스템의 내결함성과 복원력을 검증하는 테스트 기법. Netflix에서 시작된 카오스 엔지니어링에 기반한다.
ソフトウェアの品質を定量的に測定・評価するための指標群。バグ密度、コードカバレッジ、技術的負債などが代表例で、継続的な品質改善に活用される。
소프트웨어의 품질을 정량적으로 측정·평가하기 위한 지표 집합. 버그 밀도, 코드 커버리지, 기술 부채 등이 대표적이며, 지속적인 품질 개선에 활용된다.
システムが限界値を超えた高負荷状態でどう動作するかを検証するテスト手法。障害発生ポイントや回復力を把握するために実施する。
시스템이 한계치를 초과하는 고부하 상태에서 어떻게 동작하는지 검증하는 테스트 기법. 장애 발생 지점과 복구 능력을 파악하기 위해 실시한다.
ビルドやリリース後に基本的な機能が正常に動作するかを素早く確認する簡易テスト。スモークテストより範囲が狭く、特定機能の健全性を検証する。
빌드나 릴리스 후 기본 기능이 정상적으로 동작하는지 빠르게 확인하는 간이 테스트. 스모크 테스트보다 범위가 좁으며, 특정 기능의 건전성을 검증한다.
短時間に急激な負荷をシステムに与えて、スパイク（急上昇）時の挙動や耐性を確認する非機能テストの一種。システムの限界値や回復力を検証するために実施される。
짧은 시간에 급격한 부하를 시스템에 가해 스파이크(급상승) 시의 동작과 내성을 확인하는 비기능 테스트의 일종. 시스템의 한계값과 복구 능력을 검증하기 위해 실시된다.
UIコンポーネントの出力結果をファイルに保存し、次回実行時に差分を比較することで意図しない変更を検知するテスト手法。JestやStorybookで広く使われる。
UI 컴포넌트의 출력 결과를 파일에 저장하고, 다음 실행 시 차이를 비교하여 의도치 않은 변경을 감지하는 테스트 기법. Jest나 Storybook에서 널리 사용된다.
ソフトウェア開発においてQAを体系的に実施するための一連の工程。要件定義からリリースまで各フェーズで品質基準を満たすことを確認する仕組み。
소프트웨어 개발에서 QA를 체계적으로 수행하기 위한 일련의 공정. 요건 정의부터 릴리스까지 각 단계에서 품질 기준을 충족하는지 확인하는 체계.
テスト実行に必要なデータの作成・管理・マスキング・クリーンアップを体系的に行うプロセス。品質担保と個人情報保護の両立が求められる。
테스트 실행에 필요한 데이터의 생성·관리·마스킹·정리를 체계적으로 수행하는 프로세스. 품질 보증과 개인정보 보호를 동시에 충족해야 한다.
システムやアプリケーションが長時間にわたって安定して動作し続けるかを検証するテスト手法。メモリリークや性能劣化の検出に用いられる。
시스템이나 애플리케이션이 장시간 안정적으로 동작하는지를 검증하는 테스트 기법. 메모리 누수나 성능 저하 감지에 활용된다.
ビルドやデプロイ後に基本的な機能が正常動作するかを素早く確認する簡易テスト。致命的な不具合を早期発見し、詳細テストに進む前の前提確認として実施される。
빌드나 배포 후 기본적인 기능이 정상 동작하는지 빠르게 확인하는 간이 테스트. 치명적인 결함을 조기에 발견하고, 상세 테스트 진행 전 전제 확인으로 실시된다.
テスト時に実際の依存オブジェクトの代わりに使う偽のオブジェクト（モック）を作成する手法。外部APIやDBへのアクセスを模倣し、ユニットテストを独立して実行できるようにする。
테스트 시 실제 의존 객체 대신 사용하는 가짜 객체(목)를 생성하는 기법. 외부 API나 DB 접근을 모방하여 단위 테스트를 독립적으로 실행할 수 있게 한다.
JavaScriptベースのE2Eテストフレームワーク。ブラウザ上で直接動作し、リアルタイムのリロードやデバッグ機能を備え、フロントエンドのテスト自動化に広く使われる。
JavaScript 기반의 E2E 테스트 프레임워크. 브라우저에서 직접 동작하며, 실시간 리로드와 디버깅 기능을 갖추고 프론트엔드 테스트 자동화에 널리 활용된다.
複数の条件の組み合わせとそれに対応するアクションを表形式で整理したテスト設計技法。条件の網羅性を確保しテストケース漏れを防ぐのに有効。
여러 조건의 조합과 그에 대응하는 액션을 표 형식으로 정리한 테스트 설계 기법. 조건의 망라성을 확보하고 테스트 케이스 누락을 방지하는 데 효과적이다.
APIのエンドポイントに対してリクエストを送信し、レスポンスの正確性・性能・セキュリティを検証するテスト手法。PostmanやRestAssuredなどのツールが広く使われる。
API 엔드포인트에 요청을 보내 응답의 정확성·성능·보안을 검증하는 테스트 기법. Postman이나 RestAssured 등의 툴이 널리 사용된다.
障害者や高齢者を含むすべてのユーザーがWebやアプリを利用できるかを検証するテスト。WCAG準拠やスクリーンリーダー対応の確認が主な目的。
장애인 및 고령자를 포함한 모든 사용자가 웹 또는 앱을 이용할 수 있는지 검증하는 테스트. WCAG 준수 및 스크린 리더 대응 확인이 주된 목적.
テストを終了するための条件を定めた基準。バグ件数・テストケース消化率・カバレッジなどの指標を用いてリリース可否を判断するために使用される。
테스트를 종료하기 위한 조건을 정의한 기준. 버그 건수, 테스트 케이스 소화율, 커버리지 등의 지표를 활용하여 릴리스 가능 여부를 판단하는 데 사용된다.
UIの見た目の変化を画像比較で自動検出するテスト手法。コード変更後にスクリーンショットを比較し、意図しないデザインの崩れをCIパイプラインで検知する。
UI의 외관 변화를 이미지 비교로 자동 감지하는 테스트 기법. 코드 변경 후 스크린샷을 비교하여 의도치 않은 디자인 깨짐을 CI 파이프라인에서 감지한다.
報告されたバグが正しく修正されたかを検証する作業。修正後の動作確認・再現テストを行い、問題が解消されたことをQAやレビュアーが承認するプロセス。
보고된 버그가 올바르게 수정되었는지 검증하는 작업. 수정 후 동작 확인 및 재현 테스트를 수행하고, 문제가 해결되었음을 QA 또는 리뷰어가 승인하는 프로세스.
テスト工程の品質を定量的に評価する手法。バグ検出率・テストカバレッジ・欠陥密度などの指標を収集・分析し、品質改善やリリース判断の根拠として活用する。
테스트 공정의 품질을 정량적으로 평가하는 기법. 버그 검출율·테스트 커버리지·결함 밀도 등의 지표를 수집·분석하여 품질 개선 및 릴리스 판단의 근거로 활용한다.
アプリケーションのメモリ使用量を計測・分析する手法。メモリリークや過剰消費の原因を特定し、パフォーマンス改善に役立てる。VisualVMやValgrindなどのツールが使われる。
애플리케이션의 메모리 사용량을 측정·분석하는 기법. 메모리 누수나 과도한 소비 원인을 파악하고 성능 개선에 활용한다. VisualVM이나 Valgrind 등의 툴이 사용된다.
実際のスマートフォンやタブレットなど複数の端末上でアプリや画面の動作・表示を検証するテスト手法。機種・OSバージョン差異による不具合を事前に発見する目的で実施される。
실제 스마트폰이나 태블릿 등 다양한 단말기에서 앱 또는 화면의 동작·표시를 검증하는 테스트 기법. 기기 및 OS 버전 차이로 인한 결함을 사전에 발견하기 위해 실시된다.
関連するテストケースをまとめたグループ。特定の機能やモジュール単位でテストを整理・管理し、一括実行や結果の追跡を効率化するために使用される。
관련 테스트 케이스를 모아 놓은 그룹. 특정 기능이나 모듈 단위로 테스트를 정리·관리하여 일괄 실행 및 결과 추적을 효율화하기 위해 사용된다.
ソフトウェアの仕様書や要件定義書をもとにテストケースを設計する手法。ブラックボックステストとも呼ばれ、内部実装を意識せず期待動作を検証する。
소프트웨어 명세서나 요구사항 정의서를 기반으로 테스트 케이스를 설계하는 기법. 블랙박스 테스트라고도 하며, 내부 구현을 고려하지 않고 기대 동작을 검증한다.
テストがソースコードのどの程度の割合を実行したかを示す指標。行・分岐・関数単位で計測され、テストの網羅性を客観的に評価するために使われる。
테스트가 소스 코드의 어느 정도 비율을 실행했는지를 나타내는 지표. 라인·분기·함수 단위로 측정되며, 테스트의 망라성을 객관적으로 평가하기 위해 사용된다.
バグが与える影響の大きさを示す指標。Critical・High・Medium・Lowなどに分類され、修正優先度の判断に使われる。
버그가 미치는 영향의 크기를 나타내는 지표. Critical·High·Medium·Low 등으로 분류되며, 수정 우선순위 결정에 활용된다.
ソフトウェアの不具合を記録・報告するドキュメント。再現手順、期待値、実際の動作、環境情報などを含め、開発者が修正しやすい形式でまとめる。
소프트웨어의 결함을 기록하고 보고하는 문서. 재현 절차, 기대값, 실제 동작, 환경 정보 등을 포함하여 개발자가 수정하기 쉬운 형식으로 정리한다.
テストの自動化やツール導入により、テスト工程の時間・コスト・工数を削減し、品質を維持しながら開発サイクルを高速化する取り組み。
테스트 자동화 및 도구 도입을 통해 테스트 공정의 시간·비용·공수를 줄이고, 품질을 유지하면서 개발 사이클을 가속화하는 활동.
ソフトウェア開発において、設計書やソースコードを複数人で詳細にレビューし、欠陥や問題点を早期に発見・除去する品質保証手法。
소프트웨어 개발에서 설계서나 소스 코드를 여러 사람이 상세히 검토하여 결함 및 문제점을 조기에 발견하고 제거하는 품질 보증 기법.
事前にテストケースを定義せず、テスターが自由に操作しながらバグや問題を発見するテスト手法。直感や経験を活かし、仕様書では想定しにくい欠陥を見つけるのに有効。
사전에 테스트 케이스를 정의하지 않고, 테스터가 자유롭게 조작하면서 버그나 문제를 발견하는 테스트 기법. 직관과 경험을 활용해 명세서에서 상정하기 어려운 결함을 찾는 데 효과적이다.
アプリケーション実行中のCPU使用状況を計測・分析する手法。どの関数や処理がCPUリソースを多く消費しているかを特定し、パフォーマンスのボトルネック改善に活用する。
애플리케이션 실행 중 CPU 사용 현황을 측정·분석하는 기법. 어떤 함수나 처리가 CPU 리소스를 많이 소비하는지 파악하여 성능 병목 현상 개선에 활용한다.
複数の条件や環境の組み合わせを表形式（マトリクス）で整理し、テストケースの網羅性を高める手法。OSやブラウザの互換性検証などで活用される。
여러 조건이나 환경의 조합을 표 형식(매트릭스)으로 정리하여 테스트 케이스의 망라성을 높이는 기법. OS나 브라우저 호환성 검증 등에 활용된다.
ソースコードを実行せずに構文・品質・セキュリティ上の問題を検出するツール。LintやSonarQubeなどが代表例で、CI/CDパイプラインに組み込まれることが多い。
소스 코드를 실행하지 않고 구문·품질·보안 문제를 탐지하는 도구. Lint나 SonarQube 등이 대표적이며, CI/CD 파이프라인에 통합되는 경우가 많다.
システムの状態変化を網羅的にテストする手法。各状態と遷移条件を状態遷移図や表に整理し、正常・異常パターンを検証する。組み込みやWebアプリのワークフロー検証に有効。
시스템의 상태 변화를 체계적으로 테스트하는 기법. 각 상태와 전이 조건을 상태 전이도나 표로 정리하여 정상 및 비정상 패턴을 검증한다. 임베디드 및 웹 앱 워크플로 검증에 효과적이다.
プロジェクト全体のテスト方針・範囲・手法・スケジュールを定めた上位レベルの計画書。品質目標達成のための指針となるドキュメント。
프로젝트 전체의 테스트 방침·범위·기법·일정을 정의한 상위 레벨의 계획 문서로, 품질 목표 달성을 위한 지침이 되는 문서이다.
異なる環境・OS・ブラウザ・デバイス間でシステムが正常に動作するかを検証するテスト。リリース前に複数の環境での動作保証を確認するために実施する。
서로 다른 환경·OS·브라우저·디바이스 간에 시스템이 정상적으로 동작하는지 검증하는 테스트. 릴리스 전에 다양한 환경에서의 동작 보증을 확인하기 위해 실시한다.
システムの動作モデル（状態遷移図やUMLなど）を基にテストケースを自動生成する手法。テスト設計の効率化と網羅性向上に役立つ。
시스템의 동작 모델(상태 전이도, UML 등)을 기반으로 테스트 케이스를 자동 생성하는 기법으로, 테스트 설계 효율화와 커버리지 향상에 유용하다.
手動で行っていたソフトウェアテストをスクリプトやツールで自動実行する手法。回帰テストの効率化やCI/CDパイプラインへの組み込みに活用される。
수동으로 수행하던 소프트웨어 테스트를 스크립트나 툴로 자동 실행하는 방법론. 회귀 테스트 효율화 및 CI/CD 파이프라인 통합에 활용된다.
ランダムまたは半ランダムなデータをシステムに入力し、予期しない動作やクラッシュ、脆弱性を検出するテスト手法。セキュリティテストにも活用される。
랜덤 또는 반랜덤 데이터를 시스템에 입력하여 예기치 않은 동작, 크래시, 취약점을 탐지하는 테스트 기법으로, 보안 테스트에도 활용된다.
実行のたびに結果が変わる不安定なテスト（フレーキーテスト）を特定・修正・隔離する取り組み。CI/CDパイプラインの信頼性向上に直結する重要なQA活動。
실행할 때마다 결과가 달라지는 불안정한 테스트(플레이키 테스트)를 식별·수정·격리하는 활동으로, CI/CD 파이프라인의 신뢰성 향상에 직결되는 중요한 QA 작업이다.
事前の計画やドキュメントなしに、テスターの経験と直感に基づいて自由にシステムを探索するテスト手法。バグを素早く発見するのに有効。
사전 계획이나 문서 없이 테스터의 경험과 직관을 바탕으로 자유롭게 시스템을 탐색하는 테스트 기법으로, 버그를 빠르게 발견하는 데 효과적이다.
入力値の境界付近（最小値・最大値・その前後）にテストケースを集中させるテスト技法。バグが境界値周辺に多く潜む性質を利用し、効率的に欠陥を検出する。
입력값의 경계 근처(최솟값·최댓값·그 전후)에 테스트 케이스를 집중시키는 테스트 기법. 버그가 경계값 주변에 많이 숨어 있는 특성을 활용하여 효율적으로 결함을 발견한다.
スマートフォンやタブレット向けアプリの動作・UI・パフォーマンスを検証するテスト。実機・エミュレータを使い、OS種別やバージョン差異も考慮して品質を担保する。
스마트폰 및 태블릿용 앱의 동작, UI, 성능을 검증하는 테스트. 실제 기기와 에뮬레이터를 사용하며, OS 종류 및 버전 차이를 고려하여 품질을 보장한다.
コードや設計、セキュリティなどを検査・評価するツールまたは機能。IDEのコード検査機能やAWSのセキュリティ診断サービスなど、幅広い文脈で使われる。
코드, 설계, 보안 등을 검사·평가하는 도구 또는 기능. IDE의 코드 검사 기능이나 AWS의 보안 진단 서비스 등 다양한 맥락에서 사용된다.
ソフトウェアがどれだけテストしやすいかを示す品質特性。コードの構造や設計がテスト作成・実行・保守のしやすさに直結する。
소프트웨어가 얼마나 테스트하기 쉬운지를 나타내는 품질 특성. 코드 구조와 설계가 테스트 작성·실행·유지보수의 용이성에 직결된다.
テストの目的・範囲・スケジュール・担当者・手法などをまとめた文書を作成すること。品質保証の基盤となりプロジェクト開始前に作成されることが多い。
테스트의 목적, 범위, 일정, 담당자, 방법론 등을 정리한 문서를 작성하는 것. 품질 보증의 기반이 되며 프로젝트 시작 전에 작성되는 경우가 많다.
ソフトウェアのテストケースを効率的に作成するための手法。同値分割、境界値分析、デシジョンテーブルなどがあり、網羅性と効率のバランスを保つために活用される。
소프트웨어 테스트 케이스를 효율적으로 작성하기 위한 기법. 동치 분할, 경계값 분석, 결정 테이블 등이 있으며, 망라성과 효율의 균형을 유지하는 데 활용된다.
リスクの高い機能や領域を優先的にテストする手法。限られたリソースで最大の品質効果を得るため、障害発生確率と影響度に基づいてテスト優先順位を決定する。
리스크가 높은 기능이나 영역을 우선적으로 테스트하는 기법. 제한된 리소스로 최대의 품질 효과를 얻기 위해 결함 발생 확률과 영향도를 기반으로 테스트 우선순위를 결정한다.
複数のテストを同時に並行して実行する手法。CI/CDパイプラインでテスト時間を大幅に短縮でき、リリースサイクルの高速化に貢献する。
여러 테스트를 동시에 병렬로 실행하는 기법. CI/CD 파이프라인에서 테스트 시간을 크게 단축할 수 있으며, 릴리스 사이클 가속화에 기여한다.
APIの利用側（コンシューマー）が期待するインターフェース仕様をコントラクトとして定義し、提供側（プロバイダー）がそれを満たすかテストで検証する手法。マイクロサービス間の結合テストに有効。
API 소비자가 기대하는 인터페이스 사양을 계약으로 정의하고, 제공자(프로바이더)가 이를 충족하는지 테스트로 검증하는 기법. 마이크로서비스 간 통합 테스트에 효과적이다.
システムの負荷増大（ユーザー数・データ量など）に対して、性能を維持・拡張できるかを検証するテスト手法。
사용자 수나 데이터량 등 부하 증가에 대해 시스템이 성능을 유지하고 확장할 수 있는지 검증하는 테스트 기법이다.
実際のユーザーに製品やプロトタイプを操作してもらい、使いやすさや問題点を検証するテスト手法。UX改善の重要なプロセス。
실제 사용자가 제품이나 프로토타입을 직접 조작하게 하여 사용성과 문제점을 검증하는 테스트 기법으로, UX 개선의 핵심 프로세스입니다.
テスト時に本物のオブジェクトの代わりに使う代替オブジェクトの総称。スタブ・モック・フェイク・スパイ・ダミーの5種類に分類される。
테스트 시 실제 객체 대신 사용하는 대체 객체의 총칭. 스텁·목·페이크·스파이·더미의 5가지 종류로 분류된다.
実際のユーザーに製品を操作してもらい、使いやすさや問題点を評価・検証するテスト手法。UI/UX改善の重要なインプットとなる。
실제 사용자가 제품을 조작하게 하여 사용 편의성과 문제점을 평가·검증하는 테스트 기법. UI/UX 개선의 중요한 인풋이 된다.
アプリやシステムが異常終了した際に自動生成される障害報告書。スタックトレースやデバイス情報などを含み、原因調査に活用される。
앱이나 시스템이 비정상 종료될 때 자동으로 생성되는 장애 보고서. 스택 트레이스와 디바이스 정보 등을 포함하며 원인 분석에 활용된다.
本番環境とは分離された、ソフトウェアの動作検証を行うための環境。開発・QAチームがバグ検出やリグレッションテストを安全に実施できる場を指す。
운영 환경과 분리된, 소프트웨어 동작 검증을 위한 환경. 개발·QA 팀이 버그 발견이나 회귀 테스트를 안전하게 수행할 수 있는 공간을 말한다.
同一のテストケースや検証ロジックが複数箇所に重複して存在しないよう管理する品質管理手法。保守コスト削減とテストスイートの信頼性向上に寄与する。
동일한 테스트 케이스나 검증 로직이 여러 곳에 중복되지 않도록 관리하는 품질 관리 기법으로, 유지보수 비용 절감과 테스트 스위트의 신뢰성 향상에 기여한다.
本番環境や実ユーザーを対象に行うテスト手法。モニタリング・A/Bテスト・カナリアリリースなどを通じ、リリース後の品質を継続的に検証するアプローチ。
프로덕션 환경이나 실제 사용자를 대상으로 수행하는 테스트 기법. 모니터링, A/B 테스트, 카나리아 릴리스 등을 통해 릴리스 후 품질을 지속적으로 검증하는 접근 방식.
複数のモジュールやコンポーネントを組み合わせて、インターフェースやデータの受け渡しが正しく機能するかを検証するテスト工程。単体テストの次フェーズとして実施される。
여러 모듈이나 컴포넌트를 결합하여 인터페이스와 데이터 전달이 올바르게 동작하는지 검증하는 테스트 단계. 단위 테스트 이후 단계로 수행된다.
テスト工程に必要な工数・期間・コストを事前に算出するプロセス。テスト範囲、テストケース数、環境構築コストなどを考慮して見積もりを作成する。
테스트 공정에 필요한 공수·기간·비용을 사전에 산출하는 프로세스. 테스트 범위, 테스트 케이스 수, 환경 구축 비용 등을 고려하여 견적을 작성한다.
システムのユースケース（利用シナリオ）に基づいてテストケースを設計・実施する技法。ユーザー視点での一連の操作フローを検証し、機能要件の網羅性を確認する。
시스템의 유스케이스(이용 시나리오)를 기반으로 테스트 케이스를 설계·실행하는 기법. 사용자 관점의 일련의 조작 흐름을 검증하고 기능 요건의 망라성을 확인한다.
システムに大量のリクエストや処理を意図的にかけ、性能限界や応答時間の劣化を測定するテスト手法。本番環境に近い条件で実施する。
시스템에 대량의 요청이나 처리를 의도적으로 가하여 성능 한계와 응답 시간 저하를 측정하는 테스트 기법. 실제 운영 환경에 가까운 조건에서 실시한다.
ソフトウェアテストの構造モデル。底辺にユニットテスト、中段にインテグレーションテスト、頂点にE2Eテストを配置し、下層ほど数を多く実装することで効率的なテスト戦略を示す概念。
소프트웨어 테스트의 구조 모델. 하단에 유닛 테스트, 중간에 통합 테스트, 정점에 E2E 테스트를 배치하며, 하위 레이어일수록 더 많이 구현함으로써 효율적인 테스트 전략을 나타내는 개념.
テスト目的のために人工的にデータを生成・加工する手法。本番データを使わずにテストシナリオに合った任意のデータセットを作成し、テストの再現性と安全性を高める。
테스트 목적을 위해 인위적으로 데이터를 생성·가공하는 기법. 실제 운영 데이터를 사용하지 않고 테스트 시나리오에 맞는 임의의 데이터셋을 생성하여 테스트의 재현성과 안전성을 높인다.
CI/CDパイプラインにおいて、コードが次のフェーズへ進む前にカバレッジや静的解析などの品質基準を満たすことを強制する仕組み。
CI/CD 파이프라인에서 코드가 다음 단계로 진행되기 전에 커버리지나 정적 분석 등 품질 기준을 충족하도록 강제하는 설정.
Microsoftが開発したE2Eテスト自動化フレームワーク。Chromium・Firefox・WebKitをサポートし、クロスブラウザテストを単一APIで実行できる。
Microsoft가 개발한 E2E 테스트 자동화 프레임워크. Chromium·Firefox·WebKit을 지원하며, 크로스 브라우저 테스트를 단일 API로 실행할 수 있다.
ソフトウェアの品質確認のために、入力値・操作手順・期待結果を定義したテスト項目を設計・記述するプロセス。バグの早期発見と仕様の明確化に役立つ。
소프트웨어 품질 확인을 위해 입력값, 조작 절차, 기대 결과를 정의한 테스트 항목을 설계하고 기술하는 프로세스. 버그의 조기 발견과 사양 명확화에 도움이 된다.
ソフトウェアの一定規模（コード行数や機能点数）に対する欠陥数の比率を測定する品質指標。リリース判断やプロセス改善の基準として活用される。
소프트웨어의 일정 규모(코드 라인 수나 기능 점수)에 대한 결함 수의 비율을 측정하는 품질 지표. 릴리스 판단이나 프로세스 개선의 기준으로 활용된다.