본문으로 건너뛰기

용어집

이 분야의 글에는 영문 약어가 많이 나옵니다. 뜻을 모르면 문장 전체가 막히지만, 한 줄만 알면 대부분 그냥 읽힙니다. 이 커리큘럼에 실제로 나오는 약어 222개를 전공 지식 없이 읽을 수 있는 한 줄로 풀었습니다.

레슨을 읽다가 점선이 그어진 약어를 만나면 마우스를 올려 보세요. 뜻이 바로 나옵니다. 휴대전화에서는 레슨 맨 아래 낯선 말 풀이 칸에 같은 내용이 글로 정리돼 있습니다.

찾는 말이 있으면 브라우저의 페이지에서 찾기를 쓰면 가장 빠릅니다 (컴퓨터는 Ctrl+F, 맥은 ⌘+F).

QA 기본

이 분야의 일을 가리키는 말들.

AAA준비-실행-확인Arrange-Act-Assert

자동화 시험 코드를 세 덩어리로 나눠 쓰는 관습 — 상황을 만들고, 한 번 실행하고, 결과를 확인한다.

QA에게 이 순서가 깨진 시험 코드는 무엇을 확인하는지 읽기 어려워진다.

AC수용 기준Acceptance Criteria

"이 조건들을 만족하면 다 된 것으로 친다" 를 미리 글로 못 박아 둔 목록.

QA에게 다 만든 뒤에 "이게 된 거냐" 로 싸우지 않기 위해 미리 정한다. 그대로 시험 항목이 된다.

같이 보기 DoD, TC

BDD행위 주도 개발Behaviour-Driven Development

"어떤 상황에서 무엇을 하면 무엇이 된다"는 문장으로 요구사항을 적고, 그 문장을 그대로 시험으로 돌리는 방식.

QA에게 기획·개발·QA가 같은 문장을 보게 만든다. 문장이 곧 시험이라 어긋나지 않는다.

DoD완료의 정의Definition of Done

모든 작업에 똑같이 적용되는 "여기까지 해야 끝" 목록. 코드 검토·문서 갱신 같은 것들이다.

QA에게 수용 기준은 기능마다 다르고 이것은 전부에 같다. 둘 다 만족해야 진짜 끝이다.

같이 보기 AC

E2E끝에서 끝까지End-to-End

화면 한 조각이 아니라 사용자가 밟는 전체 흐름을 처음부터 끝까지 한 번에 돌려 보는 시험.

QA에게 가장 현실에 가깝지만 가장 느리고 가장 잘 깨진다. 몇 개만 고르는 것이 요령이다.

같이 보기 UI

MBT모델 기반 테스팅Model-Based Testing

화면 흐름이나 상태 변화를 그림(모델)으로 먼저 그리고, 거기서 시험할 경로를 기계적으로 뽑아내는 방식.

QA에게 손으로 케이스를 뽑으면 빠지는 경로가 생긴다. 모델에서 뽑으면 빠짐을 셀 수 있다.

MC/DC변형 조건·결정 커버리지Modified Condition/Decision Coverage

조건이 여러 개 붙은 판단문에서, 각 조건이 혼자서 결과를 바꾸는 경우까지 모두 확인했는지 재는 기준.

QA에게 항공·자동차처럼 사람이 다칠 수 있는 분야에서 가장 엄격한 등급이 이 기준을 요구한다.

같이 보기 DO-178C, ASIL

POM페이지 객체 모델Page Object Model

화면마다 "이 화면에서 할 수 있는 일"을 모아 둔 코드 조각을 만들어 두고, 시험은 그것만 호출하게 하는 설계.

QA에게 화면이 바뀌면 그 조각 한 곳만 고치면 된다. 안 하면 시험 수백 개를 다 고친다.

QA품질보증Quality Assurance

만든 것이 쓸 만한지 확인하고, 애초에 덜 망가지게 만드는 방법을 정하는 일. "테스트"는 그 일의 일부다.

QA에게 이 커리큘럼 전체의 직무 이름이다. 공고에는 QA·테스터·QA 엔지니어가 섞여 쓰인다.

같이 보기 QC

QC품질관리Quality Control

이미 만들어진 것에서 불량을 골라내는 일. 품질보증은 불량이 생기는 과정 자체를 다룬다는 점이 다르다.

QA에게 두 단어를 섞어 쓰는 조직이 많다. 면접에서 차이를 묻는 일이 잦다.

같이 보기 QA

RBT리스크 기반 테스트Risk-Based Testing

다 해 볼 수 없으니, 잘못됐을 때 피해가 크고 잘못될 가능성도 높은 곳부터 본다는 방식.

QA에게 진짜 산출물은 완벽한 시험이 아니라 "무엇을 덜 봤는지" 를 말할 수 있게 되는 것이다.

SUT시험 대상 시스템System Under Test

지금 시험하고 있는 바로 그 시스템. 시험하는 도구 쪽과 구별해 부를 때 쓴다.

TC테스트 케이스Test Case

무엇을 어떻게 해보고 무엇이 나와야 하는지를 한 건으로 적어 둔 것. 시험 문제 한 문항에 해당한다.

QA에게 QA가 가장 많이 쓰고 가장 많이 읽는 문서다. 표에서 TC-001 같은 번호로 나타난다.

TPI테스트 프로세스 개선Test Process Improvement

지금 팀의 테스트 방식이 어느 수준인지 항목별로 진단하고, 다음에 올릴 항목을 고르는 틀.

QA에게 "테스트를 잘하자"를 측정 가능한 단계로 바꿔 준다.

같이 보기 CMMI

UAT인수 테스트User Acceptance Testing

만든 쪽이 아니라 실제로 쓸 사람이 "이거면 받겠다"를 확인하는 마지막 시험.

QA에게 공공·기업 프로젝트에서 검수와 대금 지급의 근거가 된다.

개발·웹 기초

화면 뒤에서 무엇이 오가는지에 관한 말들.

API응용 프로그램 인터페이스Application Programming Interface

프로그램끼리 주고받는 창구. 사람이 화면 버튼을 누르는 대신, 프로그램이 정해진 주소로 요청을 보내 답을 받는다.

QA에게 화면이 멀쩡해도 창구가 틀린 값을 주면 버그다. 화면을 거치지 않고 창구만 직접 두드려 보는 시험이 API 테스트다.

같이 보기 HTTP, JSON, REST

CDN콘텐츠 전송 망Content Delivery Network

이미지나 파일을 세계 여러 곳에 미리 복사해 두고 가까운 곳에서 내려 주는 구조.

QA에게 낡은 복사본이 남아 있어 "고쳤는데 그대로 보인다"가 생긴다.

CLI명령 줄 인터페이스Command-Line Interface

검은 화면에 글자로 명령을 적어 넣는 방식. 버튼은 없고 줄마다 명령을 쓴다.

QA에게 자동화 도구는 거의 다 이 방식으로 실행한다. 명령 한 줄을 읽고 고치는 정도는 필요하다.

같이 보기 GUI

CORS교차 출처 자원 공유Cross-Origin Resource Sharing

웹 화면이 다른 주소의 창구를 부를 수 있는지를 정하는 규칙. 허용되지 않으면 브라우저가 막는다.

QA에게 "내 컴퓨터에선 되는데 배포하면 안 된다"의 흔한 원인이다. 서버는 정상인데 브라우저가 막는 경우다.

CPU중앙처리장치Central Processing Unit

계산을 담당하는 부품. 사람으로 치면 머리다.

QA에게 성능 시험에서 "느린 이유가 계산이냐, 기다림이냐"를 가르는 첫 지표다.

같이 보기 GPU

CSS스타일 시트Cascading Style Sheets

화면의 색·크기·배치를 정하는 규칙. 뼈대와 꾸밈을 분리해 둔 것이다.

QA에게 "글자가 잘린다", "버튼이 겹친다" 같은 결함의 원인이 대개 여기다.

같이 보기 HTML

CSV쉼표로 구분된 값Comma-Separated Values

표를 글자로 적어 둔 가장 단순한 형식. 줄마다 한 행, 쉼표로 칸을 나눈다.

QA에게 많은 양의 시험 데이터를 넣고 뺄 때 쓴다. 쉼표가 값 안에 들어가면 깨지는 것이 전형적인 결함이다.

DB데이터베이스Database

