테스트 케이스 작성은 수동 테스트의 기초 중 하나이며 애플리케이션의 기능을 검증하는 핵심 단계입니다.
질문의 역사: 오랫동안 테스트 케이스는 품질 보증의 중심 방법이었으며 요구 사항 검증을 구조화하고 테스트 담당자가 변경되더라도 테스트의 반복 가능성을 보장합니다.
문제: 주요 어려움은 지나치게 세부적으로 작성된 것과 부족한 작업 사이의 균형입니다. 지나치게 상세한 케이스는 테스트를 일상적이고 느리게 만들고, 너무 간결한 경우 중요한 시나리오를 놓칠 수 있습니다. 자주 발생하는 문제는 다음과 같습니다:
해결책: 효과적인 테스트 케이스를 위해 필요한 사항은:
주요 특징:
항상 테스트 케이스가 개발 전에 작성되나요?
아닙니다. 테스트를 실제 구현 전에 작성하는 것이 바람직하지만(shift-left) 실제로는 종종 새로운 정보가 들어오거나 테스트 환경이 구축된 후에 테스트 케이스가 수정됩니다.
하나의 테스트 케이스가 하나의 시나리오만 검사해야 하나요?
예, "하나의 테스트 - 하나의 결과"라는 고전적인 원칙은 버그 분석과 테스트된 내용을 이해하기 쉽게 만듭니다. end-to-end 시나리오의 경우 예외가 있을 수 있지만, 이러한 경우에도 예상되는 결과를 명확히 구분하는 것이 중요합니다.
요구 사항에서 자동으로 생성한 테스트 케이스를 완전히 신뢰할 수 있나요?
아닙니다. 이러한 케이스는 종종 표면적이며 중요한 비즈니스 로직, 경계 값 또는 행동 조합을 놓칠 수 있어 수동 분석이 필요합니다.
팀은 오래된 테스트 문서를 검토 없이 가져와 변경된 기능에 맞지 않는 테스트 케이스를 사용했습니다.
장점:
단점:
테스터는 테스트 케이스를 재검토하고 분석가와 어려운 점을 논의하며, 오래된 것을 정리하고 새로운 팀과 함께 리뷰를 수행했습니다.
장점:
단점: