[ISTQB CTFL] TIL 2

본 게시물의 출처는 모두 KSTQB에서 모든 사람들에게 공식적으로 제공하는 실라버스 및 샘플문제 (v2018)를 기반으로 작성했습니다. 문제의 소지가 있을 경우, shaawwert6044@gmail.com 혹은 댓글에 남겨주시면 게시글 수정 혹은 삭제 등의 조치를 취하겠습니다.

1. 전략의 수정

1.1 실라버스의 내용을 모르더라도, 하루에 샘플문제 1권씩 풀기 => 진도 나간만큼만 풀기

why?

- 그러나 1-2장을 학습하고 문제를 풀어보니, "암기되어있는 요소들을 어떻게 문제 내에서 구현되는가?"가 샘플문제의 핵심이다.

- 즉 기출문제의 관점에서 접근할 것이 아닌, 구현체의 관점에서 접근해서,,,

오히려 암기사항을 점검하는 데에는 문배2와 같이 문제와 해설이 구체적으로 되어있는 자료를 활용하여 "회독 + 점검"과 함께 병렬적으로 "구현체"에 적용하는 방법이 더 효과적이라고 생각되었다.

 

1.2 퀴즐렛과 같은 퀴즈 형식의 플랫폼을 활용하여 암기사항 암기 => 시간대별로 주제를 한정하여 집중 회독

why?

 

위와 같은 문제들 때문이다.

ISTQB 실라버스는 상당한 개념들이 "나열식"으로 정리되어있어, 일일이 외운다면 예상한 것보다 훨씬 많은 시간이 소요된다.

오히려 다회독 + 지문의 근거찾기 -> 옳지 않은 선지 걸러내기를 반복하는 것이 더욱 효과적일 것이라 판단했다. 

 

 

" 결국 무지성으로 읽어나가며 문제를 활용해 익숙해지는 것이 아닌,

내용과 예제를 이해하며 핵심 키워드를 머리에 점차 넣어가는 회독방식을 사용해야겠다😭😭 "

 

=== 헷갈리거나 처음 보는 개념 정리 ===

 

1. Fundamentals of Testing (Keyword)

• 커버리지(coverage) :

  커버리지 항목이 식별되거나 테스트 스위트(test suite)에 의해 수행된 정도를 백분율로 표시한 것

• ** 디버깅(debugging) :

  (1.1.2)소프트웨어의 장애 원인을 찾아 분석하고 제거하는 프로세스

• ** 테스팅(testing) :

  (1.1.2)소프트웨어의 결함 식별

• ** 결함(defect) :

  (1.2.3)요구사항이나 명세를 충족시키지 못하는 작업 산출물의 불완전함 또는 결점 - 버그(bug), 기본적으로 코드 수준

• ** 오류(error) :

  (1.2.3)부정확한 결과를 만들어내는 "인간의 행동"

• ** 장애(failure) :

  (1.2.3)지정된 범위 내에서 요구되는 기능을 컴포넌트나 시스템이 수행하지 못하는 경우 - 코드결함 + 환경조건, usage 수준

• 품질(quality) :

  컴포넌트나 시스템 또는 프로세스가 특정한 요구사항 및 사용자/고객의 요구와 기대를 충족시 키는 정도

• 품질 보증(quality assurance) :

  (1.2.2)품질관리 = 품질보증(요구사항 커버리지 달성) + 품질제어 (커버리지를 달성하기 위한 일련의 제어 과정)

• 근본 원인(root cause) :

  결함의 원인 중 제거되면 해당 결함유형 발생이 감소하거나 제거될 수 있는 원인

• 테스트 프로세스(test process) :

  설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트(set)

• 테스트 베이시스(test basis) :

  소프트웨어 테스트를 계획하고 수행하기 위한 기초로 사용되는 요소 - 요구사항, 설계, 코드, 사용자 스토리 등에서 추출

• ** 테스트 계획(test planning) :
  (1.4.2)테스트의 목적을 달성하기 위해 접근법을 정의하는 활동 전반 - 테스트 기법, 작업, 기한, 일정 수리 등
• ** 테스트 모니터링(test monitoring) 및 제어(test control):
  - (1.4.2) 테스트 모니터링은 모니터링 메트릭(metric, 측정 척도 및 방법)을 활요하여 계획과 진척상황을 지속적으로 비교하는 활동
  - (1.4.2) 테스트 제어는 업데이트되는 테스트 계획의 목적 달성을 위해 수행하는 여러 활동 (회의, 코딩, 아키텍쳐 수정 등등...)
  - (1.4.2) 종료조건(exit criteria) 평가도 모니터링 및 제어에 포함 - 커버리지와 테스트결과/로그 확인, 컴포넌트 및 시스템의 품질 평가, 추가 테스트 필요 여부 결정
