[팀블로그] 소프트웨어 테스팅 참고서

     

 

질문

챕터 1.2.1의 "성공을 위한 테스팅의 기여" 부분에 보면, 대표적인 예로 든 「요구사항 리뷰」를 언급했는데, 요구사항은 기획자가 리뷰하는 것이 아닌가요? 테스트를 하다가 요구사항 리뷰도 할 수 있나요? 

 

 

ISTQB 버전

ISTQB Syllabus 2018

 

 

답변

본 글은 2개로 나누어 구성하였습니다. 현재 보고 계시는 글은 기본 이해 편으로 요구사항과 테스트와의 관계에 대한 기본적인 이해를 하기 위한 글입니다. 2번째 실무 이야기편에서는 요구사항과 테스트와의 관계에 대한 한 단계 업그레이드된 이야기에 대해 설명하고 있으니 해당 부분도 함께 참고하여 주세요.

 

요구사항 리뷰가 뭔가요?

 요구사항 리뷰와 테스트와의 관계를 설명하려면 그에 앞서 「요구사항은 무엇인가?」라는 질문에 대한 답부터 찾아야 합니다. 몇 가지 나름대로 공신력 있는 자료들을 찾아보겠습니다.

 

1. ISTQB Glossary에서 말하는 "요구사항(requirement)"이라는 구분을 그대로 옮기고 번역하면 아래와 같습니다.

 

A provision that contains criteria to be fulfilled.

충족시켜야 할 기준이 포함된 조항

 

2. Wikipedia에서는 요구사항에 대해 다음과 같이 표현하고 있습니다.

 

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy.

제품 개발과 프로세스 최적화에서 요구사항이란, 특정 설계/제품/프로세스가 충족하고자 하는 단 하나의 문서화된 물리적 또는 기능적 필요이다.

 

3. PMP(Project Management Professional)에서 말는 요구사항이라는 단어의 정의는 다음과 같습니다.

 

requirement is “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”

요구 사항은 "계약 또는 기타 공식적으로 부과된 사양을 충족하기 위해 제품, 서비스 또는 결과에 존재해야 하는 조건 또는 능력"입니다. 

 

 

위 내용들에 따라 요구사항이란 제품이(혹은 프로세스가) 갖춰야 할 항목들에 대한 조항을 모아 놓은 것이라고 할 수 있으며, 문서나 디자인과 같은 형태로 존재한다고 정의할 수 있습니다.

 

요구사항과 관련된 여러 용어 설명들을 보다 보니 '요구사항(requirement)'이란 용어는 소프트웨어에서만 사용하는 게 아닌 거 같습니다. 그래서 「소프트웨어에서의 요구사항(software requirement)」이란 무엇인가에 대해 짚어볼까 합니다.

 

소프트웨어 요구사항에 대한 위키피디아의 정의는 아래와 같습니다.

 

The requirement for a system is the description of what the system should do, the service or services that it provides, and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:
  1. A condition or capability needed by a user to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or another formally imposed document.
  3. A documented representation of a condition or capability as in 1 or 2.

시스템 요구사항이란 시스템이 수행해야 하는 작업 및 제공하는 서비스를 말하며, 이에는 작동에 대한 제한 사항을 포함하여 제공합니다. IEEE 표준 소프트웨어 엔지니어링 용어집에는 '요구사항'에 대해 다음과 같이 정의합니다.
  1. 문제를 해결하거나 목표를 달성하기 위해 사용자가 필요로하는 조건 혹은 능력
  2. 계약, 표준, 세부사양, 또는 기타 공식적으로 부과된 문서의 조건을 충족하기 위해 시스템과 그 구성요소가 보유해야만 하는 조건 혹은 기능
  3. 위 1과 2를 만족하는 조건 혹은 기능에 대한 문서화된 표현

 

 위를 단순하게 말하자면, 우리가 만들고자 하는 소프트웨어에 대한 요구를 문서화하여 기술한 내용을말합니다. 그 소프트웨어가 어떤 동작을 해야 할지에 대한 설명이 있는 문서나 디자인과 같은 형태로 존재하게 됩니다. 

 

Software Engineering Body of Knowledge에는 소프트웨어 요구사항에 대해 다음과 같이 표현하고 있습니다.

 

a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. 

