[분석] 소프트웨어 테스트 케이스(TC) 작성 전 요구사항 문서 보는 방법 공유!!

오프닝: QA나 테스트 엔지니어도 개발자다

우리가 알고 있는 소프트웨어 개발자라고 하면 보통 코더, 프로그래머라고 생각하고 있을 거로 생각합니다. 하지만 이것은 잘못된 의미입니다. 기획자도 QA도 PM도 PO도 모두 개발자라는 사실을 알고 계셨나요?

 

'소프트웨어 개발'의 정의를 구글 AI에게 물어봤습니다.

소프트웨어를 기획, 설계, 구현, 테스트, 배포, 유지보수하는 일련의 과정입니다. 
즉, 컴퓨터가 특정 작업을 수행하도록 지시하는 프로그램을 만들고, 관리하는 것을 의미합니다.

 

'소프트웨어 개발자'의 정의를 구글 AI에게 물어봤습니다.

소프트웨어 개발자는 소프트웨어를 설계, 개발, 테스트, 유지보수하는 일을 하는 사람을 말합니다. 
즉, 컴퓨터 프로그램이나 애플리케이션을 만드는 전문가를 의미합니다.

 

공통으로 의미하는 것은 소프트웨어 개발 작업에 종사하는 사람을 소프트웨어 개발자라고 하는 것입니다. 그래서 좁게는 설계와 코딩을 하는 프로그래머를 의미하고, 넓게는 프로젝트를 관리하고 관련 업무를 수행하는 사람을 포함한다고 할 수 있습니다.

 

프로젝트를 수행하기 위해서는 보통 PM(Project Manager), PO(Project Owner), 기획자(Planner), 백엔드(Back-end), 프론트엔드(Front-end), 큐에이(QA or Tester) 등의 조직으로 구성되어 있습니다. 인원수는 프로젝트의 크기에 따라 다르고요. 그래서 위에서 얘기하는 정의에 따르면 QA 업무를 수행하는 사람도 '소프트웨어 개발자'라고 할 수 있는 것입니다.

프로젝트에 참여하는 모든 사람이 개발자다

 

이 이야기를 하는 이유 중 가장 중요한 것은 소프트웨어를 출시한다는 것의 책임을 누구 하나에게 지정하기 어렵다는 것입니다. 프로젝트를 수행하는 모든 인원이 개발자이기 때문에 간혹 "개발을 어떻게 한 거야?", "개발자 누구야?" 등등의 어휘는 맞지 않는다는 것이죠. 하지만 우리는 무의식적으로 알고 있습니다. 개발을 어떻게 한 거냐고 물으신다면 특정, 백엔드나 프론트엔드 개발자를 찾을 것이고, 테스트라는 용어가 보인다면 바로 QA나 테스트 엔지니어를 찾게 될 것입니다.

 

모두가 개발자의 의미를 명확히 알고 얘기하면 아무런 문제가 되지 않겠지만, 용어를 꼭 맞춰야 하는 것은 아니기 때문에 우리는 무의식적 의미를 나름의 해석으로 프로젝트를 수행하고 있습니다. 여기서 문제는 소프트웨어 잘 만들기 위해서는 생각의 맞춤이 매우 중요하기 때문에 용어 하나로 파생될 수 있는 다른 의미들은 최소화하는 것이 매우 중요합니다.

 

매우 보편적인 '개발'과 '개발자'의 의미도 다른 것과 같이 의미를 명확히 알고 사용할 때 생각의 차이를 조금이나마 줄일 수 있다는 것을 잘 알고 있어야 합니다. 구두로 맞추기 어려울 때는 문서를 통해 맞추기도 하고, 미디어(이미지, 동영상 등)를 이용해 생각을 맞추기 위해 노력을 해야 합니다.

작은 커뮤니케이션의 오류가 큰 이슈로 다가올 수 있다

 

이것은 향후 소프트웨어의 품질과도 직결될 수 있습니다. 초기 품질에 대한 중요성을 궁금해하는 경우가 있는데 저는 개인적으로 요구사항 리뷰나 기획서 리뷰보다 구성원들이 사용하는 용어를 맞추는 것이 초기 품질을 높일 수 있는 가장 중요한 요소라고 생각합니다. 

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

 

테스트를 위한 요구사항 문서를 보는 방법은?

QA와 테스트 엔지니어가 보게 되는 요구사항 문서를 기준으로 말씀드리겠습니다. 요구사항에 관심이 있으시다면 '요구사항 정의서'에 대해서 공부해보시길 바랍니다.

 

