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/

Leave a Reply

Your email address will not be published. Required fields are marked *