데이터를 넣어 두고 꺼내 쓰는 저장소. 보통 표 여러 개가 서로 연결된 형태다.

QA에게 화면에 값이 잘 보여도 저장소에 잘못 들어가 있으면 결함이다. QA가 직접 들여다보는 일이 흔하다.

같이 보기 SQL

DNS도메인 이름 체계Domain Name System

사람이 읽는 주소를 컴퓨터가 쓰는 번호로 바꿔 주는 전화번호부.

QA에게 "사이트가 아예 안 열린다"의 원인이 서비스가 아니라 이 전화번호부일 수 있다.

같이 보기 IP

DOM문서 객체 모델Document Object Model

웹 화면을 프로그램이 다룰 수 있게 나무 구조로 바꿔 놓은 것. 화면의 현재 상태를 담고 있다.

QA에게 자동화 도구는 이 구조에서 요소를 찾는다. 뼈대 글자와 현재 상태가 다를 수 있다는 점이 중요하다.

같이 보기 HTML

GC가비지 컬렉션Garbage Collection

더 이상 쓰지 않는 메모리를 프로그램이 알아서 치우는 일.

QA에게 치우는 동안 잠깐 멈춘다. 성능 시험에서 주기적인 응답 지연으로 나타난다.

같이 보기 JVM, OOM

GPU그래픽처리장치Graphics Processing Unit

비슷한 계산을 한꺼번에 많이 하는 데 특화된 부품. 그림과 기계학습에 쓰인다.

QA에게 인공지능 기능의 응답 시간과 비용이 이 부품 확보량에 좌우된다.

같이 보기 CPU

GUI그래픽 사용자 인터페이스Graphical User Interface

글자만 있는 화면이 아니라 그림·버튼·창으로 조작하는 화면. 보통 말하는 "화면"이 이것이다.

QA에게 글자만으로 다루는 방식과 구별할 때 쓴다.

같이 보기 UI, CLI

HTML하이퍼텍스트 표시 언어HyperText Markup Language

웹 화면의 뼈대를 적는 글자 형식. 제목·문단·버튼 같은 역할을 꺾쇠 괄호로 표시한다.

QA에게 화면에서 특정 버튼을 자동으로 찾아 누르려면 이 뼈대를 읽어야 한다.

같이 보기 CSS, DOM

HTTP하이퍼텍스트 전송 규약HyperText Transfer Protocol

웹에서 요청과 응답을 주고받는 약속. "무엇을 달라"고 보내면 "여기 있다" 또는 "그런 건 없다"가 돌아온다.

QA에게 응답에 붙는 숫자(200·404·500 같은 상태 코드)만 봐도 문제가 어느 쪽에 있는지 좁혀진다.

같이 보기 HTTPS, API

HTTPS암호화된 웹 전송HTTP Secure

웹 통신을 암호로 감싼 것. 중간에서 누가 들여다봐도 내용을 못 읽는다.

QA에게 로그인·결제 화면이 암호화 없이 열리면 그 자체로 보안 결함이다.

같이 보기 HTTP, TLS

ID식별자Identifier

무엇 하나를 다른 것과 구별하기 위해 붙인 이름이나 번호.

QA에게 결함·시험 케이스·요구사항을 서로 연결하는 끈이다. 끈이 없으면 추적이 안 된다.

IP아이피 주소Internet Protocol address

인터넷에 연결된 기기마다 붙는 번호.

QA에게 접속 제한·지역 차단 기능을 시험할 때 이 번호를 바꿔 봐야 한다.

같이 보기 DNS

IT정보기술Information Technology

컴퓨터와 통신으로 정보를 다루는 기술 전체.

QA에게 이 분야 전체를 가리키는 가장 넓은 말이다.

같이 보기 ICT

JS자바스크립트JavaScript

웹 화면을 움직이게 만드는 프로그래밍 언어. 버튼을 눌렀을 때 일어나는 일을 적는다.

같이 보기 HTML, CSS, DOM

JSON제이슨JavaScript Object Notation

프로그램끼리 값을 주고받을 때 쓰는 글자 형식. 괄호와 따옴표로 이름과 값을 짝지어 적는다.

QA에게 창구 응답이 거의 다 이 형식이다. 개발자 도구에서 매일 보게 된다.

같이 보기 API, XML, YAML

JVM자바 가상 머신Java Virtual Machine

자바로 만든 프로그램을 돌려 주는 바탕 프로그램.

QA에게 메모리 부족 오류와 성능 설정이 이 바탕 프로그램 쪽에 있다.

같이 보기 VM, OOM, GC

KB킬로바이트Kilobyte

데이터 양의 단위. 1,000 킬로바이트가 대략 1 메가바이트다.

같이 보기 MB

LTE엘티이Long Term Evolution

휴대전화 통신 방식의 한 세대. 흔히 말하는 4G 다.

QA에게 같은 앱도 사무실 유선망과 이동 중 통신망에서 속도가 크게 다르다. 어디서 쟀는지 적어야 한다.

MB메가바이트Megabyte

데이터 양의 단위. 사진 한 장이 대략 2~5 메가바이트쯤 된다.

NULL값 없음null

"값이 아직 없다" 를 나타내는 특별한 표시. 0 이나 빈 글자와는 다르다.

QA에게 빈칸을 0 으로 세거나 글자로 이어 붙이려다 깨지는 결함이 흔하다. 경계값 시험의 단골 항목이다.

OOM메모리 부족Out Of Memory

쓸 수 있는 메모리를 다 써서 프로그램이 죽는 상황.

QA에게 장시간 돌려야 드러난다. 짧은 시험으로는 안 잡히는 전형적인 결함이다.

같이 보기 JVM, GC

OpenAPI오픈에이피아이 명세OpenAPI Specification

창구가 어떤 주소로 무엇을 받고 무엇을 돌려주는지 정해진 형식으로 적어 둔 문서.

QA에게 이 문서와 실제 동작이 어긋나는 것 자체가 결함이다. 문서에서 시험 케이스를 기계로 뽑을 수도 있다.

같이 보기 API, JSON, YAML

OS운영체제Operating System

기기를 돌리는 바탕 프로그램 — 윈도우, 맥, 안드로이드 같은 것.

QA에게 같은 앱이 운영체제마다 다르게 동작한다. 어디서 재현했는지 적는 것이 결함 보고의 기본이다.

PDF피디에프Portable Document Format

어디서 열어도 모양이 같게 나오도록 만든 문서 형식.

QA에게 성적서·보고서 산출물이 이 형식이다. 글자가 선택되는지, 화면 읽기 도구가 읽는지도 확인 대상이다.

REST레스트Representational State Transfer

창구를 만드는 가장 흔한 방식. 주소 하나가 자원 하나를 가리키고, 동작은 정해진 몇 가지 말로 구분한다.

QA에게 창구 시험의 기본 형태다. 조회·생성·수정·삭제가 각각 어떤 말에 해당하는지 알아야 한다.

같이 보기 API, HTTP

SDK소프트웨어 개발 도구 모음Software Development Kit

어떤 기능을 쓰려고 할 때 필요한 도구와 코드를 묶어 둔 꾸러미.

QA에게 버전이 올라가면 동작이 조용히 바뀐다. 무엇이 바뀌었는지 확인할 대상이다.

SMS문자 메시지Short Message Service

휴대전화 문자.

QA에게 본인 확인 번호 전송이 제때 오는지, 늦게 오면 어떻게 되는지가 시험 항목이다.

SQL구조화 질의 언어Structured Query Language

저장소에 "이런 조건인 줄을 보여 달라"고 묻는 말. 영어 문장에 가까워서 읽기가 비교적 쉽다.

QA에게 제보받은 데이터가 실제로 어떻게 저장돼 있는지 확인하려면 이 말로 물어봐야 한다.

같이 보기 DB

SW소프트웨어Software

소프트웨어를 줄여 적은 말. 국내 공공·업계 문서에서 특히 자주 쓰인다.

TCP전송 제어 규약Transmission Control Protocol

데이터를 빠뜨리지 않고 순서대로 보내는 약속. 웹도 이 위에서 돌아간다.

QA에게 성능·연결 끊김 문제를 다룰 때 이 층에서 원인을 찾는다.

같이 보기 HTTP

TLS전송 계층 보안Transport Layer Security

통신을 암호로 감싸는 기술 그 자체. 웹에서 쓰면 주소가 https로 시작한다.