요구사항을 분석해서 최종적으로 만들어야 하는 산출물에 대한 정보를 담은 문서가 바로 기획서입니다. 명확한 정의는 '목표를 달성하기 위해서 구체적인 계획을 작성한 정제되지 않은 문서 혹은 자료'라고 할 수 있습니다. 그래서 기획서만을 봐서는 우리가 원하는 '테스트 케이스(Test Case)를 작성할 수 없습니다. 그러면 우리는 어떤 문서를 봐야 할까요?

요구사항을 포함한 문서를 잘 분석해서 TC 작성을 고민해야 한다

 

QA나 테스트 엔지니어가 봐야 하는 문서는 화면 설계서, 스토리보드가 대표적입니다. 이것은 폭포수와 애자일 방법론을 활용하는 조직에서 약간의 차이가 있습니다. 폭포수 방법론으로 프로젝트를 개발하는 조직은 최종 산출물에 화면 설계서나 스토리보드가 필수 산출물이기 때문에 무조건 작성해야 합니다. 고객이나 현업이 있다면 반드시 제출해야 하는 문서이기도 합니다. 제가 경험했던 회사에서는 화면 설계서나 스토리보드를 .ppt로 작성하는 것이 보통이었습니다. 조금 더 예전에는 .docx로 작성하기도 했었고, 공공기관에서는 아직도 .hwp 파일에 작성하기도 합니다.

 

애자일 방법론으로 프로젝트를 개발하는 스타트업 같은 경우, 조금 예전에는 엑슈어(Axure)라는 도구를 활용하기도 했고, 노션(Notion)을 활용하기도 했던 것 같습니다. 하지만 현재는 거의 피그마라는 디자인 도구를 통해 '디자인+화면 설계'를 포함하는 문서가 트랜드로 대부분 활용하고 있다고 보시면 됩니다.

[Sample] Figma를 활용한 디자인 + 화면 설계

 

기존 화면 설계서나 스토리보드를 작성하면 디자인적인 요소는 포함되지 않았으나 (3) 번과 같이 피그마를 활용한 화면 설계서에는 디자인적인 요소도 포함하게 됩니다. 여기서 중요한 것은 UI/UX 관련된 부분은 디자이너가 테스트(확인, Validation) 해야 하고, QA나 테스트 엔지니어는 문서에서 기능/성능적인 부분을 테스트 케이스화 해야 하는 것입니다.

 

이전 섹션에서 잠깐 언급했듯이 기능적인 부분에 문제가 발생하면 사용자는 매우 큰 불만족을 느끼기 때문에 최대한 기능적인 부분을 테스트 케이스화 해야 합니다. 이전 섹션을 읽어보지 않으신 분들은 아래 링크 참고해 주세요.

 

[준비] 쉽게 작성하고 빠르게 수행할 수 있는 테스트 케이스(TC) 작성하는 방법 공유!!

 

필자의 경우 테스트 케이스 작성 시 첫 번째 케이스는 UI/UX 확인 케이스를 작성하곤 합니다. 다만, 디자인적인 상세 요소(1 pixel, layout, margin 등)는 아니며 화면 설계적으로 확인이 필요한 컴포넌트의 구성이나 팝업의 문구 등을 확인 포인트로 작성하는 것이죠. 혹은 해당 페이지에 접근했을 때 UI 깨짐 등이 발생하지 않는지에 대한 최소한의 확인 포인트를 작성합니다.

 

1번 케이스에는 UI/UX 적인 요소를 작성하고, 2번 케이스부터는 1번에서 작성한 UI 요소에 대해서 기능적으로 확인하는 케이스를 나열합니다. 간단하게 정리하면 아래와 같은 내용으로 테스트 케이스를 작성하고 있습니다.

No.	Division	Step	Expected Result
TC-001	UI/UX	로그인 페이지를 확인한다.	로그인 페이지가 표시된다. - Title: "Log In" - Input Fields: Email address | Password - Placeholder Text: Email address | Password - Button: Log In - Link Button: Forgot password? | Sign up
TC-002	Function	Email address를 입력한다.	Email address가 입력된다. - 입력 조건: OOO(이메일 포맷 등)
TC-003	Function	Password를 입력한다.	Password가 입력된다. - 마스킹 처리 등 보안 관련 정책

 

테스트 케이스에 대한 상세 작성 방법은 다음 섹션에서 말씀드리도록 하겠습니다. 

긴 글 읽어 주셔서 감사합니다. 😁

---

관련 참고 자료 및 서비스

Android, iOS, Web 테스트해 드립니다. - 크몽

테스트케이스 작성 및 요구 검증 수행해 드립니다. - 크몽

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

실무 적용 QA 테스트 프로세스 관리 문서 패키지 - 크몽

요약 : 투잡, n잡, N잡, 크몽부업, 부업, 부수익, kmong부업, 전자책, vod, 유튜브