테스트 계획 및 작성 방법

Question

테스트 계획에서 테스트를 작성하는 가장 좋은 방법을 찾으려고 노력하고 있습니다. 특히 QA 직원을 포함한 모든 사람이 사용할 테스트를 작성할 때 테스트의 단계가 매우 구체적이거나 더 광범위해야 테스터가 작업을 수행 할 수있는 방법에 더 많은 여유를 갖게됩니다. 아주 간단한 예로서 워드 프로세싱 문서에서 문서를 여는 것을 테스트하는 경우 테스트는 다음과 같아야합니다.

1. 마우스를 사용하여 파일 메뉴를 엽니 다.
2. 파일 메뉴에서 "파일 열기 ..."를 선택합니다.
3. 표시되는 파일 열기 대화 상자에서 x로 이동하여 y라는 문서를 두 번 클릭합니다.

   또는

   1. 파일 열기 대화 상자 불러 오기
   2. 파일 열기 y

      이제 한 가지 대답이 "테스트 대상에 따라 다름"이라는 것을 알고 있지만 여기서는 더 광범위한 질문에 대답하려고합니다. 테스트 단계가 너무 구체적이면 위험을 감수해야합니다. 테스트 프로세스는 힘들고 지루하며 더 중요한 것은 b) 목표를 달성하기에는 너무 구체적인 경로를 작성했기 때문에 무언가를 놓칠 위험이 있습니까? 또는 광범위하게 만들면 당시 테스터의 변덕에 너무 많이 의존하고 고객 / 클라이언트에게 더 일반적인 경로에 대한 중요한 테스트를 잃게됩니까?

Answer 1

첫 번째 질문은 QA 부서에서 테스트 계획을 작성하지 않는 이유는 무엇입니까?일반적으로 소프트웨어 개발자는 소프트웨어의 작동 방식에 대한 기능 사양을 QA에 제공 한 다음 QA는이를 기반으로 테스트 계획을 만듭니다.

그렇게 말하면 작업이 제상 되는 방식을 자세히 설명하고 있으므로 단계를 매우 구체적으로 지정하는 것이 좋습니다.그러면 특정 단계가 원하는 결과를 얻도록하는 것이 테스터의 임무이며 계획에서 벗어나 일을 깨뜨리는 것도 그들의 임무입니다.

목표를 달성하는 데 여러 가지 방법이있는 경우 목표를 달성하기위한 각 경로를 설명해야합니다.

Answer 2

저는 테스터는 아니지만 혼동을 피하기 위해 테스트에서 취해야하는 "UI 경로"를 문서화하는 것이 중요합니다.

테스터와 동일한 UI 경로에서 기능에 액세스하지 않았기 때문에 재현 할 수없는 수많은 결함을 작업했습니다.예 :오른쪽 클릭 메뉴 vs 툴바 또는 다양한 대화 상자에서 수행 할 수있는 기능 등

Answer 3

QA 직원이 테스트 작성을 담당하지 않는 경우 실제로 QC (품질 관리) 인 것 같습니다. 실제로 테스트 작성을 담당하는 경우 테스트가 도움이되지만 명확한 사양이 테스트를 직접 작성하는 데 더 좋은 소스가 될 것입니다. 더 좋은 방법은 사양 검토 프로세스의 일부로 포함하여 테스트를 작성할 수있는 세부 정보를 요청할 수 있도록하는 것입니다.

실제로 다른 사람을위한 테스트를 작성하는 위치에 있다면 몇 가지 고려해야 할 사항이 있습니다. 다음과 같은 경우 고통스러운 수준의 세부 정보를 원할 것입니다.

• 테스트를 진행하는 사람들이 질문을 할 수 없습니다
• 테스트를 실행하는 사람들이 귀하의 제품에 익숙하지 않습니다.

  사실이 아닌 경우 일부 세부 정보를 피할 수 있습니다. 그러나 여전히 다릅니다. :)

  이 모든 내용은 일반적으로 '테스트 계획'으로 간주되는 내용이 아닙니다. 테스트 계획은 실행될 테스트 유형 (기능, 회귀, 보안 등), 테스트 할 기능, 작성해야 할 테스트, 테스트를 수행 할 사람, 테스트 그룹이있을 때 설명합니다. 계획 및 기타 계획 유형 활동.

  위에서 설명하신 내용은 단순히 일련의 테스트입니다.

Answer 4

첫 번째는 기능 테스트입니다.대상에 대한 경로가 둘 이상일 수 있으므로 UI 경로가 포함 된 세부 단계로 테스트합니다.모든 경로를 테스트하십시오.후자는 사용성 테스트처럼 들립니다.테스터뿐만 아니라 외부 사람도해야합니다.

Answer 5

테스트 계획과 테스트 스위트를 구분합시다 :)

테스트 모음은 자체 테스트 집합입니다.

테스트 계획은 Test Suite + 사용 가능한 리소스 (사람, 하드웨어, 시간 등)의 [일부]입니다.

테스트 문서에 두 가지 변형 (상세 및 "거친")이 모두 설명되어 있어도 괜찮습니다. 세부 및 "거친"테스트를 다른 문서에 배치하고 이러한 문서의 우선 순위를 지정하면됩니다.

