Software Quality

New : 새로운 결함을 등록 Assigned : 담당 개발자(팀)에 버그를 할당 Open : 개발자가 분석을 시작하고 결함 수정 작업을 진행 Reject : 결함이 아니여서 거절 Deferred : 이번 수정범위에 포함되지 않아 지연 Duplicate : 이미 등록된 동일 이슈가 있음 Fixed : 개발자가 결함 수정 완료 In Progress : 수정 진행 중 Pending Retest : 테스터의 재확인 테스트 대기 Retest : 결함 재확인 테스트 진행 Verified : 재확인 테스트 통과, 결함 수정 확인 Closed : 이슈를 닫고 완료 ReOpend : 재확인 테스트에서 다시 이슈 발생되어 재등록 참고 https://www.guru99.com/defect-life-cycle.html

리스크 기반 테스트를 진행하는 이유는 사용자가 제품에서 버그를 발견하더라도 소프트웨어 사용을 중단하지 않게하고 비즈니스에 심각한 영향을 미치지 않도록 하기 위함입니다. 따라서 위험 기반 테스트는 제품이나 소프트웨어의 특징, 모듈 및 기능에 대한 테스트 우선 순위를 매기는 원칙이 필요합니다. 우선 순위는 장애 가능성(기능이 잘못 동작할 가능성)과 장애로 인한 영향(잘못된 기능이 고객에게 미치는 영향)에 따라 결정됩니다. 리스크 기반 테스트는 언제 사용되어야 할까요? 프로젝트의 시간, 비용, 자원에 제한이 있거나 제약이 있거나 자원을 최적화할 필요가 있을 때 사용할 수 있습니다. 프로그램에 더 복잡하고 새로운 기술이 적용되어 많은 문제가 발생할 때 사용됩니다. 프로그램 R&D 프로젝트이고 처음으로 시도하는 ..

테스트 실행의 품질을 확인하기 위해 두개의 파라미터를 이용할 수 있습니다. Defect reject ratio - 결함이 아닌것을 결함이라고 등록 (거부된 결함 수/발생한 총 결함 수) X 100 Defect leakage ratio - 결함이 누출(릴리즈 이후에 확인되는)되는 비율 (누락된 결함 수/소프트웨어의 전체 결함 수) X 100

1. 구성요소 ID : 테스트를 고유하게 식별하게 해주는 식별자 우선순위(Priority) : 테스트 진행 우선순위(Low/Medium/High) 모듈 이름(Module) 테스트 설계자(Author) 시험 설계일(Create Date) 테스트 수행자(Tester/Performer) 테스트 실행 날짜(Run Date) 테스트 케이스 제목(Title) 테스트 케이스 요약(Description) : 테스트 케이스 목표를 설명 전제조건(Pre-Condition) : 테스트 절차 실행 전에 따라야 하는 조건 또는 단계 종속성(Dependencies): 테스트 요구사항 또는 기타 테스트 케이스에 대한 의존성을 판단 테스트 절차(Steps) : 테스트 케이스를 수행하기 위한 정확한 단계 예상 결과(Expected R..

테스트 시나리오(Test Scenario) 테스트 케이스(Test Case) 테스트할 대상의 기능을 설명 명확한 테스트 단계, 데이터, 예상 결과가 포함 무엇을 테스트할 것인가? 무엇을 어떻게 테스트할 것인가? 모호한 경우가 있을 수 있음 단계, 사전조건, 예상 결과가 명확해 모호한 경우 없음 BRS, SRS 등을 기반으로 작성 테스트 시나리오를 기반으로 작성 전체 기능을 빠르게 확인 할 수 있게 도와줌 전체 기능을 철저하게 테스트 할 수 있게 도와줌 High-Level의 작업 Low-Level의 작업 작성 및 수행하는데 소요되는 시간과 자원이 상대적으로 적음 작성 및 수행에 더 많은 시간과 자원이 필요 BRS : Business Requirement Specification BRS : System Re..

PDCA는 Plan(계획), Do(실행), Check(점검), Act(개선)의 네 단계로 이루어진 기법입니다. 소프트웨어 테스트에서는 프로젝트 진행 후 다음 프로젝트는 더 잘 진행할 수 없을까? 우리는 프로젝트에서 무엇을 배웠는가? 확인하고 프로세스 개선을 위해 PDCA 모델을 이용합니다. Plan 단계에서는 목표를 설정하고, 그 목표를 달성하기 위한 계획을 수립합니다. 이전 테스트 진행 중 어떤 문제가 있었는지 파악합니다. 프로젝트에서 발생한 문제점을 이해합니다. ex) 리그레션 테스트에 시간이 너무 오래 걸림 개선 목표를 정의합니다. ex) 리그레션 테스트에 자동화 도입 Do 단계에서는 계획을 실행합니다. 계획을 수립 후 실행합니다. ex) 리그레션 자동화 스크립트 작성 실행 과정에서 발생한 데이터를..