• ** 테스트 분석(test analysis) :
  - (1.4.2) 테스트 베이시스를 분석하여 테스트 컨디션을 식별하는 활동
  - (1.4.2) 테스트 컨디션(test condition) :소프트웨어의 기능 또는 기능의 측면을 테스트하기 위해 정의된 입력 조건 또는 상황
• 테스트 케이스(test case) :
  테스트 컨디션을 기반으로 개발된 사전조건, 입력값, 행동(해당하는 경우), 기대 결과, 사후조건의 집합
• ** 테스트 차터 (test charter) :
  (1.4.2) 세션 기반 탐색적 테스팅에서의 테스트 활동에 대한 문서 - 테스트의 분석 결과로 만들어지며, 테스터 이외에도 이해관계자들이 이해할 수 있는 문서화된 형식을 갖출 필요!
• ** 테스트 설계(test design) :
  (1.4.2) 테스트 설계에서 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어(testware)를 생성
• ** 테스트 구현(test implementation) : 
  (1.4.2) 테스트 구현 중 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만드는 것
  - (1.4.2) 테스트 스위트(test suite) : 특정 테스트 주기에서 실행해야 하는 테스트 케이스의 집합이나 테스트 절차 - 코드줄..
• ** 테스트 실행(test execution) : 
  (1.4.2) 테스트 스위트를 테스트 실행 일정에 따라 실행
• ** 테스트 완료(test completion) : 
  (1.4.2) 소프트웨어 릴리즈, 테스트 프로젝트 완료, 애자일 반복주기 종료, 특정 테스트 레벨 완료, 유지보수 릴리즈 완료
• 테스트 오라클(test oracle) :
  테스트중인 시스템의 실제 결과와 비교할 기대 결과를 판단하기 위한 출처 - ex) 요구사항 명세서, 이전 버전 소프트웨어 등,,
• 테스트웨어(testware) : 
  테스팅에 대한 계획, 설계, 실행, 평가, 보고 등에 활용하기위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물 - 테스트코드 파일,,
• 추적성(traceability)
• ** 밸리데이션(확인 validation) :
  의도된 특정 용도 또는 용도에 대한 요구사항이 충족되었음을 보증하기 위해 객관적 증거와 조사를 통해 확인하는 것
  - 제품을 올바르게 만들고 있는가?
• ** 베리피케이션(검증 verification) :
  특정 요구사항이 모두 구현되었는지를 객관적 증거와 조사를 통해 확인하는 것
  - 올바른 제품을 만들고 있는가?

2. 소프트웨어 개발 수명주기와 테스팅 (Keyword)

• ** test-level
  • 컴포넌트 테스팅(component testing) : 
    컴포넌트 테스팅(단위 혹은 모듈 테스팅이라고 부르기도 함)은 개별적으로 테스트할 수 있는 컴포넌트에 초점
  • 통합 테스팅(integration testing) : 
    컴포넌트나 시스템 간의 상호작용에 초점
    - 컴포넌트 통합 테스팅(component integration testing) : 통합된 컴포넌트 간의 상호작용에 초점
  • 시스템 테스팅(system testing) : 
    시스템이 수행할 엔드-투-엔드(endto-end) 작업과 그런 작업을 수행할 때 나타나는 비기능 동작(ex 성능 - lighthouse)
  • ** 인수 테스팅(acceptance testing) : 
    인수 테스팅의 결과로 시스템을 배포하거나 고객(최종 사용자)이 사용할 준비가 어느 정도 됐는지 평가
    - 사용자 인수 테스팅(UAT, User Acceptance Testing)  : 시스템의 사용자 인수 테스팅은 일반적으로 실제 또는 시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인
    - 운영 인수 테스팅(operational acceptance testing) : 운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅
    - 계약 인수 테스팅(contractual acceptance testing) : 계약서에 명시된 인수 조건을 가지고 수행
    - 알파 테스팅(alpha testing) : 알파 테스팅은 개발 조직의 현장에서 개발팀이 아닌 신규 혹은 기존 고객이나 운영자, 독립적 테스트팀이 수행
    - 베타 테스팅(beta testing) : 배포 전 마지막 테스팅
• ** test-type
  • 기능 테스팅(functional testing) : "동작"에 초점, 시스템이 해야 하는 그 "무엇” 
  • 비기능 테스팅(non-functional testing) : "성능, 보안, 사용성"에 초점, 시스템이 "얼마나 잘" 동작
  • 화이트박스 테스팅(white-box testing) : 화이트박스 테스팅은 시스템의 내부 구조나 구현을 기반으로 테스트 - 코드, 알고리즘, 제어흐름에 집중
  • 블랙박스 테스팅 (black-box testing) : 사용자의 관점에서 소프트웨어가 예상대로 동작하는지 확인