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

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

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 ..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 과정 분석 리포트 트랙 재테스트 종료(Close) 결함 트래킹 과정을 가지기 결함 리뷰 보드에 의해 다뤄지기 독립적으로 결정을 내리게 한다면, 실수가 생길 수 있는 환경을 만들게 됨 보드에 리드 테스터(또는 모든 테스터)를 포함하기 이해관계자, 개발 및 관리팀, 비지니스 분석과 데이터베이스팀도 포함된다 결함들에 진전이 있는지 확인하기 결함 재테스팅 개발팀이 결함을 가져갔고, 리서치했으며, 해결 표시를 하였다면 → 해결되었는지 재테스트 한다! 재테스트는 3가지의 결과를 가지고 있다 문제가 실제로 해결되었다 종..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 구성요소 정보 식별 문제 설명 다양한 상태 지표(indicator) 주석(comments) 기타 정보 지원 정보 정보 식별 고유 번호 또는 ID 트레킹 시스템이 있을 경우, 자동으로 ID 부여 / 없을 경우, 수동으로 번호 지정 제출자 어떻게 제출자를 트랙할 건지에 따라 결정한다. 오픈 시스템인 경우, 사용자들도 제출자가 될 수 있음 제출 일자 결함이 얼마나 오래 됐는지 알 수 있음 이에 반하는 프로그램 또는 제품 제품 버전 또는 개정(revision) 문제 설명 제목 - 최소한의 단어수로 문제를 이해할 ..

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