일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- Test Scenario
- STLC
- Airbridge
- 결함심각도
- QA Manager
- Risk Based Testing
- RESRful
- 테스트 프로세스 개선
- QA Engineer
- 구조기반 테스트
- 버그수명주기
- bug
- SQA
- 테스트 시나리오
- Test Summary Report
- Wepublic
- 테스트 요약 보고서
- 웹성능
- ISTQB
- 세니티테스트
- Shift Left Testing
- defect
- Retest
- Sanity Testing
- 리스크기반테스트
- 리그레이션
- 결함우선순위
- BugLifeCycle
- severity
- Software Testing Life Cycle
Archives
- Today
- Total
Software Quality
결함의 심각도(Severity)와 우선순위(Priority) 본문
심각도(Severity) | 우선순위(Priority) |
제품의 작동에 미치는 영향의 정도 | 개발자가 결함을 해결해야 하는 순서 |
QA 엔지니어가 결정 | 관계자와 협의하여 결정 |
기능에 의해 결정 | 비지니스 가치에 따라 결정 |
객관적, 변화 가능성 적음 | 주관적, 상황에 의존적, 변경 가능 |
Critical 시스템 중지/프리징, 데이터 변조 가능 Major 잘못된 기능, 주요기능 오동작 Moderate 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스 Minor 타이핑 애러, 사용자 불편, 좋지 않은 인터페이스 Cosmetic 애러는 아니지만 개선사항 |
Low Midium High |
- 반드시 위 예제대로 심각도를 분리해야 하는 것은 아니지만 너무 낮은 단계 분리는 결함의 심각도에 대한 오인할 수 있어 적절한 뷴류가 필요합니다.
- 반드시 정해진 일정에 출시해야하는 프로젝트인 경우 심각한 결함이 기간 내 수정 불가능 하다면 다른 결함을 우선 해결해 제품 전체의 완성도를 높혀야 합니다.
- 높은 우선순위 낮은 심각도는 결함 즉시 수정하기로 했지만 주요 기능에 크게 영향은 없는 이슈입니다.
- ex. 방송 시 잘못된 방송사 로고 송출
- 낮은 우선순위 높은 심각도의 결함은 해결이 어려워 즉각 수정할 수 없음을 나타냅니다.
- ex. 쇼핑몰에서 장바구니 기능이 안되지만 개별 구매는 가능한 상태로 우선 출시하기로 함
'SQA > 이론' 카테고리의 다른 글
검증(Verification)과 확인(Validation) (0) | 2023.09.24 |
---|---|
QA(Quality Assurance)와 QC(Quality Control) (0) | 2023.09.24 |
Retest와 Regression Testing (0) | 2023.09.23 |
Smoke 테스트와 Sanity 테스트 (0) | 2023.09.23 |
STLC (0) | 2023.09.22 |