그런 다음 제품을 완전히 테스트 할 시간이 충분하면 카테고리 A의 모든 문서를 가져와이 문서에 따라 제품을 테스트합니다.시간이 없지만 품질에 대한 빠른 결론이 필요한 경우 카테고리 B 문서를 가져와 여기에 설명 된 검사를 통과합니다.

좋은 점 : 제품 테스트 방법을 선택할 수 있습니다.

나쁜 측면 : "중복"문서가 필요합니다.

Answer 6

누군가 문제를 발견했을 때 정확하고 상세한 재현 단계를 원하는 것은 괜찮습니다. 그러나 그런 방식으로 테스트 계획을 작성하면 다음과 같은 문제가 발생할 위험이 있습니다.

1) 부주의 실명 -나는 사람들이 상세한 절차 테스트 스크립트를 실행하고 성실하게 걷는 것을 보았습니다. 모든 단계를 꼼꼼하게 기록하고 기록하며 바로 앞에있는 눈부신 오류를 완전히 누락했습니다. "스크립트에 없었기"때문입니다. 그들의주의는 모든 까다로운 테스트 단계에 너무 집중되어 문자 그대로 앞에있는 문제를 볼 수 없었습니다.

2) 매우 상세하고 구체적인 경로에서 한 발짝 떨어진 모든 버그를 놓칠 것입니다. 고객이 제품을 받으면 자세한 테스트 계획을 따르지 않습니다. 다양한 방법으로 앱을 탐색합니다. 그들은 마음을 바꿀 것입니다. 그들은 당신이 가능하거나 가능하다고 생각했던 것보다 더 길거나 짧을 것입니다. 그들은 거래의 중간을 거쳐 그것을 포기할 것입니다. 그들은 방황 할 것입니다. 그들은 한 길을 고수하지 않을 것입니다. 누군가가 테스트를 반복 할 때마다 해당 버그를 다시 놓칠 것입니다.

3) "누구나 따라갈 수있는"테스트 스크립트를 작성하기 위해 엄청나게 긴 시간을 소비하게됩니다. 저를 믿으세요, 저는 이것을 완벽하게하기 위해 수년을 보냈고, 그것은 인간적으로 가능하지 않습니다. 더 나쁜 것은이 작업에 낭비하는 시간이 다른 방식으로 훨씬 더 많은 수익을 낼 수 있다는 것입니다. 따라서 제품이 더 나빠집니다.

4) 당신은 많은 반복으로 끝날 것이고, 전체를 읽지 않고는 시험의 요점이 무엇인지 말하기가 어려울 것입니다. 놓친 사용 사례를 확인하기 위해 테스트를 빠르게 스캔하는 것은 쉽지 않습니다.

테스트 계획을 광범위하게 유지하고 테스트를 수행하는 사람들이 판단을 내릴 수 있도록합니다. 테스트해야하는 특정 사용 시나리오 또는 대상 사용자 그룹의 작동 방식에 대한 정보가있는 경우 테스트 계획과 함께 테스터에게 제공합니다. 아마도 사용자 페르소나의 형태로 사용 사례의 형태. 특정 사항을 확인해야하는 경우 체크리스트 사용을 고려하십시오. (자세한 내용은 Cem Kaner의 우수한 프레젠테이션을 참조하십시오. www.kaner.com/pdfs/ValueOfChecklists.pdf ).

또는 테스트 계획을 짧은 탐색 헌장으로 작성합니다. 예를 들어 다음과 같은 지침을 제공 할 수 있습니다. "Callcentre 사용자는 마우스가 연결되지 않은 워크 스테이션을 사용합니다. 고객을 대신하여 티켓을 올리는 프로세스를 탐색하여 키보드 단축키 만 사용하여 모든 활동을 완료 할 수 있는지 확인하십시오." 이렇게하면 테스터가 "필드 1로 탭하기"라고 말하는 것보다 결함을 발견 할 가능성이 훨씬 더 높습니다. "라인 품질에 대한 불만"을 입력합니다. 필드를 탭합니다. 2. 드롭 다운 메뉴에서 "전화 통화"를 선택합니다. ... 필드로 탭합니다. 68. "

Answer 7

일반적으로 시스템이나 컴퓨터에 대한 지식이없는 것처럼 테스터를 대하는 데 따른 장단점

자세한 내용을 입력하면 (예 : "파일 메뉴에서 '열기'선택 ...") 시스템에 익숙하지 않은 계약자를 사용할 수 있다는 이점이 있습니다. 하지만 이렇게 작성하려면 시간이 더 걸립니다.

많은 세부 사항을 건너 뛰면 (예 : "문서 파일 열기 ..."), 테스트 계획을 사용하는 사람보다 문제가 발생할 가능성이 더 높으며 설명을 방해하는 것보다 많습니다. 하지만 작성하는 것이 훨씬 빠릅니다.

성공적인 버전을 할 때 더 빨리 생각하는 것은 잘못된 경제 일 수 있으며, 결국 QA 담당자에게 시스템을 설명하는 데 추가 시간을 소비한다면

이 주제에 대해 자세히 설명하는 기사가 있습니다. 시스템 테스트 계획 작성

이 기사에서는 더 자세한 접근 방식을 선호합니다. 하지만 최근에이 두 가지 접근 방식 사이의 '중간 지점'( 기능 테스트 계획 이라고 함)을 개발하고 있지만 아직 공유 할 수있을만큼 성숙하지는 않습니다.

-LM