QA의 작업 산출물을 알기 힘들다는 이유로 테스트 케이스나, 버그 리포트 등을 그 기준으로 삼을 수 있다. 그러나 이는 크나큰 결점을 안고 간다. 애초에 테스트 케이스의 양은 같은 내용을 쓰더라도 작성자 성향에 따라 얼마든지 늘이고 줄일 수

주관성을 최소화하고 고객과의 상호 작용 과정을 객관적으로 평가할 수 있는 기준은?3) 결과를 통해 어떤 액션 플랜을 설계할 것인가?- 어떤 내용을 공유하고 어떻게 피드백할 것이며 추후 매뉴얼은 어떻게 만들 것인가? 이 3가지 과정은 QA를 하

원활한 정보 수집을 위해서라도 평소 많이 소통해 놓는 것이 중요하다. QA와 개발자QA에게 개발자들은 가장 많은 대화를 나눠야 하는 파트너다. QA는 개발자가 만든 빌드에서 업무를 진행해야 하고, 개발자는 QA가 전달한 다양한 메시지들을 통해 빌드를