소프트웨어 요구사항은 현실 세계에서 어떤 문제를 해결하기 위해 무언가가 나타내야 하는 속성입니다. 조직의 비즈니스 프로세스를 지원하거나, 기존 소프트웨어의 단점을 수정하거나, 장치를 제어하기 위해 누군가가 작업의 일부를 자동화하는 것을 목표로 할 수 있습니다.

 

 위 내용을 단순화 시켜보자면, "현실에 어떤 문제가 있고, 그 문제를 해결하기 위한 해결책의 속성 목록"이라 할 수 있습니다.

 

 지금까지 "요구사항이란 무엇인가", "소프트웨어 요구사항이란 무엇인가"를 살펴보았는데, 우리가 흔히 실무에서 사용하는 의미와는 좀 많이 다릅니다. 여기에서 우리는 한 가지 인정하고 넘어가야 하는 부분이 있습니다. 우리 모두는 흔히 실무에서 너무 쉽고 당연하게 '요구사항'이라는 단어를 사용하고, 실무를 수행하고 있다고 착각하고 살고 있습니다. 하지만, 사실 요구사항 수집 / 분석 / 관리 / 리뷰 등과 관련된 내용은 (테스팅이 소프트웨어 공학 내에서 별도의 학문으로 분류될 정도로 큰 축을 차지함) 소프트웨어 공학 내 '별도의 학문 영역'으로 나뉘어 있는 아주 깊이 있는 내용이며, 검색 엔진에서 Requirement Engineering이라는 키워드로 전문성 있는 자료들을 쉽게 찾아보실 수 있습니다. 요구 공학과 관련하여 좋은 한글 서적으로는 아래의 도서가 있으므로 관심이 있으신 분들은 참고하시기 바랍니다.

 

 

소프트웨어 요구사항 3

요구공학의 고전『Software Requirements』의 세 번째 판이다. 요구사항 관례 개선을 위해 현장에서 실질적으로 도움이 되는 입증된 기법들을 설명한다. 효율적인 요구공학 방법을 적용한 수십 개의

www.aladin.co.kr

 

 이런 중요한 요구사항과 관련된 실무는 왜 꼭 해야 할까요? 어렵지는 않을까요? 누가 해야 하는 걸까요? 와 같은 질문에 대한 궁금증은 요구사항 관련 실무 이야기 편에서 알아보세요

 

 그럼 이제 리뷰란 무엇일까요? 필자들이 풀이하고 있는 ISTQB의 용어 사전인 Glossary에서는 "리뷰(Review)"라는 용어를 아래와 같이 정의하고 있습니다. 

 

A type of static testing in which a work product or process is evaluated by one or more individuals to detect defects or to provide improvements.

정적 테스팅 방식 중 하나로 한 명 이상이 결함을 찾거나 개선을 하기 위해 산출물이나 프로세스를 평가하는 작업이나 프로세스이다.

 

wikipedia에는 Software Review에 대해 다음과 같이 설명합니다.

 

A software review is "a process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval"

소프트웨어 Review란 "프로젝트 담당자, 관리자, 사용자, 고객, 사용자 대표 또는 기타 이해 당사자가 소프트웨어 제품을 검토하는 프로세스 또는 회의"를 말한다.

 

이 외에도 여러 가지 표준에 각 표준을 위한 "리뷰 활동"이 정의되어 있고, 그에 대한 용어들이 각기 다르게 정의되어 있습니다만, 일반적으로 내용은 거의 대동소이합니다. 위 사항들을 종합해보자면 「리뷰라는 활동은 관련자들이 모여 산출물인 문서나 소스 코드 등을 검토하여 결함을 찾거나 개선을 하는 활동이라고 정의할 수 있습니다. 따라서 소프트웨어가 어떻게 동작하는지에 대한 설명을 적어놓은 요구사항을 관계자들이 모여 다양한 방법을 통해 검토하는 활동을 요구사항 리뷰라고 정의할 수 있습니다. 

 

아래는 소프트웨어 리뷰를 다루는 몇 가지 국제 표준 등을 소개합니다.

• ISO/IEC 23396:2020 Systems and software engineering — Capabilities of review tools에서는 소프트웨어 평가 특성을 정의하는 리뷰 방법에 대해 정의합니다.
 ISO/IEC 20246:2017 Software and systems engineering — Work product reviews에서는 시스템 및 소프트웨어의 관리, 개발, 테스트 및 유지보수에 관련된 모든 조직에서 참조하고 사용할 수 있는 작업 산출물 검토를 위한 일반 프레임워크를 소개합니다.
 IEEE 1028-2008 IEEE Standard for Software Reviews and Audits에서는 소프트웨어 리뷰 및 감사 활동에 대한 일반적인 정의가 소개되어 있습니다.
그 외에도 여러 기업의 SDLC(Software Development Life-cycle)에는 모두 Review 활동이 포함되어 있습니다. 여러 기업들의 SDLC를 찾아보고 심도 있게 공부해 보는 것도 Review를 알아가는데에 많은 도움이 됩니다.

 

 

