개발시에는 일반적으로 테스트 할 데이터, 시나리오 및 실행 단계를 문서화하는 자체 테스트 스크립트가 있습니다. 이것이 나의 dev 테스트 계획입니다. 기능이 Test에 배치되면 테스터는 작성한 자체 테스트 스크립트를 사용하여 기능을 테스트합니다. UAT에서 비즈니스 사용자는 자신의 테스트 계획을 사용하여 테스트합니다.
돌이켜 보면 블랙 박스와 화이트 박스 테스트가 혼합 된 개발 테스트와 함께 테스터와 비즈니스 사용자가 블랙 박스 테스트에 집중하는 것이 더 나은 범위를 제공하는 것 같습니다. 그러나 다른 한편으로, 이것은 단계별로만 실행되는 (예 : 테스터가 테스트 단계에서만 실행되는 것으로 생각되는 일부 경우) 고유 한 테스트 사례를 가져오고 개발자가 누락 된 결과를 찾기 위해 발견 / 버그로 만듭니다. .
테스트 스크립트를 처음부터 통합 할 가치가 있습니까? 따라서 하나의 통합 테스트 스크립트를 사용합니까?
답변:
먼저 품질 관리는 테스트가 아닙니다. QA 부서가 전체 개발 프로세스에 참여하지 않는 경우 QA가 아닌 테스트 부서입니다. QA는 업무 수행시 품질 보증을 제공합니다. 최상의 테스트는 품질 부족을 보여 주지만 품질이 존재 함을 입증 할 수 없습니다.
가장 좋은 방법은 더 나은 적용 범위를 제공하기 때문에 각 그룹이 자체 테스트를 관리하도록하는 것입니다. 그러나 각 팀은 가능한 빨리 테스트를 시작해야합니다. 즉, 사용자가 사용할 수있는 항목이 있으면 UAT가 시작되고 테스트 대상 부분이 준비되는 즉시 테스트가 시작됩니다. 이렇게하면 별개의 테스트 사례를 찾을 수 없습니다. 이것은 종종 UAT와 테스트가 완전한 제품에서 작동 할 것으로 기대하고 부분적으로 완전한 출력을 테스트하는 훈련이 필요하기 때문에 작업 모델의 일부 재 지정을 의미 할 수 있습니다. 워크 플로가 징계되지 않고 개발자가 "완료"를 의미하지 않으면 비용이 더 많이들 수 있습니다.
품질 관리팀은 다른 품질 측정과 함께이를 감독하여 프로세스가 원하는 품질의 출력을 제공 할뿐만 아니라 적절한 효율 수준으로 제공되도록해야합니다.
편집 : 품질 관리에 대한 원래 질문 참조가 제거되었으므로 이제이 답변이 OT로 나타납니다.
처음부터 UAT를 사용합니다.
그것은 보편적 인 참조로 작용하며 그것이 잘 작동한다고 생각합니다. 더 작은 구성 요소에 대해 개발자 또는 테스터 만 사용하는 테스트 스크립트가있을 수 있지만 테스트 방향은 항상 하나의 통합 된 대상을 향합니다. 하루가 끝나면 UAT가 유일하게 계산되므로 처음에 초점을 맞출 수도 있습니다.
처음부터 UAT를 수행하면 추가 이점이 있습니다. 고객의 기대와 자신 사이의 모호성을 명확하게 해결합니다.
개발자, 테스터 및 비즈니스 사용자를위한 통합 테스트 스크립트를 사용하는 것이 좋을 것이라고 동의하지만 비용이 큰 이익이되는 곳에서 많은 노력을 기울이지 않으면 불가능합니다 .
어려운 이유는 모든 시스템의 데이터베이스 내용이 다르고 테스트는 일반적으로 데이터베이스 내용에 크게 의존하기 때문입니다. "통합 테스트"에 대한 우리의 접근 방식은 모든 시스템에 추가 테스트 데이터베이스가 있으며 해당 데이터베이스를 처음부터 새로 만드는 스크립트가 있다는 것입니다. 테스트 스크립트는 내용이 표준화 된 testdb에 대해 실행됩니다.
그것은 실제로 프로젝트에 달려 있습니다. 어떤 경우에는 결과를 논의하기 위해 만나는 통합 테스트, QA 및 UAT 팀이 큰 도움이 될 수 있습니다. 테스트 노력의 중복을 줄이고 모든 당사자가 UAT 스크립트를 통해 비즈니스 요구를 명확하게 이해하도록합니다. 반면, 프로젝트의 복잡성에 따라 비즈니스 예제를 테스트하기 전에 입력과 출력을 철저하게 QA 한 것이 더 합리적 일 수 있습니다. 자체 개발 한 시스템 개발의 경우 초기 QA는 사용자 승인 전에 반드시 필요합니다. 즉시 사용 가능한 구현의 경우 통합 테스트 팀이 가장 적합합니다.