[QA]버그 정의_BUG.

🐞 Bug Tracking System (BTS)

🎯 버그(Bug) 찾기와 관리

QA의 주요 업무 중 하나는 버그를 찾고, 이를 보고하고 추적 관리하는 것임. 이러한 시스템을 BTS(Bug Tracking System) 이라고 하더라.

🎥 예전에는 영상 할 때 BTS 하면 “Behind The Shot” 이었는데… 여기서도 BTS라니! 😵‍💫

버그는 이슈 / 결함 / 오류 등으로 불림:

---

🧐 버그, 오류, 결함 정의

🐛 버그 (Bug)

• 배포 후 발생
• 사용자 관점에서 소프트웨어의 문제
• 예상과 다르게 동작하는 현상

⚠️ 오류 (Error)

• 실행 중 발생
• 코드 실행 중 문제 발생
• 시스템 중단 또는 예상치 못한 동작 유발

🏗 결함 (Defect)

• 개발 초기 단계 발생
• 코드 설계 또는 논리적 문제
• 오류 또는 버그의 근본적인 원인

---

⚠️ 버그가 초래하는 문제

버그는 연쇄적으로 문제를 일으키며, 전체 시스템에 영향을 미친다.

📉 소프트웨어 품질 저하

• 개발 단계에서 버그 발생 → 사용자 경험 저하 → 제품 품질 및 평판 하락

😡 사용자 불만 증가

• 기대에 부합하지 못하는 기능 → 사용자 신뢰도 하락

💸 매출 손실

• 고객 이탈 증가 → 매출 감소

🚨 신뢰도 하락

• 부정적 리뷰 증가 → 신규 고객 감소

---

🔥 버그의 3대 원인

1. 코딩 실수(사실 거의 대부분이 여기서 발생)
2. 요구사항 미스매치
3. 시스템 복잡성

---

🔍 버그 유형

🛠 기능적 버그 (Functional Bug)

• 소프트웨어 핵심 기능이 정상적으로 작동하지 않는 문제
• 예: 로그인 실패, 버튼 미작동 등..

🎨 비기능적 버그 (Non-Functional Bug)

• 성능, 디자인, 사용성(UI/UX) 관련 문제 : UI - User Interface Bug(디자인) , UX - User Experience Bug (사용자 행동)
• 예: 로딩 속도 느림, 화면 깨짐, 색상 이상 등..

⏳ 성능 버그 (Performance Bug)

• 속도 지연, 메모리 과부하, 서버 과부하 등
• 테스트 방법: 부하 테스트(Load Test), 스트레스 테스트(Stress Test), 반응 속도 테스트(Response Time Test), 스파이크 테스트(Spike Test)등의 테스트로 사전에 예방이 최선임!!!!

---

## 성능 테스트 유형

1. Load Test (가장 일반적인 테스트)

• 사전에 결정된 Peak Load에서 시스템 성능을 검증
• 일반적으로 1시간 동안 Peak Load 유지
• Peak Hour Traffic을 감당할 수 있는지 확인

2. Stress Test

• Peak Load의 2배 이상의 부하에서 시스템 성능 검증
• 장애 발생 여부 및 정상 부하로 돌아올 때 우아한 복구(graceful recovery) 여부 확인

3. Endurance Test

• 8시간 이상의 장기간 테스트
• 메모리 누수 등 장기간 사용 시 발생할 수 있는 이슈 감지

4. Spike Test

• 갑작스러운 사용량 급증을 시뮬레이션
• 제품 출시(iPhone) 또는 대규모 세일(Singles’ Day)과 같은 상황 대비

5. Breakpoint Test

• 동시 사용자 수를 점진적으로 증가시켜 장애 지점 파악
• 시스템이 중단되는 지점을 그래프로 시각화 가능

---

🔐 보안 버그 (Security Bug)

• 사용자 정보 보호 실패, 권한 없는 접근 허용 등
• 예:

  • 인증 및 권한 관리 오류 → 시스템이 계정 접근 권한 관리 제대로 못하는 문제(예.비번 없이 로그인 같은상황)

  • 데이터 암호화 오류 → 중요 정보가 암호화 되지 않고 저장되는 문제(예.비밀번호가 그대로 저장되는 그런..)

🔄 호환성 버그 (Compatibility Bug)

• 특정 OS, 브라우저, 버전에서 기능이 정상적으로 작동하지 않는 문제
• 예: 업데이트 후 실행 불가, 특정 브라우저에서 UI 깨짐, 특정 버전에서 실행이 안된다 등..

---

버그도 타이밍에 따라 다른데..

⏳ 버그 발견 시점에 따른 분류

🏗 개발 중 발견된 버그 (Development Phase Bug)

• 코딩 단계에서 발견
• 수정 비용 낮음 & 즉시 해결 가능

🚨 배포 후 발견된 버그 (Post-Release Bug)

• 출시 후 사용자에 의해 발견
• 수정 비용 높음 & 긴급 패치!!!

---

📌 버그 심각도 및 우선순위

🔥 치명적 버그 (Critical Bug)

• 시스템 전체 중단, 주요 기능 미작동 등..

⚡ 중요한 버그 (Major Bug)

• 핵심 기능에 큰 영향, 긴급성까진 아닌..

🎨 사소한 버그 (Minor Bug)

• UI/UX 문제 등..

---

(번외)

⚔️ 보안 관련 버그 & 해킹 공격 유형

🚨 XSS (크로스 사이트 스크립팅)

• 악성 스크립트를 웹사이트에 삽입 → 사용자 정보 탈취
• 피해 예: 피싱 공격, 로그인 정보 유출

🕵️ CSRF (사이트 간 요청 위조)

• 사용자가 모르게 특정 요청 실행
• 피해 예: 비밀번호 변경, 계좌 이체 무단 실행

🏴‍☠️ SQL Injection (SQL 인젝션)

• 입력창을 이용해 데이터베이스에 직접 명령어 입력
• 피해 예: 데이터 유출, 관리자 계정 탈취

📡 공공 와이파이 해킹 위험

• 패킷 스니핑(Packet Sniffing): 네트워크에서 데이터를 가로채는 공격
• 중간자 공격(MITM): 사용자와 서버 사이에서 데이터 조작

---

✅ 버그 예방을 위한 전략

1. 다양한 환경에서 테스트 진행 (브라우저, OS, 모바일/PC 등)
2. 테스트 자동화 도입 (CI/CD 활용)
3. 보안 점검 강화 (코드 리뷰, 침투 테스트)
4. 사용자 피드백 적극 반영
5. 적절한 BTS 도입 및 관리 (JIRA, Redmine 등)

🚀 “버그 없는 완벽한 소프트웨어는 없지만, 예방과 신속한 대응이 최선이다!”