QA에게 버전이 낡으면 취약점 점검에서 걸린다.

같이 보기 HTTPS

UI사용자 인터페이스User Interface

사람이 직접 보고 누르는 부분 — 화면, 버튼, 입력창.

QA에게 QA가 가장 먼저 만지는 곳이다. 다만 UI만 보면 창구나 저장소에서 난 문제를 놓친다.

같이 보기 GUI, UX, API

URL인터넷 주소Uniform Resource Locator

웹에서 무언가의 위치를 가리키는 주소 한 줄.

QA에게 결함을 보고할 때 주소를 그대로 붙이면 재현 단계가 한 줄 줄어든다.

UX사용자 경험User Experience

쓰는 사람이 느끼는 전체 느낌 — 빠른가, 헷갈리지 않는가, 실수해도 되돌릴 수 있는가.

QA에게 "동작은 하는데 쓰기 어렵다"는 결함을 보고할 때의 근거가 된다.

같이 보기 UI

VM가상 머신Virtual Machine

한 컴퓨터 안에 소프트웨어로 만들어 낸 또 다른 컴퓨터.

QA에게 여러 운영체제에서 같은 시험을 돌릴 때 쓴다.

VPN가상 사설망Virtual Private Network

공용 인터넷을 지나면서도 사내망에 직접 연결된 것처럼 쓰게 해 주는 장치.

QA에게 사내망에서만 되는 기능을 밖에서 시험할 때 쓴다. 느려지므로 성능 측정에는 주의한다.

XML확장 표시 언어Extensible Markup Language

제이슨과 목적이 같은, 더 오래된 글자 형식. 꺾쇠 괄호로 이름을 감싼다.

QA에게 금융·공공 시스템과 자동화 도구의 결과 파일에 아직 많이 쓰인다.

같이 보기 JSON

YAML야믈YAML Ain't Markup Language

들여쓰기로 구조를 나타내는 설정 파일 형식. 사람이 읽기 쉬운 쪽으로 만든 것이다.

QA에게 자동화 설정 파일이 대부분 이 형식이다. 들여쓰기 한 칸 차이로 깨진다.

같이 보기 JSON

컨테이너컨테이너

이 커리큘럼에서 두 가지로 쓰인다. ① 프로그램과 그것을 돌리는 데 필요한 것들을 한 상자에 담아, 어느 컴퓨터에서나 똑같이 돌아가게 만든 것 ② 화면에서 여러 요소를 하나로 묶는 바깥 틀. 서버·배포 이야기면 ①, 화면·접근성 이야기면 ②다.

QA에게 ① 은 "내 컴퓨터에선 되는데" 를 줄이려고 쓴다. 대신 그 상자 밖의 설정이 틀리면 똑같이 깨진다.

테넌트입주자tenant

한 시스템을 여러 고객사가 나눠 쓸 때, 그 고객사 하나하나를 가리키는 말. 건물의 입주자에 해당한다.

QA에게 가장 큰 결함은 **한 입주자가 다른 입주자의 자료를 보는 것**이다. 권한 시험의 핵심 축이다.

표준·인증·자격

"무엇을 지켜야 하는가"를 정하는 문서와 단체.

CC공통평가기준Common Criteria

보안 제품이 얼마나 믿을 만한지 평가하는 국제 기준. 보증 등급으로 결과를 표시한다.

QA에게 공공 보안 제품 납품에 요구된다. 등급이 높아질수록 요구하는 증거 문서가 급격히 늘어난다.

CENELEC유럽전기기술표준화위원회European Committee for Electrotechnical Standardization

유럽의 전기·전자 분야 표준을 만드는 단체.

같이 보기 EN, EU, IEC

CMMI능력 성숙도 모델 통합Capability Maturity Model Integration

조직의 개발·관리 능력을 1~5단계로 매기는 모델.

QA에게 발주처가 등급을 요구한다. 등급을 올리려면 문서와 절차의 증거가 필요하고, 그 증거를 QA가 만든다.

같이 보기 SPICE, TPI

CT-AI전문 자격 · 인공지능 테스팅Certified Tester — AI Testing

인공지능 기능을 어떻게 시험하는지 다루는 전문 과목.

같이 보기 ISTQB, AI

CT-GenAI전문 자격 · 생성형 인공지능 테스팅Certified Tester — Generative AI Testing

글이나 그림을 만들어 내는 인공지능을 어떻게 시험하는지 다루는 전문 과목.

같이 보기 ISTQB, LLM, CT-AI

CT-PT전문 자격 · 성능 테스팅Certified Tester — Performance Testing

성능 시험을 다루는 전문 과목.

같이 보기 ISTQB, TPS

CT-TAE전문 자격 · 테스트 자동화Certified Tester — Test Automation Engineering

자동화 설계를 다루는 과목. 상급 자격의 같은 과목을 이렇게도 표기한다.

같이 보기 CTAL-TAE, ISTQB

CTAL상급 테스터 자격Certified Tester Advanced Level

기초 등급 위의 단계. 분석·관리·자동화 같은 갈래로 나뉜다.

QA에게 공고에서 갈래 약칭(분석·관리·자동화)으로 특정 과목을 요구하기도 한다.

같이 보기 ISTQB, CTFL

CTAL-TA상급 자격 · 테스트 분석Certified Tester Advanced Level — Test Analyst

상급 테스터 자격 중 테스트 설계·분석을 다루는 과목.

같이 보기 CTAL, ISTQB

CTAL-TAE상급 자격 · 테스트 자동화Certified Tester Advanced Level — Test Automation Engineering

상급 테스터 자격 중 자동화 설계를 다루는 과목.

같이 보기 CTAL, ISTQB, POM

CTAL-TM상급 자격 · 테스트 관리Certified Tester Advanced Level — Test Manager

상급 테스터 자격 중 계획·일정·사람 관리를 다루는 과목.

같이 보기 CTAL, ISTQB

CTFL기초 등급 테스터 자격Certified Tester Foundation Level

테스터 자격의 가장 기초 단계. 용어와 기본 기법을 다룬다.

QA에게 비전공자가 이 분야에 들어올 때 가장 많이 선택하는 첫 자격이다.

같이 보기 ISTQB, CTAL

EN유럽 표준European Norm

유럽 공통 표준 문서에 붙는 번호 앞머리.

QA에게 유럽 수출 제품의 시험 항목이 이 번호에 적혀 있다.

같이 보기 EU

EU유럽연합European Union

유럽 나라들의 연합체. 역내 공통 규정을 만든다.

QA에게 유럽에 내보내는 제품은 역내 규정을 통과해야 한다. 규정이 시험 항목을 지정한다.

같이 보기 EN

FDA미국 식품의약국Food and Drug Administration

미국에서 식품·의약품·의료기기를 허가하는 기관.

QA에게 의료기기 소프트웨어를 미국에 내려면 이 기관이 요구하는 문서와 시험 증거를 갖춰야 한다.

같이 보기 SBOM, SOUP

GS지에스 인증Good Software

국내 소프트웨어 품질 인증. 받으면 공공 조달에서 유리해진다.

QA에게 인증 시험 항목이 곧 시험 계획이 된다. 국내 QA 실무에서 자주 만나는 절차다.

같이 보기 TTA, KOLAS

ICT정보통신기술Information and Communications Technology

정보와 통신을 다루는 기술 전체를 묶어 부르는 말.

QA에게 국내 표준·정책 문서에서 분야를 가리킬 때 쓴다.

IEC국제전기기술위원회International Electrotechnical Commission

전기·전자 분야의 국제 규격을 만드는 단체.

QA에게 안전 관련 규격 대부분이 이 단체 번호를 달고 있다.

같이 보기 ISO

IEEE전기전자기술자협회Institute of Electrical and Electronics Engineers

전기·전자·컴퓨터 분야의 세계 최대 기술자 단체. 규격도 만든다.

QA에게 소프트웨어 시험 문서 규격이 이 단체와 공동으로 만들어졌다.

같이 보기 ISO, IEC

ISMS정보보호 관리체계Information Security Management System

정보 보안을 사람·절차·기술로 묶어 관리하는 체계.

QA에게 개인정보까지 포함한 국내 인증과 구별해 쓸 때가 있다.

같이 보기 ISMS-P

ISMS-P정보보호 및 개인정보보호 관리체계 인증Information Security Management System with Personal information

