소프트웨어 결함 리포트: 분석

이어지는 시리즈

• 소프트웨어 결함 리포트
• 소프트웨어 결함 리포트: 분석
• 소프트웨어 결함 리포트: 보고
• 소프트웨어 결함 리포트: 내용
• 소프트웨어 결함 리포트: 트랙, 재시험, 마감

 

https://www.ranorex.com/rx-media/rx-blog/header-bug-reports.png

소프트웨어 결함에 대한 분석

근본 원인 찾기

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

재생산 또는 반복할 수 있는지 결정하기

• 재생산은 테스터와 개발자 모두에게 매우 중요!
  • 모든 결함들은 재생산 가능함 - 필요할 때 언제든지 가능한지가 포인트!
• 반복 = 계속 일어나는 것, 원할 때마다 발생하게 할 수는 없으므로 나타날 때까지 기다려야 함
  • 메모리 누수(leaks)가 흔한 예이다
• 로그 또는 로그 분석은 반복되는 결함을 재생산 결함으로 바꿀 수있는 핵심 키다!

결함 분리(isolation) 시도하기

• 분리는 근본 원인을 !
  • 문제가 무엇인지, 어떻게 문제가 일어났는지/일어나지 않았는지는 개발팀이 코드에서 결함 징후를 찾는데에 있어 매우 중요하다

문제에 대한 대체 방안들을 연구하기

• 개발자가 어떤 질문들을 할지 예상하고 대답을 준비하기
• 똑같은 문제에 다른 방식으로 접근할 수 있다면, 너가 한 방식이 이상한 게 아닐지도 모른다. 또한, 뭔가 잘못되었다는 강한 추측을 할 수 있다
• 똑같은 문제에 여러 방법들을 찾는 것은 개발자들에게 매우 중요하다!

 (공식적으로) 리포트할 가치가 있는지 결정하기

• 프로젝트의 어느 단계에 있는지, 문제의 심각성에 의해 결정된다
  • 프로젝트 초기 단계: 테스트 케이스들을 디버깅한다는 것은 모든 것을 결함으로서 리포트 하지 않아도 되는 것을 의미

---

소프트웨어 결함 리포트를 분석하는 것은 적절하게 우선 순위를 매기는데 확신을 준다

• 모든 결함들이 똑같이 생성되는 것은 아니다
  • (개발 중에 만들어진) 결함들의 트랙킹과 (테스팅 단계 마지막 상태에서의) 결함들의 트랙킹은 큰 차이점이 있다!
  • 중요한 것은, 계획을 가지고 따르는 것! 준엄(rigor)의 측정, 통제/점검과정을 통해 품질 확신의 도움을 주는 것
• 결함의 원인을 결정하기
• 결함이 어떻게 분리되었는지에 대한 추가 정보는 중요하다
• 문맥상 중요한 결함들은 리포트할 것!