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

Q. 유닛 테스트를 완료하기 위해 테스트 대상 시스템이 다른 시스템들과 상호작용해야 한다면, 테스팅을 생략한다. 더보기 A. False 거짓 생태계에서 유닛테스팅을 하는데에 있어 도움이 될 수 있는 전략이 있다. 이러한 이유로, 테스팅을 생략하지 말 것! Q. 유닛 테스팅을 하기 위해 필요하며, 테스트 대상 시스템과 상호작용하는 컴포넌츠들의 가벼운 버전을 명칭하는 것은? 더보기 A. 테스트 더블 Q. 테스트 대상 시스템에 의해 파라미터로서 필요한 객체를 채우는 더미값을 무엇이라고 하는가? 더보기 A. 더미 객체 Q. 테스트 대상 시스템이 사용하는 더미 입력 데이터 소스는 무엇인가? 더보기 A. 테스트 스텁 특정 시스템 컴포넌트의 개발이 완료되지 않은 상황에서도 필요한 시험을 진행하기 위해 생성된 더미 컴..

이어지는 시리즈 테스트 더블: 소개 테스트 더블: 입력값 테스트 더블: 출력값 테스트 더블 (= 영화 스턴트 대역) 시험 대상 시스템(SUT)을 지정하는 클래스 또는 시스템을 테스트하기 위해 필요한 컴포넌트들의 단순화된 버전 테스트 더블을 생성하는 이유? 컴포넌트들이 아직 완성되지 않음 컴포넌트들을 구성하는데 많은 비용이 들어감 컴포넌트들이 제 3자에 의해 소유되어있음 테스팅의 결과로 실제 컴포넌트들에 부작용이 생기는 것을 피하기 위함 항상 잘 실행되지는 않지만 어쩔 때는 괜찮은 테스트(Flakey Tests)들을 방지하는데 도움을 줌 시험 대상 시스템을 세밀한 관찰을 허용함(테스트 결과뿐만이 아닌 컴포넌트들의 상호작용) 테스트 더블은 생태계를 제공한다 더미 객체: 테스트 대상 시스템에서 파라미터로서 필..

Q. 결함을 추적하는데 있어서, 가장 중요한 점은 과정을 가지고 그 과정을 따르는 것이다. 더보기 A. True Q. 재테스팅 단계에 의해 도달하는 결론이 아닌 것은? 더보기 A. 문제 해결됨 (O) 문제 변함없음 (O) 문제가 새로운 문제로 대체됨 (O) 문제 해결할 수 없음 (X) Q. 테스팅과 검증(verification) 노트들은 어느 카테고리에 속하는가? 더보기 A. 종료(Close) 추적(Track) - X, 재테스트(Retest) - X

Q. 소프트웨어 결함 리포트 내용은 6가지 메인 구성요소들로 이루어져 있다. 다음 중 해당되지 않는 것은? 더보기 A. 정보 식별 (O) 문제 정의 (O) 상태 지표 (O) 주석 (O) 기타정보 (O) 지원정보 (O) 관련된 결함 리포트 (X) Q. 결함 식별 번호가 포함되어 있는 구성요소는 무엇인가? 더보기 A. 식별 정보 (Identification Information) Q. 문제 개요와 무엇을 했는지, 그 행동의 결과를 포함하는 구성요소는 무엇인가? 더보기 A. 문제 정의 (Description of the problem) Q. 결함 리포트를 작성하는 가정 하에, 이 결함은 중간(medium) 심각성의 영향을 미치고 있다. 이러한 정보를 포함하는 구성요소는? 더보기 A. 상태 지표 (Status ..

Q. 보고 단계는 4개의 메인 단계들로 구성되어있다. 그 중 속하지 않는 것은? 더보기 A. 개발자들이 결함을 보고할지 안할지 결정하게 하기 (X) 결함이 중복되지 않도록 확인하기 (O) 결함이 고쳐졌는지 확인하기 (O) 시스템에 결함을 입력하기 (O) 개발자들과 상의하기 (O) Q. 효과적인 결함 리포트의 특성은 무엇인가? 더보기 A. 번호 또는 ID 매기기 (O) 간단한 (O) 글로 작성된 (O) 완성된 (O) 이해가능한 (O) Q. 결함 보고서에 결함을 재생산하는 최소한의 단계를 포함해야한다. 더보기 A. True

Q. 분석의 한 부분은 결함의 잘못이 어디서 나왔는지를 찾아내는 것이다. 그 잘못은 어디에 책임이 있을 수 있는가? 더보기 A. 테스트, 테스터, 프로덕트 Q. 재생산성과 반복성은 결함에 있어서 같은 맥락이다. 더보기 A. False Q. 모든 결함들은 똑같이 생성되지 않는다. 더보기 A. True

Q. 오직 절반 정도의 테스팅 노력(effort)은 실제 테스팅에 쓰인다. 더보기 A. True Q. 소프트웨어 결함 사이클의 단계에서 포함되지 않는 하나를 고르세요. 더보기 A. 분석, 보고, 상태 추적, 버그 재시험, 버그 마무리 (O) 버그 무시 (X) 결함을 처리하는 과정의 단계가 결함을 무시 할 것 같진 않다. 분석(예. 버그지만 이에 대해 아무것도 하지 않음)의 결과일지도 모르지만, 모든 결함 사이클의 단계는 아니다.

Q. 리스크를 줄이는 행동을 가르키는 말은: 더보기 A. 리스크 완화(mitigation) Q. 리스크 등식은: 더보기 A. 리스크 = 영향도(impact) x 가능성(likelihood) 돈의 액수(영향도) x 확률(가능성) Q. 손실 관리가 흔쾌히 허용되는 정도는: 더보기 A. 리스크 수용범위(appetite) Q. 리스크 영향도에 관해서, 영향도의 깊이는: 더보기 A. 데미지의 심각성 (O) 영향받은 사람/시스템의 수 (X) 데미지 비용 (X) 모듈 사이즈 (X) 영향도의 깊이는 데미지의 심각성과 해결방안의 이용가능성으로 측정하며, 너비는 영향받은 사람/시스템의 수와 데미지 비용으로 측정된다. Q. 리스크를 고려해볼때, 영향도의 분류를 고려하는 것이 중요하다. 그 예로 해당되지 않는 것은? 더보기 ..