조직이 정보와 개인정보를 제대로 관리하는지 국내에서 인증해 주는 제도.

QA에게 일정 규모 이상 서비스는 의무다. 인증 항목이 그대로 점검 목록이 된다.

같이 보기 ISMS

ISO국제표준화기구International Organization for Standardization

여러 나라가 모여 "이건 이렇게 하자"를 문서로 정하는 단체. 그 문서 자체를 번호로 부른다.

QA에게 규격 번호가 곧 시험 항목이 되는 분야가 많다. 번호를 보면 무엇을 요구하는지 찾아갈 수 있다.

같이 보기 IEC, IEEE

ISO/IEC국제표준화기구·국제전기기술위원회 공동 표준ISO and IEC joint standard

두 국제 단체가 함께 낸 표준이라는 표시. 뒤에 붙는 숫자가 문서 번호다.

QA에게 소프트웨어 품질 규격 대부분이 이 공동 번호를 달고 있다.

같이 보기 ISO, IEC

ISO/IEC/IEEE세 단체 공동 표준ISO, IEC and IEEE joint standard

세 국제 단체가 함께 낸 표준이라는 표시.

QA에게 소프트웨어 시험 문서 규격이 이 공동 번호다. 시험 계획서 양식의 출처가 된다.

같이 보기 ISO, IEC, IEEE

ISO/SAE국제표준화기구·미국자동차공학회 공동 표준ISO and SAE joint standard

자동차 분야에서 두 단체가 함께 낸 표준이라는 표시.

QA에게 차량 보안 규격이 이 공동 번호로 나온다.

같이 보기 ISO, SAE

ISTQB국제 소프트웨어 테스팅 자격 위원회International Software Testing Qualifications Board

테스터 자격 시험을 만들고 용어를 정리하는 국제 단체.

QA에게 채용 공고에 가장 자주 등장하는 자격이다. 시험 범위가 업계 공통 어휘 구실을 한다.

같이 보기 CTFL, CTAL

ITU-T국제전기통신연합 표준화부문ITU Telecommunication Standardization Sector

통신 분야 국제 규격을 만드는 국제연합 산하 기구의 한 부문.

QA에게 통신·영상 품질 지표가 이 기구 권고안에 정의돼 있다.

KISA한국인터넷진흥원Korea Internet & Security Agency

국내 인터넷·정보보호를 담당하는 기관.

QA에게 국내 보안 인증과 취약점 신고 창구를 운영한다.

같이 보기 ISMS-P

KOLAS한국인정기구Korea Laboratory Accreditation Scheme

시험·검사를 하는 기관이 믿을 만한지 국가가 인정해 주는 제도. 인정받은 기관의 성적서는 공식 문서로 통한다.

QA에게 성적서를 발행하려면 인정 범위 안에 들어야 한다. 범위 밖 항목은 시험해도 성적서를 못 낸다.

같이 보기 ISO

KS한국산업표준 · 두 분포 차이 통계량Korean Industrial Standards / Kolmogorov-Smirnov

이 커리큘럼에서 두 가지로 쓰인다. ① 한국이 정한 국가 표준(KS X·KS Q 처럼 쓴다) ② 두 데이터 묶음의 분포가 얼마나 다른지 재는 통계값. 뒤에 번호가 붙으면 ①, 드리프트·분포 이야기면 ②다.

QA에게 ① 은 국내 인증·조달에서 요구하는 번호다. 국제 규격과 같은 내용인지 확인해야 한다.

같이 보기 ISO

KTL한국산업기술시험원Korea Testing Laboratory

국내 공인 시험 기관 중 하나.

QA에게 인증 시험을 의뢰하거나 성적서를 받는 상대가 된다.

같이 보기 KOLAS, KTR

KTR한국화학융합시험연구원Korea Testing & Research Institute

국내 공인 시험·연구 기관 중 하나.

QA에게 제품 분야에 따라 의뢰 기관이 달라진다.

같이 보기 KOLAS, KTL

NCS국가직무능력표준National Competency Standards

직무마다 필요한 능력을 국가가 정리해 둔 표준.

QA에게 국내 채용·교육과정이 이 표준을 기준으로 설계된다.

같이 보기 SFIA

NIA한국지능정보사회진흥원National Information Society Agency

국가 정보화 사업과 공공 데이터를 담당하는 기관.

QA에게 공공 사업 품질 기준과 지침이 여기서 나온다.

NIST미국 국립표준기술연구소National Institute of Standards and Technology

미국의 표준·기술 연구기관. 보안 지침을 많이 낸다.

QA에게 보안 점검 항목의 출처로 가장 흔히 인용된다.

SFIA정보화 시대 역량 체계Skills Framework for the Information Age

정보기술 직무의 역량을 등급과 항목으로 정리해 둔 국제 체계.

QA에게 "내 지금 수준이 몇 단계인가"를 공통 언어로 말할 수 있게 해 준다.

같이 보기 NCS

SPICE스파이스Software Process Improvement and Capability dEtermination

개발 과정을 항목별로 평가하는 국제 틀. 자동차 분야 변형이 널리 쓰인다.

QA에게 자동차 부품 공급사는 이 평가 등급을 요구받는다. 시험 관련 항목이 평가 대상에 들어 있다.

같이 보기 CMMI

SQuaRE소프트웨어 품질 요구·평가 규격군Systems and software Quality Requirements and Evaluation

소프트웨어 품질을 무엇으로 보고 어떻게 재는지 정한 국제 규격 묶음의 이름.

QA에게 품질 특성 이름과 측정 방법이 여기서 나온다. 인증 심사 항목의 출처이기도 하다.

같이 보기 ISO/IEC

SWE소프트웨어 공정 그룹Software Engineering process group

스파이스 평가에서 소프트웨어 관련 항목에 붙는 묶음 이름. 번호로 세부 항목을 가리킨다.

QA에게 평가 대응 때 "어느 번호에 어떤 증거를 낼지"가 실제 업무가 된다.

같이 보기 SPICE

TMMi테스트 성숙도 모델Test Maturity Model integration

조직의 테스트 능력을 단계로 매겨 다음에 무엇을 올릴지 정하는 모델.

QA에게 "테스트를 잘하자" 를 측정 가능한 단계로 바꿔 준다.

같이 보기 TPI, CMMI

TR기술 보고서Technical Report

표준 단체가 내는 문서 중, 지켜야 하는 요구가 아니라 참고용 설명에 해당하는 것.

QA에게 "이건 의무인가 참고인가"가 인증 대응에서 갈린다.

같이 보기 TS, ISO

TS기술 명세Technical Specification

정식 표준이 되기 전 단계의 문서. 내용은 요구사항에 가깝다.

QA에게 정식 표준으로 승격되면 번호가 바뀐다. 어느 판을 쓰는지 적어야 한다.

같이 보기 TR, ISO

TTA한국정보통신기술협회Telecommunications Technology Association

국내 정보통신 표준을 만들고 시험·인증도 하는 기관.

QA에게 국내 표준 번호와 시험 서비스가 이 기관에서 나온다.

같이 보기 GS, TTAK

TTAK티티에이 단체표준TTA Standard (Korea)

국내 정보통신 표준 문서에 붙는 번호 앞머리.

QA에게 신산업 분야는 국제 규격보다 이 국내 표준이 먼저 나오는 경우가 있다.

같이 보기 TTA

UN국제연합United Nations

여러 나라가 모인 국제기구. 산하 기구가 분야별 규정을 만든다.

같이 보기 UNECE, ITU-T

UNECE유엔 유럽경제위원회United Nations Economic Commission for Europe

자동차 관련 국제 규정을 만드는 국제연합 기구.

QA에게 차량 보안·갱신 관련 규정이 여기서 나와 각국 법으로 들어온다.

같이 보기 OTA

안전·보안

사람이 다치거나 정보가 새는 것을 막는 분야.

ASIL자동차 안전 완전성 수준Automotive Safety Integrity Level

자동차 분야의 위험 등급. A부터 D까지이고 D가 가장 엄격하다.

QA에게 등급마다 요구하는 시험 기법과 커버리지 기준이 다르다.

같이 보기 SIL, HARA, MC/DC

CSRF크로스 사이트 요청 위조Cross-Site Request Forgery

로그인한 사람의 권한을 몰래 빌려 원치 않는 요청을 보내게 만드는 공격.

QA에게 상태를 바꾸는 요청마다 보호 장치가 있는지 확인해야 한다.

