자동화 테스트 생성을 시작해야하는 애자일 (SCRUM) 단계는 무엇입니까?

나의 작은 배경-나는 SCRUM (1-2 주 스프린트)을 사용하는 민첩한 환경에서 거의 2 년 동안 수동 테스터입니다. 그래서 Selenium WebDriver (Java 포함)를 사용하여 작업에 자동화 테스트를 도입하고 싶습니다.

내 질문은 기능을 수동으로 테스트해야하는시기와 자동화 테스트를 위해 언제 변환해야합니까?

나는 다음과 같은 다른 접근법을 읽고 얻었습니다.

1. 새로운 스프린트가 시작되면 사용자 스토리를 이전 스프린트의 자동 스크립트로 변환하십시오.
2. 동일한 스프린트 내에서 사용자 스토리를 변환하십시오.

모든 조언 / 감사합니다. 미리 감사드립니다.

테스트 자동화 (및 기타 모든 테스트)는 done 정의의 일부 여야합니다 . 이것은 잠재적으로 선적 가능한 제품을 만들기 위해. 테스트하지 않은 상태로 배송 할 수 있습니까?

테스트는 전체 팀 접근 방식이므로 테스트 자동화는 테스터 책임이 아닙니다. 프로세스에서 가능한 빨리 테스트에 대해 생각 하십시오 .

애자일에서 테스트 자동화는 다음과 같은 이유로 매우 중요합니다.

조직의 민첩성은 기술적 민첩성에 의해 제한됩니다

즉, 제품을 변경하는 데 시간이 오래 걸리면 팀, 조직 또는 채택한 프레임 워크를 어떻게 구성하든 관계없이 변경에 느리게 응답합니다.

https://less.works/less/technical-excellence/index.html

다른 반복까지 테스트를 연기하면 항상 뒤쳐 질 것입니다. 제품 의 외부 동작 을 리팩토링 하고 안전하게 보호 하기가 어렵 기 때문에 제품의 방향을 변경하기가 어렵습니다 . 반복적 인 수동 테스트를하는 것이 속도를 늦추기위한 핵심입니다.

많은 테스터들이 제품 인터페이스가 안정 될 때까지 엔드 투 엔드 테스트를 시작해서는 안된다고 말합니다. 기다리지 말고 대신 PageObjects를 잘 활용 하고 테스트가 유지 보수 가능한지 확인하고이를 작성하고 수정하는 개발자 책임으로 만드십시오.

중요한 것은 해당 스토리에 대한 자동화 된 테스트를 작성하지 않은 한 스토리를 완료로 표시하지 않는 것입니다.

따라서 이전 스프린트에서 완료된 작업에 대한 테스트를 작성함에 따라 1이 나오지 않은 것 같습니다. 테스트가 실패하면 어떻게 되나요?

코드 작성과 동일한 스프린트로 자동화 테스트를 작성하는 것이 이상적입니다. 자동화 된 테스트가 작성 될 때까지 코드를 "완료"로 간주해서는 안되며 스프린트가 끝날 때까지 "완료"상태로 코드를 가져와야합니다.

코드를 이해하고 테스터로서의 요구를 이해하도록 개발자와 협력하여 스프린트 첫 날 프로세스를 시작해야합니다. 예를 들어, 웹 페이지를 작성하는 경우 상호 작용해야하는 모든 페이지 요소에 고유 식별자를 추가해야한다는 것을 이해하도록 도울 수 있습니다.

스크럼에서 작업은 테스트를 작성하지 않아야합니다. 당신의 임무는 스프린트 목표를 달성하기 위해 팀과 협력하는 것입니다. 이는 스프린트 초기에 발생해야하는 커뮤니케이션 및 협업을 의미합니다. 코드를 테스트 할 준비가되기 전에 테스트 디자인 및 테스트 계획에 대한 작업을 시작할 수 있습니다.

자동으로 테스트하려는 경우 테스트를 미리 만들 수도 있습니다. 이를 통해 예상되는 동작을 정의하고 클라이언트처럼 생각하도록 자극 할 수 있으며 결국 소프트웨어를보다 유용하게 사용할 수 있습니다. 또한 기능을 구현하는 즉시 테스트의 혜택을 누릴 수 있습니다.

둘 중 하나를 수행 할 수 있지만 일반적으로 자동화 테스트를 사용하여 회귀 테스트를 대상으로합니다. 그것은 회귀 테스트에 충분히 견고 할 때까지 수동으로 수행한다는 것을 의미합니다. 이것은 일부 기능에 대한 스프린트의 중간에있을 수 있으며 다른 기능에 대한 향후 스프린트에있을 수 있습니다.

다른 답변 에서 언급 한 바와 같이 , 테스트가 발생할 때 완료 정의의 일부가되어야합니다 . 그러나 나는 그 대답 중 일부에 동의하지 않기 때문에 내가 경험 한 경험으로 확장하고 싶었습니다.

진정으로 민첩한 환경에서 모든 사람이 모든 것을 할 수 있습니다. 테스트에 전념하는 사람은 100 %가 아니며, 기본적인 UI 작업 또는 기타 작업에 도움이되는 기술을 개발할 수도 있습니다. 그러나 우리는 거의 이상적인 세상에 살지 않습니다.

내가 추천하는 것은 약간의 하이브리드 접근법을 수행하는 것입니다. 완료 정의에 대해 수동 테스트는 작업이 코딩 된 스프린트의 일부 여야한다고 말합니다. 스프린트가 끝나기 전에 버그가 즉시보고되고 수정 될 수 있으므로 다음 코드를 계획 할 수 있습니다. 하나. 수동 테스트에 중점을두면 코드의 기능에 익숙해집니다. 할 일이 많지 않은 다음 스프린트의 시작 부분에서, 회귀 오류를 방지하기 위해 빌드 프로세스의 일부로 실행할 수있는 자동화 된 테스트를 설정할 수 있습니다.