Software Quality

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

Smoke TestingSanity Testing프로그램의 주요 기능이 정상적으로 동작하는지 확인새롭게 추가되거나 수정된 부분이 문제 없는지 확인안정성을 검증하는 것합리성을 검증하는 것개발자 혹은 테스터에 의해 수행일반적으로 테스터에 의해 수행문서화되거나 스크립트로 작성일반적으로 문서화되지 않음수용 테스트의 하위 집합회기 테스트의 하위 집합시스템 전체를 테스트시스템 일부 특정 구성요소만 테스트일반 건강검진특정 부위 전문 검진기본적으로 둘 모두 테스트 시작 전 잘못된 빌드로 테스트 진행하여 시간을 낭비하는 일이 없도록 하기 위해 진행하는 테스트입니다.

버그 프로그램의 소스코드 작성의 실수 혹은 예기치 못한 오류의 결과 결함 요구사항과 다르게 구현된 부분

1. What is STLC? Software Testing Life Cycle의 약자로 소프트웨어 애플리케이션이 요구 사항을 충족하고 결함이 없는지 확인하기 위해 소프트웨어 애플리케이션을 테스트하는 체계적인 접근 방식이다. 2. Typical Software Testing Life Cycle 1. 요구사항 분석(Requirement Analysis) 활동 수행할 테스트 유형을 식별 테스트 우선 순위와 포커스에 대한 세부 정보 수집 요구사항 추적 매트릭 준비 테스트 환경의 세부 사항 확인 필요한 경우 자동화 타당성 분석 결과물 RTM 자동화 타당성 보고서 2. 테스트 계획(Test Planning) 활동 테스트에 대한 계획/전략 문서 작성 테스트 도구 선택 테스트 노력 추정 리소스 계획과 역할 및 책임 ..

1. URI Scheme 구조 ServiceName://Path 실행 시 동작 앱이 설치된 경우 Path 위치로 이동 앱이 설치되지 않은 경우 앱스토어 화면으로 이동 한계점 동일한 서비스명을 사용하는 경우 의도하지 않은 앱이 실행될 수 있음 2. 유니버셜링크(iOS)/앱링크(Android) 구조 통상적으로 웹 주소 http://naver.com 실행 시 동작 앱이 설치된 경우 Path 위치로 이동 앱이 설치되지 않은 경우 앱스토어 화면으로 이동 URI Scheme과 차이점 도메인 주소를 이용해 실행 한계점 Android/iOS 상호 호환되지 않음 3. 원링크 유니버셜링크/앱링크와 차이점 Android/iOS 상호 호환 가능 Dynamic Links Firebase에서 제공하는 원링크 디퍼드(Deferre..