같이 보기 XSS, OWASP

CVSS공통 취약점 등급 체계Common Vulnerability Scoring System

발견된 취약점이 얼마나 심각한지 0~10점으로 매기는 공통 방식.

QA에게 "먼저 고칠 것"을 점수로 줄 세울 수 있다.

같이 보기 SCA

DAST동적 보안 분석Dynamic Application Security Testing

실제로 돌아가는 서비스에 요청을 보내 보며 취약점을 찾는 검사.

QA에게 진짜 동작을 보기 때문에 오탐이 적다. 대신 돌아가는 환경이 필요하다.

같이 보기 SAST, ZAP

DO-178C항공 소프트웨어 인증 지침Software Considerations in Airborne Systems and Equipment Certification

비행기에 들어가는 소프트웨어를 어떻게 만들고 증명해야 하는지 정한 문서.

QA에게 이 분야에서 가장 엄격한 증거를 요구한다. 조건 커버리지 기준이 여기서 나온다.

같이 보기 MC/DC, ED-12C

ED-12C항공 소프트웨어 인증 지침(유럽판)European equivalent of DO-178C

항공 소프트웨어 인증 지침의 유럽 쪽 같은 문서. 내용은 사실상 같다.

QA에게 유럽 인증 문서에서는 이 번호로 인용된다.

같이 보기 DO-178C

HARA위험원 분석 및 위험 평가Hazard Analysis and Risk Assessment

무엇이 어떻게 위험해질 수 있는지 먼저 찾아내고, 그 위험의 크기를 매기는 작업.

QA에게 이 결과가 등급을 정하고, 등급이 시험 범위를 정한다. 시험 계획의 출발점이다.

같이 보기 ASIL, SIL

MASTG모바일 앱 보안 시험 지침Mobile Application Security Testing Guide

위 기준을 실제로 어떻게 확인하는지 적어 둔 방법서.

QA에게 기준은 무엇을, 지침은 어떻게에 해당한다. 둘을 짝지어 쓴다.

같이 보기 MASVS, OWASP

MASVS모바일 앱 보안 검증 표준Mobile Application Security Verification Standard

휴대전화 앱이 갖춰야 할 보안 요구사항을 정리한 기준.

QA에게 "무엇을 확인해야 하는가"의 목록이 된다.

같이 보기 MASTG, OWASP

MISRA미스라Motor Industry Software Reliability Association

안전이 중요한 분야에서 "이런 식으로는 코드를 쓰지 말라"를 모아 둔 규칙집.

QA에게 규칙 위반 개수가 그대로 품질 증거가 된다. 도구로 기계적으로 검사한다.

같이 보기 SAST, ASIL

NVDA엔브이디에이NonVisual Desktop Access

화면의 글자를 소리로 읽어 주는 무료 프로그램. 시각장애인이 쓴다.

QA에게 접근성 점검을 실제로 해 보려면 이런 도구로 직접 들어 봐야 한다.

같이 보기 WCAG

ODD운행 설계 영역Operational Design Domain

이 기능이 제대로 동작한다고 보장하는 조건의 범위 — 날씨, 도로 종류, 속도 같은 것.

QA에게 범위를 적어 두지 않으면 "어디까지 시험했는가"를 말할 수 없다.

같이 보기 SOTIF

OWASP오왁스프Open Worldwide Application Security Project

웹과 앱 보안 자료를 공개로 만드는 비영리 단체. 취약점 목록과 점검 기준이 유명하다.

QA에게 보안 점검 항목의 출발점으로 가장 널리 쓰인다.

같이 보기 MASVS, ZAP, XSS

SAST정적 보안 분석Static Application Security Testing

프로그램을 돌리지 않고 코드 자체를 읽어 위험한 부분을 찾는 검사.

QA에게 빌드할 때마다 자동으로 돌릴 수 있다. 다만 실제 문제가 아닌 것도 많이 걸린다.

같이 보기 DAST, SCA

SBOM소프트웨어 구성 명세서Software Bill Of Materials

제품에 어떤 부품 코드가 어느 버전으로 들어갔는지 적은 부품 목록.

QA에게 새 취약점이 터졌을 때 "우리 제품에 그게 들어 있나"를 목록으로 바로 답할 수 있다.

같이 보기 SOUP, SCA

SCA구성 요소 분석Software Composition Analysis

가져다 쓴 부품 코드에 알려진 취약점이 있는지 목록과 맞춰 보는 검사.

QA에게 우리 코드가 아니라 남의 코드에서 터지는 문제를 잡는다.

같이 보기 SBOM, SAST

SIL안전 완전성 수준 · 소프트웨어 포함 시험Safety Integrity Level / Software-in-the-Loop

이 커리큘럼에서 두 가지로 쓰인다. ① 고장이 났을 때 사람이 다칠 위험이 큰 정도에 따라 매기는 안전 등급(숫자가 클수록 엄격하다) ② 설계 모델이 아니라 실제로 만들어진 코드를 개발용 컴퓨터에서 돌려 보는 시험 단계. 앞뒤 문장에 등급 숫자가 있으면 ①, 모델·실물 시험과 나란히 나오면 ②다.

QA에게 ① 은 시험의 깊이와 증거량을 정하고, ② 는 결함을 가장 싸게 잡을 수 있는 단계를 정한다. 같은 글자라서 섞어 읽으면 둘 다 틀린다.

같이 보기 ASIL, MIL, PIL, HIL

SOTIF의도된 기능의 안전Safety Of The Intended Functionality

부품이 고장나지 않았는데도 위험해지는 경우를 다루는 분야. 센서가 상황을 잘못 알아보는 식이다.

QA에게 자율주행에서 "고장은 없었는데 사고가 났다"를 설명하는 틀이다.

같이 보기 ODD

SOUP출처가 불분명한 소프트웨어Software Of Unknown Provenance

우리가 만들지 않아서 어떻게 만들어졌는지 모르는 채 가져다 쓰는 부품 코드.

QA에게 의료기기에서는 이 부품마다 위험을 따로 평가해 문서로 남겨야 한다.

같이 보기 SBOM, FDA

WCAG웹 콘텐츠 접근성 지침Web Content Accessibility Guidelines

장애가 있어도 웹을 쓸 수 있게 만드는 방법을 정리한 국제 지침.

QA에게 공공 서비스는 법으로 요구된다. 지침 항목이 그대로 점검 목록이 된다.

같이 보기 NVDA

WCET최악 실행 시간Worst-Case Execution Time

어떤 처리가 가장 오래 걸릴 때 얼마나 걸리는지의 상한값.

QA에게 제한 시간 안에 반드시 끝나야 하는 기기에서는 평균이 아니라 이 값이 기준이다.

같이 보기 RTOS

XSS크로스 사이트 스크립팅Cross-Site Scripting

입력창에 넣은 글자가 화면에서 명령으로 실행되게 만드는 공격.

QA에게 입력값을 그대로 화면에 보여 주는 곳이 모두 점검 대상이다.

같이 보기 OWASP, CSRF

ZAP제드 어택 프록시Zed Attack Proxy

웹 취약점을 자동으로 훑어 주는 공개 도구.

QA에게 동적 보안 검사를 처음 돌려 볼 때 가장 흔히 쓰는 도구다.

같이 보기 DAST, OWASP

산업 분야

자동차·공장·의료·금융처럼 분야마다 쓰는 말.

AUTOSAR오토사AUTomotive Open System ARchitecture

자동차 소프트웨어를 층으로 나눠 만들자고 업계가 함께 정한 구조.

QA에게 층이 나뉘어 있으므로 "어느 층에서 난 결함인가"를 가릴 수 있다.

같이 보기 ECU

CAN캔 통신Controller Area Network

자동차 안의 작은 컴퓨터들이 서로 신호를 주고받는 통신 방식.

QA에게 신호를 가로채 보거나 일부러 잘못된 신호를 넣어 보는 것이 자동차 시험의 기본 동작이다.

같이 보기 ECU

DICOM의료 영상 표준Digital Imaging and Communications in Medicine

엑스레이·시티 같은 의료 영상을 저장하고 주고받는 국제 표준.

QA에게 영상이 환자 정보와 올바르게 묶여 전달되는지가 핵심 점검 항목이다.

같이 보기 HL7, FHIR

ECU전자 제어 장치Electronic Control Unit

