테스터가 작업을 자동화해야합니까?

테스트 프로세스를 설정하려고합니다. 테스터가 자동 회귀 테스트를 개발해야하는지 또는 개발자가 그렇게해야하는지 궁금합니다.

그리고 다른 유형의 자동 테스트는 어떻습니까? 테스터가 개발해야합니까?

테스터는 자동화 된 테스트를 개발해야한다고 말합니다. 코드에 대한 "외부 쌍용"접근 방식이 있으며 생각하지 않은 버그를 발견 할 것입니다. .

또한 기능 요구 사항에 대한 이해는 개발자에 대한 이해보다 높을 수 있으므로 프로그래머에 대한 하드 코어 저수준 지식 사이에 있지만 BA보다 높은 수준은 아닙니다.

자동화 할 수 있으면 자동화하십시오.

자동화 할 수없는 것을 테스터에게 무료로 제공하십시오. 새로운 버그를 발견했을 때 자동화되어 자동화 된 테스트에 추가 될 수 있다면 추가하십시오.

제 생각에 개발자와 테스터는 다양한 유형의 테스트를 담당합니다.

논리를 작성하는 동안 개발자는 단위 및 통합 테스트도 작성해야합니다. 이를 통해 개발자는 지금까지 작성한 내용이 의도 한대로 작동하는지 확인할 수 있습니다. 또한 이러한 테스트는 개발자가 향후 변경을 수행 할 때 계속 실행됩니다. 논리가 완성되면 개발자는 사양을 이해하고 테스터에게 전달할 수있는대로 작성된 내용이 작동하는지 확인할 수 있습니다.

이 시점의 테스터는 비즈니스 로직이 의도 한대로 작동하는지 확인하는 시스템 전체 테스트를 작성해야합니다.

개발자가 코드에 너무 많이 첨부되어 있으면 테스터는 개발자의 테스트를 정리할 수 있지만 그 반대의 경우는 아닙니다.

내 경험상 테스터가 테스트 케이스를 설정하고 자동으로 실행하는 방식은 실제로 개발자가 수행하는 방식과 다릅니다. 테스터는 테스트 사례에서 최대한의 정보를 얻는 방법, 테스트를 빠르게 실행하는 방법, 테스트를 유지 관리하는 방법 등에 대해 더 많이 생각할 것입니다. 가장 중요한 것은 테스터가 개발자가 놓칠 수있는 테스트 범위의 미묘한 차이를 보게 될 것입니다.

테스트 개발 리소스가 부족하면 개발자가 도움을 줄 수 있지만 테스터는 작업을 신중하게 검토해야합니다. 개발자는 실제 테스트 사례를 작성하기 전에 조명기 및 테스트 도구에 대해 작업해야하며 개발자는 자신의 코드에 대해 테스트 사례를 작성해서는 안됩니다. 개발자가 테스트에 도움을 주면 특권이 있습니다. 개발자가 다른 제품에 노출되면 테스트를 통해 더 나은 개발자가 될 수 있습니다. 그러나 하급 개발자의 작업이 코드 검토없이 진행되지 않는 것처럼 개발자의 QA 작업은 더 많은 테스트 경험이있는 사람으로부터 QA 검토를 받아야합니다.

추가 편집 : 나는 5 년의 경험을 가진 SDET입니다. 나는 각각 10 년 이상의 경험을 가진 훌륭한 개발자들과 함께 일하고 있으며, 최근 병목 현상을 해결하기 위해 그들과 협력하고 있습니다.

제가 실제로보고 싶은 것은 테스터를위한 견고한 자동화 도구입니다. 테스터는 테스트 스크립트를 통해 진행 상황을 효과적으로 기록한 다음 나중에 해당 스크립트를 자동으로 실행할 수 있습니다. 특히 테스터가 직접 모든 스크립트를 거치지 않고도 다른 운영 체제 버전에서 동일한 스크립트를 쉽게 실행할 수있는 경우.

불행히도, 내가 작업하는 제품의 경우 시장에 나와있는 도구 중 어느 것도 제대로 작동하지 않습니다. 그러나 이것을 염두에두고 가치있는 일이있는 경우 시장에서 구할 수있는 것을 살펴볼 가치가 있습니다.

여기서 정말 중요한 한 가지 중요한 차이점은 바로 테스터가 단순히 검사 를 수행하고 있습니까 , 아니면 테스트 중 입니까?

Michael Bolton 이 작성한 이 블로그 게시물은 더 잘 설명하지만 본질적으로 행동을 확인하려고하거나 시스템 문제를 찾고 있습니까?

나는 그것이 고려하는 것도 유용하다고 생각 애자 테스트 쿼드런트을 당신이 애자일 개발 방법론을 따르지 않는 경우에도, 나는 생각 : (브라이언 마릭 원래 이러한 설명하지만 리사 크리스핀과 자넷 그레고리의 '애자 테스트 "책에서 그들을 통해 온 제품을 비판하는 테스트와 팀을 지원하는 테스트 간의 구별은 자동화를 고려할 때 누가 무엇을하고 왜 무엇을하는지에 대한 계획을 개발할 때 실제로 가치가 있습니다.

예를 들어, 개발자가 작성한 단위 검사는 변경 탐지기 역할을하여 정기적으로 재실행 할 때 조기에 회귀를 포착 할 수 있습니다. 이는 팀을 지원하는 테스트입니다. 정기적으로 신속하게 재실행 할 수 있도록 자동화 된 시스템 레벨 회귀 검사는 회귀를 조기에 포착하여 팀을 지원하고 개발자가 수행 한 단위 테스트를 보완합니다. 이를 통해 테스터가 제품을 평가하는 테스트 (예 : 탐색 테스트)를 수행 할 시간을 확보 할 수 있습니다. 또는 자동화 검사 중 일부를 적용하여 제품 스트레스 테스트를 수행 할 수도 있습니다.

내가 연결 한 Lisa Crispin 프레젠테이션에 대해 내가 정말로 좋아하는 다른 점은 자동화가 수동 테스트를 지원하는 데 사용될 수 있다는 것입니다. 테스트 데이터 생성, 현재 초점을 맞추고 자하는 시점까지 시나리오를 얻는 데 사용되는 자동화 예.

이 두 기사를 고려하면 어떤 종류의 테스트를 원하는지 분석하고 자동화에 적합한 것을 쉽게 선택하고 테스터가 수행하기에 더 적합한 자동화 비트를 파악하는 데 도움이 될 것입니다. 개발자에 의해.