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

리스크 기반 접근법 리스크 레벨을 조기에 낮추고 이해관계자에게 위험 상태 정보를 제공 제품 리스크 분석 결과 → [사용할 테스트 기법 / 테스트 레벨 & 유형 / 테스트 수행 범위 / 테스트 우선순위] 결정, 리스크 완화를 위한 다른 활동 식별 리스크 기반 테스팅 테스트를 보다 효율적, 효과적으로 수행하기 위한 방법 프로젝트 이해관계자의 집단 지식 & 통찰력을 기반으로 제품 리스크 분석 리스크 식별, 리스크 발생 가능성, 리스크 영향 평가 리스크 정보로 얻은 결과 → [테스트 계획, 명세, 테스트 케이스 준비/실행, 테스트 모니터링] 사용 리스크와 관련된 정의 리스크: 조직에 잠재적 손실; 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성 리스크 레벨: 이벤트 발생 가능성 & 이벤트로 인한 영향도(피해..

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. 모듈들이 적절하게 함께 잘 작동하고 있는지 확인하는 것은 소프트웨어 테스..

유닛 테스팅: 개발자들에 의해 행해지며, 본질적으로 화이트박스 테스팅에 속함. 리스크 기반 접근법으로, 유닛이 궁극적으로 지지하는 상위 레벨 시스템 행동에 집중하기보다는 코드 자체를 공격한다. off-by-one 오류에서 루프의 경계 등을 테스트함. 배열과 그 경계들, 구조상의 또 다른 오류들에도 적용된다. 모듈의 유닛은 그 것의 핵심 기능이 정확한지 확인하기 위해 실행된다. 기능은 유닛 레벨에서 저의되며, 모듈이나 시스템 레벨과는 상관없다. 단위 내부의 결함 제거를 주목적으로 함 구조 기반 (화이트박스 테스트) 설계 기법을 주로 사용 가능한 많은 결함 발견하고자 함 테스트 케이스와 결함을 공식적으로 관리 X (주로, 개발자에게 맡김) 단위 테스트 프레임워크 또는 디버깅 도구의 지원으로 테스트 수행 자동..

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

REVIEW 소프트웨어 테스팅 과정 단계 유닛테스팅: 개발자가 주로 오류발생이 쉬운 구조와 하위수준 기능성 보증을 위해 본인이 작성한 코드를 테스트하는 것 디자인 검증(verification) 테스팅: 개발자에 의해 실행되는 통합 테스팅을 통해 모듈의 통합을 테스트하고, 테스팅팀 또는 개발자에 의해 완성되는 기능성 테스팅을 포함 시스템 검증(validation) 테스팅: 테스트 팀에 의해 행해지며, 시스템이 완성되거나 개발이 거의 끝나갈 때, 시스템의 상위수준의 행동과 비기능적 퍼포먼스를 테스트하는 것 고객 인수 테스팅: 최종 제품을 고객에게 인수 가능(acceptable)한지 고객과 테스팅 팀이 함께 수행하는 테스팅. 디자인 검증(verification)과 시스템 검증(validation) → 테스트 ..

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

유닛 테스팅 개발자가 작성한 코드를 테스트하는 것 오류발생이 쉬운 구성, 하위 수준(low-level) 기능성 보증에 사용 개발자가 프로젝트를 하면서 유닛 테스팅 계획 생성 디자인 검증(Verification) 테스팅 개발자가 모듈의 통합을 테스트하는 통합 테스팅 실행 기능성 테스팅은 개발자들 또는 테스팅 팀에 의해 실행 예. 모든 기능성 요구사항들과 외적 요구사항들을 충족시키면서, 예상대로 기능하고 보기 좋은 유닛들을 많이 만들어낼 수 있는가? 시스템 검증(Validation) 테스팅 테스트 팀에 의해 실행 시스템이 완성되거나 개발이 거의 끝나면, 시스템은 상위 수준(high-level) 행동과 비기능적 퍼포먼스를 테스트 디자인 검증 테스트와 시스템 검증 테스트 계획들은 검증 레벨의 "시스템을 올바르게..