자동차 안에서 특정 기능을 담당하는 작은 컴퓨터. 요즘 차에는 수십 개가 들어 있다.

QA에게 자동차 시험은 화면이 아니라 이 장치의 입출력을 보는 일이 많다.

같이 보기 CAN, MCU

ERP전사 자원 관리Enterprise Resource Planning

회사의 돈·재고·인사를 한 시스템에서 관리하는 업무 소프트웨어.

QA에게 숫자가 틀리면 바로 회계 문제가 된다. 정합성 확인이 시험의 중심이다.

같이 보기 MES, SAP

FHIR파이어Fast Healthcare Interoperability Resources

의료 정보를 웹 창구 방식으로 주고받게 만든 새 표준.

QA에게 표준을 지켰다고 해도 기관별 추가 규칙이 붙는다. 그 규칙까지 맞는지 확인해야 한다.

같이 보기 HL7, API

HIL하드웨어 포함 시험Hardware-In-the-Loop

실제 부품을 연결해 두고, 주변 환경만 컴퓨터로 흉내 내서 시험하는 방식.

QA에게 진짜 차나 진짜 공장을 쓰지 않고도 위험한 상황을 시험할 수 있다.

같이 보기 MIL, PIL

HL7에이치엘세븐Health Level Seven

병원 시스템끼리 환자 정보를 주고받는 오래된 국제 표준.

QA에게 형식이 자유로워 병원마다 다르게 쓴다. 그 차이에서 결함이 난다.

같이 보기 DICOM, FHIR

HMI사람-기계 인터페이스Human-Machine Interface

설비를 사람이 조작하는 화면이나 조작판.

QA에게 잘못 누르기 쉬운 배치 자체가 안전 결함이 된다.

같이 보기 SCADA, UI

ISA-95기업-제어 시스템 통합 표준Enterprise-Control System Integration standard

공장 설비부터 경영 시스템까지를 층으로 나눠 정리한 국제 표준.

QA에게 "이 데이터가 어느 층 사이에서 틀어졌나"를 말할 공통 언어가 된다.

같이 보기 MES, SCADA

IVI차량 인포테인먼트In-Vehicle Infotainment

자동차 안의 화면 — 길 안내, 음악, 전화 연결을 담당하는 부분.

QA에게 일반 앱 시험과 가장 비슷한 자동차 영역이다. 운전 중 조작 제한 같은 고유 요구가 붙는다.

MCU마이크로컨트롤러Microcontroller Unit

아주 작은 컴퓨터 한 칩. 가전·자동차·산업 기기 안에 들어간다.

QA에게 메모리와 속도가 빠듯해서, 일반 소프트웨어에서는 안 나는 종류의 결함이 난다.

같이 보기 ECU, RTOS

MES제조 실행 시스템Manufacturing Execution System

공장에서 무엇을 얼마나 어떤 순서로 만들지 관리하는 시스템.

QA에게 설비와 경영 시스템 사이에 끼어 있어, 양쪽 연결이 어긋나는 결함이 많다.

같이 보기 ERP, SCADA, ISA-95

MIL모델 시험Model-In-the-Loop

부품을 만들기 전에 설계 모델만으로 동작을 시험하는 단계.

QA에게 가장 싸게 고칠 수 있는 단계다. 여기서 놓치면 뒤로 갈수록 비싸진다.

같이 보기 HIL, PIL

OTA무선 갱신Over-The-Air

기기를 분해하지 않고 통신으로 소프트웨어를 갱신하는 방식.

QA에게 갱신 중 전원이 끊기거나 통신이 끊기는 경우를 반드시 시험해야 한다.

같이 보기 UNECE

PCI DSS지불 카드 산업 데이터 보안 표준Payment Card Industry Data Security Standard

카드 정보를 다루는 시스템이 지켜야 할 보안 요구사항을 카드 업계가 함께 정한 것.

QA에게 카드 번호가 지나가는 화면·저장소·로그가 모두 점검 대상이 된다.

같이 보기 PG

PG결제 대행Payment Gateway

쇼핑몰과 카드사 사이에서 결제를 중개해 주는 서비스.

QA에게 결제 실패·중복 결제·취소 처리가 시험에서 가장 민감한 지점이다.

같이 보기 PCI DSS

PIL프로세서 포함 시험Processor-In-the-Loop

실제 칩에 코드를 올려 돌려 보는 단계. 모델 시험과 실물 시험 사이에 있다.

QA에게 모델에서는 맞던 계산이 실제 칩의 숫자 정밀도에서 틀어지는 것을 잡는다.

같이 보기 MIL, HIL

PLC프로그램 가능 제어기Programmable Logic Controller

공장 설비를 직접 움직이는 산업용 제어 장치.

QA에게 실물 설비를 움직이므로 QA가 직접 조작하지 않는다. 흉내 내는 장비로 시험한다.

같이 보기 SCADA, HMI

RTOS실시간 운영체제Real-Time Operating System

"정해진 시간 안에 반드시 처리"를 보장하도록 만든 바탕 프로그램.

QA에게 평균이 빨라도 한 번 늦으면 실패다. 시험 기준이 평균이 아니라 상한값이다.

같이 보기 WCET, MCU

SAE미국 자동차공학회Society of Automotive Engineers

자동차 기술 규격을 만드는 미국 단체.

QA에게 자동차 보안 규격이 국제표준화기구와 이 단체 공동 번호로 나온다.

같이 보기 ISO

SAP에스에이피SAP (ERP product family)

기업용 자원 관리 소프트웨어 중 가장 널리 쓰이는 제품군.

QA에게 대기업 프로젝트에서 이 제품 이름이 곧 시험 대상 시스템 이름이 된다.

같이 보기 ERP

SCADA감시 제어 및 데이터 수집Supervisory Control And Data Acquisition

공장 설비 상태를 한 화면에 모아 보며 조작하는 감시 시스템.

QA에게 경보가 제때 울리는지, 값이 실제 설비와 맞는지가 핵심 점검 항목이다.

같이 보기 PLC, HMI, MES

SI시스템 통합 사업System Integration

고객이 발주한 시스템을 받아서 만들어 주는 사업 형태. 국내 정보기술 업계의 큰 축이다.

QA에게 검수 기준과 일정이 계약서로 정해진다. QA의 산출물이 곧 계약 이행 증거가 된다.

같이 보기 RFP, UAT

UART직렬 통신 장치Universal Asynchronous Receiver-Transmitter

기기와 컴퓨터를 선으로 잇고 글자를 한 줄씩 주고받는 가장 단순한 통신 방식.

QA에게 화면이 없는 기기의 속내용을 들여다보는 통로다. 임베디드 시험에서 로그를 여기로 받는다.

V2X차량 사물 통신Vehicle-to-Everything

차가 다른 차·신호등·보행자 기기와 직접 신호를 주고받는 기술.

QA에게 상대가 거짓 신호를 보내는 경우까지 시험해야 한다.

같이 보기 CAN

조직·직함·업무

누가 무엇을 결정하는지에 관한 말들.

ASQ미국품질협회American Society for Quality

품질 분야의 미국 단체. 품질 자격증을 운영한다.

같이 보기 ISTQB

BA업무 분석가Business Analyst

고객의 업무를 파악해 요구사항으로 정리하는 사람.

QA에게 요구사항이 모호할 때 QA가 가장 먼저 찾아갈 상대다.

CEO최고경영자Chief Executive Officer

회사의 최종 의사결정자.

QA에게 품질 문제를 보고할 때는 기술 용어가 아니라 매출·위험·일정으로 바꿔 말해야 한다.

CIO최고정보책임자Chief Information Officer

회사 내부 정보시스템을 책임지는 임원.

CISO최고정보보호책임자Chief Information Security Officer

보안을 책임지는 임원. 법으로 지정이 요구되는 경우가 있다.

QA에게 보안 취약점 보고 경로의 끝에 있는 사람이다.

CMO최고마케팅책임자Chief Marketing Officer

마케팅을 책임지는 임원.

QA에게 출시일을 당기자는 압력이 이 쪽에서 오는 경우가 많다.

CRO최고매출책임자Chief Revenue Officer

매출을 책임지는 임원.

CS고객 지원 · 칩 선택 신호Customer Service / Chip Select

이 커리큘럼에서 두 가지로 쓰인다. ① 고객 문의와 불만을 직접 받는 조직 ② 여러 부품이 한 선을 나눠 쓸 때 "지금은 네 차례" 라고 하나를 고르는 신호. 앞뒤에 문의·고객이 있으면 ①, 통신·배선 이야기면 ②다.

QA에게 ① 은 실제 결함 제보가 가장 먼저 도착하는 곳이라 QA 에게 값진 정보원이다.

CTO최고기술책임자Chief Technology Officer

기술 전체를 책임지는 임원.

QA에게 자동화 투자와 기술 부채 결정을 승인하는 상대다.

Go/No-Go내보낼지 말지 판정Go / No-Go decision

미리 정해 둔 조건을 놓고 "이대로 내보낸다 / 내보내지 않는다" 를 한자리에서 정하는 일.

QA에게 감으로 정하면 나중에 책임 공방이 된다. 조건을 먼저 적어 두는 것이 핵심이다.

HR인사Human Resources

채용과 인사를 담당하는 조직.

QA에게 채용 공고의 요구 역량이 실제 업무와 어긋날 때 조정하는 상대다.

PM프로젝트 또는 제품 관리자Project Manager / Product Manager

일정과 범위를 정하고 결정을 내리는 사람. 회사에 따라 프로젝트 관리자와 제품 관리자 둘 중 하나를 뜻한다.

QA에게 결함의 우선순위를 최종적으로 정하는 상대다. 어느 쪽 뜻인지 먼저 확인하는 게 좋다.

같이 보기 PO

PMI프로젝트관리협회Project Management Institute

프로젝트 관리 지식 체계와 자격을 만드는 국제 단체.

PO제품 책임자Product Owner

무엇을 먼저 만들지 정하는 사람. 애자일 방식에서 쓰는 역할 이름이다.

QA에게 인수 기준을 승인하는 사람이다. 기준이 모호하면 여기서 확정받아야 한다.

같이 보기 PM

QMO품질관리 조직Quality Management Office

여러 팀의 품질 활동을 한곳에서 보며 기준을 정하는 조직.

QA에게 프로젝트 하나가 아니라 조직 전체를 보는 자리로 올라가는 경로다.

RFP제안 요청서Request For Proposal

발주처가 "이런 걸 만들어 줄 수 있나" 하고 조건을 적어 내는 문서.

QA에게 이 문서의 요구사항이 나중에 검수 기준이 된다. QA가 초기에 읽어야 하는 문서다.

같이 보기 SI, UAT

ROI투자 수익률Return On Investment

들인 돈과 시간에 비해 얼마를 돌려받았는지.

QA에게 자동화를 하자고 설득할 때 필요한 숫자다. 감으로는 승인되지 않는다.

SDET테스트 개발 엔지니어Software Development Engineer in Test

시험을 코드로 만드는 사람. 개발과 QA 양쪽 일을 한다.

QA에게 자동화를 맡는 직무 이름으로 공고에 자주 나온다.

운영·지표

품질을 숫자로 말할 때 쓰는 단위.

AUC곡선 아래 면적Area Under the Curve

분류를 얼마나 잘하는지 하나의 숫자로 요약한 값. 1에 가까울수록 좋다.

QA에게 기계학습 기능의 합격 기준으로 쓰인다. 정확도만 보면 속는 경우를 막는다.

같이 보기 ML

DORA도라 지표DevOps Research and Assessment

개발·배포를 얼마나 잘하는지 네 가지 숫자로 재는 방식.

QA에게 품질 활동의 효과를 조직 공통 숫자로 말할 수 있다.

같이 보기 MTTR, CI/CD

GSM목표·신호·지표Goals-Signals-Metrics

무엇을 이루려는지(목표)를 먼저 적고, 그것이 이뤄지면 어떤 흔적이 남는지(신호), 그 흔적을 무슨 숫자로 셀지(지표)를 차례로 끌어내는 방법.

QA에게 "좋아졌다"를 숫자로 말하려면 이 순서로 내려와야 한다. 지표부터 고르면 목표와 어긋난다.

같이 보기 HEART, SLI

HEART하트 지표Happiness, Engagement, Adoption, Retention, Task success

사용자 경험을 다섯 갈래 숫자로 재는 틀.

QA에게 "쓰기 편하다"를 측정 가능한 숫자로 바꿔 준다.

같이 보기 UX

KPI핵심 성과 지표Key Performance Indicator

"잘되고 있는가" 를 대표로 보여 주는 몇 개의 숫자.

QA에게 품질 활동이 조직의 숫자에 어떻게 닿는지 말할 수 있어야 예산이 붙는다.

같이 보기 SLO, ROI

KST한국 표준시Korea Standard Time

한국의 기준 시각. 세계 기준시보다 9시간 빠르다.

QA에게 날짜가 바뀌는 경계를 다루는 기능에서 시간대 결함이 자주 난다.

같이 보기 UTC

LCP최대 콘텐츠 표시 시간Largest Contentful Paint

화면에서 가장 큰 내용이 보이기까지 걸린 시간. 체감 속도를 재는 대표 지표다.

QA에게 검색 순위에도 영향을 준다. 웹 성능 시험의 기본 항목이다.

MTTR평균 복구 시간Mean Time To Restore

고장이 난 뒤 정상으로 돌아오기까지 걸린 시간의 평균.

QA에게 "안 고장나게"보다 "빨리 복구되게"가 현실적인 목표인 경우가 많다.

같이 보기 DORA

p9595 백분위95th percentile

느린 쪽 5%를 뺀 나머지가 이 안에 들어온다는 뜻. 100번 중 95번이 그 시간 안에 끝났다는 말이다.

QA에게 평균은 아주 느린 몇 건에 가려진다. 사용자가 느끼는 쪽에는 이 숫자가 가깝다.

같이 보기 p99, SLO

p9999 백분위99th percentile

100번 중 99번이 이 시간 안에 끝났다는 뜻. 가장 느린 1%만 뺀 값이다.

QA에게 드물게 아주 느린 경우가 실제 불만으로 이어진다. 그것을 보는 숫자다.

같이 보기 p95

ROC판정 기준을 바꿔 가며 그린 성능 곡선Receiver Operating Characteristic

"얼마나 깐깐하게 판정할지" 를 바꿔 가며, 맞게 잡은 비율과 잘못 잡은 비율을 그림으로 그린 것.

QA에게 기준점 하나만 보고 성능을 말하면 속는다. 곡선 전체를 봐야 한다.

같이 보기 AUC, ML

RTT왕복 시간Round-Trip Time

요청을 보내고 답이 돌아오기까지 걸린 시간.

QA에게 느린 원인이 처리냐 네트워크냐를 가르는 숫자다.

SLA서비스 수준 협약Service Level Agreement

"이 정도 품질은 보장한다"를 고객과 글로 약속한 것. 못 지키면 보상 조항이 따른다.

QA에게 약속한 수치가 곧 시험 합격 기준이 된다.

같이 보기 SLO, SLI

SLI서비스 수준 지표Service Level Indicator

실제로 재는 숫자 — 응답 시간, 성공률 같은 것.

QA에게 무엇을 재는지 정하지 않으면 목표도 약속도 말뿐이 된다.

같이 보기 SLO, SLA

SLO서비스 수준 목표Service Level Objective

내부적으로 지키려는 목표치. 고객과의 약속보다 조금 더 엄격하게 잡는다.

QA에게 목표를 넘기 전에 알아차리려고 둔다. 경보 기준이 여기서 나온다.

같이 보기 SLA, SLI

TPS초당 처리 건수Transactions Per Second

1초에 몇 건을 처리하는지.

QA에게 성능 시험의 목표값으로 가장 많이 쓰인다.

UTC협정 세계시Coordinated Universal Time

세계 공통 기준 시각. 한국 시간보다 9시간 느리다.

QA에게 기록에 남는 시각이 이 기준인 경우가 많다. 9시간 차이를 잊으면 재현 시각이 어긋난다.

같이 보기 KST

도구·자동화

실제로 쓰는 도구와 그 방식.

ALM애플리케이션 생애주기 관리Application Lifecycle Management

요구사항부터 시험·배포까지를 한 도구에서 추적하는 방식.

QA에게 요구사항과 시험을 연결하는 추적표가 이 도구 안에서 만들어진다.

APM애플리케이션 성능 모니터링Application Performance Monitoring

서비스가 실제로 돌아가는 동안 어디가 느린지 들여다보는 도구.