이제부터는 테스트를 진행하면서 발생할 있는 상황에 대해  요구사항과 테스트가 어떤 관계를 가지고 있는지 알아보려 합니다. 

📣 필자 주 - ISTQB에서 설명하는 리뷰에는 다양한 종류와 방법이 있지만, 본 글에서는 해당 내용에 대한 설명이 아니라 테스트와 관련된 일을 하면서 발생할 법한 상황들에 대한 이야기를 하고자 합니다. 

 

일관되지 않은 사항에 대한 테스트 예

아래는 개발하려는 app의 요구사항 내용 중 일부라고 가정해 봅니다. (필자가 상정한 가정입니다.)

 

[OO WEB 개발 프로젝트]
.....
◈ 회원정보 관리 페이지
 1. password의 최대 길이는 영문기준 30
.....
◈ 회원 가입 페이지
 1. password의 최대 입력 가능한 글자수는 영문기준 20
.....

 

 요구사항을 바탕으로 이제 테스트를 진행하려고 합니다. 회원 가입하는 페이지에서는 입력을 20자로 생성한 password가 회원정보 관리 페이지 내에서는 30자까지 변경이 가능해집니다. 회원 가입 시 실제 입력 가능한 글자 수가 20자를 넘지 못하는 상황에서 회원 관리 페이지의 최대 30자 지원은 다양한 문제를 만들어낼 가능성이 존재하게 합니다. 

 

 하지만 회원 관리 페이지의 password 최대 길이가 30자인 것이 20자의 오타일 수도 있고, 회원 가입 페이지의 20자가 오타일 수도 있고, 알지만 의도한 부분일 수도 있습니다. 이와 같은 상황에서는 의도한 부분보다는 실수일 가능성이 높습니다만, 어느 부분이 잘못되어 있는지는 알 수 없기에 해당 사항에 대한 확인이 반드시 필요합니다. 

 

(1) 단순한 오타라면 최대 길이 지원을 몇 까지 할 것인지 다시 확인한 후 정리하면 됩니다.

(2) 특별한 이유가 있다면 해당 테스트 케이스에 설명을 남겨두어 기록해 놓거나, 해당 상황으로 인해 발생할 수 있는 문제점에 대한 테스트를 고민해야 합니다. 

 

📣 필자 주 - 리뷰를 하는 사람들도 놓치는 부분이 있을 수가 있는데, 테스트하는 분들이 이런 사소한 것 같지만 일관되지 않은 사항을 발견할 가능성이 높다고 생각합니다. 

 

명확하지 않은 사항에 대한 테스트 예

아래는 개발하려는 app의 요구사항의 내용 중 일부라고 가정해 봅시다. (역시나 필자의 가정입니다)

 

[OO App 개발 프로젝트]
....
◈ 검색 결과
 1. 검색 결과가 없는 경우 안내 문구 제공
 2. 검색 결과가 있을 경우
  <UI 설명>
 3. 검색 결과가 11개 이상일 경우는 페이지로 분할하여 표시
 4. 검색 결과는 빠르게 표시되어야 함
.....

이번 예시에서 눈여겨봐야 할 부분은 "4. 검색 결과는 빠르게 표시되어야 함"입니다.

 

 "빠르게"는 사람마다 다르게 느낄 수 있습니다. 어떤 사람은 1초 이내면 빠르다고 느낄 수 있고, 어떤 사람은 0.5초 이내여야 빠르다고 느낄 수도 있습니다. 이처럼 모호한 단어가 사용되는 경우에는 테스트 기준도 명확하지 않아 테스트를 하기가 힘든 상황이 됩니다. 테스트를 하려면 "검색 결과는 최대 X초를 넘지 않아야 함"처럼 기준이 있어야 합니다. 그럼 "X초"라는 시간을 어떻게 정해야 할까요? 내가 느끼는 시간만을 기준으로 잡기에는 너무 주관적인 부분이라 역시나 담당자에게 확인을 요청해야 할 것입니다. 요청하기에 앞서 관련된 자료가 있는지 한 번 볼까요?

 

 

. 반응 속도에 대한 3가지 기준


제이콥 닐슨(Jakob Nielsen)이 1994년도 발간한 "Usability Engineering"에 따르면, 반응속도에 대한 3가지 기준을 제시합니다. 

 

  • 0.1 초 - 유저가 시스템이 즉각적으로 반응한다고 느끼는 시간
  • 1 초 - 유저가 약간의 지연이 있다고 느끼지만 문제 되지 않을 정도의 시간
  • 10 초 - 유저의 주위를 끄는 최대 시간으로 이 이상 지연될 경우 다른 작업을 하므로, 기다리는 동안 피드백이 필요함

 

