2. SW테스트 전문가 과정(ISTQB CTFL자격)

실라버스

 

3장 :

 

95p

정적분석은 리뷰와 정적분석으로 나눌 수 있다. 

정적분석 : 개발자들

리뷰를 집중적으로 다룬다. 

리뷰는 크게 2가지로 나뉜다. 

비공식리뷰와 공식리뷰로 나뉜다.

2가지로 구분.

결과를 문서화하는가? 측정을하겠다는 의미

측정은 개선을 하겠다는 의미이다.

2번 프로세스를 얼마나 준용하는가?

 

리뷰에 성공요소는 고려해야 하는 요소. 

 

쉽게 생각해서 장, 단점으로 생각하면 된다.

 

96p

비공식 리뷰는 EX) 실라버스를 그린 다음에 문제가 있는지 봐줘라고 하는 것.

 

규칙도 없으며, 가드라인드 없는 간단한 의견을 물어보는 것.

 

버디체크 : 저자가 빠져나가고 한 명에게 의견을 물어보는 것.

 

페어링 : 작업하는 동안 옆에서 지켜보면서 알려달라고하는 것

 

짝 리뷰 : 버디체크는 한명한테 짝리뷰는 저자가 빠지면서 2명에게 의견을 구하는 것.

 

공식리뷰 : 인스펙션, 기술 리뷰, 워크 쓰루. 

 인스펙션이 제일 공식적이며 뒤로 갈수록 덜 공식적이다. 

 

리뷰 프로세스 : 계획 -> 리뷰 착수 -> 개별 리뷰 -> 이슈 논의 및 분석 -> 수정 및 보고 

 

계획은 관리 프로세스. 리뷰 착수는 시작, 실행. 

 

계획과 리뷰 착수의 약간의 갭이 있다.

 

1O3p  관리자가 계획을 세운다. 관리자는 리뷰를 진행하지 않는다.

 

따라서 리뷰 리더가 따로 있다. 

 

98p 목적, 범위 , 노력과 기간 추정, 특성의 식별, 인원을 선정, 역할 담당, 시작 및 종료 설정

 

리뷰착수 : 작업 산출물과 같은 기타 자료 배포, 참가자에게 범위, 목적, 프로세스, 역활 , 작업 산출물설명

 

참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변. -> 교육, 훈련 제공

 

개별리뷰(결함 검출): 개별이 중요하다.  공식적인 리뷰를 할 때 제일 중요한 점은 모여서 하지 않는 것.

 

같이 있게 되면 관점이 섞인다. 

 

공통된게 있다면 혹은 없다면 취합, 분류

 

리뷰착수(시작회의) , 이슈논의 및 분석(리뷰회의)라고 부르기도 한다.

 

101p

식별한 잠재 결함 전달 : 취합 --> 분류  

잠재 결함 분석 및 담장자 및 상태할당 : 토론, 토의 

 

102p 

 

결함 수정: 일반적으로 저자가 수정.

 

결함 정보를 적절한 사람이나 팀과 공유(리뷰 한  작업 산출물과 연관된 다른 작업 산출물이 있는 경우)

 

수정 및 보고가 끝나는데 필요하다면 다시 개별 리뷰로 돌아갈 수 있다.

 

104p 

 

저자 : 리뷰 대상 작업 산출물 결함 수정(필요한!! 경우)

 

관리자: 리뷰 실행 결정, 계획 담당.

 

105p 

 

촉진자: 중재자(리뷰 회의 진행 시  효과적 진행 보장) 리뷰 성공 여부에 결정적인 역활

 

훈련, 자격이 있는 제 3자이다.

 

106p 

검토자 : 다양한 관점을 대표할 수 있어야 한다.

 

서기/기록자 : 잠재 결함 수집 , 결정 사항 기록.

 

107p

 

비공식 리뷰에서 키워드 : 빠른 해결, 효율적

 

공식 프로세스로 진행되지 않는다. 따라서 기록을 해도 되고 안 해도 된다.

 

체크리스트 사용 여부는 상황에 맞게 판단.

 

108p

워크쓰루: 목적 결함 발견. 참여자를 교육, 훈련을 시키는 것이 목적.

 

학습을 통해 결함 발견을 하도록 훈련 교육. 일반적으로 리뷰회의는 저자가 주도 (워크 쓰루에서)

 

서기 참석이 필수.

 

체크리스트 사용 여부는 상황에 맞게 판단.

 

주로 시나리오, 드라이 런 기법으로 수행.

 

실무에서는 비공식적인 형식에서 매우 공식적인 형식까지 다양할 수 있음.

 

 

109p 

기술리뷰 : 합의 도출. 다른 구현 방법 고려.

 

