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

총괄(summative) vs. 누적(cumulative) 정보 테스트 상태 리포트 테스트 주기(cycle)가 어떻게 진행되고 있는지 매(each) 주기 끝에 생성한다 → 테스팅 과정 중에 보고되며, [테스팅 주기, 폭포수 모델과 같은 단계 게이트(phase-gate) 프로세스, 애자일 또는 스크럼에 기초하는 스프린트]를 어떻게 정의하였는지에 따라 관계자에게 상태 업데이트를 지속적으로 보고함으로써, 테스팅이 어떻게 실행되는지 알린다. 현재 노력(effort)과 계획된 노력을 비교하여, 프로젝트 매니저가 프로젝트 & 과정 & 리스크에 관해 파악할 수 있게 한다. 더보기 스프린트 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻. 스크럼 스크럼 개발 프로세스는 소프트웨어 개발보다는 팀의 개선..

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) 행동과 비기능적 퍼포먼스를 테스트 디자인 검증 테스트와 시스템 검증 테스트 계획들은 검증 레벨의 "시스템을 올바르게..

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