📣 필자 주 - 위는 워낙 오래된 자료라 2021년, 5G 시대의 모바일을 기준으로 하면 이제는 '10초'는 너무 오랜 기다림이지 않을까 생각이 들지만, 이를 제외하고는 의미가 있어 보이는 수치입니다. 

 

 

. 모바일 페이지 로딩 속도와 이탈률의 관계


모바일 페이지 로딩 속도에 따른 이탈률에 대한 구글의 자료가 있습니다.  

이탈율 : 구글 자료

 

로딩 시간이 오래 걸릴수록 비례하여 이탈률 수치가 커지는 것을 보여주고 있습니다.

 

 

. 로딩 속도와 매출 손실의 관계

 

실제 현장에서 발생한 매출 감소 자료도 있습니다. 

속도와 매출관계 사례

 

구글에서 자료를 찾아보면 로딩 속도 100ms 지연마다 1% 매출 손실이 있다고 하는 등의 로딩 속도에 대한 매출 영향의 실제 데이터들이 존재합니다.

 

한국은 워낙 인터넷 속도가 빠르다보니 응답속도를 별거 아닌 것 취급하며 쉽게 생각하지만 위와 같은 사례들을 보면 응답속도는 사업에 대단히 중요한 영향을 미치는 요소임을 알 수 있습니다. 이런 사례들을 바탕으로 "이 서비스는 응답속도가 x초 정도는 되어야 하지 않을까"라고 제안을 해볼 수도 있고, 적어도 이 상황에 대해 알리고 해결방안을 찾아야 할 것입니다. 

 

중요한 건 리뷰를 통해 제안을 해야 한다는 것이 아니라, 리뷰라는 테스트 활동을 통해 초기 설계, 기획, 요구사항 등에 잠재적 문제가 있음을 알리고 보완하도록 기회를 갖는 것입니다. 

 

📣 필자 주 - 모호한 표현을 정확하게 수치로 변환하는 것은 단순한 일이 아니기에 이런 자료를 바탕으로 제안하는 것이 더 좋을 것입니다. 스펙은 테스터의 영역이 아니긴 하지만 이런 자료와 테스터들의 경험을 바탕으로 제안을 한다면 조금 더 나은 결과를 도출할 수 있을 것이라 생각합니다. 

 

 

디테일이 부족한 사항에 대한 테스트 예

아래는 개발하려는 또 다른 app의 요구사항 내용 중 일부라고 해 봅시다. (역시나 필자의 가정입니다)

 

[OO App 개발 프로젝트]
.....
◈ 비밀번호 생성
 1. 비밀번호는 숫자로만 구성된 6자리만 설정 가능
.....
◈ 비밀번호 입력 화면
 1. 암호 입력 키패드 표시
◈ 결제 화면
.....

 위의 요구사항만을 가지고 개발할 경우에는 암호를 입력하는 키패드를 어떤 것으로 해야 할지가 정의되어 있지 않아 개발자 역량에 따라 구현될 가능성이 높습니다.

 

keypad 비교

 

 개발자가 비밀번호는 숫자로만 가능한지 아닌지에 대한 사전 조건을 파악하고, 이런 상황에는 qwerty보다는 숫자 키패드가 더 편리하고 오입력을 막아줄 수 있으니 숫자 키패드로 만들어야겠다며 숫자 키패드로 개발하는 것은 어려운 일입니다. 비밀번호에 대한 테스트도 하는 테스터들이라면, 키패드가 숫자패드로 해도 충분하다는 것을 자연스럽게 하게 될 것입니다. 따라서 다른 사람들보다 요구사항의 부족한 디테일을 보완해 줄 수 있는 가능성이 높습니다. 

 

 

