QA (Quality Assurance) QC (Quality Control) 관련 용어 VI

QA (Quality Assurance) QC (Quality Control) 관련 용어 VI

📌 애드훅 (Ad-hoc) 뜻 for Quality Assurance

**애드훅(Ad-hoc)**은 즉흥적 또는 특정 목적에 맞춰 임시로 수행되는 작업을 의미합니다.

🔑 QA(품질 보증)에서의 의미

  • 사전에 계획되지 않은 비정형 테스트 방식
  • 특정 기능이나 버그가 발생했을 때 빠르게 점검하는 테스트 방식
  • 정해진 테스트 케이스 없이 즉각적인 문제 해결에 초점

📌 사용 예시

분야 설명
QA 테스트 앱에서 갑자기 발견된 버그를 빠르게 재현하고 수정 여부 점검
네트워크 특정 장애가 발생했을 때 즉흥적으로 네트워크 구성
소프트웨어 긴급 기능 추가나 수정 작업 수행

💡 한 줄 요약

**애드훅(Ad-hoc)**은 계획에 없던 문제를 즉각적이고 임시적으로 해결하는 방식입니다! 🔍

 

✅ Regression (회귀 테스트)

Regression은 QA(품질 보증) 테스트에서 사용되는 용어로, 기존 기능이 새로운 코드 변경(수정, 업데이트, 버그 수정 등)으로 인해 정상적으로 작동하는지 확인하는 테스트를 의미합니다.

🔑 주요 특징

  • 새로운 기능 추가나 수정 후 기존 기능에 영향이 없는지 검증
  • 주로 자동화 테스트로 많이 수행
  • 수정된 부분 외에도 전반적인 기능까지 테스트 범위에 포함
  • 오류가 발생하지 않는지 다시 점검하는 테스트 방식

📌 예시

  1. 로그인 기능 수정 후, 회원가입 및 로그아웃 기능이 정상 작동하는지 확인
  2. 쇼핑몰에서 결제 페이지 개선 후 장바구니나 주문 내역 페이지가 정상 작동하는지 테스트

🚨 목적

👉 코드 수정이 예상치 못한 부작용(side effect)을 발생시키지 않도록 예방하기 위해 진행합니다.

 

📌 언제 사용해야 할까?

✔ 애드훅 테스트

  • 정해진 테스트 없이 빠르게 버그를 탐색해야 할 때
  • 긴급한 장애나 예상치 못한 동작이 발생했을 때
  • 기존 테스트 시나리오에 없는 오류를 발견하고 싶을 때

✔ 리그레이션 테스트

  • 신규 기능이 추가되었을 때
  • 버그 수정 후 기존 기능이 정상 동작하는지 검증할 때
  • 주기적인 소프트웨어 업데이트 후 안정성을 확인할 때

 

📌 요약

  • 애드훅(Ad-hoc) 테스트 = 자유롭게 탐색하며 버그를 찾는 즉흥적인 테스트
  • 리그레이션(Regression) 테스트 = 변경된 코드가 기존 기능을 망치지 않았는지 확인하는 반복 테스트

✅ 결론: 애드훅 테스트는 빠르고 유연하지만 비체계적이고, 리그레이션 테스트는 안정성을 보장하지만 시간이 오래 걸릴 수 있음. 상황에 따라 적절히 활용하는 것이 중요! 🚀

✅ Slot-Filling 뜻 (슬롯 필링)

Slot-Filling은 **자연어 처리(NLP)**에서 사용되는 기술로, 사용자의 질문이나 명령에서 **필요한 정보(슬롯)**를 자동으로 추출하는 과정입니다.

🔑 Slot-Filling 작동 방식

  1. 의도(Intent) 파악
    사용자의 목적이 무엇인지 파악
    예시: “항공권 예약하고 싶어요” → [예약 의도]

  2. 슬롯(Slot) 식별
    필요한 정보 항목을 지정
    예시:

    • 출발지: 서울

    • 목적지: 뉴욕

    • 날짜: 3월 10일

  3. 슬롯 필링 수행
    사용자의 말에서 슬롯에 해당하는 데이터를 채움

📌 예시

사용자 질문: “3월 10일에 서울에서 뉴욕으로 항공권 예약해줘”

슬롯 값
출발지 서울
목적지 뉴욕
날짜 3월 10일

🚀 Slot-Filling 사용하는 곳

  • 챗봇

  • 음성 비서 (Alexa, Siri)

  • 예약 시스템

  • 고객 지원 자동화

🔑 핵심 포인트

  • 사용자 의도(Intent)를 먼저 파악

  • 슬롯에 필요한 정보만 채워넣음

  • 누락된 정보는 추가 질문으로 보완

💡 정리

Slot-Filling은 대화형 AI에서 자동으로 정보를 추출해주는 기술로, 사용자의 요구사항을 정확하게 이해하고 처리하는 데 필수적입니다!

✅ 핸드오버(Handover)란?

현재 담당자가 작업하던 내용을 다음 담당자에게 명확히 전달하여 업무 연속성을 유지하도록 하는 인수인계 과정입니다.

🧩 핸드오버의 주요 요소

  1. 업무 범위 정리 – 어떤 작업을 했고, 어떤 일이 남아 있는지

  2. 진행 상태 – 완료된 부분 vs 진행 중 vs 미진행 항목

  3. 참고 자료 – 관련 문서, 계정 정보, 툴 접근 권한 등

  4. 이슈 사항 및 리스크 – 예상되는 문제점, 주의사항 등

💡 예시 상황

  • QA 테스트 중, 테스트를 다른 팀원에게 넘길 때

  • 디자이너가 프로젝트를 마치고 다른 디자이너에게 넘길 때

  • PM(프로덕트 매니저)이 이직하며 후임자에게 자료를 전달할 때

🗂 관련 용어

  • Work Handover Document – 인계할 때 만드는 문서

  • Handover Checklist – 인계 항목들을 빠짐없이 체크하기 위한 리스트

 

**핫픽스(Hotfix)**는 시급하게 수정이 필요한 문제를 빠르게 해결하는 패치를 뜻합니다. 일반적인 정기 업데이트와 달리 예외적으로 빠르게 반영되며, 주로 서비스에 영향을 주는 심각한 버그나 보안 이슈 해결을 위해 사용돼요.

✅ 핫픽스(Hotfix)란?

라이브(운영 중인) 서비스에서 치명적인 문제나 긴급한 버그를 해결하기 위해
빠르게 배포하는 긴급 수정 업데이트입니다.

🧯 언제 핫픽스를 하게 될까?

  • 서비스가 죽는 버그가 있을 때 (ex. 앱이 실행되지 않음)

  • 사용자 데이터 손실 가능성이 있을 때

  • 보안상 심각한 취약점이 발견되었을 때

  • 결제, 로그인, 작성 등 핵심 기능에 문제가 생겼을 때

🔁 핫픽스 vs 일반 배포 차이점

항목 핫픽스 (Hotfix) 일반 배포 (Release)
목적 긴급 문제 해결 기능 추가/버그 수정
속도 매우 빠름 일정에 따라 진행
범위 최소한의 변경 다양한 변경 포함
테스트 제한적으로 진행 가능 정식 QA 과정을 거침

💡 예시

“배포 이후 에디터 기능이 깨져서 글을 저장 못 한다고 해요.
긴급히 핫픽스로 수정해서 바로 운영 서버에 반영해야겠어요.”

✅ RC 버전이란?

**Release Candidate(릴리스 후보)**의 줄임말로,
정식 버전으로 출시하기 전에 내놓는 마지막 테스트용 버전이에요.

🧪 RC는 어떤 위치에 있을까?

소프트웨어 릴리스 흐름에서 보면 다음과 같아요:

scss
개발 → 알파(Alpha) → 베타(Beta) → RC(Release Candidate) → 정식 릴리스(Stable)
버전 설명
Alpha 초기 개발 버전, 내부 테스트용
Beta 외부 테스트 가능, 주요 기능 탑재
RC 거의 완성. 버그만 없으면 정식 버전으로 출시
Stable 최종 사용자에게 배포되는 정식 버전

🔍 RC 버전의 특징

  • 기능 추가는 완료, 더 이상 새 기능은 없음

  • 안정성 점검이 목적 (예: 성능, 충돌, UI 이슈 등)

  • QA 팀이나 클라이언트가 마지막 검증을 진행

  • 문제가 없다면 → 그대로 정식 버전으로 출시 가능

 

✅ 릴리즈(Release)의 뜻

소프트웨어나 제품을 외부에 정식으로 배포하거나 공개하는 행위
→ “사용자들이 쓸 수 있도록 내보내는 것”

🧩 예시로 보면 더 쉬워요!

용도 설명
앱 출시 앱스토어에 앱을 올리는 것 = 앱을 릴리즈함
웹사이트 개선 기능 개발 → QA 완료 → 사용자에게 적용 = 릴리즈
버전 관리 “v1.2.0 버전이 릴리즈됨” → 새로운 기능이 포함된 버전이 나옴

📌 릴리즈 관련 용어들

함께 자주 쓰이는 용어들도 알려드릴게요!

용어 뜻
릴리즈 노트 (Release Note) 새로 추가된 기능, 수정된 내용 등을 기록한 문서
릴리즈 후보 (RC, Release Candidate) 정식 출시 직전의 마지막 테스트 버전
릴리즈 일정 실제 배포 날짜나 타임라인

🎯 QA 관점에서 릴리즈란?

QA가 완료되고 → 클라이언트 또는 PO가 승인하면 →
실제 서비스에 반영하는 단계 = 릴리즈

✅ 마이그레이션(Migration) 이란?

기존에 있던 데이터를 다른 시스템이나 환경으로 옮기는 작업
→ 또는, 시스템 자체를 새로운 환경으로 전환하는 것도 포함돼요.

🧩 쉽게 풀면?

  • 기존 데이터를 → 새로운 장소나 포맷으로 “이사” 보내는 것!

  • 단순 복사 아님! 구조나 포맷, 호환성 등을 맞춰야 하므로 검증과 테스트가 중요해요.

📌 마이그레이션의 종류 예시

구분 설명
DB 마이그레이션 MySQL → PostgreSQL 등 데이터베이스 이전
서버 마이그레이션 온프레미스 → 클라우드로 이전 (예: AWS, Azure)
서비스 마이그레이션 이전 버전 웹사이트에서 새 버전 웹사이트로 이전
파일/데이터 포맷 마이그레이션 CSV → JSON 등 포맷 변환과 함께 데이터 옮김

🔍 QA에서 마이그레이션 테스트는?

  • 데이터가 유실 없이 잘 이전되었는지

  • 이전된 데이터가 기능에 맞게 작동하는지

  • 성능, 보안 등 이슈가 생기지 않았는지 등을 검증하는 것

 

QA/QC 정보 더보기.. 

https://eunice0121.com/category/qa-qc/