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

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

Q. 테스트 (상태) 리포트의 한 부분이 아닌 것은? 더보기 A. 테스트 케이스 코드 (X) 미해결된 결점들 (O) 테스트된 것들 (O) 테스트되지 않은 것들 (O) Q. 모든 테스팅이 끝났을 때, 보고되는 테스트 리포트는 최종 리포트뿐이다. 더보기 A. False 상태 리포트도 포함되어야 한다. Q. 테스트 (상태) 리포트는 중요하다. 왜냐하면: 더보기 A. 관리팀이 리스크를 더 잘 관리할 수 있도록 한다 (O) 마케팅팀이 고객들에게 업데이트를 제공하고, 고객 기대를 관리할 수 있게 한다 (O) 검시(postmortem) 평가들을 통해 과정 향상에 도움을 준다 (O) Q. 테스팅은 그러나 개발과 않다. 더보기 A. 독립적이다, 격리되어있지

Q. 유닛 테스팅은 적은 양의 코드(function 또는 클래스)로 개발자들에 의해 실행되는 화이트 박스 테스팅이다. 더보기 A. True Q. 유닛테스팅에 속하지 않는 것은? 더보기 A. 배열의 경계를 테스팅 (O) off-by-one 에러를 위해 루프의 경계를 테스트 (O) 에러가 나기 쉬운 구조들 (O) 모듈 통합 테스팅 (X) 유닛 테스팅은 전체 모듈에 행해지는 것이 아니고, 코드의 작은 부분들에 시행된다. Q. 디자인 검증 테스팅은 두가지의 특성을 가지고 있다: 통합 테스팅, 기능성 테스팅 더보기 A. True 통합 테스팅은 모듈들이 함께 잘 작동하는지를 테스트하고, 기능성 테스팅은 그 모듈들이 유용한지를 테스트한다. Q. 모듈들이 적절하게 함께 잘 작동하고 있는지 확인하는 것은 소프트웨어 테스..

Q. 추적성표(traceability matrix) 또는 필요조건(requirements)표에 관한 설명 중 틀린 것은? 더보기 A. 놓친 필수요건들을 리스트할 것이다 (X) 테스트되지 않은 필수요건들을 찾는데 도움이 된다 (O) 필수요건들에 묶이지 않는 테스트 케이스들을 발견하는데 도움이 된다 (O) 추적성표는 알려진 필수요건들이 어떻게 테스트되는지 결정한다. 놓친 필수요건들이 있는지는 결정하지 않는다. Q. 테스트 계획의 염려 또는 리스크들을 고려해볼 때, 가능하면 예방하는 것이 중요하다. 더보기 A. True 테스트 계획에 결함이 있는 것을 안다면, 결함들은 고려되어야 한다. 예를 들어, 만약 필수요건들이 미완성이거나 테스트함에 있어 관리팀의 서포트가 없다면, 늦기전에 빨리 문제들을 고치는게 낫다...

Q. 유닛 테스팅 계획은 항상 공식적인 문서로 생성된다. 더보기 A. 거짓 유닛 테스팅 계획은 종종 공식적인 문서가 아니다. 프로젝트를 하면서 개발자에 의해 세워지는 계획이다. Q. 어떤 테스트가 올바른 제품을 설계하는지 안 하는지 결정하는가? 더보기 A. 고객 인수 테스트 (Customer Acceptance Test) 고객 테스팅은 개발자와 고객 사이에서 행해진다. 고객에게 최종 제품이 허용되는지 확인한다. Q. 시스템 검증 테스팅은 오류가 발생하기 쉬운 구조와 하위 수준 기능들의 보증에 대해 테스트 한다. 더보기 A. 거짓 시스템 검증 테스팅은 상위 수준 행동들과 비기능적 퍼포먼스를 테스트한다. 유닛 테스팅은 오류가 발생하기 쉬운 구조와 하위 수준 기능을 개발자가 테스트하는 것이다. Q. 품질 보증..

Q. 변이테스팅에 대해 틀린 것은? 더보기 A. 변이테스팅은 얼마나 많은 코드 구조가 커버됐는지 알 수 있다. (X) 변이 적절 점수는 테스트의 퀄리티를 보여준다. 점수가 높을수록, 테스크 케이스들의 퀄리티가 높다. (O) 변이는 변이로 인한 결과값과 오리지널 프로그램의 결과값의 구별할 수 있을 때 삭제된다.(O) Q. 변이테스팅에 대해 틀린 것은? 더보기 A. 변이 연산자는 변이가 컴파일 될 수 없도록 프로그램을 구문상변화(syntactic change)를 시킨다. (X) 변이테스팅에서 하나의 변이만 생설 할 수 있다. (X) 변이와 오리지널 프로그램은 구문상(syntactically)으로 다르다. (O) 변이 연산자는 구문상변화를 주지만, 결과변이(resulting mutant)는 구문상으로 맞아야하..

Q. 구조 기반 기법은: 더보기 A. 화이트박스 테스팅이다. 구조 기반 기법은 코드의 내부 구조에 기반하여 테스트를 작성한다. Q. 구조 기반 기법에 대해 틀린 것은? 더보기 A. 테스팅의 목적은 버그가 없는 것을 확인하기 위해 100% 구조적 커버리지를 달성하는 것이다. (X) 대부분 상황에서, 구조적 커버리지가 100%를 되게 하는 것은 실행 불가능하다. (O) 구조적 테스팅은 화이트 박스 테스팅이다. (O) 구조적 커버리지 조건은 테스트의 적절함을 측정하기위해 코드의 구조를 사용한다. (O) 100% 커버리지는 방어적인(defensive) 프로그래밍으로 인해 불가능할 지도 모른다. 어떠한 구조적 커버리지 기준에서도 100% 커버리지를 달성하는 게 버그가 없다는 것이라고 확신하지 않는다.

Q. Validation과 Verification의 차이점은: 더보기 A. Validation은 올바른 제품을 만들고 있는지를 확인하고, Verification은 제품을 올바르게 만들고 있는지 확인한다. V-모델에서, Validation은 사용자 필요조건 단계에서 계획되고, Verification은 사용자 스펙(specification) 단계에서 계획된다. Q. V-모델에 따르면, 시스템은 verification 단계를 지났다라는 것은 무슨 의미인가? 더보기 A. 시스템은 유닛 테스팅부터 verification 테스팅의 테스트들을 다 통과했으며, 이제 validation 테스팅을 위해 준비됐다. 시스템은 사용자로부터 행해지는 validation 테스팅을 위해 준비되었다. Q. V-모델에 따르면, 유효한(..