기술 전문가가 반드시 참석해야 한다. 

 

리뷰회의는 훈련된 촉진자가 해야한다. 

 

110p

 

인스펙션 : 결함 발견, 품질 평가, 결함 발생 예방 

 

가장 강력한 리뷰 유형이다. 정의된 프로세스를 수행. 

 

결론: 비공식 워크쓰루 기술리뷰 인스펙션에서 빠르게 처리할려면 비공식.

 

강력한 효과를 기대하려면 인스펙션

 

역할기반 체크리스트 기반(강력하니까) 많이 쓴다. 

 

111p

 

일반적으로 비공식으로 리뷰를 진행한 후 공식리뷰로 진행( 비용과 시간이 너무 많이 소모)

 

따라서 문서의 완성도를 위해 비공식 리뷰를 많이 진행한 후 공식 리뷰를 진행.

 

리뷰는 2가지 이상이 합쳐 질 수 있다. 공식+공식도 가능하며, 비공식 + 공식 리뷰도 가능하다.

 

114p

Ad hoc, 체크리스트, 시나리오, 역할기반, PBR, 

 

우상향 대각선---------------------------> 효과 경험 의미 ↑

 

좌상향 대각선 <------------------------ 교육 ↑

 

요구사항 명세서에서 가장 중요한 점 : 사용자 관점

 

Ad hoc : 특별한 준비 없이 일반적으로 사용되는 기법. 검토자에게 리뷰 수행 방법에 대해 안내가 거의 또는 전혀 없다.

검토자의 능력에 크게 의존(누구는 깊이 볼 것이고, 누구는 느리게 보고, 누구는 많이 보고)

등등 따라서 효과가 천차 만별.

 

관점 및 역할기반 : 훈련을 받아한다. 남을 이해하는 것이 쉽지 않음. 따라서 PBR이 나옴

 

검토자 간에 중복 이슈를 줄여야 한다. 그래야 더 많은 영역을 볼 수 있다. 

 

리뷰에서 가장 효과적인 기법이다. 리스크를 기반으로 다양한 이해관계자의 관점을 적절하게

포함시키고 평가하는 것이 중요하다.

 

PBR : 내가 필요한 특정한 관점에 대해 리뷰를 하는데 역할기반이랑 차이점은 

 

2차 3차 산출물을 만들 수 있는 것.

 

시나리오 및 드라이 런:  특정한 결함을 특정한 방법을 통해 추출(?)하는 것?

 

작업 산출물의 예상되는 용도를 기반으로 작성.

 

체크리스트 : 커버리지를 생각해야한다.  체크리스트를 기반으로 이슈를 식별하는 체계적인 기법

 

체계적인 커버리지를 도출.

 

커버리지에는 2가지가 있다. 깊이와 넓이.

 

체크리스트를 만들고 거기에 특정 인원을 배분하고 깊고 넢게 그 부분을 리뷰한다.

 

커버리지 이외에도 볼 려고 노력해야 한다. 

 

ad hoc , 체크리스트 기본적으로 내 의견이 중심이다. 

체크리스트는 좀 더 깊고 넓게 내 의견을 기술. 

 

118p

 

리뷰 성공 요소 : 

 

각 리뷰는 목적이 있어야 한다.  리뷰 유형을 선택해야한다( 워크쓰루, 인스펙션 등등)

 

그리고 나서 리뷰 기법을 선택한다(체크리스트, 역할기반 등등)

 

체크리스트를 사용할 경우 가장 최신 정보를 반영(재사용 하지 않는다.)

 

결함에 대한 피드백은 초기에 그리고 빈번하게 해서 품질 관리를 수행.

 

충분한 여유를 가지고 리뷰 일정을 수립한다. 

 

119p

 

사람과 관련된 성공 요인

 

리뷰 목적 달성  적절한 사람들 참여( 관점이 중요!)

 

리뷰 회의를 잘 관리해 참여자가 리뷰에 참여한 시간이 가치 있다고 인식하게 해야한다.

 

가치가 있다는 것은 학습을 한다는 것. 

 

리뷰 결과를 가지고 참여자들을 평가하면 안 된다. (생각이 다른 것이지 능력과 다르다. 

문제를 많이 지적하고 발견하다고 능력이 있다는 착각을 해서는 안 된다.) 

 

학습 및 적절한 교육이 필요하다. 

 

4장 :

 

테스트 기법  종류 

 

입력 로직(구조) 출력

 

블랙박스 :  행위기법 , 테스트 대상의 내부 구조를 고려하지 않고 입력과 출력에 집중.

ex) 1을 넣으면 1이 나와는 것이 중요. ( 입력과 출력)

 

로직은 화이트박스 : 테스트 대상의 내부 구조와 처리에 집중. 

 

경험기반:

(테스트 , 개발자 , 사용자 다 포함)

명세에 정의 되어 있지 않지만 조직이나 개인의 경험으로 봤을 때 .

 

블랙박스 테스트 기법:

 

입력과 출력이 기반.

 

블랙박스 기법은 크게 2가지로 나눈다.

 

data와 생성과 검증 : 동등 분할 , 경계 값 분석 

 

기능 검증 : 결정 테이블, 상태 전이, 유스케이스

 

134p

 

동등분할  :

 

하나의 인 풋에 하나의 아웃 풋으로 1:1로 대응된다.  즉 중복되는 값이 없다.

 

그렇다면 동등분할을 쓸 수 있다.  그리고 이 명세를 기준으로 정확히 프로그램이 

 

설개되었다(정확히 구현됐다). (프로그래머의 실력이 뛰어나서)

 

유효한 TC 와 유효하지 않은 TC도 포함한다. 

 

이 기법은 단독으로 쓰기 보다는 다른 기법과 같이 쓰인다. 

 

이 기법은 가정이 많아 강력하지 않다. 

 

커버리지와 결함률가 다르다. 

 

 

136p

 

경계 값 분석

 

양쪽 끝 값을 뽑아서 측정 분석. 연속된 데이터로 구성된 경우에만 적용 가능하다.

 

144p 

 

결정 테이블 테스팅:
모든 조건 조합(비지니스 규칙) 을 명세 

 

장점 : 중요한 모든 조건 조합 식별, 요구사항 누락된 부분 식별.

 

어떤 명세의 결과는 binary(0,1) 

 

145p

 

 올바른 계좌, otp 일치, 계좌에 충분한 돈 따라서 2의3승 = 8가지 시나리오

 

따라서 6 x 8 개  결정 테이블 생성.

 

 

151p

 

상태 전이 test는 상태전이 test 다이어그램을 모델로 한다.

 

문법 규칙을 알아야한다. 

 

시스템과 시스템의 상호작용을 그랙픽 언어로 바꾼 것이다.

 

상태: 시간이 주어졌을때 변경이 없이 그대로 가만히 유지되고 있는 것을 상태

 

input 안 이벤트, 액션은 output 

 

152p

 

상태 전이는 상태와 전이가 컨디션이다 .

 

최소 경로는 2개 대기 -> 금액투입 -> 음료선택해서 2개  

 

모든 경로를 한 번씩만 들리면 된다. 

 

 

번외: 절차 - 기대효과  => test case

 

test case가 모인 것이 test case set

 

사람이 셋을 실행하면 프로시져

 

도구가 셋을 실행하면 스크립트

 

이것을 다 합친것을 테스트 스위트 

 

163p

유스케이스 테스팅 :

 

유스케이스를 기본으로 테스팅한다.

 

 

유스케이스 : 사람(액터)과 시스템 간의 상호작용 

 

167p

 

화이트 박스 테스트 기법  

 

구문 테스팅과 커버리지:

코드의 실행 가능한 구문(test condition)을 실행하여 커버리지 측정

 

결정 커버리지:

테스트로 실행한 결정문 결과의 수 / 테스트 가능한 모든 결정문 결과의 수(%)

 

결정이 더 강력하다.

 

173p

 

경험기반 테스트 기법

 

블랙박스, 화이트 박스 가지고는 검증하기 힘든 경우, 명세가 불충분한 경우 사용한다.

 

장애의 목록을 작성하는 것이 중요하다.  

 

175p

탐색적 테스팅 기법:

 

결함이 어딘가 있으나 모른다. 따라서 찾아야 하는데 어떻게 찾는지 모름... 제일 어려운 경우

 

하나 하나 다 해봐야한다.......

 

185p

 

테스트 관리 : 

 

테스팅 작업은 특정 테스팅 역할을 부여 받은 사람이나 다른 역할을 하는 사람도 수행 가능하다

 

 

독립적 테스트의 장점

 

개발자와 다른 유형의 장애를 찾아낼 수 있다. ---> 효과적이다.

 

188p

 

테스트 관리자 : 

전반적인 책임과 테스트 활동을 성공적으로 이끄는 것.

 

테스터: 

테스팅 활동을 하고 있는 모든 사람.

 

190p

 

메트릭이 중요.

 

결함 관리 시스템, 형상 관리 체제, 테스트 프로세스 지원 도구는 

 

T.M이 관리해야한다.  구현, 운용, 유지보수의 책임이 있다.

 

191p

 

테스트 계획을 리뷰하고 계획 작성에 참여한다.