테스트 계획은 누가 작성해야합니까?

저는 회사의 사내 개발 팀에 있으며 마케팅 팀의 요구 사항에 따라 회사의 웹 사이트를 개발합니다. 승인 테스트를 위해 사이트를 릴리스하기 전에 따라야 할 테스트 계획을 제공해야했습니다.

그러나 개발 팀은 요구 사항이 요청자로부터 온 것이기 때문에 테스트 대상, 확인 대상, 동작 방식 등 테스트 계획이 필요하지 않다고 생각합니다. 우리는 항상 이것에 대해 논쟁 중이며 개발자는 다음과 같은 것을 적어 놓는 데 시간 낭비라고 생각합니다.

1. 버튼 A를 클릭하십시오 .
2. 양식 필드 에 XYZ 를 입력하고 버튼 B를 클릭하십시오 .
3. 동작 C 가 표시되어야합니다 .

요청한 각 요구 사항 / 기능에 대해 반복해야합니다. 이것은 기본적으로 요구 사항 문서에 이미있는 내용을 나타냅니다.

우리는 프로젝트 관리를 위해 민첩한 접근 방식을 사용하고 있으며 매번 반복이 끝날 때마다 요청됩니다.

단위 및 통합 테스트 외에, 최종 사용자 승인 테스트 계획을 세우는 사람은 누구입니까? 요청자 또는 개발자 여야합니까?

미리 감사드립니다.

감사합니다
CK

테스트 계획은 개발자가 작성해서는 안됩니다. 테스트 계획의 일부는 개발자가 요구 사항을 올바르게 해석했는지 확인하는 것입니다. 개발자는 작성할 코드에 대해 테스트 계획을 효과적으로 작성할 수 없습니다. 테스트 계획은 QA를 수행 할 담당자 나 비즈니스 분석가가 작성해야합니다. 개발자가 계획을 작성해야하는 경우, 작성하려는 프로그램의 일부에 대한 계획을 작성하도록 누군가를 지정하지 마십시오.

이것은 개발자가 작성한 코드를 테스트해야하기 때문에 개발자가 작성해야하는 단위 테스트 디자인과는 다릅니다. 그러나 테스트 계획은 응용 프로그램이 예상대로 작동하는지 확인하기 위해 테스트해야하며 응용 프로그램이 효과적으로 작동하도록 응용 프로그램의 작동 방식을 모르는 사람이 수행해야합니다.

품질 보증팀은 테스트 계획을 작성하고 실행해야합니다.

테스트 계획은 기능 사양과 병렬로 작성하는 것이 이상적입니다. 기능을 테스트하는 방법에 대한 생각이 마음을 집중시키고 사양을 개선하는 방법이 놀랍습니다.

스크럼 답변 : '완료 정의'를 정의하려는 경우 테스트 계획을 빠르게 세우는 것이 항목 중 하나가됩니다. 테스트하지 않은 경우 수행 할 스토리를 다른 방법으로 설명 할 수 있습니다.

그러면 테스트 계획을 작성하는 담당자는 누구입니까? 팀

팀은 누구입니까? 제품을 실현하려는 모든 사람은 팀의 구성원이어야합니다.

따라서 귀하의 경우 테스트 계획을 작성할 수있는 사람을 귀하의 '개발 팀'에 포함 시키거나 고용 할 수 있습니다. 애자일로 전환하는 경우 개발 계획에서 테스트 계획 작성이 발생 함을 알 수 있습니다. 둘 다 같은 이야기에서 시작하여 통신을 통해 결국 동기화되고 동시에 전달됩니다. 이해 관계자가 중요하다고 생각하는 테스트 사례를 통과하기 전에 스토리를 '완료'로 선언해서는 안됩니다.

기능 테스트 계획은 기능 / 비즈니스 분석가가 작성해야합니다. 그들은 기능 분석을 작성합니다 (애자일을하고 있다고해도 분석이 있다고 가정합니다). 그래서 테스트 목적으로 따라야 할 응용 프로그램의 경로를 기록해야합니다.

그것은 당신이 일하는 방식에 전적으로 달려 있지만 내 의견으로는 개발자는 응용 프로그램을 테스트하는 방법, 그것을 테스트하는 데 사용할 데이터 등에 관한 기능적 문서를 작성해서는 안됩니다.

다음은 두 그룹 모두 행복하게, 가능성이있는 아이디어 와 애자일 방식으로 이동과 잘 맞지는 :

사용자 수락 확인을 자동화하고 스크린 캐스트하십시오.

http://pragprog.com/magazines/2009-12/automating-screencasts

