답변:
어쩌면 나는 구식이지만 가장 현대적인 개발 또는 절차 기술조차도 고객에게 제품을 출시하기 전에 다른 눈, 신선한 눈을 대체 할 수 없습니다.
제품이 단순히 다른 개발자를위한 API 인 경우에도 QA를 사용하여 API 사용자로 생각하여 귀하 또는 고객이 미리 생각하지 않은 테스트 / 사용 시나리오를 제공 할 수 있습니다.
제품이 사용자 인터페이스를 기반으로하는 경우 클라이언트에게 보내기 전에 다른 사람 (사용자 나 팀의 구성원이 아님)이 최종 결과를 보길 바랍니다.
QA의 임무는 응용 프로그램을 중단하는 것이며, 개발자의 업무는 중단하지 않는 것입니다. 따라서 그들은 다른 관점에서 테스트를 작성합니다. 예를 들어 개발자는 예상되는 동작이 발생하는지 확인하기 위해 테스트를 작성하고 QA는 사용자가 개발자가 결코 생각하지 않은 것을 사용자가 수행 할 때 수행되는 작업을 확인하기 위해 테스트를 작성합니다. 또한 개발자는 종종 요구 사항을 잘못 해석하고 QA 테스트는 개발자가 생각한 것과 해석이 다른 경우이를 파악한 다음 프로젝트 이해 관계자와 함께 어떤 해석이 올바른지 결정합니다. 코드를 작성한 개발자가 작성한 테스트에는 개발자가 사각 지대가 많기 때문에 종종 사각 지대가 있습니다. 예를 들어, 97 %의 시간 동안 발생하는 문제를 테스트 할 수 있지만 가장 중요한 경우는 아닙니다.
이전 고용주에서 QA의 역할은 제품을 테스트하는 것이 아니라 개발자가 QA에서 정의한 이전에 정의 된 승인 테스트와 관련하여 그들이 말한 것을 본질적으로 수행하도록 보장하는 것이 었습니다.
반면에 제품 소유자는 테스트와 전혀 관련이 없습니다. IMHO는 모든 수준의 테스트를 처리하는 것이 제품 소유자의 역할이 아닙니다.
어느 시점에서 직원에 대한 확신이 있어야합니다. 수표와 균형은 좋지만 실제로는 직원의 업무 윤리의 작은 부분만을 다루는 개발주기 내에서 해결책을 강요 할 필요는 없습니다.
완벽한 세계에서는 개발자 및 QA와의 공동 작업이 승인 테스트를 공동 작성하여 공식화하는 것을 봅니다. QA는 개발 팀과는 다른 양상을 가져야합니다. QA는 제품 초기에 파이에 손을 대고 전체주기 동안 계속 참여해야합니다. 반면에 제품 소유자는 QA를 통해 제품의 현재 상태, 위험 등을 이해하고 전체적인 방식으로 제품에 집중해야합니다. 제품을 구성하는 특정 뉘앙스가 아닙니다.
BDD의 일부는 이해 관계자들이 협력하여 수용 기준을 산출하는 3 가지 Amigos 접근법을 적용하고 있습니다. QA / Dev는 시나리오를 승인 테스트로 실행하도록 단계 코드를 작성할 수 있습니다. BDD 도구가 자동으로 실행하는 것과 동일한 승인 테스트를 수동으로 실행할 QA 값은 어디에 있습니까? QA의 부가 가치는 이러한 승인 테스트를 검증하고 스크립트 된 승인 테스트 외부에서 수동 탐색 테스트를 수행하는 것입니다. 복제는 대개 같은 결과를 낳습니다.
개발자는 요구 사항 및 사양을 다시 작성하지 않고 QA는 앱 코드를 다시 작성하지 않습니다. QA가 개발자가 승인 테스트로 실행하는 것과 동일한 스크립트 테스트를 수행하지 않아도됩니다. 이제 개발자가 QA 모자를 착용해야합니다.