먼지 쌓인 키보드
[ISTQB] CTFL 헷갈리는거 정리 본문
인수테스팅의 목적 - 전체 시스템 품질에 대한 자신감 획득 - 완성된 시스템이 기대한대로 동작하는지 확인 - 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증
|
폭포수모델 - 개발활동이 순차적으로 이루어짐 - 테스트활동은 모든 개발활동이 완료된 후 (반대) V-모델 : 테스팅을 초기에 시작하면 좋다는 원리(조기테스팅을 적극적으로 구현)
순차적 개발 모델 - 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작 - 1차원적 선형의 순차적 활동
점진적 개발 모델 - 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행 - 소프트웨어 기능이 점진적으로 늘어나며, 그 증가 크기를 기능 증분이라고 함 ex) 기능 증분은 사용자 인터페이스 화면이나 신규 문의옵션 변경 하나 만큼 작을수도있음
|
경험기반 테스트 기법 오류추정 - 테스터의 지식을 기반으로 실수, 결함 및 장애 발생을 예측하는데 적용 - 어떤 결함이 발생할지 테스터의 경험을 사용하여 예측하고, 해당 결함만을 중심적으로 검출 - 애플리케이션 과거 동작, 개발자가 하는 실수 유형, 다른 애플리케이션에서의 장애
탐색적 테스팅 - 테스터가 테스트를 수행하면서 테스트 설계를 능동적으로 제어 - 보다 나은 테스트 설계를 위해 테스트를 수행하며 얻은 정보를 활용하는 비공식적인 테스트 기법 - 비공식 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가 - 명세가 충분하지 않거나 적은 경우/상당한 시간적 압박이 있을 때 - 공식적인 테스팅 기법을 보완하는데 유용
체크리스트 기반 테스팅 - 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성 - 체크리스트에 기록된 테스트 컨디션을 커버하기위해 테스터가 테스트를 설계, 구현, 실행
|
블랙박스 테스팅 - 컴포넌트나 시스템의 내부구조를 참조하지않고 기능과 비기능을 테스팅하는것 - 컴포넌트나 시스템의 내부 구조나 데이터에 대한 자세한 지식없이 내부 구조를 블랙박스로 보고 명세서는 물론 입력과 출력을 분석하여 선정한 테스트 케이스를 이용하여 시스템의 결함을 발견하는 테스트 접근법
화이트박스 테스팅 - 구문 테스팅/결정 테스팅 - 테스트 대상의 내부 구조를 기반 - 시스템의 내부 구조나 구현을 기반으로 테스트를 도출
|
테스트 매니저 vs 테스터 테스트 매니저/관리자 - 테스트 전책과 테스트 전략을 개발하고 리뷰 - 정황을 고려한 테스트 활동과 테스트 목적과 리스크 이해를 바탕으로 테스트 활동을 계획 - 테스트 계획서 작성과 업데이트 - 테스트 환경 구축에 관한 결정 - 테스터의 역량과 경력 개발 - 사용할 도구와 가이드라인 선택 - 우선 순위를 정함 - 테스트 수행중 수집한 정보를 기반으로 테스트 요약 보고서 작성
테스터 - 테스트 계획을 리뷰하고 계획 작성에 참여 - 요구사항, 사용자 스토리와 인수조건, 명세, 모델의 테스트 용이성을 분석, 리뷰, 평가 - 테스트 컨디션을 식별 및 기록하고, 테스트 케이스, 테스트 컨디션, 테스트 베이시스 간 추적성 설정 - 테스트 산출물 리뷰 - 테스트를 체계화하고 테스트 자동화 프레임워크를 결정 - 다른 사람이 작성한 테스트 리뷰 - 상세 테스트 수행 일정 수립
|
테스트 추정 기법 메트릭 기반 기법 - 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측 ex) 과거 유사한 테스트 프로젝트의 예산을 참고
전문가 기반 기법 - 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측 ex) 테스트 매니저를 인터뷰하여 전반적인 경험을 수집 테스트 자동화를 위한 노력의 추정은 테스트 팀에서 합의로 도출 |
테스트 도구 테스팅 및 테스트웨어 관리 지원 도구 - 형상 관리 도구 - 요구사항 관리 도구 - 결함 관리 도구 - 테스트 관리 도구
정적 테스팅 지원 도구 - 리뷰도구 - 정적 분석 도구
테스트 설계 및 구현 지원 도구 - 모델 기반 테스팅 도구 - 테스트 설계 도구 - 테스트 데이터 준비 도구
테스트 실행 및 로깅지원 도구 - 커버리지 측정 도구 - 테스트 실행 도구(리그레션 수행) - 테스트 하네스
성능 측정과 동적 분석 지원 도구 - 모니터링 도구 - 성능 테스팅 도구 - 동적 분석 도구
특수 목적 테스팅 지원 도구 - 데이터 품질 평가 - 데이터 변환/마이그레이션 - 사용성, 접근성, 현지화, 보안, 이식성 테스팅
|
테스트 컨디션 - 특정 테스트 목적 달성과 관련된 테스트 베이시스의 한 측면
테스트 케이스 - 하나 또는 그 이상의 테스트 케이스에 의해 검증될 수 있는 컴포넌트나 시스템의 항목 또는 이벤트
|
품질 보증 - 품질 요구사항을 충족하는지에 대한 자신감 제공에 중점을 두는 품질 관리의 일환
품질 - 컴포넌트, 시스템 또는 프로세스가 명시된 요구사항이나 사용자/고객의 필요와 기대를 만족하는 정도
|
컴포넌트 통합 테스팅 - 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점
시스템 통합 테스팅 - 시스템, 패키지, 마이크로 서비스 간의 상호운용성과 인터페이스에 초점
|
리뷰 활동 순서 계획 -> 리뷰착수 -> 개별 리뷰 -> 이슈 논의 및 분석 -> 결함 수정 및 보고
|
공식리뷰 역할/책임/참가자 저자 - 리뷰 대상 작업 산출물 작성, 결함 수정
관리자 - 리뷰 계획 담당 - 리뷰 실행 결정 - 인력, 예산, 시간 할당
촉진자(중재자) - 리뷰 회의시 효과적인 회의 진행 보장 - 필요한 경우 다양한 관점들에 대한 중재
리뷰 리더 - 전반적으로 리뷰에 대한 책임을 지는 사람 - 참여자를 결정하고 언제 어디서 진행할지 결정
검토자 - 해당 주제에 대한 전문가, 프로젝트 참여 인원, 이해관계자나 비즈니스 배경을 가진 사람 - 리뷰 대상 작업 산출물의 잠재적 결함 식별 - 다양한 관점을 대표
서기 - 개별 리뷰 활동에서 발견한 잠재 결함 수집 - 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록
|
비공식/워크쓰루/기술리뷰/인스펙션 차이 비공식 리뷰 - 공식적인 절차를 따르지 않은 리뷰 - 리뷰 미팅을 저자가 주도 - 리뷰 보고서 작성X (나머지 리뷰는 작성) - 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
워크쓰루 - 소프트웨어 개발 멤버가 집단 토의에 따라 설계 문서나 프로그램 중의 논리적인 오류를 발견 - 서기 역할이 있음 - 리뷰 미팅을 저자가 주도
기술적 리뷰 - 선택하고자 하는 기술적 접근번에 대한 합의에 초점을 맞춘 동료 그룹 토의활동 - 서기 역할
인스펙션 - 개발 표준 위반과 상위 레벨 개발 문서와의 불일치 등과 같은 결함을 발견하기 위해 문서를 눈으로 검사하는 리뷰 - 가장 공식적인 리뷰 - 규정과 체크리스트에 기반한 공식 프로세스를 참조하는 리뷰 수행시 - 서기역할
|
블랙/화이트/경험 블랙박스 테스트 기법 특징 - 컴포넌트나 시스템의 내부구조 참조없이 기능적 또는 비기능적 명세 분석을 토대로 테스트 케이스를 도출 - 적절한 테스트 베이시스 분석을 기반 ( 공식 요구사항 문서, 명세서, 유스케이스, 사용자 스토리 등) - 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는데 사용 - 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정
화이트박스 테스트 기법 특징 - 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍쳐, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출 - 커버리지는 대상 구조에서 테스트한 항목을 기준으로 측정 - 명세서는 테스트 케이스의 기대 결과 판별을 위한 추가 정보로 사용되는 경우가 많음
경험 기반 테스트 기법 특징 - 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 도출
|
제품 리스크/ 프로젝트 리스크 차이 제품 리스크 - 테스트 대상에 직접적으로 관계된 리스크 - 작업 산출물이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성 (예제) - 보고서에 기재된 합계 오류 - 사용자가 앱과 함께 소프트 키보드를 사용하기가 너무 어려움 - 검색어 입력 중 시스템이 사용자 입력에 너무 느리게 응답함 - 시스템 아키턱처가 기대하는 보안 기능을 지원하지않을수있음
프로젝트 리스크 - 테스트 인력 부족, 변경 불가한 출시시기, 변경이 잦은 요구사항 등 프로젝트의 관리 및 제어와 관계된 리스크 (예제) - 인수 테스팅 도중 인수 조건 변경 - 일일 스탠딩 회의에서 테스터가 테스트 결과를 보고하지 못함 - 개발자가 테스트 팀이 발견한 결함을 모두 수정할 시간이 없을수있음 - 테스트 케이스가 명시된 요구사항의 커버리지를 모두 만족시킬수없음 - 시스템이 전달되는 시점까지 성능 테스트 환경을 준비하지못할수있음
test) - 테스트 케이스가 명시된 요구사항의 커버리지를 모두 만족시킬수없음 - 보고서에 기재된 합계 오류 - 시스템이 전달되는 시점까지 성능 테스트 환경을 준비하지못할수있음 - 사용자가 앱과 함께 소프트 키보드를 사용하기가 너무 어려움 - 검색어 입력 중 시스템이 사용자 입력에 너무 느리게 응답함 - 시스템 아키턱처가 기대하는 보안 기능을 지원하지않을수있음 - 인수 테스팅 도중 인수 조건 변경 - 일일 스탠딩 회의에서 테스터가 테스트 결과를 보고하지 못함 - 개발자가 테스트 팀이 발견한 결함을 모두 수정할 시간이 없을수있음
|
영향도분석 - 수정에 영향을 받는 시스템 영역을 파악할때 사용 - 영향의 정도는 변경이 그만한 가치가 있는지 결정할때 사용 - 유지보수 테스팅에서 리그레션 테스트 선택을 위해 사용
|
인수/컴포넌트/통합/시스템 인수 테스팅 - 전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진행 목적 - 전체 시스템의 품질에 대한 자신감 획득 - 완성된 시스템이 기대한대로 동작하는지 확인 - 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증
컴포넌트 테스팅 (= 모듈테스팅) - 개별적으로 테스트활수있는 컴포넌트에 초점 - 통합된 컴포넌트 간의 인터페이스와 상호작용에서 결함을 찾아내기위해 수행하는 테스트 목적 - 리스크 완화 - 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단 - 컴포넌트 품질 수준에 대한 자신감 획득 - 컴포넌트에 존재하는 결함 발견 - 다음단계로의 결함 전이 방지
통합 테스팅 - 컴포넌트나 시스템 간의 상호작용에 초점 목적 - 리스크 완화 - 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단 - 인터페이스 품질 수준에 대한 자신감 획득 - 결함 발견 - 다음 단계로의 결함 전이 방지
시스템 테스팅 -명시된 요구사항을 만족하는지 확인하기위해 통합된 시스템을 테스트 목적 - 리스크 완화 - 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증 - 완성된 시스템이 기대대로 동작하는지 확인 - 결함 발견 - 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지
|
테스트 메트릭 보고에 유용한 도구 - 테스트 관리 도구
|
'공부 관련 > 소프트웨어 QA' 카테고리의 다른 글
ISTQB CTFL 자격증 도착과 제작 기간 (1) | 2020.03.09 |
---|---|
ISTQB CTFL 자격증 턱걸이 합격! (0) | 2020.02.28 |
[CTFL 실라버스 정리] 6. 테스트 지원 도구 (0) | 2020.02.10 |
[CTFL 실라버스 정리] 5.3 테스트 모니터링과 제어 (0) | 2020.02.10 |
[CTFL 실라버스 정리] 5. 테스트 관리 (0) | 2020.02.06 |