당신이 겪고있는 문제의 일부처럼 들리는 것은 당신이 작성하는 테스트 계획이 매우 반복적이고 순전히 확인 적이라는 것 입니다. 솔직히 말해서, 난 전혀 당신에게있는 거 쓰기 테스트를 호출 할 것입니다 - 그냥 요구 사항을 확인 않다면, 그것의 검사 . 이를 자동화하고 스크린 캐스트하면 고객을 위해 깔끔한 데모를 정기적으로 패키지 할 수 있습니다 (매일 짧은 시간에 보낼 수도 있음). 데모를 클릭하고 테스트 계획을 여는 것보다 시청할 가능성이 높습니다. 이를 통해 작업을 시작하므로 더 빠른 피드백을 얻을 수 있기를 바랍니다 (더 민첩한 접근 방식으로 나아가는 경우 매우 중요). 구성 요소를 재사용 할 수 있으므로 워크로드가 줄어 듭니다.

또한 실제로 요구 사항을 실행하는 방법도 제공합니다. Gojko Adzic의 실행 사양을 보셨습니까? 여기를보십시오 : http://gojko.net/2010/08/04/lets-change-the-tune/ 고객에게 데모하기 위해 요구 사항을 실행 가능한 양식으로 가져 오는 방법으로 생각하는 경우 그러면 갑자기 무의미 해 보입니다.

이제 테스터 모자를 착용하면 스크린 캐스트가 시작되면 귀하 / 귀하의 이해 당사자가 적절한 테스트를 수행 할 수있게됩니다. 요구 사항을 확인하는 것이 아니라 예를 들어 다음과 같이 더 많은 피드백을 받고자하는 분야에 대한 짧은 질문이나 제안과 함께 스크린 캐스트를 제공하는 것이 좋습니다.

1) 새로운 등록 양식이 있습니다.이 스크린 캐스트를보고 어떻게 작동하는지 확인하십시오!

피드백에 대한 의견 : 고객이 잘못된 데이터를 입력 할 수 없도록하기 위해이 양식에 추가 검사를 추가했습니다. 고객이받을 때 표시되는 오류 메시지를 확인하고 싶습니다 잘못된 것을 입력하고 고객이 이해하기 쉬운 지 여부를 알려주십시오.
또한 특별한 고객 데이터 (예 : 이름이 길거나 이름이 짧거나 이름이 이상한 사람이있을 수 있음)가있는 경우 또는 우리가 생각하지 않은 다른 것, 또는 그들의 주소에 거리 이름이 없거나 이상한 것이 있습니까?) 그렇다면 몇 분 동안 시도해 볼 수 있습니까?

즉, 멋진 스크린 캐스트를 제시 한 다음 피드백을 요청하고 너무 구체적이 아닌 상태로 프레임을 구성하면 확인이 아닌 잠재적 인 문제에 대해 생각하게됩니다. 테스트 계획에서 맹목적으로 클릭하는 대신 생각 하도록하십시오 . 당신은 기본적으로 그것들을 위해 탐구 테스트 헌장 을 작성하고 있습니다. ( Agile Testing Quadrants 를 보면 Quadrant 3의 테스트가됩니다).

집을 리노베이션 해보십시오. 하청업자가 당신을 위해 무엇을했는지 확인하도록 요청하는 체크리스트를 수락 하시겠습니까? 아니면 자신의 체크리스트를 작성하고 계약자가 지정한 것을 수행했는지 확인 하시겠습니까?

답은 분명합니다. 요청자는 사양에 따라 요청한 사항이 수행되는지 확인해야합니다. 자신의 체크리스트를 가지고 앱을 테스트해야합니다. 이 목록에 대해

그러나 개발자는 자체 점검 목록을 가지고 있어야하며 앱을 처리하기 전에 적절한 내부 테스트가 수행되고 버그가 해결되었는지 확인해야합니다. UAT를 위해 끝났다. 이상적으로 개발자는 대부분의 테스트를 테스트 스크립트 형태로 자동화해야합니다. TDD를 기억하십니까? 이상적으로는 응용 프로그램의 구성 요소를 테스트하기 위해 테스트 스크립트 (이 경우 단위 테스트 사례)를 작성해야합니다. 그런 다음 통합 및 후속 회귀 테스트를 수행하기 위해 이러한 단위 테스트 사례를 결합하기 위해 테스트 스위트를 작성해야합니다.

최종 사용자 승인 테스트 계획은 일반적으로 고객을 대표하는 회사의 고객 또는 비즈니스 담당자가 작성합니다. 고객이 원하는 기능을 나타내고 QA의 통합 테스트를 보완합니다. 사용자 승인 테스트의 주요 목표 중 하나는 고객이 원하는 것으로 생각하는 QA 및 개발이 실제로 정확한지 확인하는 것이므로 QA 나 개발 모두 사용자 승인 테스트를 효과적으로 계획 할 수 없습니다.