마무리

 요구사항 관리, 리뷰 활동에 대해서는 글의 초반에 언급한 바와 같이 '요구공학(Requirement Engineering)'이라는 분야가 따로 있을 정도로 넓고 깊은 지식이 존재합니다. 그래서 이번 편에서 필자들은 테스트를 수행하거나 준비를 하면서 만날 법한 상황을 가정해서 쓴 예들을 제공하였습니다.

 

 요구사항이 테스트 전 단계에서 모두 완벽하게 정리되면 좋겠지만, 현실적으로 힘들고, 요구사항은 계속 변경되고, 누군가 회사에서 중요한 직책을 맡은 한 사람의 한 마디에 의해 뒤집힐 수 있습니다. 프로젝트에 참여한 많은 사람들이 다양한 관점을 통해 요구사항을 수집하는 단계에서 놓친 부분을 발견해서 수정하고, 애매한 사항에 대해 같이 고민해보고, 테스터의 경험을 살려 아이디어를 제공하는 것이 리뷰입니다. 요구사항 리뷰에는 다양한 기법이나 과정들을 통해 하는 방법도 있지만, 그런 것을 잘 알지 못하거나 하지 않아도 예제들과 같은 상황에서 문제점을 확인하고 보완하는 과정을 거친다면 그게 바로 테스트를 하면서도 요구사항을 리뷰하게 되는 실전이 되어, 리뷰의 원래 목적인 요구사항을 보완하는데 도움을 줄 수 있게 됩니다. 

 

 테스트 전문가 여러분! 여러분들이 어제 했던, 오늘 하고 있는 업무들이 결과적으로는 요구사항 리뷰가 될 수 있습니다. 그리고 이를 기반으로 여러분들이 하는 활동들이 품질향상의 밑거름이 될 수 있습니다. 그러므로, 남이 지금 당장 알아봐 주지 않는다고 주눅 들지 말고 열심히, 하루하루의 테스트 업무를 수행하십시오. 그렇게 쌓인 데이터는 언젠가 테스트를 넘어서 QA수준의 업무로 향상될 걸로 (필자들은 강력히) 믿습니다, 그리고 여러분들을 지지하고 있습니다. 

 

오늘도 여러분의 슬기로운 테스터 생활을 응원합니다!

 

 

참여자 정보

글쓴이 : Bykj천년나무

• 검토한이 : 품생품사, 아이티마니, 창자로줄넘기

 

 

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다. 개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

 

 

관련 참고자료

※ 아래는 필자들이 선정한 관련 외부 자료입니다. 
아래 자료들은 필자들이 작성한 본문 의견과 다를 수 있으며, 필자들과 관련되지 않았을 수 있습니다.
 

ISTQB Glossary

 

glossary.istqb.org

 

TTA정보통신용어사전

한국정보통신기술협회(TTA)는 정보통신 기술 발전과 타 분야와의 기술 융합에 따라 무수히 생성되는 정보통신용어를 해설하고 표준화하여, 전문가뿐만 아니라 비전문가들도 올바르게 활용할 수

word.tta.or.kr

 

An Introduction to Perceived Performance | Treehouse Blog

Learn about perceived performance and how you can optimise your site to make it feel faster to users.

blog.teamtreehouse.com

 

Response Time Limits: Article by Jakob Nielsen

How users react to delays in a user interface, whether website or application. The 3 main response time limits are determined by human perceptual abilities.

www.nngroup.com

 

Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed

It's critical that marketers design fast mobile web experiences. New research shows how various sectors are performing when it comes to mobile page speed.

www.thinkwithgoogle.com

 

How to do a Requirements Review from a BA Perspective | ReQtest

Requirements review - Ulf Eriksson describes the techniques needed to do a requirements review from a business analyst's perspective.

reqtest.com

 

Requirements engineering - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search Defining and maintaining requirements in systems engineering Requirements engineering (RE)[1] is the process of defining, documenting, and maintaining requirements[2] in the engineerin

en.wikipedia.org

 

Requirement Engineering(요구 공학)

Requirements Engineering(RE) 약어 RE: Requirements Engineering (요구공학) RM: Requirement...

blog.naver.com

 

Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine

1 Introduction In this paper, we identify politics and power as crucial components of requirements engineering (RE) and argue that the role it plays, especially…

re-magazine.ireb.org

 

A history of the international requirements engineering conference (RE)RE@21

This paper traces the history of the International Requirements Engineering Conference from its beginnings as the International Symposium on Requirements Engineering and the International Conference on Requirements Engineering. The history is tracked to th

ieeexplore.ieee.org

 

ISTQB Glossary

 

glossary.istqb.org

 

Software review - Wikipedia

A software review is "a process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".[1] In this context, the term "software pr

en.wikipedia.org

 

Software requirements - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search The requirement for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary

en.wikipedia.org

 

Requirement - Wikipedia

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for exa

en.wikipedia.org

 

IEEE SA - IEEE 1028-2008

No Inactive-Withdrawn Standards No Inactive-Reserved Standards

standards.ieee.org

 

ISO/IEC 20246:2017

Software and systems engineering — Work product reviews

www.iso.org

 

ISO/IEC 23396:2020

Systems and software engineering — Capabilities of review tools

www.iso.org

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band