dev + qa = hq sw dev + qa = hq sw

테스트 베이시스 테스트 분석 및 설계의 기초로 사용되는 지식 체계 테스트 분석, 설계 단계의 논리적인 케이스로 테스트 케이스 설계를 위한 기준이 되는 문서 (ex. 요구사항 명세서, 관련 기준 또는 표준) 요구사항을 내포하고 있는 모든 문서 테스트 컨디션 테스트 베이시스로 식별된 구성 요소 또는 시스템의 테스트 가능한 측면 테스트 케이스에 대한 트랜잭션, 기능 또는 구조적 요소와 같은 기능을 포함할 수 있는 특정 제약 조건 집합 특정 테스트 목적 달성과 관련있는 테스트 베이시스의 한 측면 하나 이상의 테스트 케이스에 의해 검증될 수 있는 컴포넌트나 시스템의 항목 또는 이벤트 (ex. fuction, transaction, quality attribute, 또는 structural element 등) 테스..

프레임워크 사전적 정의, 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조 (뼈대, 골조) 소프트웨어 프레임워크 소프트웨어 개발자가 응용 소프트웨어의 표준 구조를 구현하기 위해 사용 애플리케이션 프레임워크 프로그래밍에서 특정 운영 체제를 위한 응용 프로그램 표준 구조를 구현하는 클래스와 라이브러리 모임 공통적인 개발 환경 제공 (개발 시간 ↓ 리소스 비용 ↓ 생산성 ↑) 프로세스 프레임워크 규모나 복잡성에 관계없이 모든 소프트웨어 프로젝트에 적용 할 수 있는 소수의 프레임워크 활동을 식별 → '완전한 프로세스'의 기본 구조 구축 ex. 스크럼, 테스트 자동화 프레임워크 테스트 프레임워크 = 자동화 테스트 프레임워크, 테스트 자동화 프레임워크 테스트 케이스를 생성 및 설계하기 위한 가이드라인,..

테스트 설계 기법 테스트 케이스를 도출, 설계하는데 사용하는 절차 테스트 컨디션, 테스트 케이스, 테스트 데이터를 식별 테스트 케이스를 도출하고 테스트 대상이 어느 수준까지 테스팅되었는지 확인 (보장성 확보) 기법 선택 요인 테스트 대상 시스템의 종류 컴포넌트/시스템의 복잡도 규제 기준 고객/계약 요구사항 유즈케이스 모델 리스크 수준/유형 사용 가능 문서 테스터 지식 및 역량 사용 가능 문구 시간, 예산 소프트웨어 개발 수명주기 예상되는 결함 유형

테스트 프로세스를 구성하는 주요 활동 테스트 계획 - 테스트 모니터링 및 제어 - 테스트 분석- 테스트 설계 - 테스트 구현 - 테스트 실행 - 테스트 완료 테스트 계획 테스팅의 목적 & 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동 적합한 테스트 기법 및 작업 명시 테스트 일정 수립 작업산출물 = 하나 이상의 테스트 계획 (+ 테스트 베이시스에 대한 정보 포함) 테스트 모니터링 및 제어 테스트 계획에 정의된 테스트 메트릭을 기반하여 모니터링 → 실제 & 계획을 지속적으로 비교 시간이 지나면서 업데이트 될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행 + 테스트 종료 조건 평가 (명시된 커버리지 조건 대비 테스트 결과 & 로그 확인 - 품질 수..

테스트 유형 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합 테스트 요구사항을 가장 효율적으로 다루는 적절한 방법을 사용하여, 주어진 레벨에 적용되는 접근 방식 및 기술 주요 목표에 따라 테스팅은 여러 유형으로 나누어진다 기능 테스트 방식으로 기능 요구사항을 어느정도 준수하는지 평가하는 테스트 블랙박스 방법 적용 & 모든 레벨에서 수행 처리하는 '과정'보다 '결과' 중시 기능성 테스트 프로세스 1. 소프트웨어가 수행할 기능들 열거 2. 기능 사양(specifications)에 따라 입력 데이터 구성 3. 기능 사양에 따라 출력값 결정 4. 테스트 케이스 실행 5. 실제 출력값과 예상된 출력값 비교 성능 테스트 대상 테스트 항목에 필요한 부하를 발생시켜, 테스트 실행 동안 성..

블랙 박스 테스트 애플리케이션의 내부적 작동 방식과 입력값 처리 방식에 대한 지식 없이 에 초점을 맞춤 목적: 소프트웨어의 기능이 올바르게 작동하고 사용자 요구를 충족하는지 확인 모든 테스트 레벨에 적용할 수 있지만, 대부분 단위 및 통합 테스트에 사용 외부로 노출되는 기능과 비기능에 대한 테스트 중점 ex. 자동차 테스트: 차가 잘 가는지 속도, 주행 능력 등을 테스트 화이트 박스 테스트 애플리케이션의 일부 구조적 부분에 대한 테스트를 수반하므로, 코드에 대한 깊은 지식이 필요 일반적으로, 코드 작성에 직접 관여하는 개발자가 테스트 담당 목적: 과 를 강화하고, 과 을 향상 주로, 시스템, 사용자 승인 테스트 수준에서 사용 ex. 자동차 테스트: 차의 엔진이 제대로 작동하는지 조향장치와 같이 내부 구조..

테스트 레벨 테스트가 수행될 소프트웨어 개발 주기의 여러 단계 (테스트 프로세스 중의 특정 예시 단계) 소프트웨어 개발 프로세스에 중점을 둔 영역에 따라, 4 개의 점진적 테스트 레벨이 있음 기준으로 분류 컴포넌트/유닛 테스트 - 통합테스트 - 시스템 테스트 - 인수 테스트 컴포넌트/ 유닛 테스트 유닛: 소프트웨어 시스템에서 테스트할 수 있는 가장 작은 부분 소프트웨어 시스템의 모든 단일 단위를 검사하여, 예상한대로 요구 사항과 기능을 충족하는지 확인하는데 목적을 둠 일반적으로, 개발자가 개발 프로세스 초기에 수행 각 컴포넌트를 독립된 환경에서 테스트 통합 테스트 결합된 단위가 그룹으로 함께 잘 작동하는지 확인하는데 목적을 둠 모듈 내 단위 간의 상호 작용에서 결함 감지 통합된 장치 간의 인터페이스 및 ..

소프트웨어 테스트 전략 테스트의 일부로서 수행할 단계들을 정의해놓은 로드맵 → 이 단계들이 언제 계획, 수행되야하는지? 얼마나 많은 노력, 시간, 리소스들이 필요한지? = 조직 내에서 수행하는 하나 이상의 프로젝트를 테스트하기 위해 포괄적인 요구사항을 나열한 문서 → 테스팅을 어떤 방식으로 수행해야 하는지? 그 것이 어떻게 테스트 정책과 연계되는지? 테스트 전략 목적 ☞ 테스트 프로젝트의 주요 과제, 어려움들을 명확하게 하기위해 프로세스에서 사용되는 정확한 시기에 따라 테스트 전략은 예방(Preventive) 또는 사후(Reactive)로 분류 테스트 전략의 7가지 유형 전략 특성 주된 포커스 영역 (Primary Focus Area) 이용 사례 (Use Case) 분석적(Analytical) 예방 테스..