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

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 테스팅 중 발견한 결함 반드시 기록! 결함은 [코드 작성 중, 정적 분석, 리뷰, 동적 테스팅, 제품 사용 중] 에 보고 가능 결함은 [코드나 운영 중인 시스템 & 요구사항, 사용자스토리 & 인수조건, 개발 문서, 테스트 문서, 사용자 메뉴얼, 설치 가이드]와 같은 문서에서 이슈로 보고 가능 소프트웨어 결함 보고 1. 중복되지 않는지 확인 → 이미 보고된 문제가 아닌지 (검색 가능 결함 트레킹 시스템) 2. 개발자와 상의 → 개발자가 결함 리포트에 입력하지 않도록 설득하지 못 하게 하기! 3. 시스템에 입력 → 결함 트레킹 시스템..

Q. 분석의 한 부분은 결함의 잘못이 어디서 나왔는지를 찾아내는 것이다. 그 잘못은 어디에 책임이 있을 수 있는가? 더보기 A. 테스트, 테스터, 프로덕트 Q. 재생산성과 반복성은 결함에 있어서 같은 맥락이다. 더보기 A. False Q. 모든 결함들은 똑같이 생성되지 않는다. 더보기 A. True

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함에 대한 분석 근본 원인 찾기 누구의 잘못인지 찾기 - 테스트? 테스터? 제품? 테스트가 잘못되었는지? 테스트를 제대로 실행하지 않은 테스터의 잘못인지? 실행 시스템에 관해 잘못 추정했는지? 제품을 잘못 구축했는지? 검증(verification) 실패하면, "올바르게" 구축할 수 있는지? 검증(validation) 실패하면, "올바른" 제품을 구축할 수 있는지? 테스터는 분석 먼저! 개발자는 테스터들이 테스트 결함들을 사전 협의없이 넘겨주게 하지 말 것! 결함에 대한 분석이 포함되어있고, 몇몇의 작업자 오류들은 허용..

Q. 오직 절반 정도의 테스팅 노력(effort)은 실제 테스팅에 쓰인다. 더보기 A. True Q. 소프트웨어 결함 사이클의 단계에서 포함되지 않는 하나를 고르세요. 더보기 A. 분석, 보고, 상태 추적, 버그 재시험, 버그 마무리 (O) 버그 무시 (X) 결함을 처리하는 과정의 단계가 결함을 무시 할 것 같진 않다. 분석(예. 버그지만 이에 대해 아무것도 하지 않음)의 결과일지도 모르지만, 모든 결함 사이클의 단계는 아니다.

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 2가지 핵심적 이해 테스팅의 목적은 오류를 찾는 것만이 아닌 고치는 것이다 결함 리포트의 라이프 사이클과 구성요소를 이해하는 것은 개발과 테스팅 사이의 소통에 있어 도움이 된다 소프트웨어 결함 리포트의 목적 - 발생한 모든 부정적인 이벤트 정보를 개발자 & 기타 관계자에게 제공해 구체적 영향 식별, 재현 테스트로 문제 격리, 잠재 결함 수정, 필요에 따라 다른 문제 해결 방법 구상 - 테스트 관리자에게 작업산출물의 품질과 테스팅 영향을 추적할 방법을 제공 - 개발 & 테스트 프로세스 개선에 대한 아이디어 제공 소프트웨어 결함 리포..

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. 독립적이다, 격리되어있지