메뉴

테스트 시나리오 대 테스트 사례 : 이들의 차이점은 무엇입니까?

  • 메인
  • 수동 테스트
  • 테스트 시나리오 대 테스트 사례 : 이들의 차이점은 무엇입니까?

test scenario vs test case

문제를 제거하기 위해 도구를 사용해보십시오

테스트 시나리오 대 테스트 케이스의 차이점.

6 년전 , 중간 규모의 MNC와 함께 작업하는 동안 테스트 케이스라는 완전한 증명 문서를 준비하는 데 시간을 낭비하지 않고 테스트 시나리오를 문서화 하자고 제안했을 때 모든 머리가 짜증나게했습니다.

얼굴의 표정은 내가 그것을 제안함으로써 큰 ​​실수를 저질렀다는 것을 분명히 전달하고 있었다. 아무도 그 생각을 부인하지 않았지만 아무도 받아들이지 않았습니다. 모든 사람들은 전통을 따르는 것, 즉 테스트 케이스 문서를 작성하는 것이 더 안전 할 것이라고 느꼈습니다. 나는 논쟁 할 수 없었다.

테스트 시나리오 대 테스트 케이스

4 년 후 , 회사는 테스트 프로젝트를 받았습니다. 여기서 유일한 제약은 시간이고 유일한 기대는 완전한 증명이었습니다. 테스트.

우리는 다시 회의에 참석했고 중요한 기한을 맞추기위한 아이디어를 논의하고있었습니다. 응용 프로그램은 주로 다른 메뉴 항목을 통해 다른 보고서를 검색하고 생성하는 것입니다. 테스트 케이스를 문서화하는 것은 대부분의 시간을 잡아야했고 우리는 문서가 클라이언트에게 얼마나 많이 사용 될지 확신하지 못했습니다.

나는 테스트 시나리오를 문서화하는 것을 제안했고 어떻게 든 주저하면서 모두가 동의했습니다. 귀중한 문서화 시간을 절약하고 테스트에 활용할 수 있다는 점을 언급 할 필요가 없습니다.

학습 내용 :

테스트 케이스가 테스트 시나리오로 빠르게 대체되고 있습니까?

시간이 지남에 따라 모든 것이 변함에 따라 소프트웨어 산업과 프로세스도 많이 변했습니다.

컴퓨터 하드웨어 또는 소프트웨어에서 오류를 식별하고 제거하는 프로세스는 무엇입니까?

전통적인 폭포 과 V- 모델 민첩하고 반복적 인 모델로 대체되고 있습니다. 문서가 필요합니다 그러나 기한을 맞추고 프로세스를 쉽고 투명하게 만들기 위해 문서화 방식을 변경할 수 있습니다.

테스트 케이스 문서화는 언제 중요합니까?

  1. 클라이언트는 프로젝트의 일부와 동일한 것을 요청했습니다.
  2. 시간 제약이 없습니다 (불가능하다고 생각합니다).
  3. 테스터는 제품에 대해 더 신선하거나 알려지지 않았습니다.
  4. 회사 정책 (변경 될 수 있다고 강력하게 믿습니다).

한 가지 경험을 공유하겠습니다.

저와 제 팀은 유연한 타임 라인으로 Fortune 500 대 기업의 프로젝트를 테스트하는 데 참여했습니다. 사용 가능한 최상의 템플릿으로 테스트 사례를 문서화하고 클라이언트의 승인을 받았습니다.

빌드가 QA 팀에 출시되기 시작하면 대부분의 하루 동안 우리의 임무는 기계적으로 하루에 100 건의 테스트 사례를 따르고 통과 / 실패 결과로 문서를 업데이트하고 하루가 끝날 때 클라이언트에게 보내는 것이 었습니다. 대부분 팀원들이 불평하기 시작했습니다. 단조로운 작업 하지만 회사는 수익을 창출하고있었습니다.

그런 다음 테스트 할 새 빌드없이 하루 동안 휴식이있었습니다. 우리는 하루를 시작할 때 함께 앉아 하루 동안 무엇을 할 것인지에 대해 논의했습니다. 테스트 사례 문서를 개선하기 위해 더 많은 아이디어를 생성 하자고 제안했을 때 모든 팀원이 노력을 거부했습니다.

그들에 따르면 우리가 모든 시나리오를 다루었 기 때문에 더 이상 생각할 것이 없었습니다. 그리고 그들을 설득 상자에서 생각하고 더 많은 아이디어를 생성하십시오. 정말 힘들 었어요.

대부분의 경우 우리가 테스트 사례를 문서화하고 클라이언트가 승인 한 경우에도 인간의 마음은 우리가 우리의 일을 마쳤다고 생각하고 우리의 마음은 제품을 테스트하는 다른 방법을 생각하려는 노력을 자동으로 멈 춥니 다.

그리고 테스트 케이스 문서가 준비되면 우리는 그것을 기계적으로 따르기를 원합니다. 경력에서 몇 번이나 귀하 또는 팀원이 승인 된 테스트 케이스 문서에 추가 테스트 케이스를 제공 한 경험이 있습니까?