QA에게 성능 시험 결과를 "느리다"가 아니라 "어느 구간에서 몇 초"로 말할 수 있게 해 준다.

AWS아마존 웹 서비스Amazon Web Services

서버와 저장소를 빌려 쓰는 클라우드 서비스 중 가장 큰 것.

QA에게 시험 환경을 빌려 쓰는 대상이자, 비용이 시험 설계에 영향을 준다.

BPMN업무 프로세스 표기법Business Process Model and Notation

업무 흐름을 도형으로 그리는 표준 표기법.

QA에게 그림의 분기마다 시험 경로가 하나씩 나온다.

같이 보기 OMG, MBT

CI지속적 통합Continuous Integration

코드를 올릴 때마다 자동으로 합쳐서 빌드하고 시험까지 돌리는 방식.

QA에게 자동화 시험이 여기서 돌아야 의미가 있다. 사람이 기억해서 돌리는 시험은 곧 안 돌게 된다.

같이 보기 CI/CD

CI/CD통합·배포 자동화Continuous Integration / Continuous Delivery

합치고 시험하고 배포하는 과정을 자동으로 이어 둔 흐름 전체.

QA에게 품질 관문을 어디에 둘지가 QA의 설계 문제가 된다.

같이 보기 CI

CMDB구성 관리 데이터베이스Configuration Management Database

회사가 가진 시스템과 장비, 그 연결 관계를 적어 둔 목록.

QA에게 장애가 났을 때 영향 범위를 여기서 찾는다. 목록이 낡으면 범위 판단이 틀린다.

같이 보기 ITSM

CRC순환 중복 검사Cyclic Redundancy Check

데이터가 전송 중에 깨지지 않았는지 짧은 검사값으로 확인하는 방법.

QA에게 깨진 데이터를 일부러 넣어 보고 걸러지는지 확인하는 것이 시험 항목이다.

CSP클라우드 사업자Cloud Service Provider

서버와 저장소를 빌려 주는 회사. 빌린 쪽과 빌려준 쪽의 책임 경계가 정해져 있다.

QA에게 "어디까지가 우리 책임인가" 가 시험 범위를 정한다.

같이 보기 AWS

HAR통신 기록 파일HTTP Archive

브라우저가 주고받은 요청과 응답을 전부 담아 저장한 파일.

QA에게 "내 환경에서만 된다"를 증명할 때 이 파일을 첨부한다. 재현 설명이 훨씬 짧아진다.

같이 보기 HTTP

IDE통합 개발 환경Integrated Development Environment

코드를 쓰고 돌려 보고 오류를 찾는 일을 한 창에서 하게 해 주는 프로그램.

ITIL아이틸IT Infrastructure Library

정보기술 서비스 운영의 모범 사례를 정리해 둔 지침 체계.

QA에게 운영 조직의 용어와 절차가 이 체계에서 나온다.

같이 보기 ITSM

ITSM정보기술 서비스 관리IT Service Management

정보기술 서비스를 접수·처리·개선하는 운영 방식 전체.

QA에게 운영 중 발견되는 결함이 이 절차를 타고 들어온다.

같이 보기 ITIL, CMDB

JDK자바 개발 도구 모음Java Development Kit

자바로 프로그램을 만들고 돌리는 데 필요한 도구 꾸러미.

QA에게 버전이 다르면 같은 코드가 다르게 동작한다. 시험 환경에 적어야 할 항목이다.

같이 보기 JVM, JUnit

JMeter제이미터Apache JMeter

많은 사람이 한꺼번에 쓰는 상황을 흉내 내 서비스가 버티는지 보는 무료 도구.

QA에게 성능 시험에서 가장 흔히 쓰인다. 결과를 평균이 아니라 백분위로 읽어야 한다.

같이 보기 TPS, p95

JQL지라 질의 언어Jira Query Language

결함 관리 도구에서 "이런 조건인 건만 보여 달라"고 적는 말.

QA에게 결함 현황을 직접 뽑아 볼 수 있다. 보고서 숫자를 손으로 세지 않게 된다.

JUnit제이유닛JUnit

자바로 만든 프로그램의 단위 시험을 쓰고 돌리는 가장 널리 쓰이는 도구.

QA에게 개발자가 짠 시험 코드가 대개 이 형식이다. 읽을 줄 알면 무엇이 이미 확인됐는지 알 수 있다.

같이 보기 AAA, JVM

LDRA엘디알에이LDRA tool suite

안전이 중요한 분야에서 쓰는 코드 검사·커버리지 측정 도구 제품군.

QA에게 인증 증거로 인정받는 측정 결과를 내 준다.

같이 보기 MISRA, SAST

MySQL마이에스큐엘MySQL

가장 널리 쓰이는 무료 데이터 저장소 제품 중 하나.

같이 보기 DB, SQL

OMG오엠지Object Management Group

모델링 표기법 표준을 만드는 국제 단체.

같이 보기 BPMN

PICT픽트Pairwise Independent Combinatorial Testing tool

조건이 여러 개일 때 시험할 조합을 알아서 줄여 뽑아 주는 무료 도구.

QA에게 조합이 수천 가지일 때 손으로 고르면 빠진다. 도구가 근거 있게 줄여 준다.

PostgreSQL포스트그레에스큐엘PostgreSQL

널리 쓰이는 무료 데이터 저장소 제품 중 하나.

같이 보기 DB, SQL, MySQL

PR풀 리퀘스트Pull Request

"내가 고친 코드를 본체에 합쳐 달라"고 올리는 요청. 합치기 전에 사람들이 보고 의견을 단다.

QA에게 QA가 코드 변경을 가장 빨리 알 수 있는 창구다. 무엇이 바뀌었는지 여기서 읽는다.

같이 보기 CI

RPA업무 자동화 로봇Robotic Process Automation

사람이 화면에서 반복하던 조작을 그대로 대신해 주는 도구.

QA에게 화면이 조금 바뀌면 멈춘다. 자동화 중 가장 깨지기 쉬운 종류다.

SRE사이트 신뢰성 엔지니어링Site Reliability Engineering

서비스가 안 죽게 만드는 일을 개발처럼 코드로 하는 직무와 방식.

QA에게 운영 품질 지표를 함께 설계하는 상대다.

같이 보기 SLO, MTTR

XPath엑스패스XML Path Language

문서의 나무 구조에서 "몇 번째 줄의 어느 칸" 처럼 위치를 적어 원하는 조각을 집어내는 표기법.

QA에게 화면에서 버튼을 자동으로 찾을 때 쓴다. 구조가 조금만 바뀌어도 깨지는 것이 약점이다.

같이 보기 DOM, HTML, XML

AI

인공지능 기능을 시험할 때 필요한 말들.

AI인공지능Artificial Intelligence

사람이 규칙을 일일이 적지 않아도 데이터에서 규칙을 찾아 판단하는 소프트웨어.

QA에게 같은 입력에 같은 답이 안 나올 수 있다. "정답 하나를 비교"하는 기존 시험 방식이 그대로 안 통한다.

같이 보기 ML, LLM

LLM대규모 언어 모델Large Language Model

엄청난 양의 글을 학습해 말을 이어 쓰는 모델. 대화형 인공지능의 바탕이다.

QA에게 그럴듯한 거짓을 자연스럽게 쓴다. 사실 여부를 사람이나 다른 장치로 따로 확인해야 한다.

같이 보기 AI, RAG

MCP모델 컨텍스트 프로토콜Model Context Protocol

인공지능이 외부 도구와 자료를 쓰도록 연결하는 약속.

QA에게 모델이 실제 시스템을 건드릴 수 있게 되므로, 권한 범위가 시험 대상이 된다.

같이 보기 LLM, API

ML기계학습Machine Learning

데이터를 많이 보여 주고 규칙을 스스로 찾게 하는 방식. 인공지능을 만드는 주된 방법이다.

QA에게 학습 데이터가 치우쳐 있으면 결과도 치우친다. 데이터 자체가 시험 대상이 된다.

같이 보기 AI, AUC

RAG검색 결합 생성Retrieval-Augmented Generation

모델이 답하기 전에 믿을 수 있는 문서를 먼저 찾아와 그것을 근거로 답하게 하는 방식.

QA에게 근거 문서를 못 찾았을 때 모델이 지어내는지가 핵심 시험 항목이다.

같이 보기 LLM