검증(Verification) 확인(Validation) 목적 소프트웨어가 기획서의 요구 사항에 맞게 올바르게 만들어졌는지 확인 소프트웨어가 고객의 요구 사항과 기대를 충족하는지 확인 방법 문서, 설계, 코드, 프로그램 검사 실제 제품 테스트 및 유효성 검사 코드 실행 여부 코드 실행하지 않음 코드 실행 방법 검토, 연습, 검사, 책상 검사 등 블랙 박스 테스트, 화이트 박스 테스트 및 비기능 테스트 등 대상 응용 프로그램 및 소프트웨어 아키텍처, 사양, 전체 설계, 고수준 및 데이터베이스 설계 등 실제 제품 수행자 QA 팀 테스트 팀 수행 순서 Validation 이전 Verification 이후 장점 개발 주기 초반에 버그를 발견할 수 있음 ex. 설계 문서상의 결함 검증에서 발견할 수 없는 버그를 ..

QA(Quality Assurance) QC(Quality Control) 요청된 품질이 달성될 것이라는 확신을 제공하는 데 초점을 맞춤 요청된 품질을 충족하는데 중점을 둠 결함 방지를 목표로 함 결함 식별 및 수정을 목표로 함 프로그램 실행과 무관 프로그램 실행 항상 포함 예방적인 기법 수정적인 기법 결과물 생성 절차 결과물 확인 절차 소프트웨어 개발 수명주기(SDLC)와 관련됨 소프트웨어 테스팅 수명주기(STLC)와 관련됨 Verification Validation 품질 요구 사항을 충족하기 위해 표준 및 방법론 정의 제품 작업 중 표준 준수 확인 QC 전에 수행 QA 활동이 끝난 후에만 수행 Low-Level 활동, QC가 감지할 수 없는 오류 및 실수 감지 가능 High-Level 활동, QA가 ..

심각도(Severity) 우선순위(Priority) 제품의 작동에 미치는 영향의 정도 개발자가 결함을 해결해야 하는 순서 QA 엔지니어가 결정 관계자와 협의하여 결정 기능에 의해 결정 비지니스 가치에 따라 결정 객관적, 변화 가능성 적음 주관적, 상황에 의존적, 변경 가능 Critical 시스템 중지/프리징, 데이터 변조 가능 Major 잘못된 기능, 주요기능 오동작 Moderate 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스 Minor 타이핑 애러, 사용자 불편, 좋지 않은 인터페이스 Cosmetic 애러는 아니지만 개선사항 Low Midium High 반드시 위 예제대로 심각도를 분리해야 하는 것은 아니지만 너무 낮은 단계 분리는 결함의 심각도에 대한 오인할 수 있어 적절한 뷴류가 필요합니..

RetestRegression Testing결함 수정을 확인하기위한 테스트코드 변경이 다른 기능에 영향을 주지 않았는지 테스트다른기능은 확인하지 않고 해당 기능만 확인코드 변경 이전 동작하던 주요 기능들이 여전히 잘 동작하는지 확인실패한 테스트를 대상으로 함성공한 테스트를 대상으로 함특정 결함 확인 위한것으로 자동화 불가수동으로 반복 진행하기 어려움으로 자동화 진행하는 것이 좋음버그가 발견되지 않은 경우 진행하지 않을 수 있음버그가 발견되지 않더라도 항상 진행알려진 문제에 초점을 맞추기 때문에 우선순위가 높음발생 가능성에 대한 테스트로 우선순위 낮음특정 결함만을 확인함으로 시간이 많이 걸리지 않음전반적인 영역을 확인함으로 시간이 많이 걸림동일한 데이터와 환경에서 수정된 빌드로 결함 확인사용설명서, 보고된..