Windows 10에서 json 파일을 여는 방법

한 가지 더 경험 :

주간 팀 챌린지 활동 중에 우리는 애플리케이션을 발표하고 팀원들에게 테스트 시나리오를 따르도록 요청했습니다.

지각 한 응답자 나 비 응답자를 포함한 모든 팀원이 아이디어를 내놓았습니다. 왜? 각 테스트 케이스의 모든 기능 및 사전 조건 시퀀스에 대한 예상 결과를 채워야하는 공식 문서가 없었습니다. 우리는 하루에 40 개의 테스트 시나리오를 수집했고 그것은 훌륭한 경험이었습니다.

내 경험을 선호하기 위해 예를 하나 제시하고 싶습니다.

샘플 애플리케이션을 가져 와서 사용자 이름, 비밀번호, 로그인 및 취소 버튼이있는 로그인 페이지를 말합니다. 동일한 테스트 케이스를 작성하도록 요청하면 다른 옵션과 세부 사항을 결합하여 50 개 이상의 테스트 케이스를 작성하게됩니다.

단, 테스트 시나리오를 작성하는 경우 아래와 같이 10 줄만하면됩니다.

고급 시나리오 : 로그인 기능
저수준 시나리오 :

1. 애플리케이션이 실행 중인지 확인하려면
2. 로그인 페이지의 텍스트 내용을 확인하려면
3. 사용자 이름 필드를 확인하려면
4. 비밀번호 필드를 확인하려면
5. 로그인 버튼 확인 및 취소 버튼 기능

또한보십시오=> 웹 및 데스크톱 애플리케이션 테스트를위한 180 개 이상의 샘플 테스트 시나리오.

우리 모두 시간이 부족하기 때문에 테스트 시나리오는 예전 IODEX가 아닌 진통제 스프레이로 작동합니다. 그리고 여전히 효과는 동일합니다.

테이블 형식의 테스트 시나리오와 테스트 케이스의 차이점

마지막으로 테스트 시나리오와 테스트 케이스의 차이점을 요약하고 싶습니다.

테스트 케이스테스트 시나리오
그것은 무엇입니까 => 테스트 대상, 취해야 할 조치 및 예상 결과에 대한 자세한 정보를 제공하는 개념테스트 대상에 대한 한 줄 정보를 제공하는 개념입니다.
약 => 세부 사항 문서화에 관한 것입니다.세부 사항을 생각하고 논의하는 것이 더 중요합니다.
중요성 => 테스트가 외부에 있고 개발이 현장에있을 때 중요합니다. 세부 사항이 포함 된 테스트 케이스를 작성하면 개발팀과 QA 팀이 동기화하는 데 도움이됩니다.시간이 짧고 대부분의 팀원이 한 줄짜리 시나리오의 세부 정보에 동의 / 이해할 수있는 경우 중요합니다.
장점 => 모든 테스트 사례를 한 번에 문서화하는 것은 향후 1000 회의 회귀 테스트를 추적하는 데 유용합니다.
대부분의 경우 버그보고 중에 유용합니다. 테스터는 테스트 케이스 ID에 대한 참조를 제공하기 만하면되고 매분 세부 사항을 언급 할 필요가 없습니다.
차세대 소프트웨어 테스트 커뮤니티에서 선호하는 시간 절약 및 아이디어 생성 활동.
수정 및 추가는 간단하며 사람에 국한되지 않습니다.
그룹의 사람들이 특정 모듈 만 알고있는 거대한 프로젝트의 경우,이 활동은 모든 사람이 다른 모듈과 브레인 스토밍을 살펴보고 토론 할 수있는 기회를 제공합니다.
=>에 유익 완벽한 테스트 케이스 문서는 새로운 테스터의 생명선입니다.테스트 시나리오에서 애플리케이션을 분할하여 좋은 테스트 커버리지를 얻을 수 있으며 제품의 반복성과 복잡성을 줄입니다.
단점 => 테스트 대상과 테스트 방법에 대한 모든 것을 자세히 설명하는 데 더 많은 리소스가 필요하므로 시간과 비용이 많이 소요됩니다.특정 사람이 만든 경우 검토 자 또는 다른 사용자가 정확한 아이디어를 동기화하지 못할 수 있습니다. 더 많은 토론과 팀 노력이 필요합니다.

결론

테스트 사례는 소프트웨어 개발 수명주기에서 가장 중요한 부분이며 사례가 없으면 추적, 이해, 추적 및 추론하기가 어렵습니다. 그러나 Agile 시대에는 테스트 케이스가 테스트 시나리오로 빠르게 대체되고 있습니다.

공통 테스트 체크리스트 테스트 시나리오와 결합 된 각 테스트 유형 (데이터베이스 테스트, GUI 테스트, 기능 테스트 등)은 소프트웨어 테스터를위한 현대적인 포병입니다. 토론, 교육, 질문 및 연습은 확실히 최종 그래프를 변경할 수 있습니다. 당신의 생산성 버그 보고서 매트릭스도 있습니다.

평소와 같이 귀하의 생각과 질문을 환영합니다. 조율하십시오.

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

^