질문의 역사:
소프트웨어의 복잡성이 증가함에 따라 버그의 일부가 테스트 케이스나 사양 바깥에서만 발견된다는 것이 관찰되었습니다. 이러한 버그는 실제 사용자에게 가장 중요할 수 있습니다. 테스트 담당자는 표준 테스트와 개인의 경험을 결합하여 이러한 결함을 찾기 위해 특별한 기술을 사용합니다.
문제:
상호 작용하는 구성 요소, 비명백한 상황에 대한 잘못된 처리 또는 요구 사항의 부재와 관련된 숨겨진 버그를 발견하고 기록하는 것은 가장 어렵습니다. 종종 테스터는 "TЗ에 명시되지 않았다면" 발견된 문제를 문서화해야 할지 확신하지 못합니다.
해결책:
탐색적 테스트, 페어 테스트 방법 및 유사한 제품에 대한 경험을 사용합니다. 이러한 버그는 최대한 자세하게 문서화해야 합니다: 단계, 관찰 결과, 왜 결함으로 간주하는지, 관련 요구 사항이나 수용된 논리에 대한 링크.
핵심 사항:
요구 사항에 설명되지 않은 버그는 문서화하지 않거나 무시할 수 있습니까?
아니요, 정확한 요구 사항 링크가 없더라도 항상 보고해야 하며, 그렇지 않으면 중요 문제가 고객에게 전달될 수 있습니다.
사용자 불편은 버그인지 아니면 개선 요청(기능 요청)인가요?
행동이 명백히 비논리적이거나 혼란을 초래하거나 위험을 초래하는 경우, 버그로 기록하고, 그렇지 않으면 개선으로 기록합니다.
테스터가 각 비명백한 버그에 대해 팀과 상담해야 합니까?
논란이 있는 사례는 무의미한 티켓을 피하기 위해 사전 논의하는 것이 좋습니다.
테스터는 두 개의 창을 동시에 열면 시스템이 멈춘다는 것을 발견했지만, 해당 시나리오가 요구 사항 및 테스트 케이스에 설명되지 않았기 때문에 버그를 기록하지 않았습니다.
장점:
단점:
테스터는 두 개의 창을 여는 단계와 행동 순서를 설명하여 버그를 기록하고, 스크린샷을 첨부하며, 왜 이것이 버그라고 생각하는지 설명했습니다(실제 사용자는 이 상황에 처할 수 있습니다).
장점:
단점: