시간이 지남에 따라 수동 테스트는 스크럼과 같은 유연한 방법론에 맞게 조정되었습니다. 처음에 테스터들은 "스프린트의 끝"에서 작업 결과를 테스트했습니다. 이는 종종 긴급 상황과 부족한 테스트를 초래했습니다(문제).
주요 문제는 테스트 시간 부족, 요구 사항의 잦은 변경, 스프린트 기간 중 테스터에게 전달되지 않는 작업입니다. 테스터들은 압박을 받게 되어 품질이 저하됩니다(문제).
해결책은 스프린트의 시작부터 테스터를 팀에 통합하는 것입니다: 회의에 참여하고 새로운 작업이 생길 때마다 테스트 케이스를 계획하며 함께 매일 스탠드업과 회고를 진행하고, 테스트 아티팩트의 상태가 투명하게 유지되도록 돕는 것입니다(해결).
주요 특징:
스프린트의 모든 작업이 끝난 후에만 테스트를 시작할 수 있습니까?
아니요, 테스터는 스프린트의 첫날부터 참여해야 하며 가능한 한 미완성 기능도 테스트해야 합니다.
모든 버그는 현재 스프린트에서 수정해야 합니까?
반드시 그렇지는 않습니다. 치명적인 버그는 그렇지만 비치명적인 버그는 외부 백로그로 이동되어 다음 스프린트에서 수정될 수 있습니다.
스크럼에서 자동화가 있는 경우 수동 테스트가 필요합니까?
예, 수동 테스트는 새로운 기능 및 비형식적 요구 사항 검증, 탐색적 테스트에 매우 중요합니다.
테스터는 계획에 참여하지 않았고 스프린트가 끝날 때까지 새로운 작업 스트리에 접근할 수 없었습니다. 결과적으로 테스트는 급하게 작성되었고, 일부 버그는 다음 스프린트로 연기되었습니다.
장점:
단점:
테스터는 스프린트의 첫 날부터 팀에 참여하여 회의에 참석하고 발생하는 작업을 미리 보며 개발과 함께 테스트를 계획했습니다.
장점:
단점: