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

Q. _____________는 생태계를 제공한다. 더보기 A. 테스트 더블 Q. 모의 객체와 스파이 객체는 시험 대상 시스템에 대한 세밀한 모니터링을 허용한다. 더보기 A. True 모의 객체와 스파이 객체는 시스템 내 또는 다른 시스템들 사이의 상호작용을 가까이 관찰할 수 있게 한다. Q. 모의 객체와 스파이 객체를 사용한 테스팅에서 상호작용의 한 부분이 아닌 것은? 더보기 A. 필요한 입력값들은 시험 대상 시스템을 위해 생성된다. (X) → 더미 객체, 테스트 스텁, 페이크 객체 메소드가 호출 되었는지/안 되었는지 (O) 메소드 호출에 적절한 파라미터들이 사용되었는지 (O) 올바른 순서대로 메소드가 호출되었는지 (O) Q. __________ 객체는 페이크 객체들의 상호작용을 관찰할 수 있게 한다...

Q. 테스트 더블을 위한 테스트 입력값을 제공할 때, _________와 __________을 사용한다. 더보기 A. 더미 객체; 테스트 스텁 입력값 - 더미 객체, 테스트 스텁 출력값 - 모의, 스파이 객체 Q. 테스트 더블을 구성하면서, 많은 값들에 대한 결과값을 제공하길 바란다. 무엇을 사용하겠는가? 더보기 A. 테스트 스텁 테스트 스텁은 여러 값들에 대한 결과값을 제공한다. Q. 테스팅 중에 유닛 테스트가 값비싼 데이터베이스 사용을 필요로 하는 것을 알았다. 어떤 것을 테스트 더블로서 사용할 것인가? 더보기 A. 페이크 객체 페이크 객체는 값비싼 것을 저렴한 것으로 대체한다. 예) 인메모리 데이터베이스 Q. Mockito에는 어떻게 구성했는지에 따라 클래스가 행하는 역할들 사이의 차이점이 있다. ..

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

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) 결함을 처리하는 과정의 단계가 결함을 무시 할 것 같진 않다. 분석(예. 버그지만 이에 대해 아무것도 하지 않음)의 결과일지도 모르지만, 모든 결함 사이클의 단계는 아니다.