문서요약 - 테스트 스크립트, 테스트 케이스, 테스트 시나리오의 차이 by SmartBear

제목: 테스트 스크립트, 테스트 케이스, 테스트 시나리오의 차이 이해하기(Test Scripts, Test Cases, and Test Scenarios: Understanding the Difference)

저자: SmartBear

문서유형: 웹문서

https://smartbear.com/learn/software-testing/test-scripts-test-cases-test-scenarios/

 

테스트 스크립트, 테스트 케이스, 테스트 시나리오의 세 가지 용어를 정의하고 그 차이를 설명한 자료

---

테스트 스크립트(Test Scripts)

• 가장 상세한 방식의 테스팅 문서화
• 하나의 테스트를 수행하는데 필요한 모든 액션과 데이터를 한 라인씩 기술한 것
• 통상적으로 1) 프로그램에서 특정 액션을 수행하기 위해 해당 프로그램을 어떻게 사용할지를 완전하게 기술한 ‘스텝’(예, 어떤 버튼을 어떤 순서로 누르는지)과 2) 각 스텝에서 예상되는 구체적인 ‘결과’(예, UI 상의 변화를 관찰)가 스크립트에 포함됨
  - 스텝 예: “X 버튼을 클릭한다”
  - 예상 결과 예: “윈도우가 닫힘”
• 테스터가 새로 일을 시작한 경우 해당 제품이나 비즈니스 도메인에 익숙하지 않을 수 있고 심지어 소프트웨어 테스팅에 대해서도 잘 모를 수도 있는데, 스크립트가 이런 간극을 메우는데 도움이 됨

상세한 스크립트를 사용하는데 전념하기에 앞서 아래와 같은 취약점을 고려할 필요가 있다.

• 진행 중인 소프트웨어 프로젝트는 변경이 자주 발생함(예, 페이지가 재설계 되거나 새로운 기능이 추가됨). 따라서 새 제품에 맞춰 스크립트를 업데이트 하는데 테스터가 지속적인 시간과 노력을 쏟아야 함
• 스크립트화된 테스트는 종종 어떤 특정한 것을 반복적으로 테스트 하도록 설계됨(즉, 테스트가 실행될 때 마다 매번 동일한 스텝과 동일한 데이터를 사용함). 따라서 테스트 스크립트에서 주어진 방향 밖에 놓여진 버그는 테스터가 해당 스크립트에서 벗어나지 않는 한 발견이 어려움. 스크립트화된 테스트는 숨은 버그를 찾는데 요구되는 창의성과 기술적 역량을 테스터가 사용하는 것을 항상 권장하지는 않음

테스트 케이스(Test Cases)

• 두번째로 가장 상세한 방식의 테스팅 작업 문서화는 테스트 케이스를 사용하는 것임
• 취해야 할 정확한 스텝이나 사용할 데이터에 대한 상세화 없이 테스트되어야 할 특정한 아이디어를 서술함
• 테스트 케이스 예: “판매가 상에 할인 코드가 적용될 수 있는지를 테스트 한다.” 
  테스트 케이스가 코드를 어떻게 적용하는지나 코드를 적용하는 방법이 다수 존재하는지 등에 대해서는 언급하지 않음. 따라서 이 테스트 케이스를 커버하는 실제 테스팅이 가끔 달라질 수도 있음. 정확히 어떻게 테스트 케이스의 테스트를 실현할지를 테스터가 결정하도록 유연성(융통성)이 주어짐
• 테스트 케이스의 이런 유연성이 장단점을 동시에 가짐
  - 테스터가 테스팅 및 테스트 대상 소프트웨어에 친숙한 경우(예, 무엇이 이미 테스트되었고, 무엇이 최근 프로그램에서 변경되었고, 사용자가 주로 어떻게 프로그램을 사용하는지 등에 대해 테스터가 명확하게 알고 있음), 테스터가 버그를 드러낼 가능성이 높은 방법이나 경로를 선택하게 되므로 유연성이 장점이 됨
  - 반면 어떻게 프로그램이 사용되는지, 프로그램의 최근 리스크가 뭔지, 이런 리스크들을 어떻게 평가해야 할지 등에 대해 테스터가 잘 이해하고 있지 못한 경우, 중요한 버그를 밝히기 위해 액션을 평가하는데 필요한 정보나 기량을 테스터가 가지고 있지 못할 수도 있음

테스트 시나리오(Test Scenarios)

• 가장 상세하지 않은 타입의 문서화
• 프로그램 사용 시 사용자가 마주하게 될 수도 있는 목적(an objective)을 기술한 것
• 테스트 시나리오 예: “프로그램을 닫음으로써 사용자가 성공적으로 로그아웃 할 수 있는지 테스트 한다”
• 통상적으로 테스트 시나리오는 시나리오가 만족스럽게 커버되었는지 확실히 하기 위해 몇몇 다른 방식으로 테스팅이 수행될 것을 요구함. 예를 들어, 위의 간략한 시나리오 기술을 기반으로 테스터가 메뉴 옵션을 통해 프로그램을 닫는 것을 선택할 수도 있고, 테스크 매니저를 통해 프로그램을 죽일(kill) 수도 있고, 컴퓨터를 꺼버릴 수도 있고, 또는 프로그램 메모리가 부족하거나 크래시 되는 경우 어떤 일이 발생하는지 관찰할 수도 있음
• 테스트 시나리오가 테스팅을 어떻게 실현할지에 대한 정보를 거의 주지 않으므로 테스트 시나리오를 책임진 테스터에게 최대한 많은 유연성을 제공함
• 이런 유연성이 테스트 케이스의 경우와 유사하게 장점과 취약점을 동시에 가져옴. 테스팅 기량과 도메인 지식을 갖춘 테스터라면 테스트 시나리오를 관련 있는 테스트 아이디어로 분해하고, 가장 적절한 접근 방법을 선택하고, 중요한 문제를 발견하는 테스트를 수행하는 등의 일을 쉽게 할 수 있지만, 초보자에게는 타인의 도움을 받지 않는 한 이게 어렵거나 불가능한 일이 될 수도 있음

어떤 것을 선택할 것인가?

• 테스트 시나리오, 테스트 케이스, 테스트 스크립트가 동시에 사용될 수 있으므로 테스터가 단 하나만 고를 필요는 없음
• 그룹 내 테스터들의 기량과 도메인 지식의 수준, 그리고 작업의 성격에 따라 적절한 문서 형태를 선택하여 활용